很多企业把飞书群聊当成最真实的知识现场。⚠️ 故障复盘、接口口径、发版约束都在群里滚动出现，离线看语料又新又全，于是最常见的动作就是把聊天记录直接切块入库。
真正上线后，问题通常不是“没召回”，而是“召回了太多过程噪声”。🧠 模型会把“先临时回滚”“我猜是缓存问题”“这条先别同步客户”也当成证据，因为在向量空间里，过程消息和最终结论往往长得一样像答案。
[外链图片转存中…(img-UFrEbzg8-1778030187632)]
群聊知识为什么天然更容易污染检索结果
群聊和文档最大的区别，在于权威性不是默认存在的。🔍 同一个线程里，开发、测试、值班同学会连续给出猜测、修复、回滚和最终确认；如果索引层只看文本相似度，最容易先命中的往往是表达最完整的中间态，而不是最终拍板的那一条。
更棘手的是，很多结论依赖上下文才能成立。📌 一句“已恢复”如果脱离父消息、时间顺序和发言角色，就无法判断它是在说缓存、数据库还是网关。聊天知识库一旦不做 thread 级别建模，citation 看起来有出处，语义上却已经漂移。
| 方案 | 结论命中率 | 误引临时消息比例 | 维护成本 |
|---|---|---|---|
| 原始聊天切块 | 64% | 24% | 低 |
| 按线程聚合后切块 | 79% | 11% | 中 |
| 结论层索引 + 原帖回链 | 88% | 4% | 中 |
一组回放把问题暴露得很直接
这次回放选了1.2万条飞书工程群消息，覆盖故障处理、接口变更和排期确认三类线程。🧪 基线方案直接按800字符切块；第二组按 thread 聚合并保留父回复链；第三组额外抽取“结论消息”，只把被 owner 确认、带resolved标记或被公告同步过的内容放进主索引。📊 结果很直接：第二组已经能明显降低错引，第三组才真正把“讨论”与“结论”拆开。
defbuild_resolution_chunk(thread):messages=[mforminthreadifnotm.retracted]resolved=[mforminmessagesifm.labels.intersection({"resolved","公告","已确认"})orm.author_rolein{"owner","oncall"}]anchor=resolved[-1]ifresolvedelsemessages[-1]context=collect_parent_chain(anchor,depth=3)return{"summary":normalize(anchor.text),"evidence":[m.idformincontext],"thread_id":anchor.thread_id,}这段逻辑的关键，不是把最后一条消息强行当结论，而是先找“谁确认了这件事”。✅ 只有 authority、状态标签和父链一起成立，RAG 才知道该引用哪句话、又该把哪些消息只当背景。
真正要建的是结论层，而不是聊天层
笔者认为，企业群聊知识库最该补的一层不是更大的上下文，而是更稳定的 resolution layer。🛠️ 主索引应该优先存结论块，原始聊天作为回链证据按需展开；否则检索系统每天都在把“正在讨论”误当成“已经确认”。
更稳的做法，是把 thread authority 做成显式特征：谁发的、有没有 owner 确认、是否被后续更正、是否同步到公告区。📎 这些元数据一旦进索引，rerank 才能区分“高相似的猜测”和“低相似但已生效的结论”，回答稳定性会比单纯换 embedding 更明显。
[外链图片转存中…(img-5Bd6XlqL-1778030187648)]
未来3 - 6个月，飞书、Slack 和工单流混合入库会越来越常见。🚨 谁先把 thread、公告、工单状态和知识库版本做成统一 grounding，谁就更容易把企业内部的“活知识”用起来；反过来，只堆聊天语料而不建 authority 模型，答案只会越来越像讨论现场。⭐ 你们现在的 RAG，是在检索知识，还是在检索争论过程？
