670次问答、108个负反馈：一个工控知识库POC根因分析与优化方向
前两天知识星球里有个盆友提了个很典型的问题：系统做出来了，业务部门测了一圈反馈效果不行，但给不出具体指标。技术这边不知道该怎么下手调优，也不知道该用什么数据去跟领导汇报，在这个阶段是该申请更多资源支持还是调整预期。
这个问题在过去一年我接触的客户里非常普遍。不管是有 IT 团队自己先试错的，还是找外部供应商做初步验证的，在上线后的效果评测上都会碰到类似的困境。说实话，埋点设计本身不是什么难题，传统软件开发里已经有成熟的做法。真正的难点在于 RAG 场景下的归因分析。传统应用的 bug 定位相对直接，但 RAG 系统的问题可能来自多个环节：是检索没召回？是模型理解错了？是知识库本身没覆盖？还是用户问得太模糊？这些因素交错在一起，没有一套针对性的分析框架，确实很容易陷入"感觉效果不行但说不清哪里不行"的局面。带着这类问题来找我做咨询的客户也越来越多。
但坦白讲，作为外部服务商，在不清楚客户数据质量和项目现状的情况下，我也很难给出确定的交付承诺。客户这边预算有限，希望能花小钱办大事；我也因为被白嫖过太多次心累，不想跟进一个最后没法交付的项目。踩过n个坑之后，我现在通常会建议找来的客户先做一个为期一周的付费 POC。这个阶段不追求完美的系统交付，而是通过极简的架构快速跑通流程，核心是帮客户清洗核心数据、验证场景可行性，并产出一份基于数据的复盘报告。对客户来说，一周时间、可控成本就能拿到决策依据；对我来说，也能评估项目难度、筛选靠谱的合作机会。这笔费用不高，后续正式合作可以抵扣，实测了几个客户下来确实是一个双赢的双向选择方法。
本文的RAG归因分析示例效果
这篇试图说清楚：
如何定义一周 POC 的交付边界的（做什么与刻意不做什么）、POC 阶段的埋点应该记录哪些字段、如何对差评进行根因分析（检索不到、答错、超出范围各占多少）、用户提问有哪些典型的问题模式，以及如何把这些项目经验逐步沉淀为可复用的行业规则库。
以下，enjoy：
1、项目背景与 POC 阶段的取舍
这个项目之前公众号里介绍过的工控售后场景的case，客户是一家老牌工控软件厂商，大概有 1600 多份 Word 格式的技术文档，十几个工程师每天要在几十个微信群里回复客户的各种问题，工作量巨大且重复性很高，这也算是垂直领域知识库最标准的脏活累活场景。
从 1600+ 份 Word 文档到生产级 RAG：一个工控行业知识库的全链路实战复盘
面对这种需求，POC 阶段的定位非常关键。可能有些团队一上来就想做一个小而全的 MVP，把 Rerank、混合检索、甚至 Agent 流程都加上去，结果折腾了两三周部署都还没弄利索。
付费 POC 的核心目标只有一个，就是用最快的速度验证核心假设。客户掏一笔钱，不是为了买一个功能完美的软件，而是为了买一个预期。对于老板和一线工程师来说，他们关心的核心就一点，就是这套系统生成的回答，能不能减轻售后的压力？或者换句话说，理想的情况下把客户在微信群里的问题连同图片直接扔进去，系统输出的答案能直接复制发给客户，或者简单改改就能用。POC 阶段就是要验证当前的这套数据能不能达到这个效果。为了在一周内给到这个答案，我刻意做了一系列减法。
1.1、暂不引入 Rerank 和复杂评估平台
在这个阶段，我直接禁用了重排序步骤，也没有接入 Langfuse 或 Ragas 这种复杂的评估平台。在 POC 阶段，如果是纯向量检索都召回不到的内容，加了 Heavy Rerank 往往也解决不了根本问题。这时候的问题通常出在数据分块和清洗上。在验证阶段，为了那一点精度的提升去增加部署复杂度，性价比不高。
1.2、前端界面使用 Streamlit 快速搭建
很多客户会纠结界面好不好看，但在 POC 阶段，我会明确说明前端就是用 Streamlit 搭建的演示版。能对话、能展示引用的文档出处、能点赞点踩，这就够了。把时间省下来，全投入到数据清洗脚本的编写上，这才是影响最终效果的核心。
1.3、埋点做极简处理
这也是本文重点要讲的。在后续的正式版里，为了调优我会记录每个环节的中间分数（如向量相似度等）。但在 POC 阶段，只记录不同用户问了啥、系统回了啥、召回了哪几个文档以及用户满不满意（点赞/点踩）。因为现阶段不需要精细化调优，只需要通过这些宏观数据判断这套数据在当前的基础 RAG 架构下，大概能跑到什么水平。
值得一提的是，能做到一周交付，并不是因为纯手速快或者简单粗暴的 24h AI Coding，而是这套付费 POC 的交付逻辑本身已经标准化了。除了数据清洗依然需要针对每个客户的文档做定制化处理外，整套前后端的代码脚手架其实是一套固定的模板
做完这些减法并套用标准化模板后，所有的精力都聚焦在最重要的一件事上，就是如何客观地评估这套初版系统的回答质量？这就涉及到了一套标准化的埋点与复盘逻辑。
2、POC 埋点设计原则
在 POC 阶段，埋点设计需要在开发成本和分析需求之间找到平衡。记录太少无法定位问题，记录太多（如记录全量 Prompt、Embedding 向量等）又会增加不必要的开发负担。基于够用就好的原则，实际只记录了 5 个核心分析字段，几个项目实际跑下来证明这对于验证阶段也完全够了。当然，工程上还需要 session_id、created_at 这类基础字段来做会话追溯和时序分析，这些是自然就有的，不在下表单独列出。
| 字段 | 用途 | 考量 |
|---|---|---|
| original_query | 用户问题 | 做热词分析和问题聚类，看看用户到底在问什么 |
| llm_response | 完整回答 | 用于人工抽检回答质量，看有没有一本正经胡说八道 |
| final_context_filenames | 召回的文档 | 统计文档热度，看看哪些文档是被问到的 |
| feedback_score | 点赞/点踩 | 只有两个值（1/-1），用来统计最直观的满意度 |
| latency_total_ms | 总耗时 | 宏观判断响应速度，看用户能不能忍 |
至于像 Similarity Score（相似度分数）、LLM Prompt（提示词）以及 Rerank Score（重排分数）这些字段，在 POC 阶段刻意没有记录。原因也很简单，一期和客户明确说明了不进行精细化的召回阈值调优，也不做 Prompt 的 A/B 测试，更为了简化架构禁用了 Rerank，换句话说这些数据在当前阶段没有实际分析价值，记了也是冗余。
2.1、说个踩坑记录
最初版本里有个踩坑的小点，这里也顺便提下。为了方便后面用 Python 脚本分析，起初采用了一种双写策略，就是把日志同时写入 sessions.jsonl（文件追加）和 sqlite.db（数据库更新）。结果第一个项目 POC 复盘的时候发现用户反馈是异步的，就是当用户过了一分钟点赞的时候，SQLite 里的这条记录被更新了，但 JSONL 文件是追加写入的，之前写进去的那行记录里 feedback 字段还是空的。这就导致解析 JSONL 时以为没人反馈，必须去查数据库才能对上号。看下面这个对比应该能说明问题.
// 10:00:01 写入 sessions.jsonl (此时用户还没点赞)
{
"session_id": "sess_abc123",
"query": "KingView 启动报错...",
"feedback_score": null <-- 还是空的
}
// 10:00:45 用户点了赞，SQLite 记录更新
| session_id | query | feedback_score |
|-------------|-------|----------------|
| sess_abc123 | ... | 1 | <-- 数据库里有值了这也算是给各位提个醒，在 POC 阶段尽量保持单一数据源原则，要么全信数据库，要么全信日志文件，别搞这种复杂的同步逻辑。
3、POC 数据的调优分析
拿到这一周的数据后，我用一套标准化的 Python 脚本（Pandas + Echarts）进行了复盘。
3.1、整体数据画像
这个项目当时一周时间跑下来，一共发生了 670 次实际问答。得益于管理层在 POC 期间的配合，虽然没有在系统层面做强制拦截，但明确的行政要求保障了数据的置信度，最终的反馈率高达 53%，当然实际上我希望能够更高一点，所以现在会和客户在 POC 的合作协议里面明确写出来这部分反馈率的要求。
在没有做精细化 Rerank 的前提下，好评率定格在 69.7%。这个数字看起来不高，但后面根因分析会讲到，差评里有 37% 是因为知识库本身没有相关文档（超出范围），如果剔除这部分，系统本身的好评率理论上可以达到 79% 左右，这个水平在 poc 阶段基本可以接受。
3.2、性能瓶颈的客观归因
虽然这类需求并不是一个对响应延迟要求很高的场景，但性能也是大部分客户会关注的焦点。脚本最初拉出的 P50 耗时高达 57 秒，深入分析日志后，发现这其实是统计口径和异常数据造成的误导。真实的推理首字延迟在 3-5 秒 左右，受限于 Mac Mini 的内存带宽，确实需要几秒钟的预处理时间，这属于物理硬件的限制。
那 57 秒 的离谱数据是怎么来的？其实是 排队时间 + 推理时间。虽然只有十几个用户，但大家测试的时间点比较集中。在 Mac Mini 上，处理一个几千字上下文的请求，完整的推理（端到端吐完所有字）可能需要 20-30 秒。这意味着只要有 2-3 个人如果不凑巧撞在一起发请求，后面那个人的等待时间就会叠加前面的耗时，直接奔着一分多钟去了，甚至触发 180s 的网关超时。处理这类问题的做法是在统计时先过滤掉异常值，再计算分位数：
# 过滤超时请求，只统计正常响应（<150s）
normal_latencies = [l for l in latencies if l['total'] < 150000]
# 按总耗时排序，取中位数位置的请求作为 P50
sorted_normal = sorted(normal_latencies, key=lambda x: x['total'])
p50_request = sorted_normal[len(sorted_normal) // 2]剔除掉这些因排队导致的极端数据，单次请求的正常耗时在 20 秒上下，对于微信群形式的售后问答场景，这个等待延迟基本可以接受。
关于生产环境的性能优化，不同客户需求偏好略有不同。如果客户对成本敏感且愿意接受部分数据走公网，通常会采用端云协同的方案。也就是设计一个路由层，把不敏感的通用逻辑（比如通用代码解释、闲聊润色）路由到云端 API 处理，速度快且便宜；而涉及核心资产的敏感查询（设备参数、故障日志）则强制走本地模型。如果客户坚持全私有化且并发量确实上来，那就简单直接加硬件，再买几台 Mac Mini 做负载均衡，或者上专业的推理加速卡。
3.3、差评根因分析
这个项目的 670 轮对话里，一共有 108 个差评。我先用脚本把所有差评数据拉出来，拉出来之后，下一步是给每条差评做根因分类。
# 从 SQLite 拉取所有差评记录
cursor = conn.execute("""
SELECT session_id, full_data, feedback_comment
FROM qa_sessions
WHERE feedback_score = -1 -- 只筛选点踩的记录
ORDER BY timestamp DESC
""")
这里有个选择，是让业务专家人工标注，还是用大模型辅助？实际操作中我选择了后者。原因很简单，POC 阶段业务专家时间或者配合力度有限，让他们逐条看 108 条差评不太现实；而且差评记录里往往已经有用户的评论理由（比如"答非所问"、"根本没找到相关文档"），大模型可以结合 query + response + 召回文档 + 用户评论综合判断，效果不比人工差。跑一遍分析只需要调几十次 API，成本也就几块钱，最后人工抽检验证即可。
这其实也是我在这类项目里总结出来的一个分工原则：数值型指标用脚本直接统计（好评率、P50 耗时、文档热度），语义型分析交给大模型（差评根因、问题模式、意图识别），人工只做抽检和最终确认。这样既保证了效率，也不会漏掉太多细节。不过标注完成之后，发现和最开始的假设实际还有些偏差。
1. 检索不到（约 24%）
这类问题的表现是系统压根没召回相关文档，或者召回的文档和问题完全不沾边。但检索不到只是表象，背后可能有几种原因：一种是用户的表述太口语化，和文档里的标准术语对不上（比如用户说"光电"，文档里写的是"光电耦合器"）；另一种是文档切片方式有问题，关键信息被拆散了。这部分需要在正式上线前做更深度的分析，POC 阶段先把问题识别出来就够了。
2. 检索到但答错（约 35%）
这类问题是系统找到了相关文档，但最终的回答质量不行。要么理解错了，要么输出格式乱了（JSON 解析失败），要么答非所问。优化思路有几个方向：一是调 Prompt，用 Few-Shot 给模型更多的上下文样例；二是加 Rerank，让相关的文档排得更靠前（当然前提是召回集里确实有相关内容，如果 TopK 里压根没有相关 chunk，再重的 Rerank 也无能为力）；三是考虑模型路由，简单的参数查询用14b这样的小尺寸模型，复杂的故障诊断走 30b 或云端 API。
3. 超出知识库范围（约 37%）
这个结论说意外也不意外，做过几个知识库项目就会发现，很多客户自认为完整的文档库，往往可能也只是覆盖了 80% 的场景。这个项目也是典型，对方提供了 1600 多份文档，说是全量资料，我也确实对每一份都做了数据治理和入库。但真正跑起来才发现，一线工程师的测试问题五花八门，总有一部分知识还停留在老师傅的脑子里，或者散落在微信群的聊天记录中，从来没形成过书面材料。比如用户问的是"A 型号怎么配置"，但知识库里只有"B 型号"的文档。对于这类问题，调参数肯定没用。不过在实际交付的时候，直接告诉客户"这是你们文档不够"往往不太好交代，需要有一套自证的方法。
我在这类项目通常会用三级验证：
先做一轮术语展开（缩写/别名映射）后的关键词检索，如果仍然零命中，这是"可能超纲"的强信号；然后看向量检索返回的 Top1 相似度分数，如果明显低于正常匹配的分布区间（这个阈值需要根据具体的 Embedding 模型和业务数据做校准，本项目上校准后的经验值大概在 0.3-0.5 之间，仅供参考），说明检索到的东西和问题语义上就不沾边；最后还有一个辅助诊断的思路，就是让 LLM 根据问题生成一段"假设性文档"。不是让它回答问题，而是让它描述"如果知识库里有这个内容，它大概会怎么写"，然后用这段描述去反向检索，如果连这个假设性文档都匹配不到任何内容，那基本可以确认知识库里确实没有相关资料。
不过有些客户对上面这套验证逻辑还是理解起来有点费劲，毕竟"相似度分数"和"假设性文档"这些概念比较抽象。这种情况下我会做一些可视化的向量分布图来辅助说明。大致做法是先把知识库所有文档 Chunk 的 Embedding 向量用 UMAP 算法降维到二维平面，然后挑选 2-3 个有代表性的超纲问题，把它们的向量也投射到同一张图上。实现上就是用 sentence-transformers 生成向量，再用 umap-learn 做降维，最后用 matplotlib 画散点图，整个流程几十行 Python 代码就能跑通。
注：绿色是范围内问题，红色是超纲问题
举例来说，上图中的蓝色点是知识库文档的向量，聚成几个簇，分别对应"组态配置""通讯协议""故障排查"等主题；绿色是正常问题，落在簇里面或附近；红色是超纲问题，明显落在远离所有簇的无人区。做到这一步大部分客户基本就一看就 get 了。当然，降维会丢失高维空间的信息，这类图示更多是帮助客户直观理解用的，严谨的验证还是得靠上面的三级方法。
基于这个分析结论，如果客户认可 POC 的效果并确认正式合作的话，在上生产环境之前，算法层面的调优（Rerank、Prompt 优化、模型路由等）当然要做，但同样重要的是建立一套知识库的增量更新机制。这套机制要做成业务人员也能操作维护的，不能只有技术人员才能碰。
至于后续的运维模式，不同客户有不同的偏好，有的客户希望像传统软件一样每年付运维费、外部团队长期支持；但也确实有客户更希望自己掌握主动权。我个人更倾向于后者，也就是培训客户的技术和业务团队，教会他们如何识别超纲问题、如何补充文档、如何验证效果。毕竟知识库的日常维护本质上是业务工作，最懂哪些问题超纲的是客户自己，而不是外部技术团队。当然，如果客户遇到复杂问题，也可以按年度顾问或按次咨询的方式继续合作，这样双方都比较灵活。
3.4、问题模式分析
除了差评归因，我还对 original_query 做了一轮词频和模式分析。用户提问的不规范性在预期之内，或者很难预设不同的用户按照什么套路出牌。但每接触一个新的业务场景，不规范的程度和方式确实都不一样，这也是为什么 POC 阶段我刻意不做任何前置的培训或引导，就是要让用户按照最自然的方式去提问，反映真实的使用习惯。在这个项目里观察到的几个典型问题：
缩写泛滥
用户在微信群里问问题非常随意，各种缩写和黑话层出不穷。比如"控制器"直接叫"头子"，"通讯线"叫"485"，"光电耦合器"就叫"光电"，"KingView"有人写"KV"有人写"组态王"。另外还有更离谱的，有工程师直接发一串报错代码问"这是啥意思"，连主语都省了。这些表述如果不做 Query Rewrite（查询改写），根本匹配不到文档里的标准术语。所以二期必须建立一套术语映射表，把常见的缩写和黑话翻译成标准表达。
意图模糊
很多问题一句话问好几件事，或者问得太笼统。比如"KingView 怎么配置通讯，另外上次那个报错解决了没"，这其实是两个问题。还有人问"系统老是报错怎么办"，但不说是什么错、什么场景、什么版本，系统根本没法回答。不做意图拆分和澄清引导，系统要么胡乱回答一通，要么只回答了其中一个问题。这部分的优化思路是加一层意图识别，如果检测到多意图或者意图不清晰，就主动追问让用户补充信息。
高频热点明显
虽然客户提供了 1600 份文档，但统计下来，80% 的提问集中在其中 50 份文档上（这里的"集中"是按被召回/被引用的文档频次统计的）。这又是一个典型的二八法则。这个发现对二期的优化策略有很大指导意义。与其对 1600 份文档都做精细化切分（工作量巨大），不如先集中精力把这 50 份热点文档的切分策略、元数据标注、QA 对补充都做到位。等这部分效果稳定了，再逐步扩展到其他文档。这种"先攻高频、再扩长尾"的策略，在很多项目里实测对于效果提升的性价比都比较高。
4、产品化思考：垂直场景 RAG 的核心壁垒
前面讲的都是 POC 阶段的事情。至于后续的检索增强、架构升级、安全加固这些，每个项目情况不同，都是边做边改的事情。这里不展开赘述，关键是和客户对齐预期、把控好迭代节奏。我更想聊的是，做了十几个类似的项目之后，除了前两篇文章给大家介绍的 rag 文档入库前的扫描工具之外，还有什么东西是可以沉淀下来、可以复用的？
做了十几个知识库项目后，我把入库前的文档摸底流程产品化了
4.1、通用框架解决不了的问题
市面上的 RAG 框架已经很多了，RAGFlow、Dify、FastGPT 等等。这些框架在分块策略、检索策略上提供了各种穷举的选项，功能很全，但对于真正落地的垂直场景项目来说，尤其是中小企业来说往往太重了。
更关键的是，这些框架解决的是"怎么切、怎么检索"的技术问题，但解决不了这个行业的数据长什么样、用户怎么提问的业务问题。比如本文中演示的工控领域：用户会把"KxxxSCADA"简写成"KS"或"组态王"；"IO 没数据"可能指的是 KxxxIOServer 采集不到，也可能是变量显示不更新；"授权失效"需要区分是软授权还是硬件锁，不同类型的排查步骤完全不同。这些行业特有的表达方式和业务逻辑，没法靠通用框架配置出来，只能靠在项目里一点点积累。
4.2、行业规则库
我现在的做法是，每做完一个项目，就把积累下来的规则抽取出来，形成一套行业规则库。这个规则库大致包含几个部分：
术语映射表
把用户常用的缩写、黑话映射到标准表达。以这个项目为例（脱敏后）：
| 用户可能的表达 | 标准术语 |
|---|---|
| KS / ks | KxxSCADA |
| KIO / kio / io 服务 | KxxIOServer |
| KV / kv / 组态王 | 组态王 (KxxView) |
| 485 / 四八五 | RS-485 通讯线 |
| 头子 / 控制头 | 控制器 |
| 深思锁 / 圣天锁 | 加密锁 (具体型号) |
问题模式库
把高频的问题模式归类，针对每种模式设计追问模板和检索策略。比如：
| 问题模式 | 示例 | 需要补充的信息 |
|---|---|---|
| XX 没数据 | "io 没数据" | 是哪个软件？是采集不到还是显示不出？ |
| XX 崩溃/闪退 | "KS 软件闪退" | 操作系统版本？软件版本？崩溃前的操作？ |
| 授权失效 | "授权失效了" | 软授权还是硬件锁？具体错误提示？ |
意图分类规则
根据 POC 阶段的数据统计，这个项目的用户意图大致分为六类：故障排查与问题解决、配置与操作指导、授权与加密锁问题、功能咨询与产品介绍、数据存储与历史库、Web 发布与客户端问题。
针对不同的意图类别，检索策略和回答模板是不一样的。比如故障排查类需要先引导用户确认版本和报错信息，配置指导类则可以直接给出步骤。
4.3、垂直 SaaS 而非通用框架
这些规则积累到一定程度之后，它就不只是项目经验，而是可以产品化的资产。我现在的思路是不做通用的 RAG 框架（市面上已经够多了），而是做垂直场景的 RAG SaaS。比如专门针对工控行业的知识库助手、专门针对水处理设备集成行业的报价助手。每个垂直场景背后，都有一套针对这个行业的规则库在支撑。技术栈本身（用 LangChain 还是 LlamaIndex）反而变得不那么重要了，真正能沉淀下来的是对行业数据和用户习惯的理解。
另外实测不同垂直行业之间的规则库迁移性其实比想象中要高。比如"术语映射表"的结构是通用的，换一个行业只是换一批术语；"问题模式库"的追问逻辑也可以复用。先把一两个细分领域吃透，再逐步扩展，这个路径会更务实一些。专注一个行业不是局限，而是只有在具体场景里反复打磨，才能真正深化对技术边界的理解。
在场景的选择上，因为找过来的项目确实比较多，我会有意识地挑着做，尽量覆盖不同的技术方向。比如知识库问答类侧重检索和生成，报告生成类侧重长文本输出和格式控制，审查类侧重精准匹配和风险识别，还有一些隐患识别类的项目会涉及多模态。不同类型的项目对技术栈的要求不一样，也能帮助团队沉淀更全面的能力。
5、写在最后
最后总结几个核心观点，首先付费 POC 是双赢的，用可控的成本验证可行性，比盲目签大单靠谱；其次好评率低不一定是模型有问题，可能是知识库不全，做数据分析要先把归因逻辑想清楚；最后是做垂直行业项目，技术栈不是壁垒，行业 Know-how 才是，每个项目都是个积累可产品化的资产的机会。
春节期间我会抽时间把相关的工具进行部分开源。除了本文提到的规则库结构和分析脚本，后续还会逐步开源一套轻量级的 RAG 前后端框架，包括分块策略、检索策略的模块化配置，目标是做到开箱即用、按需调整。和 RAGFlow、Dify 这些全功能框架不同，我尝试从实际项目里提炼出一套更轻、更灵活的方案，适合中小团队快速落地垂直场景。完整版本和持续更新会发布在知识星球里。
另外，这个项目我会用真实数据的格式生成一批模拟数据，把相关的分析脚本、Streamlit 前端模板、清洗脚本都打包放在视频教程和知识星球里，方便大家测试整个流程。如果你也是一线从业者，欢迎加入者星球《企业大模型应用从入门到落地》
