问题：PDF 结构丢失、段落断裂、表格识别错误、图像关联中断。
解决方案：文档结构化解析（Document Normalization），多模态解析。
文字/图像/表格之间的关联关系丢失
表格 + 解释性文本 绑定为一个 chunk
图像 + caption + 引用段落 绑定为一个 multimodal block
采用 多模态 embedding（CLIP / siglip / Voyage-multimodal）
Chunk 边界断裂（Chunking 不感知结构）
滑动窗口分块
表格、图像不切碎，保持单独 chunk
基于标题层级/段落
多文档版本混乱（旧版手册与新版矛盾）
多语言文档混合（中英并存）
专业领域知识
data = {
'name': 'blue',
'age': 18
}
try:
name = data['name']
except KeyError:
name = 'default'
列表作为python中使用最常见的一种数据类型，同样也是最方便实现队列的数据结构。尽管这不是最高效的解决方案 ，但是可能是最便捷的实现方案。
列表提供了append()方法用于在尾部添加元素（相当于队列的入队操作），以及pop(0)方法来移除并返回列表的第一个元素（相当于队列的出队操作）。
list.append()方法在列表的末尾添加元素。这对应于队列中新元素的加入，遵循先进先出的原则。list.pop(0)来模拟。这种方法虽然实现了功能，但是效率低下，特别是当队列很大时，因为每次出队操作都需要移动后续的所有元素。之前在学习airflow时发现，airflow中大量使用多进程来实现任务的运行，所以还是比较奇怪为什么它会选择多进程呢？所以查询了很多的资料来学习下关于python多进程。
Debug，是程序开发人员必会的一项调试程序的技能。可以说如果你不会调试程序，你就没有办法从事编程工作。那么debug可以帮助我们做什么呢？
其实可以总结出来一点就是调测功能。我自己在开发一个工作流的框架，其中就需要用到debug功能来帮助实现流程的调测，其中特别针对于UI自动化的调测，这简直就是神器，因为UI自动化需要一步一步的运行，在点击下个元素的时候如果失败可能会造成失败重来的尴尬局面，所以debug对于调测就是神器。
SQLAlchemy连接数据库所使用的Engine对象默认采用一个连接池来管理连接
当我们使用Engine对象所对应的SQL数据库连接的资源时，这些对数据库的连接是通过一个连接池（Connection pooling）来管理的。当我们释放（release）一个连接资源时，这个连接并不是被销毁了，而是仍然连接着数据库，只不过其将会被重新存储如一个用于管理连接的连接池（默认为QueuePool）中。放入连接池中的连接可以被复用。事实上总有一定数目的数据库连接被保存在这个连接池中，即使在我们的代码中看起来像是连接被释放了一样。这些连接会在我们的程序结束运行之后自动被销毁，或者当我们显式地调用销毁连接池的代码时被销毁。
连接复用
由于这个连接池的存在，每当我们在代码中调用Engine.connect()方法或者调用ORM对应的Session的时候，往往会得到一个已存在与连接池中的数据库连接，而不是得到了一个全新的连接对象。然而当连接池中没有现成可用的连接对象的时候，在不超过配置所允许的连接上限的条件下，新的连接对象会被创建并返回给调用这些方法的程序。
默认使用的QueuePool
SQLAlchemy默认所使用的连接池为sqlalchemy.pool.QueuePool。当目前总连接数没有超过配置的上限且池中没有现成可用的连接的情况下，一个新的连接会被建立并返回给调用创建新连接的方法的程序。这个上限等于create_engine.pool_size 与create_engine.max_overflow之和。
可上溢的连接池
如果我们将参数create_engine.max_overflow设置为”-1”，那么连接池会允许“上溢”无限多的新连接。在这种情况下，连接池永远不会阻塞一个新的数据库连接请求。相反，每当有新的连接请求且无当前可用的连接对象，连接池就会无条件地创建新的连接对象来返回给这个请求。
然而，即使我们在程序端不限制并发的数据库连接的数目，如果程序无限制的创建新的数据库连接对象，连接的数目最终会到达数据库端的连接数目上限，并且耗尽所有数据库允许的连接，最终同样会造成程序异常。
曾经在使用flask-socket中不添加monkey.patch_all()遇到一些莫名奇妙的错误。所以这里查了些资料关于monkey.patch_all。
monkey.patch_all() 是什么？monkey.patch_all() 是 gevent 库中的一个核心函数，用于在程序启动时动态替换标准库中的某些模块（如 socket、threading、select 等），使其支持 非阻塞的协程操作。
其核心作用是让标准库的阻塞式 I/O 操作（如网络请求、文件读写）在 gevent 的协程（Greenlet）框架下运行，从而实现 高效的异步编程。
关于异常处理是我们在开发中经常会遇到的，每个开发者都避免不了遇到异常处理，想要开发出来健壮的程序必须要做好异常处理。我也在几年的开发中也总结出来一些异常处理的技巧，在这里也分享一下。
当预期某段代码可能引发异常时，将其包裹在try块内 ，然后使用一个或多个except子句来捕获并处理这些异常。例如，处理文件读取错误：
try:
with open('example.txt', 'r') as file:
content = file.read()
except FileNotFoundError:
print("文件未找到 ，请检查路径是否正确。")
有时 ，一段代码可能会抛出多种类型的异常 ，这时可以使用一个except块来同时捕获多个异常类型 ，或者使用多个except块分别处理不同异常：
try:
# 假设这里执行的代码可能抛出多种类型的异常
result = 10 / 0
except (ZeroDivisionError, TypeError) as e:
print(f"发生错误: {e}")
在处理异常时，可能需要保留原始异常信息的同时，添加额外的上下文或重新抛出异常。使用raise from语法可以达到这一目的：
try:
open('nonexistent.txt')
except FileNotFoundError as fnf_error:
raise ValueError("配置文件缺失") from fnf_error
flask 是作为高度自由的框架，因此 flask 的代码可能会写的比较自由，这种自由可能是带有一定风险的，就是 flask 的代码可复用性并不会很高，对于简单单表的增删查改可以参考我的这种方式可以对于单表的操作变得比较简单。
我在这家工作刚来的时候公司的同事写一个增删改查接口用了将近100行代码，使用这套代码模版后相关代码只有10行内就可以完成一个增删改查的功能。这肯定大大提高了工作效率，我们可以花费更多的精力在更复杂的业务逻辑上。
这个问题就必须要涉及到session,cookie,token之间的区别了