还在靠 RAG 查文档？教你一招，AI 回答更靠谱！

显示全部楼层

在使用 AI 编程的过程中，你是否也遇到过这样一个问题——或者说是一种挑战：手上拥有一大堆文档，但却急需定位其中某条具体的信息。

几年前，答案很简单粗暴：看文档！

而如今，很多人已经转向更智能的做法：直接问 GPT！

更别提配合 Cursor、Cline 这类编程助手，查找答案变得更轻松了。

虽然在大多数情况下，这一方法都能奏效，但偶尔你会发现得到的答案并不全面，有时甚至只是一知半解，远不能满足需求。

实例解析：NotebookLM 的表现

让我以 NotebookLM（借助 Gemini 引擎）为例，讲讲我的亲身体验。

我把 dify 的文档（一款令人惊叹的开源大语言模型聊天工具）输入给 NotebookLM。在这个例子中，我问了怎么创建一个聊天助手，可惜它要么完全不知情，要么只是给出零散的信息。

其实，即便是 Cursor、Windsurf 等强大工具，也可能出现相当随机的回答。

为什么会这样？

主要原因在于：

文档规模 vs. 模型容量
根据文档的大小以及大语言模型（LLM）的 token 限制，这些模型往往会隐式使用检索增强生成（Retrieval-Augmented Generation），简称 RAG 的方式来处理文档。
检索机制
简单来说，系统会先构建一个向量化的数据库，然后基于这个数据库进行搜索。
现阶段挑战
尽管这种方法在不少场景下可以应急，但基于 RAG 的搜索质量，正是当前生成式 AI 领域的研究热点之一。
因此，有时要在瞬间生成一个完整答案，其实并不容易。

幸运的是，借助像 Gemini 这样支持高达 200 万 token 上下文的大语言模型，我们可以有一种更简单的方法。

具体来说：

这种方法不仅简单直观，还能大大降低因 RAG 检索偶发偏差而导致的信息丢失风险。

听起来是不是有点抽象？那我们就以实际项目为例，看看如何利用这种方案用 Dify 创建聊天助手。当然，这个方法同样适用于其他任何文档，只要你能获取到源文档的代码即可。

开源项目通常都会有公开的文档。你可以通过点击文档页面上的“编辑”按钮迅速定位到对应的 Git 仓库和具体目录。

以https://docs.dify.ai/为例，你很容易就能发现它们所在的文件夹。

注意：指定准确的文件夹，可以减少传给模型的文件量。

如果直接把整个仓库（包含大量不必要的源代码）作为上下文，往往是得不偿失。最理想的做法是，只提取出其中的 Markdown 文档。例如，在 Dify 的案例中，所有文档都集中在指定文件夹里。

既然找到了文档目录，接下来就需要将整个目录中的 Markdown 文件“拼接”成一个单一的文件。

这时，一款名为Repomix的开源工具就能大显身手。你可以通过npx repomix命令运行它，或者直接访问它的在线版：https://repomix.com/。

操作流程大致如下：

短短几秒钟后，你就能得到一个文件，其中整合了所选文件夹中所有的内容，以一个长字符串形式呈现。你可以选择复制或下载该文件。

同时，在页面左侧还能看到这个压缩版本的 token 数量。在我的案例中，大约是 475000 token。

（虽然这一数值已经接近 Claude Sonnet 的上限，但与 Gemini 2x 的上百万甚至两百万 token 相比，仍然绰绰有余。）

现在，将整份文档保存成文件或复制到剪贴板后，就可以前往 Gemini（或者当 token 数量未超限时的 Claude）中粘贴进去。

接下来，你就能基于这完整的文档上下文开始提问或让 AI 自动生成代码了。

在我的示例中，我使用的是 Gemini AI Studio 的免费版本。和之前不同，这一次，我再次询问关于如何添加助手，结果获得了极其全面且正确的答案！

通过上述步骤，你就可以使用同一个提示（一整份文档作为上下文）来提问或生成代码，而不必再依赖那些敷衍的 RAG 检索结果，或是听起来合理却与真实文档不符的“凭空捏造”答案。

温馨提示：

局限性在于 token 限制
主要受制于你所使用模型的 token 限制。例如，Gemini 支持高达 100 万 token，这个容量非常大，能够容纳大量的文档。
探索更多可能性
此外，你也可以进一步探索在编程助手内查找其他相关工具的方法。