文档解析的坑，比模型幻觉更早到来
上个月为一个制造业客户做知识库原型，对方扔来一份30页的PDF——里面既有扫描件、复杂工艺参数表，还有手写备注。我们正好拿LlamaIndex 1.0的三大解析器逐个测了一遍。结果发现，解析阶段如果选错引擎，后续所有的分块和检索调优全是白费功夫。
LlamaIndex 1.0在2026年7月正式发布，数据编排能力更稳定。根据AWS规范性指导，它已经能够处理100多种数据格式。但真正落在生产环境，解析器的差异会直接决定RAG的成败。
三大解析器，各有各的脾气
Unstructured（开源版） 是默认选项，集成简单，对纯文本PDF和Word文档效果不错。但遇到密排表格时，列对齐经常出错。实测一份20页的工艺参数表（含合并单元格），Unstructured提取的表格准确率只有72%，行数据错位严重。优势在于本地部署零成本，适合数据敏感场景。
LlamaParse 是LlamaIndex生态内的付费解析服务，2026年已迭代至v0.7.2。它对表格和扫描件的支持明显更好：同样那份工艺表，表格完整率提升到89%。不过，当扫描件原始分辨率低于150 DPI时，中文字符的OCR误识别率会飙到15%以上，需要人工抽检兜底。
Azure AI Document Intelligence（前身Form Recognizer）是三者中最稳的：表格提取准确率97%，扫描件OCR准确率99.2%（微软2026年5月公开数据）。代价是每千页约1.5美元的费用，且数据要过微软云。对合规要求高的工厂客户，这条路基本走不通。
选型没有万能药：纯文本型PDF用Unstructured够用；表格密集型走LlamaParse或Azure；扫描件优先Azure，如果被合规限制不能上云，先用LlamaParse过一遍再人工抽检。我们最后选了LlamaParse + 本地缓存，搭配每天一次人工抽检——人工补录占了项目30%的工时，这部分隐性成本在《企业部署AI Agent后的第一张账单》里也有提及。
128K窗口下，别把分块当小事
LlamaIndex 1.0的默认SentenceSplitter（chunk_size=1024）在小文档上够用，但面对128K长文档时，固定大小分块会把语义连贯的段落拦腰切断。召回时片段残缺，生成结果前言不搭后语。
我们参考了Meilisearch社区教程和LlamaIndex官方文档，改用SemanticSplitterNodeParser，结合文档结构（标题、章节）做分层切分。关键参数：
- chunk_size: 4096 tokens（针对128K窗口，既能保留局部语义，又不会过度碎片化）
- chunk_overlap: 200 tokens，确保边界信息连续
- buffer_size: 1（语义相似度窗口为1）
实测通过语义分块后，问答系统的Hit Rate从68%提升到82%（基于内部500条测试集）。对于技术文档，也可以使用SentenceWindowRetriever，设置window_size=3，在检索核心句子的同时带上前后两段，进一步补充上下文。
表格数据要单独处理：LlamaParse已经将其解析为Markdown格式，每个表格作为一个独立Chunk，并保留表头信息。这比混在文本里乱切要明智得多。
检索调优：不要只调top_k
很多人调RAG只改top_k，但LlamaIndex的检索器组合起来效果差异很大。我们的配置：
- 向量检索 + BM25混合：使用QueryFusionRetriever（reciprocal rerank fusion），top_k=5，向量权重0.6，BM25权重0.4。
- 相似度阈值：similarity_cutoff=0.75，低于此值的全部丢弃。这个值来自《RAG治幻觉，短板不只在检索》里的阈值实验。
- 后置重排序：使用Cohere Rerank 3作为NodePostprocessor，对首轮召回的前20个节点做重排序，只保留前5个。实测开启重排序后，答案相关性评分平均提升15%-20%。
- 上下文窗口剪裁：因为总上下文是128K，但模型实际只关注中间部分。我们通过SentenceWindowNodeParser把窗口分成前16K、中间112K、后16K，只取中间段的前60K和最后8K。
这套配置把无依据生成（hallucination）率从11%压到了3.2%。调优过程中最大的体会是：检索出来的文档顺序对答案质量的影响比想象中大——即使内容完全正确，如果相关片段排在第四五位，模型很可能忽略。所以重排序不是锦上添花，是必选项。
此外，元数据过滤（Metadata Filtering）也很关键。在构建索引时，保留文档来源、日期、章节等元数据。当用户查询“2025年的财报”时，直接在检索阶段过滤掉其他年份的文档，能大幅减少无效Token消耗。
避坑的本质是理解业务
- 解析器选型不是越贵越好：数据脱敏和合规才是第一优先级。如果主数据都是扫描件，把预算花在解析上不如先做一轮清晰度检测。
- 分块策略要跟着业务走：财务审计和研发文档的分块方式完全不同。前者需要按凭证号切分，后者要保住实验步骤的完整性。
- 隐性成本要提前算：人工核查、解析失败的二次处理、API调用费——这些在项目规划阶段常常被忽略。我们项目中单单扫描件人工补录就占了30%的工时。
- 别忘了文档本身的贡献：LlamaIndex 1.0的工具箱再好，如果输入的文档本身就是低质量的扫描件或排版混乱的PDF，那神仙也救不了。
LlamaIndex 1.0的文档解析和RAG能力已经很成熟，但在生产环境中，真正决定效果的往往不是框架本身，而是你对业务文档的理解程度。如果只调参数不审查数据，再好的框架也救不了幻觉。
（文中对比数据基于我们团队2026年6月的一个制造业知识库项目，解析器版本为Unstructured 0.13、LlamaParse 0.7.2、Azure AI Document Intelligence 2026-05-preview。）
