AKKE决策调研 · DECISION RESEARCH · 2026
任务 3 / 8五大战略 · 主题4 · 微信自动化工作流（加V后两场景）
微信工作流要不要上 RAG 行业建模？先验证再决定
抖音获客→加微信→「小艳」人设在微信里自动/半自动回复、维系关系、聊到到店。问题不是「RAG 行不行」，而是「微信里的准客户到底问什么」——而那个答案，决定了 RAG 是解药还是稀释剂。
结论现阶段不上 先验证：微信对话更偏关系维系 + 订单特定，RAG 通用 FAQ 天花板 ≈ 20%；叠加企微 kf 的 48h / 5 条窗口 = 每条回复都更该精准。先抽真实微信 / kf 聊天记录做分类验证（通用 FAQ ≥ 40% 才上 RAG）。
≈20%
RAG 可覆盖率估计（通用 FAQ 部分）
31 条
现有知识库总量（13 文档 + 18 对话）
48h / 5 条
企微 kf 发送窗口约束（errcode 45047）
§1 WHETHER 先行：别给错题写答案
在问「用哪套 RAG / 怎么 embedding / 切多大 chunk」之前，先回答「这道题是不是 RAG 能答的题」。
RAG（检索增强生成）解决的是一类很具体的问题：当答案散落在一堆非结构化文字里、模型记不住或会编时，先检索相关片段、再让模型据此作答。它天然适配「产品规格、工艺说明、行业 FAQ」这类静态、文档型知识。
但微信工作流的对话对象不是路人——是已经从抖音加到微信的准客户。他们问的不是「全屋定制是什么」，而是「我那单进度到哪了 / 上次说的那个改动行不行 / 这周能不能到店看」。这些问题的答案不在任何文档里，在订单 / ERP / 上下文里。
刹车点：微信里给错题写答案，比抖音 DM 代价更高。RAG 能把「行业知识」答得更顺，但准客户的高频问题根本不在知识库——这时候堆知识不是增益，是稀释：挤占有限的 prompt 预算、冲淡「小艳」语气、还可能拿行业泛答去糊弄一个本该查订单的具体问题。先验证「题型分布」，再决定要不要这味药。
§2 覆盖率分解：RAG 能接住多少？
把准客户的提问拆成两类——RAG 能答的「通用 / 行业」 vs 只有上下文 / ERP 才有的「订单 / 关系特定」。
图1 · 微信准客户提问的 RAG 可覆盖率（估计）
通用 / 行业 FAQ ≈ 20%——工艺、节奏、流程、报价口径；静态文档型，RAG 可答
订单 / 关系特定 ≈ 80%——「我那单进度 / 上次说的 / 到店时间 / 款式改动」；只有上下文 / ERP 有
※ 20% 为方向性估计，非实测；§6 给出落地验证方法把它替换成真数字。
口径：以「加微后准客户」为对象（非抖音陌生评论）。RAG 的天花板 = 通用 FAQ 占比；这一块越小，上 RAG 的边际收益越低。
结论很直接：RAG 的上限，就是通用 FAQ 在提问里的占比。如果这块只有 ~20%，那么即便 RAG 做到完美，它也只能改善五分之一的对话——而剩下 80% 的订单 / 关系问题，RAG 不仅帮不上，检索回来的行业泛答还可能被模型当成「答案」糊上去。
§3 微信场景为何更不适合 RAG
两个叠加因素：①加微客户的问题更订单 / 关系特定；②企微 kf 的 48h/5 条窗口让「堆知识稀释」的代价更高。
图2 · 准客户提问的路由：谁该查知识库，谁该查订单
INPUT
加微准客户提问
已是高意向、问的多是「我那单 / 上次说的」
ROUTE A · RAG 可答
知识库可答
行业节奏 · 工艺做法 · 服务流程 · 报价口径
ROUTE B · RAG 答不了
只有上下文 / ERP 有
我那单进度 · 上次说的改动 · 到店时间 · 款式调整 · 尾款
Route A 是 RAG 的主场；Route B 要的是订单查询 / 对话记忆（text-to-SQL / API），不是向量检索。两条路混在一个知识库里，反而让模型分不清该「查文档」还是「查那单」。
图3 · 加微准客户提问类型占比（估计，订单 / 关系类显著更长）
方向性估计，待 §6 实测替换。要点不在精确数字，而在量级：订单 + 关系 + 到店三类（Route B）合计 ~80%，远超 RAG 能接的通用 FAQ。
两点要命的叠加：①加微客户的问题更订单 / 关系特定——他们已经是准客户，不再问「你们是干嘛的」，只问「我这单怎么样」，这部分 RAG 结构上答不了；②48h / 5 条窗口让稀释代价翻倍——企微 kf 在客户发消息后 48 小时内最多只能下行 5 条（超限 errcode 45047）。每一条回复都是稀缺资源，越该精准命中那一单，越不该塞一段「检索来的行业泛答」把宝贵的回复额度浪费在答非所问上。
§4 三条「现在不上」的硬事实（仓库核验）
不是「RAG 不好」，而是「按现状上 RAG，连地基都没浇」——三条都来自仓库实查。
① pgvector 从未启用
向量检索的底座根本没装。全仓唯一的 CREATE EXTENSION 是 pg_net；vector(1536) 列在 008_knowledge_base.sql:27,55 两处都还是注释行。要上 RAG，第一步得先 CREATE EXTENSION vector 并取消注释。
② 知识注入「rarely referenced」
现有全量注入已被证明用处不大，还被反向砍小。代码注释自陈知识库 llm.ts:228 "rarely referenced"；2026-04 把每轮注入从 1-2 条砍到 1 条、字符上限 3000 → 1500（KNOWLEDGE_CHAR_LIMIT），因为知识块会稀释 PERSONA 语气。
③ 内容稀薄 + 问题订单特定
检索没东西可检，且检了也答不到点。知识库共 31 条（13 文档 + 18 对话），体量撑不起向量召回；更根本的是准客户的问题多为订单特定——根因不是「检索质量差」，是「答案压根不在知识库」。
合起来看：地基（pgvector）没浇、现有的全量注入已被实测「rarely referenced」并主动缩量、内容只有 31 条且问题偏订单特定。在这三条同时成立时上 RAG，是给一个低频问题装重型基建。
§5 行业语境：RAG 的边界在哪
这不是 Akke 独有的坑——RAG 在垂直服务 / 客服领域的覆盖局限，是被反复印证的共识。
RAG 擅长非结构化文本，不擅长事务型数据。RAG 检索的是与提问语义相近的文本片段，适合「答案能从已有文字里综合出来」的问题；一旦答案需要从结构化字段精确取值（如订单状态），它就力不从心——业界普遍认为 RAG 对结构化数据的准确率常低于 60%，且最常见的失败模式正是「相关内容缺失（missing content）」，即问了一个文档里根本没有答案的问题。DreamFactory · API-First Alternative to RAG 2025 arXiv 2502.14930 RAGVA in Practice
订单 / 进度类问题属于「事务型」，要的是查询而非检索。客服领域对「订单状态」这类问题的主流做法是 text-to-SQL / API 直连结构化库与实时账户数据，把自然语言翻译成精确查询、返回确定字段值；而不是丢进向量库做相似度召回。换句话说，准客户「我那单到哪了」这种问题，正确解法是接订单系统，不是 RAG。Janea Systems · SQL-to-RAG Pipeline 2025 AI21 · RAG for Structured Data 2025
「加微后的准客户」问题更偏订单特定，是关系阶段的必然。RAG 客服的价值集中在「售前 / 通用答疑」——回答能从公司文档里综合出来的问题。一旦客户进入「已成交 / 进行中」的关系阶段，提问就从「是什么」转向「我的那一单怎样了」，重心从知识库迁移到交易 / 交互数据（service requests、purchases、进度）。微信工作流的对象恰好全是后者。Gladly · RAG for Customer Service 2025 Salesforce · What is RAG 2025
一句话：RAG 是「文档问答」的答案，不是「订单问答」的答案。微信工作流里 ~80% 是订单问答——所以问题不是 RAG 做得好不好，而是这道题压根不该交给 RAG。
§6 最小验证实验：用真数据替换那个 20%
所有「20% / 80%」都是估计。上不上 RAG，不该靠拍脑袋，而该靠一份 1 人 1 天就能做完的分类标注。
图4 · 「先验证再决定」实验流程（1 人 · 约 1 天）
STEP 1 · 抽样
抽真实记录
取 1 个 org 近 1 个月微信 / kf 聊天记录（加微后的真实对话）
STEP 2 · 打标
人工逐条分类
每条客户提问标「通用 FAQ」 or「订单 / 关系特定」二选一
STEP 3 · 算占比
算通用 FAQ 占比
通用 FAQ 条数 ÷ 总提问条数 = RAG 真实天花板
STEP 4 · 分流
阈值判定
≥ 40% → 上 RAG；< 40% → 投 copilot 精准草拟
阈值 40%：通用 FAQ 至少占四成，RAG 才有足够题面值得装基建；低于 40% 说明真正的瓶颈在订单 / ERP 接入与对话记忆，钱应投在那里。
✓ 通用 FAQ ≥ 40% → 上 RAG
- 题面够大，向量召回的边际收益能覆盖基建成本
- 走 §7 的「取消注释 + 装 extension」最小路径，无需改 schema
- 先在通用 FAQ 子集灰度，看人工接管率是否真降
✗ 通用 FAQ < 40% → 投 copilot 精准草拟
- 瓶颈在订单 / 关系问答，RAG 答不了，装了也白装
- 钱投在：接订单系统（text-to-SQL/API）+ 跨会话客户记忆
- 给运营做「精准草拟 + 一键发」copilot，比自动答更省那 5 条窗口
工作量：抽样 + 标注 + 算占比，1 人约 1 天。这一天的成本，远低于「先把 pgvector 上了、灌完 embedding、才发现 RAG 只能接住 20% 提问」的返工。先验证，再决定。
§7 若过关：HOW（一句话）
验证通过后，落地路径短到一句话——schema 早就预留好了。
最小落地路径 · 无需改 schema
CREATE EXTENSION IF NOT EXISTS vector; + 取消 008_knowledge_base.sql:27,55 两行 embedding vector(1536) 注释 → 回填 embedding → 把 buildKnowledgeSection() 的全量注入换成 top-k 向量召回。双表（knowledge_documents / conversation_examples）结构当初就为此预留，不动 schema。
注：HOW 之所以只值一句话，正因为难点从来不在工程，而在 §6 那个「通用 FAQ 占比」到底够不够 40%。先量它。
§ 资料来源
仓库核验（.ev）
· 008_knowledge_base.sql:27,55 vector(1536) 注释未启用
· 20260622152041_…:21 全仓唯一 CREATE EXTENSION = pg_net
· llm.ts:228 知识注入 "rarely referenced"
· llm.ts KNOWLEDGE_CHAR_LIMIT 3000→1500
· project_akke_knowledge_base.md 31 条 + 40% 验证门