本节目标：对刚跑通的最小系统做一次刻意的压力测试。

看懂它的 5 道裂缝，你就拿到了整门课的地图——后面每一章，都是在补其中一道。

跑通 ≠ 好用

1.3 里我们让茅台 2024 营收答对了，容易让人误以为「RAG 不过如此」。

但那是精心挑选的、最友好的一类问题。

换几个问题，这个最小系统立刻暴露短板。

我们逐道拆解。

裂缝 1：表格被切碎，版面信息丢失

现象：问「茅台 2024 年应收账款是多少」，可能答错或答不全。

原因：年报里大量数据在跨页大表里。

我们 MVP 的分块策略还很粗糙——表格虽然「整体保留」了，但超过 400 字仍会被 hardSplit 硬切。

而且 MinerU 把表格转成 HTML / Markdown 时，表头和数据行的对应关系在切割中可能丢失。

一句话：解析与分块的质量，决定了整个系统的上限。

垃圾进，垃圾出。

去哪补：第 2 章 · 数据层——版面解析、扫描件处理、结构感知分块（表格到底该怎么切才不丢语义）。

裂缝 2：检索召回不准，路由还很脆

现象：1.3 里我们给 MVP 加了个最朴素的检索前路由，它确实挡住了最低级的错误。

不做路由时，问茅台营收，Top-K 里会混进五粮液（这是真实跑出来的命中来源）：

- 贵州茅台·2024·P1  (0.758)
- 贵州茅台·2024·P56 (0.740)
- 五粮液·2024·P21   (0.732)   ← 串进来了
- ...

提取出 { company: 'maotai', period: '2024' } 过滤后，五粮液就消失了。

但这只挡住了最表层的错误，真正的检索难题尚未触及。

原因：

• 这个路由靠关键词死匹配——用户换个说法「它去年赚了多少」，公司和年份都提取不出，就完全失效；
• 纯向量检索对「语义相近但不是想要的」区分度不够；
• 没有 query 改写、没有重排，召回什么全凭一次相似度。

去哪补：第 4 章 · 检索核心（2026 瓶颈，重点）——检索前处理（query 改写、多查询、更聪明的元数据路由）、混合检索（稠密 + 稀疏）、Rerank 重排。这是 2026 年 RAG 效果的主战场。

裂缝 3：数值对不上、模型仍会臆造

现象：有时数字差了个小数点，或者上下文不足时它仍然强行作答，而不是说「查不到」。

原因：我们只用了一句 prompt 防幻觉，没有任何量化手段去衡量「它到底有多可信」。

你甚至无法判断改了一版 prompt 是变好还是变差。

去哪补：第 5 章 · 生成与评估——把引用溯源做扎实，引入 RAGAS（忠实度 / 相关性 / 召回）+ 自定义数值准确性指标，用评估驱动迭代，改一版就能量化收益，而不是凭感觉。

裂缝 4：对比类、多跳问题彻底失灵

现象：问「茅台和五粮液近三年毛利率谁更高、差距怎么变」，最小系统完全无法回答。

原因：这类问题需要多步推理——先分别查两家公司三年的数据，再计算、再对比。

朴素 RAG 是「一次检索一次生成」，缺少「规划 + 多次检索 + 推理」的能力。

去哪补：第 6 章 · 进阶范式（2026 重点）——Agentic RAG（让 Agent 决定检索几次、怎么改写）、GraphRAG（用实体关系图解决多跳 / 对比）、CRAG（时效性纠错）。还会用 Mastra 把问答系统暴露成 MCP 工具。

裂缝 5：上线后全无观测能力

现象：系统跑在本地是一回事，真要给别人用——你不知道检索质量在下降、不知道每次问答花了多少钱、不知道谁能看哪些数据。

原因：MVP 只是个能跑的 demo，完全没有生产化配套：没监控、没成本统计、没权限。

去哪补：第 7 章 · 生产化（差异化新增）——部署服务化、可观测（检索质量监控 + 链路追踪 + 成本统计）、权限治理（元数据级访问控制，企业级 RAG 的生死线）。

全课地图

一张图看清五道裂缝、各补哪一章：

第 3 章 表示与存储是第 2 章 数据层的自然延伸：把分好的块用什么嵌入、存进什么向量库、怎么设计索引。

本章小结

回头看，你在本章完成了三件事：

1、建立了 RAG 的心智模型

六步流水线，以及「开卷考试」的直觉。

2、亲手跑通了一个真实系统

从茅台年报 PDF，到带页码的正确答案。

3、看清了它的不足

5 道裂缝，以及后面每一章的使命。

这就是「项目倒推教学」的起点。

不是先学一堆理论再找场景套，而是先做出一个能跑的东西，再顺着它的痛点一层层深入。

每深入一层，你的系统就更接近「能放进简历、能拿去面试、甚至能变成你自己产品」的样子。

➡️ 下一章：第 2 章 · 数据层——先把第一道、也是最影响上限的裂缝补上：怎么把年报解析、分块做对。

⬅️ 回到：本章导读