我用Kimi和FastGPT搭了个能读文档的问答机器人

入职新公司刚满两个月，leader就丢过来一个需求：把团队积累的几百份技术文档做成内部问答系统，让新人不用天天在群里@老人问问题。

第一反应是“这不就是个RAG吗”，但真上手之后发现，从选型到调优，坑比想象的多得多。这篇文章聊聊我是怎么用Kimi的API加上FastGPT这个开源框架，从零搭起一个能读文档的问答机器人的。

为什么选这两个

团队的技术文档散落在Notion、语雀、还有一堆Markdown文件里，加起来大概400多篇，包括架构设计、接口文档、故障复盘、新人入职指南等。需求很明确：新人有问题直接问机器人，机器人从文档里找答案，找不到就老实说不知道，别瞎编。

一开始想自己用LangChain加向量数据库写，但评估下来光文档解析、切片、Embedding、检索排序这套流程，没个一两周搞不定。后来听人提到FastGPT，说把RAG流程都封装好了，文档上传、向量化、问答一条龙，还支持自定义模型接入。试了一下确实省事。模型方面，Kimi的中文长文档理解能力能打，API价格对内部工具来说完全能接受，128k上下文窗口也够大，切片策略不用太精细。

FastGPT部署不复杂，官方有Docker Compose配置，改几个环境变量就能跑。我们用了公司内网一台闲置服务器，8核16G，跑FastGPT加一个本地向量模型（BGE-M3，通过Ollama挂载），绰绰有余。

文档处理：最费时间的一环

搭建很快，真正耗时间的是文档处理。

FastGPT支持直接导入Markdown、PDF、Word，但直接丢进去效果很差。原因很简单：文档格式非常不统一，有的标题层级混乱，有的是会议纪要流水账，还有的PDF是导出的PPT，一页上没几个字全是图。

处理流程分三步：

第一步，把所有文档统一转成Markdown。Notion和语雀都有导出功能，PDF用开源工具转文本。图片暂时放弃，第一版先保证文字内容能覆盖80%的问题。

第二步，人工整理目录结构。花了差不多一个周末，把所有文档按主题重新分类：架构设计、接口文档、运维手册、故障复盘、新人指南。好处是后续可以在FastGPT里按目录做权限控制，也可以针对不同目录调整检索权重。

第三步，写Python脚本做格式清洗。去掉多余空白行、统一标题格式、规范代码块标记。别小看这一步，Embedding模型对格式混乱的文本很敏感，格式整齐一点，检索命中率能差不少。

import re
from pathlib import Path

def clean_markdown(text: str) -> str:
    text = re.sub(r'(#{1,6})([^\s#])', r'\1 \2', text)
    text = re.sub(r'\n{3,}', '\n\n', text)
    text = re.sub(r' +\n', '\n', text)
    return text.strip()

for md_file in Path('./docs').rglob('*.md'):
    content = md_file.read_text(encoding='utf-8')
    cleaned = clean_markdown(content)
    md_file.write_text(cleaned, encoding='utf-8')

FastGPT里的切片策略选了自定义模式，每块500个token，重叠50个token。这个参数是试出来的。默认800 token切片时，有些问题需要跨段落理解，切太大反而引入噪音。500加50的重叠，配合Kimi的128k上下文，检索召回效果比较稳。

检索调优：踩了两个大坑

第一个坑是Embedding模型选择。FastGPT默认用OpenAI的text-embedding-ada-002，但文档里大量中文技术术语，效果一般。换成BGE-M3之后，中文检索准确率明显提升。BGE-M3是智源出的，支持中英双语和长文档Embedding，本地部署不吃资源。

有个细节：FastGPT里配置Embedding模型时，要确保向量维度跟模型输出一致。BGE-M3输出1024维，如果之前用ada-002（1536维）创建过知识库，切换模型后需要重建索引，否则会报维度不匹配错误。我在这卡了一个多小时，一直报vector dimension mismatch，后来才反应过来是索引没重建。

第二个坑是检索top-k的设定。默认召回top-5，但很多问题需要跨文档找答案，比如“A服务的超时时间是多少”和“为什么A服务会超时”，答案可能在不同文档里。我把top-k调到8，然后加重排序步骤。FastGPT v4.7以上支持rerank模型，挂了BGE-Reranker用本地Ollama跑，效果提升很明显。代价是响应时间多了几百毫秒，对内部工具来说无所谓。

提示词设计：让Kimi别瞎编

RAG系统最大的问题是幻觉。用户问一个文档里没有的问题，模型可能一本正经地编答案。Kimi本身知识储备丰富，它“知道”很多东西，但那些不一定来自我们的文档。

我的做法是在FastGPT的提示词里加了一条硬约束：

你是一个内部技术文档问答助手。请严格基于以下检索到的文档内容回答问题。
如果文档内容不足以回答用户的问题，请直接回复："抱歉，我在当前知识库中没有找到相关答案。建议查阅原始文档或联系相关模块负责人。"
不要使用你的先验知识补充回答。不要编造任何文档中不存在的信息。

这条约束加上去之后，幻觉问题基本解决了。测试时故意问了一个文档里没有的问题，Kimi老老实实回了一句“抱歉，没找到”。

FastGPT的提示词里有“引用来源”功能，开启后回答会带上引用的文档片段，对追溯答案来源很有用。

效果和后续计划

上线两周，知识库里有386篇文档，每天大概30-50次提问。回答准确率（人工抽评）大概85%。剩下的15%主要是两类：问题本身太模糊，比如“那个东西怎么配”；文档本身写得就不清楚，这个锅不在模型。

性能方面，单次问答响应时间3-5秒，主要是Embedding检索加重排序占时间，Kimi生成速度很快。这个速度对内部工具完全够用。

后续打算做几件事：一是把图片OCR加进去，很多架构图里的信息目前缺失；二是做用户反馈闭环，点赞点踩的数据用来优化切片策略和提示词；三是考虑升级FastGPT到v4.8，据说新增了多知识库混合检索功能，对我们按目录分类的场景很实用。

一些不成熟的想法

折腾这一圈下来，感受是：NLP入门到进阶，中间隔着的不是算法理论，而是工程落地能力。模型本身已经很强了，但真正决定系统好不好用的，是文档质量、切片策略、检索排序、提示词设计这些“脏活累活”。

FastGPT这类框架的价值在于把RAG的通用流程抽象出来，不用重复造轮子。但它也不是银弹，很多细节还得自己抠。比如文档里有一些表格，直接切片会切碎，检索时表格内容就丢了。目前用Markdown表格转列表的方式绕过去，不算优雅，但能用。

如果你也想做类似的东西，建议是：先别纠结模型选谁，先把文档整理好。垃圾进垃圾出，这个道理在NLP里尤其成立。