问题
真实世界的文档库对朴素 RAG 充满敌意：扫描版 PDF、密集表格、答案藏在图里、 多语言混排、成千上万份文件。只靠切块加向量，会以极高的自信检索出错误的段落。
我建了什么
一个自托管的 RAG 平台，把检索质量当管线工程而不是一次模型调用：
- 版面感知的摄取 —— 基于 Docling 的解析，保住表格与图片的结构而不是拍平成词汤； 规范化正文的 content-hash 去重；
- 混合检索 —— dense 检索前置查询路由，后接 cross-encoder 重排 （实测的提升来自重排，而不是换 embedding 模型）；
- 语料关系图谱 —— 文档级与跨文档的 graph / 思维导图视图，把文档之间的相关度 变成看得见、走得动的结构：哪些文档围绕同一主题成簇、从一份文档走到它的邻居， 而不是只能对语料盲问；
- MCP 服务层 —— 智能体带鉴权与审计日志地调用
search工具。这一层让它从 一个应用变成了别的系统可以搭建其上的基础设施； - 活的语料库 —— 一条由智能体舰队运转的月度灌库 工作流（盯源 → 抓取 → 清洗 → 验证 → 入库）让知识库保持现行——答案引用的是文档 今天的样子，包括晚于任何模型训练截止日期的新文本；
- 运维 —— Postgres + FAISS + FastAPI，Docker 部署在常开的家庭基础设施上， 服务数千份文档的语料。
它证明了什么
检索是一门工程学科：解析保真度、检索分级、诚实的评测，比换模型更能移动指针。 我踩过的坑——双存储失步、去重键选错哈希、定长切块稀释按条召回——每一个都变成了 一条设计规则；其中好几个是靠在真实问题上量召回发现的，而不是靠看 demo 顺眼。
现状
2026 年春天起在生产环境运行，每天被查询——包括被 智能体舰队通过 MCP 层调用。