消息留存只解决"存得下"，解决不了"查得到"。客户投诉要调三个月前的聊天记录、主管要抽查客服质量、运营要找某类问题的典型对话——这些需求全靠检索系统。这篇讲在留存数据之上建检索与质检的方案。

背景痛点

留存库是按时间追加的流水表，查"某客户近三个月聊过什么"要扫大量数据；"找出所有承诺过返现的对话"更是全表翻。留存做完了才发现，数据越多，人越找不到东西。

原理

所谓会话检索，是指对留存消息建立面向查询的索引结构：

消息流水 → 清洗分词 → 建全文索引 → 按客户与会话聚合 → 提供查询。

两条查询主线：按主体查（某客户的完整会话时间线）与按内容查（关键词、语义匹配）。质检建立在检索之上：定义质检规则（响应时长、敏感词、承诺类话术），定期抽样跑规则，输出质检报告。

核心实现

检索层的索引写入（示例代码，需按官方文档校验）：

def index_message(msg):
    # 示例代码，需按官方文档校验
    doc = {
        "msgId": msg.id,                     # 与留存表对齐的主键
        "conversationId": msg.conversationId,
        "externalId": msg.externalId,        # 客户维度聚合键
        "text": normalize(msg.text),
        "ts": msg.ts,
    }
    es.index(index="wecom_msgs", document=doc)

按客户聚合用 externalId 字段，按内容查用全文索引。同步拉取补历史数据时走同一入口，保证索引完整。消息留存与同步拉取的说明见消息模块文档，客户 ID 体系见联系人模块文档。

踩坑

一、索引与留存表用同一主键：两边对不上，质检报告就不可信，这是检索系统最大的隐性成本。

二、媒体消息索引不到正文：图片语音只有类型没有文本，质检规则别指望覆盖全部会话，覆盖率要如实标注。

三、质检是抽样不是全量审判：全量规则跑下来误报海量，客服团队的抵触会毁掉整个机制；抽样加人工复核是可持续的形态。

四、检索结果脱敏展示：能查到所有会话的权限只给到需要的角色，检索系统本身要按数据合规设计。

总结

检索与质检的顺序：先索引（按主体查是刚需）、再语义检索（按内容查是增值）、最后质检（有了查询能力才做得起来）。这篇基于 Eyun 平台的企微接口整理，接口与字段以官方文档为准，质检规则上线前先跑历史数据校准误报率。