obsidian这篇文章记录我在 X-Chat 项目里，把一个普通即时通讯系统接入 AI 服务时遇到的问题、解决方案和后续优化方向。

这次做 RAG 检索与排序后，我最大的收获是：RAG 不是“把文档交给大模型回答”，而是一条检索、排序、证据判断、生成回答的工程链路。关键词检索：适合技术术语、接口名、文件名等精确匹配。向量检索：适合语义相似、表达方式不同的问题。混合检索：把两者结合起来，提高召回稳定性。证据门控：避免检索结果只是主题相关，但没有真实答案。如果只看最终回答，很容易忽略中间问题。为什么搜到这些 chunk？为什么这个

这次做 RAG 检索与排序后，我最大的收获是：RAG 不是“把文档交给大模型回答”，而是一条检索、排序、证据判断、生成回答的工程链路。关键词检索：适合技术术语、接口名、文件名等精确匹配。向量检索：适合语义相似、表达方式不同的问题。混合检索：把两者结合起来，提高召回稳定性。证据门控：避免检索结果只是主题相关，但没有真实答案。如果只看最终回答，很容易忽略中间问题。为什么搜到这些 chunk？为什么这个

在做聊天项目接入 AI 知识库的时候，一个很容易被忽略的问题是：比如系统里有两个群：Java 学习群上传了一份 Netty 文档，Python 学习群上传了一份 FastAPI 文档。用户在 G10001 里问 AI 问题时，理论上只能查：不能查到：这就是所谓的群知识库隔离。在我的 X-Chat 项目里，这个隔离不是靠复杂的权限框架完成的，而是靠一个非常清晰的设计：其中，群知识库场景下：也就是说，

这篇文章结合我自己的聊天项目，拆解了 AI 回复“一个字一个字蹦出来”的实现原理。文章从 NDJSON 流式协议入手，讲解 Python FastAPI 如何通过 `StreamingResponse` 按行输出 JSON 事件，Java Spring Boot 如何用 OkHttp 按行读取并转成 WebSocket 消息，最后由 Vue 前端根据 `messageId` 将增量内容追加到同一条

为了解决上面的问题，我在项目里加了证据门禁。当前检索结果是否足够支持这个问题？我这里做的是一个学习版的证据门禁，主要通过问题中的关键字段和检索结果中的字段是否匹配，来判断证据是否足够。它不是最完美的方案，但能先解决“主题相关却没有答案”的误答问题。IP云服务器生产环境薪资内部公司那检索结果里也应该真的出现这些词。如果问题问的是生产环境 IP，但检索结果里完全没有 IP 或生产环境，就应该拒答。这一