从查文档查到崩溃,到给自己做一个 RAG 问答机器人

阅读提示：全文约 1600 字，阅读需要 6 分钟。

说实话，我一开始只是想安安静静写点代码，结果大部分时间都花在了翻文档上。

事情是这样的。前段时间我在搞 ESP32，本来以为照着例子改改就能跑，真正上手才发现，麻烦根本不在写代码，而在查资料。手上这块板子能用到的文档实在太多了，DF 的文档要看，MicroPython 的文档要看，Arduino 的文档也要看，三套东西各说各话，同一个接口在不同文档里的写法还不一样。我经常是写着写着卡住了，然后在 DF、MicroPython、Arduino 这几个文档站之间来回跳，跳到最后自己都忘了刚才想查什么。

查文档这件事，麻烦的不是没有资料，而是资料太多、太散。你明确知道自己要找一个答案，但就是不知道该去哪个文档里找，找到了还得确认这个版本对不对、这个写法适不适合自己手上的板子。这种消耗其实特别隐蔽，单看每一次好像只花了几分钟，但一天下来，整块的时间就被切得稀碎。

于是我就想，能不能做一个问答机器人，我把问题丢给它，它去这些文档里帮我找答案，直接告诉我结论和出处。这就是我准备写这个 RAG 开发系列的原因，也是我动手做这个机器人的起点。

从查文档到做机器人

在动手之前，我先把这个想法捋了捋。我要的东西其实很朴素：一个能听懂我问题的入口，一个能覆盖那几套文档的知识库。还有一条能把问题和资料对上号的链路。至于界面，我没打算自己从头写，直接接飞书机器人就行，平时本来就在飞书里干活，把问答放在聊天窗口里，用起来最顺手，也不用额外记一个网址。

但真要落地，绕不开一个核心问题：大模型本身并不知道我这些文档里写了什么。它没见过 DF 的文档，也没读过我手上这个版本的 MicroPython 说明，直接问它，它要么答得笼统，要么干脆编一个看起来很像那么回事的答案。所以关键不在于模型多强，而在于怎么把我这些文档“喂”到它能用的地方去。这就引出了 RAG。

RAG 到底是怎么回事

RAG 这个词，其实思路很直白：先去找资料，再让模型带着资料回答。

打个比方，你问一个同事问题，他如果凭记忆答，可能记错；但如果他先翻出手册，对着手册那一页念给你听，准确率就高得多。RAG 做的就是后面这件事，它不让模型凭空回忆，而是先从你的资料库里检索出最相关的内容，再把这几段内容连同你的问题一起交给模型，让它基于这些内容来组织答案。

所以整个流程可以拆成两个阶段来看。一个是准备阶段，把文档处理成能被检索的形式；一个是问答阶段，用户提问后去检索、再生成回答。我下面按环节大概说一下，每个环节都只讲个轮廓，不往细里钻。

几个关键环节

文档收集与清洗。 这是最基础也最容易被低估的一步。我手上这些文档来源不同、格式不同，有的是一整页网页，有的是说明段落，直接堆进去效果不会好。得先把它们整理成一段一段干净的内容，去掉导航、页脚这类没用的部分，不然检索出来的全是噪音。

切分。 文档太长，不能整篇塞给模型，得切成小块。切得太碎，上下文丢了，答案不完整；切得太大，检索不准，还浪费空间。这个度怎么把握，是这个环节要解决的问题。

向量化与入库。 把切好的每一块文本转成向量，存进向量库。这一步的意义在于，之后用户提问时，系统不是靠关键词硬匹配，而是按语义相似度去找内容。我问“这块板子怎么连网”，它能找到讲网络连接的那一段，哪怕那段里没出现“连网”这两个字。

检索。 用户提问后，把问题也转成向量，去库里找最相近的若干块内容。找几块、怎么排序、要不要过滤，都是这里有讲究的地方。

生成。 把检索到的内容和用户的问题一起交给大模型，让它基于这些内容作答。这一步的关键是约束它别乱发挥，答案要落在检索到的资料上，最好还能带上出处，方便我回去核对。

接入飞书机器人。 前面那条链路跑通之后，就是把它接到飞书上。用户在飞书里发消息，机器人接收问题、走完检索和生成、再把答案回过去。这样我写代码卡住的时候，不用切窗口，直接在聊天框里问一句就行。

下期开始逐个拆

在此总结一下，这个系列我打算这么走：先讲清楚 RAG 是什么、由哪些环节组成，再讲怎么把它接进飞书机器人，让这套东西真正能用起来。这一篇只是个总览，每个环节我都只点到为止，没有展开。

其实真正费时间的，恰恰是那些我没展开的细节。文档怎么清洗才算干净，切分粒度怎么定，检索回来的内容不相关怎么办，模型答得偏离资料怎么约束，这些问题每一个都够单独写一篇。

所以下期开始，我会一个环节一个环节地拆开说，把我踩过的坑和最后的做法都写出来。如果你也在折腾 ESP32，或者你手上也有一堆查起来没完没了的文档，这个系列应该对你有用。

留个问题：你平时查文档，最烦的是找不到，还是找到了不确定对不对？我挺好奇别人的答案。