三步把百页PDF变成可分析文本LiteLLM大规模文本提取实战指南【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmLiteLLM 是一个开源 AI 网关与 Python SDK除了用统一的 OpenAI 格式调用 100 多个大模型它还内置了 PDF 文本提取、文本分块、OCR 和向量入库的完整管线。这篇文章带你完成一件事把大量文档变成干净文本再交给任意大模型批量分析全程只用一套 API。一堆产品手册变成数据泥潭想象这样一个场景你拿到几十份产品手册、报价单和扫描版发票需要从中提取型号、价格和条款汇总成一张表。手工复制粘贴不现实如果每换一个 PDF 库、每换一个模型 API 就要重写一遍代码更是噩梦。你真正想要的是文件进去干净文本出来分析结果自动汇总中间不需要为不同厂商写适配层。这正是 LiteLLM 文本提取管线要做的事。安装 LiteLLM SDK 并跑通第一个模型环境要求 Python 3.10 以上。 最短路径是装两个包litellm 本体和 pypdfPDF 解析依赖pip install litellm pypdf # 安装 SDK 与 PDF 解析依赖 export OPENAI_API_KEYsk-你的密钥 # 设置任一模型密钥pypdf 缺失时解析器会自动回退到 PyPDF2两者都没有才会放弃本地提取、转走 OCR这段逻辑在 litellm/rag/ingestion/file_parsers/pdf_parser.py 里值得花两分钟读一下。三步走完 PDF 提取到分析的全流程下面这条主线覆盖最典型的用例PDF 提纯文本 → 分块 → 批量让大模型提取关键信息。第1步把 PDF 读成纯文本调用内置的extract_text_from_pdf传入 PDF 的原始字节即可。注意它在提取失败时返回None而不是抛异常所以拿到结果后要做一次判空from litellm.rag.ingestion.file_parsers.pdf_parser import extract_text_from_pdf text extract_text_from_pdf(open(产品手册.pdf, rb).read()) if text is None: # 大概率是扫描版没有可提取的文本层 raise SystemExit(提取失败请改用 OCR)第2步把长文切成模型能吞下的块按 3000 字符硬切是最保守的做法。如果想要更贴合语义的切分可以用项目自带的递归字符切分器 litellm/rag/text_splitters/它会优先沿段落、句子边界断开避免把一句话拦腰斩断。第3步批量调用大模型并汇总结果分好块后用统一的completion接口逐个分析。换模型只改model参数代码一行不用动from litellm import completion chunks [text[i:i3000] for i in range(0, len(text), 3000)] results [] for c in chunks: resp completion( modelopenai/gpt-4o-mini, messages[{role: user, content: f提取这段文本的关键信息{c}}], ) results.append(resp.choices[0].message.content) print(\n.join(results)) # 汇总所有块的分析结果用 OCR 和 RAG 摄取处理扫描件与大批量文档文本层缺失的扫描件可以交给litellm.ocr它把 Azure AI OCR、Vertex AI OCR 等能力包成同一个接口源码在 litellm/ocr/main.py不用为每家厂商写单独的 SDK。文档量大时更推荐直接用 litellm/rag/main.py 里的 all-in-one 摄取管线一条链路完成上传 → OCR → 分块 → 向量化 → 存入向量库支持 OpenAI、Bedrock、Gemini、Vertex AI、S3 Vectors 五类向量库后端。入库后随时用query按语义检索再回答不必每次全文重跑分析。 如果分析任务跑在生产环境把 LiteLLM 代理接上 Langfuse 之后每次调用的 token 用量、耗时和成本都能在面板里逐条看到排查哪类文档最烧钱这类问题会直观很多代理侧部署也很简单一条命令拉起uv tool install litellm[proxy] # 安装代理网关 litellm --model gpt-4o # 本地启动默认 4000 端口官方基准测试中代理在 1k RPS 下 P95 延迟约 8ms批量提取这类高并发短请求场景压力不大。批量处理文本的 4 个常见坑提取返回 None→ 原因是扫描件没有文本层或缺少 pypdf/PyPDF2 → 判空后对扫描件改走 OCR或补装解析依赖。分析结果被截断→ 长文档超出模型上下文窗口 → 先分块再送入切分粒度宁小勿大必要时换递归切分器。批量跑一次成本失控→ 每个块都调用高价模型 → 用便宜模型做初筛、贵模型做复核重复请求可在代理配置里开启缓存参考 proxy_server_config.yaml 中的 cache 配置项。走代理时模型名报错→ 请求里要写配置中model_name定义的别名而不是上游真实模型名 → 在model_list里补上映射即可。动手之前把这条管线接进你的项目LiteLLM 的文本处理思路很朴素提取、切分、入库、分析各是一等公民却共用同一套接口所以你不需要在 PDF 库、向量库、模型 SDK 之间反复切换胶水代码。先从一个小批量文档试起跑通后再扩到整个文档库。核心代码位置提取与摄取管线在 litellm/rag/OCR 在 litellm/ocr/整体设计与功能说明见 README.md 和 ARCHITECTURE.md。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 三步把百页PDF变成可分析文本：LiteLLM大规模文本提取实战指南
三步把百页PDF变成可分析文本LiteLLM大规模文本提取实战指南【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmLiteLLM 是一个开源 AI 网关与 Python SDK除了用统一的 OpenAI 格式调用 100 多个大模型它还内置了 PDF 文本提取、文本分块、OCR 和向量入库的完整管线。这篇文章带你完成一件事把大量文档变成干净文本再交给任意大模型批量分析全程只用一套 API。一堆产品手册变成数据泥潭想象这样一个场景你拿到几十份产品手册、报价单和扫描版发票需要从中提取型号、价格和条款汇总成一张表。手工复制粘贴不现实如果每换一个 PDF 库、每换一个模型 API 就要重写一遍代码更是噩梦。你真正想要的是文件进去干净文本出来分析结果自动汇总中间不需要为不同厂商写适配层。这正是 LiteLLM 文本提取管线要做的事。安装 LiteLLM SDK 并跑通第一个模型环境要求 Python 3.10 以上。 最短路径是装两个包litellm 本体和 pypdfPDF 解析依赖pip install litellm pypdf # 安装 SDK 与 PDF 解析依赖 export OPENAI_API_KEYsk-你的密钥 # 设置任一模型密钥pypdf 缺失时解析器会自动回退到 PyPDF2两者都没有才会放弃本地提取、转走 OCR这段逻辑在 litellm/rag/ingestion/file_parsers/pdf_parser.py 里值得花两分钟读一下。三步走完 PDF 提取到分析的全流程下面这条主线覆盖最典型的用例PDF 提纯文本 → 分块 → 批量让大模型提取关键信息。第1步把 PDF 读成纯文本调用内置的extract_text_from_pdf传入 PDF 的原始字节即可。注意它在提取失败时返回None而不是抛异常所以拿到结果后要做一次判空from litellm.rag.ingestion.file_parsers.pdf_parser import extract_text_from_pdf text extract_text_from_pdf(open(产品手册.pdf, rb).read()) if text is None: # 大概率是扫描版没有可提取的文本层 raise SystemExit(提取失败请改用 OCR)第2步把长文切成模型能吞下的块按 3000 字符硬切是最保守的做法。如果想要更贴合语义的切分可以用项目自带的递归字符切分器 litellm/rag/text_splitters/它会优先沿段落、句子边界断开避免把一句话拦腰斩断。第3步批量调用大模型并汇总结果分好块后用统一的completion接口逐个分析。换模型只改model参数代码一行不用动from litellm import completion chunks [text[i:i3000] for i in range(0, len(text), 3000)] results [] for c in chunks: resp completion( modelopenai/gpt-4o-mini, messages[{role: user, content: f提取这段文本的关键信息{c}}], ) results.append(resp.choices[0].message.content) print(\n.join(results)) # 汇总所有块的分析结果用 OCR 和 RAG 摄取处理扫描件与大批量文档文本层缺失的扫描件可以交给litellm.ocr它把 Azure AI OCR、Vertex AI OCR 等能力包成同一个接口源码在 litellm/ocr/main.py不用为每家厂商写单独的 SDK。文档量大时更推荐直接用 litellm/rag/main.py 里的 all-in-one 摄取管线一条链路完成上传 → OCR → 分块 → 向量化 → 存入向量库支持 OpenAI、Bedrock、Gemini、Vertex AI、S3 Vectors 五类向量库后端。入库后随时用query按语义检索再回答不必每次全文重跑分析。 如果分析任务跑在生产环境把 LiteLLM 代理接上 Langfuse 之后每次调用的 token 用量、耗时和成本都能在面板里逐条看到排查哪类文档最烧钱这类问题会直观很多代理侧部署也很简单一条命令拉起uv tool install litellm[proxy] # 安装代理网关 litellm --model gpt-4o # 本地启动默认 4000 端口官方基准测试中代理在 1k RPS 下 P95 延迟约 8ms批量提取这类高并发短请求场景压力不大。批量处理文本的 4 个常见坑提取返回 None→ 原因是扫描件没有文本层或缺少 pypdf/PyPDF2 → 判空后对扫描件改走 OCR或补装解析依赖。分析结果被截断→ 长文档超出模型上下文窗口 → 先分块再送入切分粒度宁小勿大必要时换递归切分器。批量跑一次成本失控→ 每个块都调用高价模型 → 用便宜模型做初筛、贵模型做复核重复请求可在代理配置里开启缓存参考 proxy_server_config.yaml 中的 cache 配置项。走代理时模型名报错→ 请求里要写配置中model_name定义的别名而不是上游真实模型名 → 在model_list里补上映射即可。动手之前把这条管线接进你的项目LiteLLM 的文本处理思路很朴素提取、切分、入库、分析各是一等公民却共用同一套接口所以你不需要在 PDF 库、向量库、模型 SDK 之间反复切换胶水代码。先从一个小批量文档试起跑通后再扩到整个文档库。核心代码位置提取与摄取管线在 litellm/rag/OCR 在 litellm/ocr/整体设计与功能说明见 README.md 和 ARCHITECTURE.md。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考