做企业微信二次开发做到一定程度都会撞到同一堵墙客户问的问题越来越杂客服背不动的知识越来越多。把知识库接进来让消息回调里那条问题自动找到答案再回出去是大多数团队最终都要走的路。这篇就聊聊怎么用 Eyun 企业微信 API 把知识库接到企微会话里搭一套能跑起来的智能问答系统。一、先理清楚整个问答链路很多人一上来就研究向量化、研究 embedding 模型其实工程上更应该先理清楚链路。一个最小可用的问答系统包含四个环节环节输入输出由谁负责接收企微回调推送的消息结构化问题文本Webhook 接收层检索问题文本候选知识片段知识库检索层生成问题 候选片段回复文本LLM 或模板拼装层回写回复文本调消息接口发出API 调用层四段中间任何一段卡住整个链路就断了。常见踩坑是把精力全压在检索和生成上结果接收层没做好幂等同一条消息被处理两遍客户收到两条重复回复或者回写层没处理错误码检索到了答案但消息发不出去客户在那头等。二、接收层把回调消息变成问题文本Eyun 企业微信 API 推过来的回调报文里文本消息的正文在content[].textcontentType为0或2。接收层要做的不是简单取字段而是做几件事验签用首次设置回调时返回的secret校验请求防止伪造推送。幂等以data.msgId为唯一键处理过的直接返回 2xx不再走后续链路。过滤把群聊里 本号的消息、单聊直发消息区分开把命令类消息比如#转人工路由到不同处理分支。上下文拼装客户提问经常是上下文相关的比如先问你们产品支持私有化部署吗再问价格多少。第二句单独看没有主语需要把同会话最近 N 轮历史拼进去一起送检索。conversationId是会话维度的唯一键单聊就是对方 userId群聊是 roomId用它做上下文缓存键最合适。三、检索层知识库怎么组织知识库接进来不是把文档往向量库一塞就完事。要分清三种知识形态形态特点检索方式典型内容结构化FAQ问题-答案对明确关键词 语义混合怎么申请退款 → 标准回答非结构化文档长文模糊切块 向量召回产品白皮书、操作手册业务实时数据需要查接口才能答意图识别 API 查询我的订单到哪了这三种知识用一套检索逻辑处理一定会出问题。FAQ 走精确匹配最快最准长文档走向量召回才有意义业务数据根本不在知识库里要走意图识别后再调对应业务接口。一个比较稳的检索分层结构第一层 关键词命中先对问题做分词、同义词扩展命中 FAQ 直接返回。覆盖 60% 高频问题延迟低。第二层 向量召回关键词没命中走向量检索召回 TopK 片段再用 rerank 模型精排。覆盖 30% 长尾问题。第三层 意图路由识别为业务查询类订单、工单状态不查知识库直接调业务接口拿数据。置信度低于阈值的不强行回答标记为需转人工。四、生成层模板优先LLM 兜底检索回来的候选片段怎么变成发给客户的回复别一上来就 LLM 自由生成风险大、延迟高、成本贵。推荐分层FAQ 命中直接用预先写好的答案零延迟零幻觉。文档片段召回且置信度高用 LLM 做摘要式生成把片段重组成自然语言回答。多片段召回用 LLM 做 fusion把若干片段揉成一个连贯回答。置信度低不生成走转人工流程。LLM 生成时一定要带约束 prompt要求只基于给定片段回答明确告诉它片段里没有的内容回答该问题暂无法回答已为您转接人工。这一步看起来简单但是阻止幻觉的关键。五、回写层把答案发出去拿到回复文本之后调 消息模块 的sendText接口发回去。几个细节conversationId要用回调报文里的原值不能拿数据库里存的旧值客户可能换设备登录导致 uin 变化。长回答超过 600 字最好分段发企微消息有长度上限。群聊场景下记得带列表把提问人 出来否则群里没人知道这条回复是回给谁的。调用失败要重试但重试前先看错误码-11001是断线要先调reconnect再重试-11002是挤号别重试直接告警。六、上下文与多轮对话客户问问题很少一轮就完事多轮对话是绕不开的坎。工程上的做法是在检索层之前加一层会话状态机状态触发条件行为idle默认走标准问答流程clarifying检索置信度中反问客户澄清意图confirming涉及高风险操作让客户确认后再执行human转人工问答流程退出等人工接管状态机的好处是让系统行为可预测。客户问退款系统反问是订单 A 还是订单 B客户回A这时候不应该再走一遍完整检索而是走 clarifying → confirming 的分支直接带着上一轮的上下文继续。七、知识库维护与效果度量上线只是开始真正决定系统好不好用的是持续运营。要埋两组指标效果指标问答命中率多少比例的问题被知识库成功回答人工接管率多少问题最终转人工客户满意度通过消息回复后的正向反馈统计性能指标端到端延迟从回调到达到消息发出P95 应控制在 3 秒内检索延迟向量召回 P95 在 200ms 内生成延迟LLM 调用 P95 在 1.5 秒内知识库要定期做两件事一是把人工客服处理过的优质回答回灌到知识库二是把高频但答不准的问题标出来补充对应知识。这个闭环比换更强的 LLM 重要得多。写在最后把知识库接到 Eyun 企微平台 上做智能问答技术方案本身不复杂复杂的是工程细节幂等、上下文、置信度阈值、转人工时机、知识库运营。这些细节任何一处糊弄上线就会被投诉淹掉。把链路拆清楚、分层实现、持续运营这套系统才能真正减轻客服压力而不是成为新的麻烦源头。 企业微信API接口如何连接知识库？打造企业微信智能问答系统的技术方案
做企业微信二次开发做到一定程度都会撞到同一堵墙客户问的问题越来越杂客服背不动的知识越来越多。把知识库接进来让消息回调里那条问题自动找到答案再回出去是大多数团队最终都要走的路。这篇就聊聊怎么用 Eyun 企业微信 API 把知识库接到企微会话里搭一套能跑起来的智能问答系统。一、先理清楚整个问答链路很多人一上来就研究向量化、研究 embedding 模型其实工程上更应该先理清楚链路。一个最小可用的问答系统包含四个环节环节输入输出由谁负责接收企微回调推送的消息结构化问题文本Webhook 接收层检索问题文本候选知识片段知识库检索层生成问题 候选片段回复文本LLM 或模板拼装层回写回复文本调消息接口发出API 调用层四段中间任何一段卡住整个链路就断了。常见踩坑是把精力全压在检索和生成上结果接收层没做好幂等同一条消息被处理两遍客户收到两条重复回复或者回写层没处理错误码检索到了答案但消息发不出去客户在那头等。二、接收层把回调消息变成问题文本Eyun 企业微信 API 推过来的回调报文里文本消息的正文在content[].textcontentType为0或2。接收层要做的不是简单取字段而是做几件事验签用首次设置回调时返回的secret校验请求防止伪造推送。幂等以data.msgId为唯一键处理过的直接返回 2xx不再走后续链路。过滤把群聊里 本号的消息、单聊直发消息区分开把命令类消息比如#转人工路由到不同处理分支。上下文拼装客户提问经常是上下文相关的比如先问你们产品支持私有化部署吗再问价格多少。第二句单独看没有主语需要把同会话最近 N 轮历史拼进去一起送检索。conversationId是会话维度的唯一键单聊就是对方 userId群聊是 roomId用它做上下文缓存键最合适。三、检索层知识库怎么组织知识库接进来不是把文档往向量库一塞就完事。要分清三种知识形态形态特点检索方式典型内容结构化FAQ问题-答案对明确关键词 语义混合怎么申请退款 → 标准回答非结构化文档长文模糊切块 向量召回产品白皮书、操作手册业务实时数据需要查接口才能答意图识别 API 查询我的订单到哪了这三种知识用一套检索逻辑处理一定会出问题。FAQ 走精确匹配最快最准长文档走向量召回才有意义业务数据根本不在知识库里要走意图识别后再调对应业务接口。一个比较稳的检索分层结构第一层 关键词命中先对问题做分词、同义词扩展命中 FAQ 直接返回。覆盖 60% 高频问题延迟低。第二层 向量召回关键词没命中走向量检索召回 TopK 片段再用 rerank 模型精排。覆盖 30% 长尾问题。第三层 意图路由识别为业务查询类订单、工单状态不查知识库直接调业务接口拿数据。置信度低于阈值的不强行回答标记为需转人工。四、生成层模板优先LLM 兜底检索回来的候选片段怎么变成发给客户的回复别一上来就 LLM 自由生成风险大、延迟高、成本贵。推荐分层FAQ 命中直接用预先写好的答案零延迟零幻觉。文档片段召回且置信度高用 LLM 做摘要式生成把片段重组成自然语言回答。多片段召回用 LLM 做 fusion把若干片段揉成一个连贯回答。置信度低不生成走转人工流程。LLM 生成时一定要带约束 prompt要求只基于给定片段回答明确告诉它片段里没有的内容回答该问题暂无法回答已为您转接人工。这一步看起来简单但是阻止幻觉的关键。五、回写层把答案发出去拿到回复文本之后调 消息模块 的sendText接口发回去。几个细节conversationId要用回调报文里的原值不能拿数据库里存的旧值客户可能换设备登录导致 uin 变化。长回答超过 600 字最好分段发企微消息有长度上限。群聊场景下记得带列表把提问人 出来否则群里没人知道这条回复是回给谁的。调用失败要重试但重试前先看错误码-11001是断线要先调reconnect再重试-11002是挤号别重试直接告警。六、上下文与多轮对话客户问问题很少一轮就完事多轮对话是绕不开的坎。工程上的做法是在检索层之前加一层会话状态机状态触发条件行为idle默认走标准问答流程clarifying检索置信度中反问客户澄清意图confirming涉及高风险操作让客户确认后再执行human转人工问答流程退出等人工接管状态机的好处是让系统行为可预测。客户问退款系统反问是订单 A 还是订单 B客户回A这时候不应该再走一遍完整检索而是走 clarifying → confirming 的分支直接带着上一轮的上下文继续。七、知识库维护与效果度量上线只是开始真正决定系统好不好用的是持续运营。要埋两组指标效果指标问答命中率多少比例的问题被知识库成功回答人工接管率多少问题最终转人工客户满意度通过消息回复后的正向反馈统计性能指标端到端延迟从回调到达到消息发出P95 应控制在 3 秒内检索延迟向量召回 P95 在 200ms 内生成延迟LLM 调用 P95 在 1.5 秒内知识库要定期做两件事一是把人工客服处理过的优质回答回灌到知识库二是把高频但答不准的问题标出来补充对应知识。这个闭环比换更强的 LLM 重要得多。写在最后把知识库接到 Eyun 企微平台 上做智能问答技术方案本身不复杂复杂的是工程细节幂等、上下文、置信度阈值、转人工时机、知识库运营。这些细节任何一处糊弄上线就会被投诉淹掉。把链路拆清楚、分层实现、持续运营这套系统才能真正减轻客服压力而不是成为新的麻烦源头。