RAG 效果差？先确认瓶颈是不是在解析这一步
数据截至 2026-07，价格与限额以各官网为准。
RAG 答不准的时候，绝大多数团队的第一个动作是换嵌入模型或者加个重排，但真正该做的第一个动作是把召回的原文打印出来看一眼。如果打印出来的那几段本身就是乱码、表格被压成一行、章节标题跟正文黏在一起，那你后面调再多检索参数也只是在给坏原料换包装。定位瓶颈的成本远低于盲改的成本，这一步不能跳。
先承认一个很常见的误解：不少人默认”解析”是 RAG 里最不需要操心的一环——不就是把 PDF 转成文本吗，随便找个库跑一下就行了。这个判断在语料干净的时候确实成立，比如全是 Markdown 文档、内部 Wiki 导出、结构规整的纯文字合同。但一旦语料里混进扫描版 PDF、双栏排版的论文、带合并单元格的财报表格、盖了章带水印的法律文书，“随便找个库跑一下”的结果就会差得离谱，而且这种差是静默的——程序不报错，索引也建成功了，只有答案质量在悄悄崩。
下面这套顺序，是按”先确认再动手”的原则排的。
一、先把问题归到四类里的一类
调优之前，把你遇到的现象归类。RAG 链路上可能出问题的位置有四类：解析、检索、生成、评估。
- 解析：文档进系统这一步就没读对。表现是召回的片段本身残缺、串行、丢表格、丢标题层级。
- 检索：文档读对了、也切好了，但该找的那段没被找出来。表现是原文里明明有答案，召回列表里却没有它。
- 生成：该找的那段找出来了，模型却没用好，或者答非所问、过度发挥。表现是召回列表第一条就是标准答案，回答却跑偏。
- 评估：你其实说不清现在到底哪一类出了问题，全靠人工试几个问题拍脑袋。表现是每次改完都”感觉好点了”，但拿不出证据。
这四类要修的地方完全不同，混着修就会出现”改了三天，指标没变”的情况。归类这一步花不了十分钟，却决定了后面几周的方向。
二、怎么确认瓶颈就在解析这一步
有三个动作，按顺序做，基本能给解析这一步定性。
第一个动作：把召回内容原样打印出来。 不要只看最终回答，把检索器返回的 top-k 片段完整打印到终端或日志里，一个字都不要截断。人眼扫一遍就知道文档有没有被读明白。常见的坏味道包括：表格塌成一串没有分隔的数字、页眉页脚混进正文、跨页的段落被硬切成两半、公式变成一堆乱码符号、多栏排版被按行横向拼接导致左右两栏的句子交错。看到这些，基本可以停止调检索了。
第二个动作：抽样对照原文。 挑三到五份最典型的文档，把解析出来的纯文本跟原始文件并排看。重点看两个位置：一是表格，二是标题层级。表格是最容易出问题的地方，因为它的语义依赖二维位置关系，一旦被压平成一维文本，“某年某项目多少钱”这种信息就永久丢失了；标题层级则决定分块能不能尊重文档结构，标题丢了，切出来的块就没有上下文归属。
第三个动作：做一次”人给答案”的对照实验。 把某个回答不好的问题，手工从原始文档里复制正确的那一段，直接塞进上下文让模型回答。如果这样一来回答就对了，说明生成环节没问题，问题在前面的召回或解析；如果手工塞进去还是答不对，那要看的是提示词和生成策略，跟解析无关。这个实验很土，但结论非常干净。
三、确认是解析的问题，往哪个方向修
如果上面三步指向解析，那么优先考虑在解析能力上更专的方案，而不是继续在通用框架里堆参数。
按公开的项目定位来看，这个方向上有两条比较明确的入手路径。一条是 LlamaIndex：它整体是数据优先的思路，专注对私有内容做索引和查询，RAG 专用的原语更贴身，配套的 LlamaParse 就是冲着文档解析去的。另一条是 RAGFlow：它是开源的 RAG 引擎，差异化点在深度文档理解——分块尊重文档结构，带版面感知解析，还内置知识图谱构建；按项目自身的说明，它面向的正是扫描版 PDF、财报、版式复杂的法律文书这类传统文本解析器搞不定的语料，同时提供低代码界面来配 RAG 工作流。具体到当前版本支持哪些格式、解析器怎么配，以各项目官方文档当前版本为准。
还有一种情况值得单独说：如果你的语料本身是有链接关系的结构化内容——比如条款之间互相引用的制度文件、彼此指向的产品文档——那可以考虑图检索的路子，RAGFlow 的 GraphRAG 就是这个方向。这类语料的痛点不是”读不出字”，而是”读出来了但关系断了”，靠纯向量检索很难补回来。
自托管这块要预留资源。RAGFlow 走 Docker 部署，有 slim 和 full 两种镜像，slim 约 2GB、full 约 9GB，区别在于是否内置嵌入模型。选 slim 意味着你得自己接嵌入服务，选 full 则一次性把体积扛下来，机器磁盘和拉取时间要提前算进去。
四、解析没问题，那多半卡在检索
如果打印出来的片段本身很干净、原文里的答案段也确实存在，只是没被排到前面，那就是检索的活儿了。这一段可调的旋钮很多：嵌入模型的选择、混合检索（关键词加向量）的配比、重排模型、chunk 大小与重叠、查询改写。
框架层面，LangChain、Haystack、Cognita 这一类在检索环节可调的旋钮最多，适合做这种精细拉扯。LangChain 出现最早、生态最大，有 chains、agents，以及模型、嵌入、向量库的大量集成，适合通用的端到端 LLM 应用和 agent；代价是学习曲线更陡，抽象层次也更多。这里有一条需要带上限定说明的数据：有第三方评测指出，LangChain 的 LCEL 语法虽然能做复杂的查询重写，但相比 LlamaIndex 的直接检索会多出约 15% 到 20% 的延迟开销。这是第三方基准口径，不是官方指标，不同硬件和不同链路结构下差异会很大，只能当作”抽象层不是免费的”这个方向性提示，别当成验收标准。
向量库也在这一层。常配的一个选择是 Qdrant，它支持过滤、payload 索引与量化，可以作独立二进制运行，也可以跑 Docker 容器；第三方称在 100 万以上向量的规模下可做到 50ms 以内的检索，同样是第三方口径，实际表现取决于你的维度、量化配置和硬件，以官方文档当前版本和你自己的压测为准。
需要提醒的是，检索这一层的调优很容易上瘾——参数多、每次改都有变化、看起来一直在进步。所以第五节那件事必须先做。
五、没有评估，调优就是在盲改
如果你说不清现在的问题属于哪一类，或者每次改完只能靠”感觉好点了”来判断，那真正的瓶颈既不在解析也不在检索，而在评估。
可操作的做法是先攒一个小而真实的问答集：从业务同事实际问过的问题里挑三十到五十条，人工标出正确答案在哪份文档的哪一段。这份东西不需要多大，但必须真实——用自己编的问题测出来的分数没有参考价值。有了它，你才能把”召回里有没有正确段落”和”回答对不对”这两件事分开量化，也才能知道换个嵌入模型到底是变好了还是只是换了个错法。
工具层面不用另起炉灶，在你已有的框架上加挂 RAGAS 是常见做法，它可以跟现有链路配合使用，不需要为了评估重写整套管道。具体支持哪些指标、怎么接，以官方文档当前版本为准。
六、star 数不适合当选型依据
选型时很容易被 GitHub 上的数字牵着走，这里把公开数据放上来，但要先说清它意味着什么。
截至 2026 年 1 月的第三方统计，GitHub star 数大致是：LangChain 约 125,000，Dify 约 114,000，RAGFlow 约 70,000，LlamaIndex 约 46,500，Haystack 约 24,000。这些数字反映的是关注度和传播广度，不代表它在你的场景里更适用——一个解析扫描件的项目，star 少一半也可能是更对的选择。而且这是特定时间点的快照，现在的数值已经不同，别拿它做当前判断。
按瓶颈选，是比按名气选更稳的路径：卡在解析就往解析强的方向走，卡在检索就选旋钮多的，卡在说不清就先补评估。
七、它们不是互斥的，可以混着用
新手常见的另一个误区是把选型当成单选题，非要在几个框架里挑一个”赢家”。实际的生产组合经常是拼起来的：一种常见搭法是 LlamaIndex 做 ingestion 与索引，LangChain 做编排，LangGraph 做 agent 工作流，各取所长。
要注意的是，LangChain 和 LlamaIndex 本身是库，所谓”自托管”就是你自己跑 Python 服务和向量库，运维成本主要在你这边；而像 RAGFlow 这样的引擎是带部署形态的。如果硬性要求数据留在内网，就在可自托管的方案里挑；如果更看重快速搭起来，低代码平台能减少搭建成本，但灵活性和可控性会相应让出一些。这是取舍，没有普遍正确的一边。
八、诚实说说这套方法的局限
第一，本文给的是定位顺序，不是配方。定位清楚之后具体怎么修，仍然依赖你的语料特点，同样是扫描件，医疗单据和财务报表要处理的问题也不一样。
第二，解析问题不总能靠换框架解决。有些文档天生就难——手写批注、拍歪的照片、低分辨率扫描件、盖章遮住关键数字，这类情况可能需要在入库前做人工整理或者 OCR 预处理，指望某个框架一键解决不现实。
第三，本文引用的延迟开销、检索速度等数字都来自第三方评测口径，不是官方承诺的指标。做技术选型时，这类数字只能当线索，最终还是要在你自己的语料和硬件上跑一次对照实验。各项目版本迭代很快，功能边界会变，涉及具体能力的判断请以各项目官方文档当前版本为准。
小结
RAG 效果差的时候，先别急着换模型。把召回的原文完整打印出来看一眼，抽几份典型文档跟原始文件对照，再做一次”手工塞正确段落”的实验，基本就能把问题归到解析、检索、生成、评估这四类里的一类。归到解析，就往文档理解更强的方向走；归到检索，就去调旋钮更多的框架；归到说不清，那先补一份真实的评估集，它比任何参数都值钱。最后记住这些框架不是单选题，拼着用往往比硬选一个更符合实际。