LiteLLM 大规模文本分析与提取实战3 步跑通 PDF 管线的完整指南【免费下载链接】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你手上有一堆 PDF 报告要从每一份里把关键数据扒出来分析。手工干得累为每个模型厂商单独写一套接入更头大。下面用 LiteLLM 走完整套文本提取与文本分析管线安装跑通、PDF 提取、分块批量分析再到代理日志与成本控制。要解决的问题批量文本任务的实际流程是固定的从文件里提文本 → 分块 → 丢给模型分析 → 汇总结果并盯住成本。麻烦在两端文件端格式杂模型端 100 多家厂商每家 API、限流、计费都不一样。LiteLLM 干的事是把「模型端」压缩成一个completion()调用同时把「PDF 文本提取」和「分块切分」两个基础件直接做进了 SDK。你只需要关心中间那步问模型什么。LiteLLM 安装步骤3 分钟跑起来安装 SDK 和 PDF 解析依赖版本以仓库 pyproject.toml 为准pypdf 要求 6.x 以上pip install litellm pypdf6.12.0想读源码或改代码克隆仓库git clone https://gitcode.com/GitHub_Trending/li/litellm用一行litellm.completion(modelgpt-4o-mini, messages[...])验证调用是否通了通了再往下走。本文用到的几个关键目录路径作用litellm/rag/ingestion/PDF、图像等文件文本提取litellm/rag/text_splitters/分块切分器litellm/batch_completion/并行批量调用litellm/proxy/代理服务器、日志与成本PDF 文本提取代码示例仓库里的提取入口是 litellm/rag/ingestion/file_parsers/pdf_parser.py内部优先用 pypdf装不上就回退 PyPDF2。它接收的是文件字节流所以文件来自磁盘、S3 还是消息队列都不影响from litellm.rag.ingestion.file_parsers import extract_text_from_pdf with open(report.pdf, rb) as f: text extract_text_from_pdf(f.read()) print(text[:200] if text else 提取失败可能是扫描版图片)注意它失败时返回None而不是抛异常。批量任务里如果不判断这个值第一份扫描版 PDF 就会让整批任务断掉。大文档分块策略与批量文本分析500 页的报告塞不进任何模型的上下文窗口。仓库自带RecursiveCharacterTextSplitterlitellm/rag/text_splitters/先按段落切、再按换行、最后按空格逐级细化基本不会把句子拦腰截断还能设置chunk_overlap让相邻块共享几行上下文。from litellm.rag.text_splitters import RecursiveCharacterTextSplitter from litellm import completion chunks RecursiveCharacterTextSplitter(chunk_size2000).split_text(text) for chunk in chunks: resp completion(modelgpt-4o-mini, messages[{role: user, content: f提取这段文本的关键事实: {chunk}}]) print(resp.choices[0].message.content)文件量到几百份时把循环换成 litellm/batch_completion/main.py 里的batch_completion它默认用 100 个 worker 的线程池并行多模型、多部署的场景则交给代理做负载均衡后文会讲。扩展到生产代理、日志与成本追踪文本分析跑久了最先疼的是预算。LiteLLM 代理服务器litellm/proxy/就是为此设计的挡在调用前面统一做跨模型负载均衡、限流、重试以及按密钥统计花费。审计日志页能直接看到每次改动前后的spend字段变化常见坑与成本控制扫描版 PDF 提不出字。extract_text_from_pdf只处理真实文本层扫描文档要接 OCR 通道——litellm/rag/ingestion/ 里有 bedrock、vertex_ai 等 ingestion 适配器可参考。分块不留重叠上下文就断了。切报告时不设置chunk_overlap跨块的句子会各被理解一半默认块大小和重叠值定义在 litellm/constants.py。按难度选模型。「抽取数字」这类任务用便宜模型就够「跨报告对比结论」再上旗舰两者成本差一个数量级。缓存与预算都打开。代理支持响应缓存和按密钥设预算预算触顶会告警重跑任务的开销接近零。想盯每一笔分析请求接 Langfuse 最直接trace 视图里单次请求的 token 数、耗时、花费一目了然。延伸资源文本提取与各 ingestion 适配器源码litellm/rag/ingestion/RAG 总入口litellm/rag/main.py分块切分器实现litellm/rag/text_splitters/并行批量调用litellm/batch_completion/可观测性示例Langfuse notebookcookbook/logging_observability/完整测试套件tests/第一步可以很小今天装好依赖、跑通上面那 5 行提取脚本把一份 PDF 的文本拿出来明天再接代理、把预算限制配上。管线搭到能跑比一开始就设计成「大而全」更省时间。【免费下载链接】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），仅供参考 LiteLLM 大规模文本分析与提取实战：3 步跑通 PDF 管线的完整指南
LiteLLM 大规模文本分析与提取实战3 步跑通 PDF 管线的完整指南【免费下载链接】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你手上有一堆 PDF 报告要从每一份里把关键数据扒出来分析。手工干得累为每个模型厂商单独写一套接入更头大。下面用 LiteLLM 走完整套文本提取与文本分析管线安装跑通、PDF 提取、分块批量分析再到代理日志与成本控制。要解决的问题批量文本任务的实际流程是固定的从文件里提文本 → 分块 → 丢给模型分析 → 汇总结果并盯住成本。麻烦在两端文件端格式杂模型端 100 多家厂商每家 API、限流、计费都不一样。LiteLLM 干的事是把「模型端」压缩成一个completion()调用同时把「PDF 文本提取」和「分块切分」两个基础件直接做进了 SDK。你只需要关心中间那步问模型什么。LiteLLM 安装步骤3 分钟跑起来安装 SDK 和 PDF 解析依赖版本以仓库 pyproject.toml 为准pypdf 要求 6.x 以上pip install litellm pypdf6.12.0想读源码或改代码克隆仓库git clone https://gitcode.com/GitHub_Trending/li/litellm用一行litellm.completion(modelgpt-4o-mini, messages[...])验证调用是否通了通了再往下走。本文用到的几个关键目录路径作用litellm/rag/ingestion/PDF、图像等文件文本提取litellm/rag/text_splitters/分块切分器litellm/batch_completion/并行批量调用litellm/proxy/代理服务器、日志与成本PDF 文本提取代码示例仓库里的提取入口是 litellm/rag/ingestion/file_parsers/pdf_parser.py内部优先用 pypdf装不上就回退 PyPDF2。它接收的是文件字节流所以文件来自磁盘、S3 还是消息队列都不影响from litellm.rag.ingestion.file_parsers import extract_text_from_pdf with open(report.pdf, rb) as f: text extract_text_from_pdf(f.read()) print(text[:200] if text else 提取失败可能是扫描版图片)注意它失败时返回None而不是抛异常。批量任务里如果不判断这个值第一份扫描版 PDF 就会让整批任务断掉。大文档分块策略与批量文本分析500 页的报告塞不进任何模型的上下文窗口。仓库自带RecursiveCharacterTextSplitterlitellm/rag/text_splitters/先按段落切、再按换行、最后按空格逐级细化基本不会把句子拦腰截断还能设置chunk_overlap让相邻块共享几行上下文。from litellm.rag.text_splitters import RecursiveCharacterTextSplitter from litellm import completion chunks RecursiveCharacterTextSplitter(chunk_size2000).split_text(text) for chunk in chunks: resp completion(modelgpt-4o-mini, messages[{role: user, content: f提取这段文本的关键事实: {chunk}}]) print(resp.choices[0].message.content)文件量到几百份时把循环换成 litellm/batch_completion/main.py 里的batch_completion它默认用 100 个 worker 的线程池并行多模型、多部署的场景则交给代理做负载均衡后文会讲。扩展到生产代理、日志与成本追踪文本分析跑久了最先疼的是预算。LiteLLM 代理服务器litellm/proxy/就是为此设计的挡在调用前面统一做跨模型负载均衡、限流、重试以及按密钥统计花费。审计日志页能直接看到每次改动前后的spend字段变化常见坑与成本控制扫描版 PDF 提不出字。extract_text_from_pdf只处理真实文本层扫描文档要接 OCR 通道——litellm/rag/ingestion/ 里有 bedrock、vertex_ai 等 ingestion 适配器可参考。分块不留重叠上下文就断了。切报告时不设置chunk_overlap跨块的句子会各被理解一半默认块大小和重叠值定义在 litellm/constants.py。按难度选模型。「抽取数字」这类任务用便宜模型就够「跨报告对比结论」再上旗舰两者成本差一个数量级。缓存与预算都打开。代理支持响应缓存和按密钥设预算预算触顶会告警重跑任务的开销接近零。想盯每一笔分析请求接 Langfuse 最直接trace 视图里单次请求的 token 数、耗时、花费一目了然。延伸资源文本提取与各 ingestion 适配器源码litellm/rag/ingestion/RAG 总入口litellm/rag/main.py分块切分器实现litellm/rag/text_splitters/并行批量调用litellm/batch_completion/可观测性示例Langfuse notebookcookbook/logging_observability/完整测试套件tests/第一步可以很小今天装好依赖、跑通上面那 5 行提取脚本把一份 PDF 的文本拿出来明天再接代理、把预算限制配上。管线搭到能跑比一开始就设计成「大而全」更省时间。【免费下载链接】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），仅供参考