烦人的__pycache__屏蔽；LLM模型的输入限制；解决LLM模型的输入限制；OCR对pdf进行文字提取（未完成）；

1.烦人的__pycache__屏蔽；
pycache 是 Python 自动生成的字节码缓存目录，它的存在只有一个目的：
让 Python 下次运行更快
对开发没有任何帮助，却一直显示在文件夹中，干扰开发。
我直接在vscode中将__pycache__屏蔽。
操作步骤：
打开 VS Code👉Ctrl + ,（设置）👉搜索：exclude👉找到 Files: Exclude👉添加规则：

**/__pycache__
**/*.pyc

2.LLM模型的输入限制

把图片 先转成文字，再让模型抽取结构化信息，输出/上下文限制会小很多、稳定很多。
先尝试不使用（ocr）模型进行pdf → 文字转换：pdfplumber与fitz。

情况	正确做法
pdfplumber 提取失败	用 fitz
fitz 失败	用 pdfminer
全失败	OCR
表格 / 扫描书	OCR + 版面分析

不幸的是，都失败了，对于这些扫描件fitz和pdfminer还是很不够看，只能使用ocr进行提取了。

项目	多模态	OCR + 文本
最大可处理数量	2～4 张图	上百条文本
稳定性	低	极高
是否会漏人	会	基本不会
是否好 debug	否	是
工程可控性	低	高

多模态的最大可处理数量目前有较大限制。

3.解决LLM模型的输入限制
由于一直使用的是输入图片的方式，对pdf文件进行识别，但现在发现LLM模型在多模态输出方面有严格的限制；
于是采用pdf直接转文字的方式，直接输入模型，再进行处理。
目前是：
UploadFile → HTTP 传输对象
bytes → 实际内容（存在服务器内存当中）
把文件转成字节流（bytes），把“文件”从「传输形态」解耦成「内容形态」
在不同模块、不同来源、不同算法之间自由流转。

4.OCR对pdf进行文字提取（未完成）
OCR提取文字使用的是Marker。
Marker（marker‑pdf）本身支持在 GPU 上进行推理和 OCR 加速，不过和某些单纯 OCR 库不太一样，
它不是一个“独立 GPU OCR API”，而是一个 PDF → 结构化提取（包括 OCR、布局分析、格式化等）全流程工具，并且它支持 GPU 推理来提升速度。
👉第一次使用Marker，修改模型存储路径。
Marker把模型下载到缓存内部，对后面使用容器运行非常不方便，需要修改其模型路径。