5. 2023—2024：模型不知道我的资料，RAG 与知识库问答兴起

来源：大模型技术演进

2023 年 7 月 12 日，Google 将此前展示过的 Project Tailwind 以 NotebookLM 的名字开始向美国少量用户开放。它的出发点很具体：用户选定自己的 Google Docs，系统围绕这些材料生成摘要、回答问题，并提供可以回到原文的引用。NotebookLM 当时的发布公告

这给聊天助手提出了一种新的期待。人们已经见识过模型谈论历史、解释代码、撰写文章，现在更想知道：它能不能读懂我正在研究的材料，帮我找回自己记过却忘了放在哪里的内容？

从“问一个通用助手”，到“围绕自己的资料交流”，看起来只是给聊天框增加了文件，背后却牵动了整套应用设计。模型怎样拿到文档？几百份材料中应该先看哪些？回答里的结论来自哪一页？文档改了以后，答案能不能跟着更新？

类似需求也进入了工作场景。摩根士丹利在 2023 年 9 月全面推出面向财务顾问的 AI @ Morgan Stanley Assistant，帮助顾问访问公司的知识资料。对专业人员来说，能够更方便地找到已有研究和内部信息，本身就是一种明确的工作价值。摩根士丹利对该产品推出时间与用途的官方回顾

个人文档助手与企业知识助手面对的资料规模不同，却碰到了同一个问题：模型在训练中获得的能力，如何用于它没有见过、也不会自动访问的材料？RAG 与知识库问答，就是这一阶段围绕这个问题发展起来的重要方向。

模型会解释一个领域，不代表它知道你的文件。

一个语言模型可能知道数据库、摄影或市场营销的一般知识，但它不会因为“能力很强”，就自动知道你昨天写的项目记录。保存在电脑里的文件、没有公开的团队资料，以及训练结束后才出现的信息，都需要另外提供给系统。

这里有两件容易混在一起的事：模型有没有处理材料的能力，以及这次回答时有没有拿到材料。前者关心理解、归纳和表达；后者关心数据从哪里来。

如果资料只有几段，直接贴进对话往往就够了。但资料变成几百页、几千份文件，人工复制就不再方便。模型一次能够接收和处理的内容也有上限，这个范围通常叫作上下文窗口。即使内容放得下，每次都发送全部材料，也会带来更多输入处理、等待和费用。

于是，一个熟悉的办法重新获得了价值：先找资料，再依据资料回答。

RAG 是 Retrieval-Augmented Generation 的缩写，通常译为“检索增强生成”。在本篇讨论的常见应用中，系统先从外部资料里找出相关内容，再把这些内容连同问题交给语言模型，让模型据此组织回答。

这个研究方向早于 ChatGPT。2020 年，Patrick Lewis 等人的论文就提出了名为 RAG 的方法，将生成模型与可检索的外部知识结合。当时的具体研究方案包含训练设计，不能直接等同于后来所有“检索几段文字再调用聊天 API”的应用。2020 年 RAG 论文

2023 年的新变化，是对话模型的理解与指令遵循能力、API 的可获得性，以及开发者对个人和企业资料的需求汇合了。应用可以尝试复用已有模型，把主要开发工作放在资料接入和检索上，而不必为每个知识库从头训练一个模型。

知识库问答，通常是在回答时补充资料。

用一个假设的个人项目来理解：你保存了两年的学习笔记，想问“我上次做网站部署时，域名解析的问题是怎么解决的？”

一个基本系统可以先找到涉及域名、DNS、部署报错的笔记，再把其中的相关段落交给模型。模型看到实际记录以后，才有依据还原你的处理过程。它不是凭一般知识猜测你当时做了什么。

这套系统通常有两段不同的工作：

准备资料：读取文件 → 整理与切分内容 → 建立便于检索的索引。

回答问题：理解查询 → 检索相关内容 → 将材料与问题交给模型 → 返回答案和来源。

索引可以先理解为帮助程序快速查找内容的结构。准备阶段一般在导入或更新资料时进行；提问时再利用已有索引寻找材料，不需要每问一次都重新处理整个文件夹。LangChain 在 2023 年 2 月的教程中，就已经把“数据导入”和“围绕数据聊天”分成这两部分。LangChain 的同期教程

在这种实现里，上传笔记、生成索引，并没有改变负责回答的语言模型参数。文件留在外部存储中，相关片段在提问时进入上下文。删除或更新文件后，还需要同步处理索引，系统才能准确反映变化。

因此，“给 AI 喂资料”是一个方便但不够精确的说法。它可能指提供上下文、建立可检索知识库，也可能指用数据训练模型，几种操作的成本与结果差别很大。微调是进一步训练、调整模型参数；RAG 是组织外部信息供生成过程使用。两者可以配合，也不必二选一。RAG 与微调的研究综述

向量检索为什么在这一时期经常出现？

继续看刚才的笔记。你提问时写的是“网站打不开”，笔记标题却可能是“DNS 缓存问题排查”。如果只要求字面完全相同，就容易漏掉有关内容。

嵌入模型，也叫 Embedding 模型，可以把一段文字转成一组数值，即向量。经过适合检索任务的训练后，这种表示有助于把意思相关、表达不同的文本匹配起来。系统把问题也转成向量，再寻找相近的文档片段，这就是常见的向量检索思路。LangChain 在 2023 年对检索机制的说明

初学者可以把向量理解为一种用于比较的数值表示。它不是把整段文字完整装进一个可以无损还原的“压缩包”，相似度也不是“答案正确的概率”。它帮助程序筛选候选材料，最终仍需要读取原文。

这里通常出现两类不同的模型：嵌入模型负责帮助找材料，生成模型负责阅读材料并回答。更换一个更强的聊天模型，未必能修好前一步漏检的问题。

向量存储与向量数据库则负责保存这些表示，并支持查询。2023 年的 LangChain 教程使用了 FAISS 组织向量检索；同年 6 月，LlamaIndex 与 Weaviate 的集成文章展示了另一种组合：由框架管理资料和查询流程，由数据库承担外部存储与检索。LlamaIndex 与 Weaviate 的同期介绍

这些组件经常一起出现，但 RAG 并不要求必须使用某一家向量数据库，甚至不要求只能进行向量检索。面对精确的错误码、产品型号或文件名，关键词匹配可能很有价值。把关键词与语义检索结合起来，就是常说的混合检索。早在 2023 年 3 月，LangChain 就将检索接口从偏重向量数据库改为更一般的 Retriever，以容纳其他检索方式。当时的接口调整说明

这件事反映了一个很早就显露出来的认识：应用需要找到足以回答问题的材料，向量只是实现这个目标的一种手段。

LangChain 与 LlamaIndex，把反复出现的工作做成了框架。

单独写一次模型调用并不复杂，但知识库应用还需要读取不同格式的文件、切分内容、连接存储、组织提示词，再把来源交给用户。每个开发者都重新写一遍，会产生大量重复工作。

LangChain 在这轮探索中提供了连接模型、资料和处理步骤的组件。2023 年 2 月发布的“ChatGPT Over Your Data”教程，已经展示了从加载文本到检索、再到回答的完整思路，也考虑了后续追问如何结合聊天历史进行查询。它帮助开发者看见：一个聊天体验背后，可以由多个程序步骤共同完成。当时的实现教程

LlamaIndex 则从数据这一侧切入。创始人 Jerry Liu 在 2023 年 6 月的介绍中回顾，项目最初名为 GPT Index，后来发展为连接用户资料与语言模型的数据框架，覆盖导入、解析、索引、检索和回答组织等环节。LlamaIndex 的早期定位与发展记录

两者的能力存在重叠，也都在继续演进。回看这个阶段，可以分别从“怎样把应用步骤连接起来”和“怎样把资料组织得便于模型使用”理解它们的切入点，不必把这种区分当成永久不变的产品边界。

它们的重要性在于，把个人开发者原本要逐项处理的问题变成了可以复用的组件。于是，尝试一个领域问答工具，不再只是研究模型的人才能做的事；有一些编程基础的人，也可以把精力放到自己的资料和使用场景上。

不过，框架让流程容易搭起来，并不意味着接上的组件一定适合你的数据。文档读错了，或者检索到的材料不完整，后面仍然可能得到一份流畅但没有依据的回答。

中国开发者开始把中文模型、检索模型和知识库界面组合起来。

上一篇提到 ChatGLM-6B 可以在具备条件的本地环境运行。模型能够回答中文问题以后，一个自然的下一步，就是让它结合本地文件作答。

Langchain-ChatGLM 的项目记录显示，2023 年 4 月发布的 0.1.0 版本就支持基于 ChatGLM-6B 的本地知识库问答；同年 8 月，项目更名为 Langchain-Chatchat，并扩展模型和数据库支持。它是围绕相关模型和框架构建的应用项目，需要与 ChatGLM 模型本身、LangChain 框架区分开来。项目发展记录

这种组合给国内技术爱好者提供了一个可以观察和改造的入口：网页上的一问一答，背后连着文件处理、中文检索与模型推理。界面可以把复杂过程收起来，但开发者仍然能够分别替换其中的组件。

中文检索的基础能力也在发展。北京智源人工智能研究院在 2023 年 8 月发布 BGE 系列嵌入模型，包含中文模型；9 月又发布了重排模型。重排可以理解为对初步找到的一批候选内容再作一次相关性判断，帮助选择更值得交给生成模型的材料。BGE 模型卡与历史更新记录

这条线索很容易被只关注聊天模型的视角忽略。一个中文知识库问答产品的改善，可能来自更好的生成模型，也可能来自更合适的嵌入模型、重排模型或文件处理方法。大模型应用的生态，正在形成这种更细的分工。

真正拿来使用以后，文档质量成了绕不过去的问题。

演示里的资料往往干净、简短，真实文件却可能包含扫描页、双栏排版、表格和反复出现的页眉。文档解析，是把这些文件里的内容与结构提取出来；扫描图片中的文字还可能需要 OCR，也就是光学字符识别。

假设一份设备说明书用表格对应“故障代码”和“处理方式”。如果读取时把列顺序打乱，系统可能保留了所有文字，却丢失了哪种故障对应哪种处理办法。后续检索再准确，也只能找到已经被破坏的材料。

切分同样会改变可用信息。把“适用于某个旧版本”与后面的操作步骤拆散，模型可能只拿到步骤，漏掉适用条件。分得过细容易丢失上下文，分得过大又可能带来更多无关内容。2023 年 5 月，LlamaIndex 就在文档摘要索引的介绍中讨论了片段缺少全局背景、检索数量和相关性等问题，并尝试利用文档摘要帮助选择材料。同期的文档摘要索引探索

到了 2024 年，这些问题进一步进入产品设计。RAGFlow 于 4 月 1 日开源，项目团队在当年回顾中强调了文档版面解析和混合检索这两项初期设计：先改善输入资料，再改善寻找资料的过程。RAGFlow 的 2024 年回顾

可以由此理解这个阶段的变化：从“上传文件后能聊起来”，走向“复杂材料也能被正确处理”。这不是单纯增加聊天框功能，而是在补齐应用真正有用所需的数据处理能力。

另外，资料更新和访问范围也会影响答案。旧版说明书与新版说明书都在库里，系统就需要版本信息；团队中不同成员能访问不同文件，检索也需要遵守相应范围。这些问题来自资料本身，不能只靠一句“请准确回答”解决。

从找一个答案，走向理解一整批材料。

检索几个相关片段，很适合尝试回答“某个设置在哪里”之类的问题。但如果问“我过去两年的学习笔记，主要围绕哪些主题，兴趣发生了什么变化”，只找几段相似内容就容易以偏概全。

2024 年 7 月 2 日，微软研究院公布 GraphRAG 代码开放。这个方案利用语言模型从资料中提取实体和关系，组织成知识图谱，并生成不同层次的群组摘要，尝试支持跨材料的整体性问题。GraphRAG 开源公告

知识图谱在这里可以理解为用节点和关系组织信息，例如哪些人物参与了哪些项目、不同事件怎样关联。提前整理关系与摘要，可以为某些全局问题提供比零散片段更合适的依据，但也增加了索引构建的工作与成本。它适合解决什么问题，需要结合具体资料判断。

这里的 GraphRAG 与后面会介绍的 LangGraph 是不同项目：前者讨论怎样组织和检索知识，后者用于组织应用或 Agent 的执行流程。名字中都有 Graph，并不意味着它们处在同一个层次。

从文档摘要到知识图谱，这些探索共同说明，RAG 并非一条永远固定的“向量搜索加聊天”流水线。问题变复杂，寻找、组织和综合证据的方法也需要变化。

知识库问答改变了判断应用质量的方式。

对于通用聊天，用户很容易先被语言是否流畅吸引。围绕自己的资料提问时，判断标准变得更具体：有没有找到相关记录，有没有漏掉关键条件，结论是否得到原文支持。

仍以个人笔记为例，可以用三类问题观察系统。这些是用于理解质量差异的构造例子，不需要现在安装软件：

问题	真正需要观察的表现
“那次域名解析问题怎么解决的？”	找到实际记录，区分你做过的操作与通用建议
“哪份笔记记录了最终解决办法？”	返回能够定位的来源，让读者核对上下文
“我没有记录的另一次故障怎么处理的？”	说明资料不足，避免编造你的个人经历

引用的价值是提供核查入口，但“带有引用”本身并不保证答案正确。引用的段落可能只提到同一个主题，并没有支持回答中的具体结论。NotebookLM 的首发公告在介绍来源引用时，也提醒用户回到原材料核对。NotebookLM 对来源核查的说明

如果回答出错，可以沿着流程查找原因：原文件有没有正确读入，相关内容有没有被检索出来，模型有没有忠实使用材料。这种定位方式，比把所有问题都归结为“模型不够聪明”更有帮助。

回看 2023—2024 年，RAG 把一部分大模型应用从开放式聊天带到了有明确资料范围的任务中。个人笔记、产品说明、内部知识都成为可以构建应用的起点；围绕这些资料，嵌入模型、向量检索、数据框架、解析工具与知识库产品一起发展起来。

它没有让模型永久掌握用户的全部知识，也没有让错误消失。它建立了一种可继续改进的分工：资料提供依据，检索选择内容，模型负责理解和表达，应用让这个过程可使用、可核查。

当需求继续往前走，用户又会希望助手先查资料，再整理结论、调用其他工具，最后输出固定格式的结果。一次检索和一次回答开始不够用。下一篇，我们就看看定制助手与工作流怎样把这些步骤组织起来。

---

上一篇：04｜2023：模型成为可调用的能力，提示词与 API 开启应用探索

下一篇：06｜2023—2024：一次调用不够用，定制助手与工作流发展起来

返回：第 0 部分大纲