大模型知识问答的困境 —— RAG 的局限与 llm-wiki 理念

所属课程：《法律问答系统(llm-wiki)》八讲课件 · 第 1/8 讲定位：一门纯概念课。这一讲不出现任何代码，只回答一个关键问题——为什么要做”非 RAG”的知识问答系统？

本讲目标：

说清大模型直接做领域知识问答的三个致命短板；
看懂 RAG 的标准流程，以及它解决了什么、遗留了什么；
理解 llm-wiki 的核心主张：在”摄入期”把知识编译成资产，查询期只做”定位 + 综合”；
拿到贯穿全课程的一张理念对比表。

1. 直接用大模型做”劳动法问答”，会发生什么

假设我们什么都不做，只把问题丢给一个通用大模型（比如 qwen-max），请它回答”公司拖欠工资，我能主张什么”。

它会遇到三个天然短板：

短板	表现	例子
领域知识不足	训练语料里法条不完整、不精确、还常是旧版本	劳动法与劳动合同法在补偿/解除规则上细节极多，模型记不全、记不准
时效性差	知识截止到训练时刻，无法更新	新司法解释、新法规出台后，模型一无所知
幻觉难溯源	回答流畅但可能”一本正经地编”	编出一条不存在的”《劳动法》第 XX 条”，且无法回溯到原始出处给用户看

第三点对法律场景尤其致命：用户需要知道”你凭什么这么说”，回答必须能定位到具体法条原文，而不是一段笼统的漂亮话。

一句话：LLM 是”能说”，不是”知道”。它缺少一块可靠、可更新、可溯源的外部知识。

2. 主流解法：RAG（检索增强生成）

业界最通用的补法叫 RAG（Retrieval-Augmented Generation，检索增强生成），思想非常朴素：

提问时，先把最相关的文档片段”现找”出来塞给模型，让模型照着这些资料回答。

典型流程四步：

用户问题
   │
   ▼
① 切块      把知识文档切成固定长度的小片段（chunk）
   │
   ▼
② 向量化    用 embedding 模型把每个 chunk 编码成向量，存进向量数据库
   │
   ▼
③ 检索      把 query 也编码成向量，在库里找最相似的 top-k 个 chunk
   │
   ▼
④ 拼接+生成 把 top-k 块拼进 prompt，交给 LLM 综合成答案

RAG 解决了两件事：

给模型”临时喂资料”，弥补领域知识与时效不足；
模型是基于给定资料作答，幻觉显著下降。

它已成为当下知识问答的事实标准——所以本系统说自己不是 RAG，反而需要解释清楚：RAG 好端端的，为什么要绕开它？

3. RAG 的四个隐忧

RAG 思路没毛病，但工程上它默认了几件事，恰恰在这些默认上会出问题：

3.1 切块破坏语义（最致命）

RAG 按固定长度（如 500 token）硬切文档。对散文还行，对法律条文是灾难：

一条法条常常横跨几个 chunk → 检索到的是半条法条；
语义上应当成一体的”第四十六条+第四十七条”被切散，检索各自为战；
chunk 是机器定的，不是语义定的——它不尊重”章→节→条”的天然边界。

3.2 向量库是黑盒，不可读、不可审计

向量是一串浮点数，谁也读不出它”存了什么”。于是：

没法人工检查”知识库里到底有没有这条规则、版本对不对”；
检索”为什么召回它”无法向业务/用户解释；
内容有错，很难定位到是哪一段引入的。

对法律这类需要可追溯、可复核的知识，这是硬伤。

3.3 一问一检、答完即弃，知识不”复利”

RAG 每次提问都临时检索一遍，检索完就丢弃。结果：

同一问题答一百遍，检索成本付一百遍；
检索到好的答案，不会沉淀成更好的知识；
系统没有”越用越聪明”，只有”每次重新来一遍”。

3.4 答案与出处两张皮

RAG 常把引用做得像”事后贴标签”：模型先答完，再把 top-k chunk 的标题列在末尾。但 model 到底用了哪一块，很难保证——**引用可信度存疑 **。

4. llm-wiki 的解法：把知识”提前编译”成资产

llm-wiki 的想法是：与其每次提问时临时翻书，不如先花力气把书读透、编成目录，提问时只查目录 + 照着目录里的原文作答。

对照上面的四个隐忧，它的立场是：

RAG 的默认	llm-wiki 的反问
查询时才处理文档	为什么不在摄入期就把文档读好？
按长度切 chunk	为什么不按”章→节→条”这样的语义单位切？
向量做知识载体	为什么不用可读、可审计的 Markdown + JSON？
问一次丢一次	为什么不让每次问答都沉淀、复用？

于是知识处理被拆成两个阶段，而不是一个”查询时临场表演”的过程：

┌─────────────  摄入 Ingest（一次性"编译"）  ─────────────┐
│  法律 PDF ──► 结构化知识点（一条法条一个知识点）           │
│              + 知识点之间的关联图谱（谁引用谁、谁和谁相关） │
│              + 可读的 Wiki 页面集（人也能翻）             │
└─────────────────────────────────────────────────────────┘
                           │ query（提问）
                           ▼
┌─────────────  查询 Query（只做"定位 + 综合"）  ──────────┐
│  用户问题 ──► 定位最相关的知识点 ──► LLM 依据原文综合回答    │
│              （可读可审计）        （带引用、可回溯）       │
└─────────────────────────────────────────────────────────┘

几个关键词：

知识点（Knowledge Point）：最小知识单元。本系统把《劳动合同法》《劳动法》切成 205 个知识点，一条法条对应一个，而不是定长 chunk。粒度是语义天然边界。
关联图谱：知识点之间是谁引用谁、谁与谁主题相近，显式建成边。这给”多跳推理”铺好了路（后续第 6 讲细讲）。
向量只当”辅助”，不当”仓库”：向量仍参与召回打分，但知识本体是 Markdown + JSON，可读、可审计。
问答复利：这套架构天然为”随问答复利积累”服务——每回答一次，人对知识结构的理解可以加深、可以补图补概念。

5. 理念对比总表（本讲要背下来的一张表）

维度	RAG	llm-wiki（本项目）
知识构建时机	查询时临时检索	摄入时提前”编译”
知识单元	定长 chunk	法条级知识点（语义边界）
知识载体	向量数据库	Markdown 页面 + JSON 图谱
可读可审计	差（向量不可读）	好（人可直接翻 Wiki）
查询行为	检索 → 拼接 → 推理	定位知识点 → 综合生成
引用可信度	事后贴标签	回答依据给定知识点，可回溯原文
知识是否复利	否	是（可随问答积累完善图谱）
适用文档类型	任意（散文、网页、问答…）	结构化强、颗粒分明的领域文档（法律/规章/操作手册）

注意最后一行：llm-wiki 不是万能替代 RAG。对”资料库是海量网页、没有稳定结构”的场景，RAG 仍是首选。本系统的取舍成立的前提是—— 知识是两部结构规整的法律，天然存在”章→节→条”的划分。想清楚”什么知识适合哪种方案”，比只会一种方案更重要。

6. 从理念到本课程项目

后续 7 讲，就是把这个理念落地成真实系统的过程：

摄入期：PDF → 205 个知识点 → 概念增强 → 关联图谱 → Wiki（第 3、4 讲）
查询期：混合检索定位 → 图谱多跳补全 → 大模型综合生成（第 5、6 讲）
工程闭环：短期记忆 / CLI / 日志 / 测试（第 7 讲）
如何证明它够好：recall@k 与 Ragas 评估（第 8 讲）

每讲都会带大家走进 app/ 下的真实代码，对照”理念 → 实现”一条线看下来。

企业常见面试问答

Q1：你们项目为什么不用 RAG？它比 RAG 好在哪？

因为我们处理的是结构化强、语义边界分明的法律文档（章→节→条）。RAG 默认在查询时临时检索、按长度硬切 chunk，会切开法条、破坏语义；向量库又是黑盒，对法律这种需要可溯源、可复核的场景不可审计。llm-wiki 在摄入期就把文档”编译”成* 法条级知识点 + 关联图谱 + 可读 Wiki*，查询时只做”定位知识点 + 让 LLM 依据给定知识点作答”，引用可回溯、知识可随问答复利积累。要强调：这不是全盘否定 RAG，而是针对该领域文档特性的取舍。

Q2：你说的”法条级知识点”和 RAG 的 chunk 有什么本质区别？

chunk 是按长度（token 数）机械切分，是机器定的、与语义无关，一条法条可能被切成好几段；知识点按”章→节→条”这类**文档的天然语义边界 **切分，每个知识点是完整的一句话义单元（本系统 205 个 = 劳动合同法 98 条 + 劳动法 107 条）。前者是”碎纸片”，后者是” 一张张完整卡片”。

Q3：怎么解决大模型的幻觉和”编法条”问题？

三层手段：① 检索侧先定位到具体知识点，用真实法条原文兜底；② 生成侧用领域 prompt 约束——” 仅依据【参考资料】作答、不要臆造法条、给不出就如实说明”；③ 回答末尾列出引用的全部知识点标题 ，且每条知识点携带来源文件名+行号，可回溯到原文，让引用可被核验。

Q4：为什么向量检索仍被保留了？你不是说不把向量当仓库吗？

区别在于角色：向量不做知识库的存储载体，只做召回时的一种相似度打分手段，与 BM25 关键词走双路、再用 RRF 融合排序（第 5 讲细讲）。知识本体始终是可读的 Markdown + JSON。这样既保住”可读可审计”，又借助向量抓住了”用户换一种说法也能命中” 的语义召回能力——两全。

下一讲：第 2 讲系统总览与工程环境