PDF 转 RAG chunks：保留标题路径、页码与检索上下文
RAG 质量在生成 embedding 之前就已经开始了。PDF 分块后仍要能独立理解，还要保留标题路径和原始页证据，才能在答案出错时回到文档核查。
直接答案：按标题和文档区块分，而不是按任意字节位置硬切。每个 chunk 同时保留稳定 ID、标题路径、来源页和区块级 provenance；真正定下大小与重叠之前，先用自己语料里的问题做 retrieval eval。
一个 chunk 不只有文字，还需要上下文
“收入增长 3%”离开公司名、报告期和章节标题后，就很难成为可靠的检索材料。标题路径和简短文档上下文能让片段脱离整份 PDF 后仍可理解。Anthropic 的 Contextual Retrieval 也描述了同类问题：孤立 chunk 可能丢掉检索和使用它所必需的信息。
| Chunk 字段 | 用途 | 核验问题 |
|---|---|---|
| text | 送入检索或 embedding 的正文 | 单独看还能理解吗？ |
| heading_path | 文档上下文 | 路径指向正确章节吗？ |
| pages | 原始位置 | 复核人能重新打开证据吗？ |
| sources | 区块方法与偏移 | 缺失字段是否保留为 null？ |
pdfmd 的 RAG profile 实际导出什么
当前 pdfmd.rag-chunk.v1 使用 JSONL，每个 chunk 占一行 JSON。它在标题边界和约 1,600 字符处开启新块，重叠保留前一个非标题区块，并给出估算 token 数。这些是透明默认值，不代表对所有模型和语料都最优。
{"schema_version":"pdfmd.rag-chunk.v1",
"id":"report-chunk-3",
"heading_path":["风险因素","供应链"],
"pages":[8,9],"estimated_tokens":312,
"text":"...","sources":[{"block_id":"p8b4","page":8}]}整库入库前先评估检索
- 准备证据位于已知页码的可回答问题，再加入无法回答的对照题。
- 先看正确 chunk 是否被召回，再评价最终生成答案。
- 对编号、代码和专有名词同时测试关键词与语义检索。
- 在同一套问题上比较至少两组 chunk 大小与重叠。
- 需要引用或审计时，把来源映射 JSON 和 chunks 一起保存。
OpenAI vector store 同时提供自动与静态 chunking strategy，这说明 chunk 大小是入库决策，不是通用常数。生产调整应记录版本并重跑 eval；更大重叠可能提高召回，也会增加存储、重复命中和 prompt 成本。
官方资料与事实边界
以下链接支持规范与平台行为；pdfmd 的扣点和处理路径以本站价格页与隐私政策为准。
把复核清单保存下来
下载 Markdown 清单，下次转换时重复使用；格式变化会记录在公开 changelog。
常见问题
PDF RAG 应该用多大的 chunk？
没有通用答案。可从导出默认值开始，再用自己文档的问题比较 retrieval 结果，确认后才批量入库。
为什么每个 chunk 都要保留 heading_path？
它补回段落脱离 PDF 上下文后丢失的章节信息。
JSONL 能直接导入所有向量数据库吗？
不能。它是便于逐行处理的中间格式，还要映射到你的检索系统所需 schema。
pdfmd 会生成 embedding 或托管向量数据库吗？
不会。它只导出 chunks 和 provenance；embedding、索引、检索评估与存储由你的技术栈完成。
先导出带证据的 chunks，再做自己的 eval
转换一次 PDF 后选择 RAG 分块 profile。云端转换需要 Google 登录和页面点数；结果不会自动保存，离开前请下载 JSONL。