DeepSeek‑OCR for Long Text: Compress the Noise, Keep the Signal
更新于 2025年10月23日
13 分钟
简介：文本过长的问题不在于它有多长
关于大型语言模型（LLM）中的“长上下文”问题，大家似乎都认为它已经解决了——直到你给它们输入一个 200 页的 PDF 文件，结果它们只返回一首关于虚无的俳句。模型本身并非难以处理长度，而是会被无关信息淹没。输入的是垃圾，输出的也只能是看似合理的垃圾。如果你想要有意义的答案，不需要更大的模型，而是需要更少的无用信息。
隆重推出 DeepSeek‑OCR。它是一款 OCR 引擎，能够完成优秀工具应该做的事情：将图像和 PDF 文件转换为文本，而且过程毫不费力。但这里的诀窍不仅仅在于 OCR 本身。而是利用 DeepSeek‑OCR 来压缩长文本——提取结构、减少冗余、保留关键信息——这样，下游的 LLM 就不会把 token 浪费在 1998 年的图表说明上。
“压缩”是关键词。不是 ZIP 文件压缩，而是语义压缩。人类一直在这样做。阅读一页，记住一个段落。阅读一个段落，记住一句话。我们称之为理解。有了 DeepSeek‑OCR 的参与，你就可以近似实现这个流程：清晰地提取文本，合理地分割文本，并生成分层摘要，供模型实际使用。少一些冒险，多一些成果。
这是一份操作指南。但对于那些认为将原始 PDF 文件直接扔进聊天框并祈祷就能完成工作流程的人来说，这也是一次温和的干预。让我们把它变成一个系统。
“如何使用 DeepSeek‑OCR 为 LLM 压缩长文本”的真正含义
工具本身不会压缩，决策才会。当人们说“如何使用 DeepSeek‑OCR 为 LLM 压缩长文本”时，他们真正想要的是一种可重现的方法，可以将混乱的、可视化的文档转换为简洁、结构化的文本块，以便语言模型可以进行推理，而不会胡乱生成脚注。这个过程可以分解为四个任务：
- 准确提取：正确地从页面上提取文字。
- 结构恢复：保留标题、列表、表格和阅读顺序。
- 语义精简：在保留含义的同时，减少冗余。
- 检索原则：只在需要时向模型提供所需的信息。
DeepSeek‑OCR 处理前两个任务。你（和你的 LLM）处理后两个任务。由此产生的流程以唯一重要的方式“为 LLM 压缩长文本”：更少的 token，相同的答案，更少的废话。
步骤 1：正确使用 DeepSeek‑OCR（提取层）
糟糕的 OCR 会污染下游的一切。如果一开始就存在拼写错误、损坏的列以及伪装成句子的分离页脚，那么你的“压缩”只会使这些错误永久化。DeepSeek‑OCR 的工作是为你提供干净的文本，并带有布局提示。
- 首先选择 PDF 文本提取。如果 PDF 是数字原生（可选择文本），则直接提取文本，并且仅在嵌入式图像或扫描页面时才回退到 OCR。不要对已经是文本的内容进行 OCR——引入错误来修复错误是不明智的。
- 对于扫描的 PDF，请使用 DeepSeek‑OCR 进行页面级别和块级别的布局检测。你需要将标题、段落、表格和图表说明分开。模型稍后会感谢你的。
- 设置可读的行宽。来自双栏 PDF 的长而不间断的行会产生看起来像 beat 诗歌的乱码索引。
- 尽可能将表格提取为 CSV 或 Markdown 格式。表格包含大量含义。当它们完整地从提取中幸存下来时，你的压缩会变得更智能，而不是更愚蠢。
结果：一个仍然很长，但并非混乱的语料库——文本、标题、列表、表格、带有类似 alt 描述的图像。结构是第一层压缩。
步骤 2：按含义分块，而不是按页码
一个常见的错误：按页面或 token 数量进行切片，然后就认为完成了。页码是为打印机准备的；含义并不关心页码。使用 DeepSeek‑OCR 的布局提示按章节和小标题分块。
- 每个顶级标题（H1/H2）一个块，H3/H4 则对应子块。保持每个块在目标模型舒适的上下文窗口内——比如 800–1,200 个 token。
- 将表格及其解释性段落放在一起。拆分它们是让模型发明数据来填补空白的好方法。
- 不要将附录材料与正文混在一起。这是可选阅读材料；区别对待。
压缩开始发生在你的分块策略中：更紧凑、连贯的单元，LLM 可以在不忘记开头的情况下消化到结尾。
步骤 3：语义压缩传递：分层摘要
现在是“为 LLM 压缩长文本”的部分。不要将整个文档减少为单个执行摘要（高管喜欢，模型讨厌），而是为每个块创建分层摘要：
- 要点概要（5–10 个要点）：关键点、声明、定义、数字。
- 一段式概要：细心的读者在五分钟后会记住的内容。
- 词汇表提取：专业术语及其单行定义。
- 引用和锚点：章节标题、页码、表格 ID。
这是具有引用完整性的压缩。要点是你的无损索引；段落是你的有损编解码器。两者都保留。当你稍后向模型提出问题时，检索要点和相关段落，而不是整个块。你将提供更少的 token 并获得更好的答案。魔术技巧：这只是编辑。
步骤 4：像人类分析师一样总结表格
表格是长文档隐藏其真正要点的地方。除非你喜欢丢失信息，否则不要将它们展平为文本。
- 保留原始表格（CSV/Markdown）以供追溯。
- 添加“表格备忘录”：关于表格显示内容的 3–5 个要点，关于其含义的一句话，以及任何奇怪之处（缺失的行、危险信号、带有剑号的脚注）。
- 保留单位、时间范围和队列定义。“销售额增长 10%”如果没有“环比、剔除汇率因素、仅限亚太地区”，那就是琐事。
当查询涉及数字时，将备忘录和表格一起提供给 LLM。这是通过清晰度实现的压缩，而不是通过删除实现的压缩。
步骤 5：生成前检索（RAG，减去流行语）
你不需要说“RAG”来做 RAG。你只需要在要求模型回答之前选择正确的块。
- 使用向量搜索（同义词、释义）索引分层摘要，并使用关键字搜索（完全匹配）索引标题。两次搜索，短列表，求交集。
- 检索：要点 + 概要 + 相关表格备忘录。可选地包括来自源块的前几句话作为原始文本以获得细微差别。
- 用证据回答：指示模型引用块 ID 或页面。
这是你为 LLM 压缩长文本的方式，而不会对你的输入进行脑叶切除术。把它想象成图书管理员，而不是搅拌机。
一种最小的、非常有效的提示模式
对于每个块，运行一致的摘要提示。一致性是成功的一半。
提示框架：
“你是一位细心的技术编辑。用要点（仅限事实）、一段式概要、术语表和引文（章节标题和页面）总结以下块。保留单位、日期和限定词。如果声明在文本中缺乏证据，请标记为 {uncited}。避免重写表格；按 ID 引用它们。输入从 --- 之后开始。”
然后提供该块。将输出与块 ID 一起存储。你现在已经制造了自己的压缩层，这与优秀的记者将笔记与引言分开的方式没有什么不同。
为什么特别选择 DeepSeek‑OCR？
存在大量的 OCR 工具。有些速度快但错误；有些速度慢但错误。DeepSeek‑OCR 速度快，更重要的是，它尊重布局。它的多列处理和图表说明分离为你节省了数小时的后期处理时间。问题不在于“它是否完美？”，没有一个是完美的。问题在于故障模式是否可预测。对于 DeepSeek‑OCR，它们在很大程度上是可预测的：棘手的连字、标题渗入正文以及偶尔的数学错误。你可以为此做好计划。计划是压缩的一半。
还值得一提的是：返回 token 高效文本的 OCR 很重要。如果你的 OCR 添加了幻影空格、错误的断字或重复的行，你将在每个下游调用中为这些 token 付费。DeepSeek‑OCR 倾向于保持它的干净。减少锯末，减少碎片。
实用工作流程：从 PDF 到答案，没有无用信息
一个务实的“如何使用 DeepSeek‑OCR 为 LLM 压缩长文本”的实际工作流程：
- 摄取
- 检测数字文本与扫描页面；如果需要，混合模式。
- 运行 DeepSeek‑OCR，启用布局提取和表格检测。
- 导出：文本使用 Markdown 格式（标题、列表），表格使用 CSV/Markdown 格式，图表使用 PNG 引用（可选）。
- 标准化
- 修复断字：仅当下一行以小写字母开头时，才在换行符处取消断字。
- 合并断开的段落；在章节之间保留空行。
- 转换弯引号，规范化 Unicode (NFC)。模型关心，因为 token 关心。
- 分块
- 按 H2/H3 边界拆分；将表格附加到最近的引用段落。
- 强制执行大小限制（每个块目标 1k token）。不要在论证中途拆分。
- 首次摘要
- 对每个块运行一致的摘要提示。
- 为每个表格添加单独的表格备忘录。
- 索引
- 基于要点和概要文本构建向量索引。
- 基于标题、词汇表术语和表格 ID 构建关键字索引。
- 查询时间
- 通过向量 + 关键字交集检索前 3–6 个块。
- 组合上下文：要点 + 概要 + 任何表格备忘录 + 来自源的 2–3 个引用的句子。
- 要求提供带有引文的答案；禁止推测。
- 答案后完整性检查
- 如果答案引用了 {uncited} 声明，则自动重新检索父块。
- 如果数字出现时没有单位，则拒绝并使用单位约束重新提问。
恭喜你，你已经为 LLM 压缩了长文本，而没有将其变成燕麦片。
压缩不是摘要；它是分类
摘要试图说更少。压缩试图用更少的 token 保持相同的含义。不同的目标。使用 DeepSeek‑OCR，你正在构建一个信息管道，每个阶段都会丢弃你不需要的东西：
- OCR 丢弃像素并保留文本。
- 分块丢弃页面边界并保留论证。
- 分层摘要丢弃重复并保留声明。
- 检索丢弃大多数声明并保留回答问题的少数声明。
最后一步是大多数“长上下文”幻想破灭的地方。如果模型不知道哪些 2k token 重要，那么 20 万 token 的上下文窗口就是一个把戏。压缩是你如何决定的。
关于错误、偏见和“模型说了算”
如果你压缩了错误的内容，你就会从文档中压缩出真相。然后，模型愉快地推理剩下的内容，并以权威的语气进行推理。保障措施：
- 逐字保留引言；清楚地标记释义。
- 在实际情况下，在块和句子级别保持出处。
- 为必须不进行总结的定义、方程式和法规语言维护一个小型的“逐字缓存”。
- 对所有内容进行版本控制。如果源发生更改，则使摘要无效。不要提供一周前的寿司。
DeepSeek‑OCR 有时会连接标题和段落，或误读连字。没关系。这就是为什么你的摘要引用章节和页面的原因。如有疑问，请出示收据。
Token 计算，枯燥但真实
“如何使用 DeepSeek‑OCR 为 LLM 压缩长文本”的经济学归结为 token。OCR 文本很便宜；LLM 上下文并非如此。
- 如果每个块的原始大小约为 1,000 个 token，而你的分层摘要约为 200 个 token，那么你已经实现了 5 倍的压缩。
- 在查询时，检索 5 个摘要会使用约 1,000 个 token 的上下文，而不是 5,000 多个原始 token。这在你添加答案之前。
- 有选择地添加表格。一个 200 行的表格是一千个单元格的死亡；一个 5 个要点的备忘录加上一个 10 行的过滤提取是生机。
你不需要电子表格就能看到节省。你只需要停止像深夜卷饼一样将整个文档塞进提示中。
Sider.AI 的适用范围（如果你真的想让它工作）
这是每个人都期望营销宣传的部分。但实际上：Sider.AI 确实有效——至少对于这一点而言。上传一个顽固的 PDF，让它运行 OCR，你将获得一个干净、可导航的文本，其中包含你可以切片成块而无需人工干预的章节锚点。聊天层不是魔法；它是在你准备好的压缩摘要上进行有条不紊的检索。令人惊喜的是，它并没有假装自己是一个拥有博士学位的 PDF 阅读器。它是一位精明的助手，拥有一把锋利的刀，这正是你在目标是为 LLM 压缩长文本而不损坏含义时所需要的。
脚注标记大小的注意事项
- 复杂数学：如果你将它们展平，OCR 加摘要将破坏符号表达式。保留 LaTeX 或图像作为方程式；用文字而不是符号进行总结。
- 图表：永远不要要求模型“推断”未标记的图表。那是塔罗牌，而不是分析。OCR 标题，保留图像以供参考，并提出有针对性的问题。
- 法律和合规性：某些文本必须逐字保留。标记它。不要压缩掉一个条款，然后询问模型该条款是否存在。条款或律师不是这样运作的。
经过完整性检查的示例模式
假设你有一份 120 页的年度报告。
- 使用 DeepSeek‑OCR 进行 OCR -> 获取 Markdown 文本 + CSV 表格。
- 按章节分块：“管理层讨论”、“风险因素”等。
- 每个块的摘要：8 个要点、1 个概要段落、词汇表、引文。
- 收入、成本、员工人数和部门的表格备忘录。
- 构建双重索引：要点上的向量；标题和词汇表上的关键字。
- 查询：“毛利率的同比变化是多少，为什么？”检索带有成本评论的两个块 + 收入表格备忘录。用引文和 1–2 个引用的句子回答。
你没有阅读 120 页。你也没有假装模型也这样做了。你为 LLM 压缩了长文本，并得到了一个经得起考验的答案。
解决这种情况以可预测的方式出错的问题
- 模型引用了一个不支持该声明的章节。修复：收紧检索——提高章节标题的关键字命中率，降低通用向量匹配的级别。
- 摘要与来源相矛盾。修复：为敏感章节添加“无释义”模式；在上下文中包含 2–3 个逐字句子。
- OCR 错误聚集在标题或页脚中。修复：教你的预处理器在摘要之前删除重复的样板文件；这是噪音。
- 表格膨胀了 token 预算。修复：限制为按相关性排序的前 N 行并保留备忘录；如果需要更深入地挖掘，请包含指向完整 CSV 的链接。
“为 LLM 压缩长文本”的愚蠢与聪明方式
愚蠢：“总结这个 300 页的 PDF。”
聪明：“从这 10 个章节摘要和 3 个表格备忘录中，回答这个狭隘的问题，并引用来源。”
前者奉承模型并浪费你的钱。后者奉承你的用户并尊重现实。DeepSeek‑OCR 为你提供干净的文本；你的管道保持它的诚实。
结论：压缩即尊重
尊重读者。尊重 token。尊重事实。这就是如何使用 DeepSeek‑OCR 为 LLM 压缩长文本的贯穿线。OCR 步骤是基本条件；其余的是伪装成工作流程的编辑判断——按想法分块、在不破坏细微差别的 summarize、检索重要的内容，并让模型用收据回应。
长上下文窗口很好。清晰的上下文更好。如果你想要像细心的读者一样行事的模型，请向它们提供细心的读者保留的内容。其他一切都只是页数。
常见问题解答
问题 1：如何在不丢失含义的情况下使用 DeepSeek‑OCR 为 LLM 压缩长文本？
提取保留布局的干净文本，按标题（而不是页面）分块，并生成分层摘要——要点、一段式概要、词汇表和引文。在查询时仅检索这些摘要和相关的表格备忘录。这样可以为 LLM 压缩长文本，同时保留信号。
问题 2：当我为 LLM 压缩长文本时，最佳块大小是多少？
目标是每个块 800–1,200 个 token，与章节或小标题对齐，而不是任意分页符。目标是连贯的论证，而不是相等的字节数；这就是你如何为 LLM 压缩长文本而不将逻辑切成两半的方法。
问题 3：即使文本可以选择，我是否应该使用 DeepSeek‑OCR 对每个 PDF 页面进行 OCR？
否。如果文本是数字原生的，则直接提取它，并且仅对扫描页面或图像使用 DeepSeek‑OCR。重新 OCR 清洁文本会添加错误——这是为 LLM 压缩长文本的反面。
第四季度：当为大型语言模型压缩长文本时，我该如何处理表格？
将表格保留为CSV/Markdown格式，并添加简短的备忘：表格显示的内容、隐含的意义以及任何注意事项。当相关时，检索备忘以及经过筛选的切片；这比将一个200行的网格直接转储到提示中更明智。
产品