搭建支持会话中上传文档的RAG聊天机器人的技术实践咨询

1. 会话与隔离：Weaviate多租户方案的合理性 #

• 不是过度设计，属于生产环境的标准可行方案，但要权衡资源成本：Weaviate的多租户机制天然支持数据隔离，每个会话对应一个租户能彻底避免跨会话文档泄露。但租户数量过多会增加集群元数据开销，可优化为同一用户的多个会话共享租户，或会话闲置超时后立即删除租户及对应数据，减少资源占用。
• 替代方案的风险：若用类（Class）+ 会话ID属性的方式做隔离，查询时需过滤会话ID，但生产环境曾出现过滤逻辑漏洞导致的信息泄露故障，安全性远不如多租户可靠。

2. 实时索引：处理延迟的落地方案 #

• 优先采用异步后台处理+状态反馈：阻塞等待大文件（如几十页PDF）会导致用户等待时间过长，直接拉低体验，生产环境中这种方案会大幅提升用户流失率。异步模式下，用户上传后立即返回“文档处理中，请稍候”的状态，后台用Celery+Redis任务队列处理分块、嵌入、索引流程。
• 渐进式索引技巧：先处理文档核心内容（标题、目录、前几页）完成初步索引，让用户能快速提问，剩余内容后台继续处理；分块时优先提取文本密度高的区域（如PDF正文），忽略页眉页脚，提升首次检索的有效性。
• 踩过的坑：曾因嵌入请求超时未配置重试，导致部分文档索引失败，用户提问时找不到对应内容，后来增加指数退避重试+失败告警才解决问题。

3. 混合检索：全局知识库与会话文档的协同方案 #

• 生产环境最常用并行检索+结果融合：同时检索全局知识库和会话文档的向量库，合并结果后按相关性排序。这种方案简单可靠，不会因路由判断错误遗漏信息。
• 查询路由方案的局限性：用LLM判断问题应检索哪个库，虽精准但增加额外LLM调用成本，且当问题同时涉及两者（如“结合我上传的财报和公司全局利润率指标分析情况”）时，路由极易出错，我们曾尝试该方案，因频繁判断错误最终切换回并行检索模式。
• 优化技巧：给会话文档的检索结果增加权重（如相关性得分乘以1.2），优先返回用户上传的内容，更符合用户预期。

4. 上下文感知问题：LLM重写查询的实际效果与边缘场景 #

• 标准方案的实际效果：大部分场景下足够好用，像“那利润率情况如何？”这类简单指代，GPT-3.5/4的重写准确率能达90%以上。生产环境中我们用GPT-4配合历史对话摘要（压缩长对话减少tokens），成本与效果平衡较好。
• 遇到的边缘场景：
  • 多轮指代混淆：用户先问“A产品营收”，再问“那它的成本呢？”，后续又问“B产品利润率呢？”，最后问“那它的情况呢？”，LLM易误将“它”判定为A产品，需在重写时加入最近3轮对话上下文。
  • 跨文档指代：用户上传两个文档，先问“文档1的营收”，再问“那它的利润率呢？”，LLM可能无法识别“它”指向文档1，需在会话中记录当前关注的文档标识，重写时同步传入。
• 踩过的坑：曾因仅传入最近一轮对话导致重写错误，改成传入最近3轮对话+会话文档列表后，准确率大幅提升。

生产环境技术栈与故障复盘 #

• 技术栈：OpenAI GPT-4o（嵌入用text-embedding-3-large）+ FastAPI + Weaviate（多租户模式）+ Celery（异步任务）+ Redis（任务队列+会话缓存）+ Unstructured（文档解析，支持PDF/DOCX/图片）
• 可行方案总结：
  • 会话隔离：Weaviate多租户+超时自动清理
  • 实时索引：异步任务+渐进式内容处理
  • 混合检索：并行检索+结果加权融合
  • 上下文问题：LLM重写+历史对话摘要+文档标识记录
• 曾导致故障的问题：
  • 异步任务未配置重试，部分文档索引失败
  • 类+属性隔离方案的过滤逻辑漏洞，引发数据泄露
  • 上下文重写时传入信息不足，导致指代错误
  • Weaviate租户未及时清理，集群元数据膨胀引发查询延迟升高

内容的提问来源于stack exchange，提问作者umair mehmood