同事在群里甩了一张截图 上周三下午，运营在群里 @ 我，配了张图：用户问"退款多久到账"，机器人答"7 个工作日内"。而政策文档在 6 月 2 日就改成了"3 个工作日"。 后台里那份 PDF 更新时间是 6 月 2 日 15:47，状态"已解析、已入库"。文档是新的，索引里的内容是旧的。 这篇记录
「我们的知识库问答准确率只有 71%，要不要做微调」 去年 11 月，业务方拿着一份评测报告来找我：客服问答准确率 71%，离可用的 85% 差得远。他们的结论是「做微调，把行业知识训进模型」。 我说先别急，让我把两条路都跑一遍再决定。这篇是三个月实测的结果，包括所有成本数字。结论先放：我们最后选了
知识库从 5 万文档涨到 320 万，第一版设计撑不住了 我们公司的知识库最早是给客服用的，5 万篇 FAQ，存储设计得很随意：一张 kb_doc 表，切片直接以 JSON 数组的形式塞在 chunks 字段里，向量存在 Milvus 里，两边用 doc_id 关联。 这个设计在 5 万篇的时候完全
压测卡在 400 QPS 上不去 知识库问答系统三月中旬做上线前压测，目标 800 QPS，结果压到 400 就开始大量超时。看 Grafana 面板，网关 CPU 才 40%，数据库连接池很闲，但整体 P99 已经飙到 3.2s。 拿 async-profiler 抓了 60 秒火焰图，TIME_
8.6 万份文档，Tika 抽出来的表格全是乱码 去年底接了个企业知识库的项目，要把公司十年积累的技术文档、产品手册、标书、合同模板全部灌进 RAG。总量 8.6 万份，PDF 占 45%，Word 30%，Excel 15%，剩下是 PPT 和 HTML。 第一版我图省事，直接用 Apache T
搜索改版做了三个月，用户还在搜不到东西 公司的技术文档站搜索，原来是纯 Elasticsearch BM25。今年 8 月我接手改版，第一版直接换成了向量检索，想着"语义搜索肯定更强"。上线一个月，搜索结果的点击率从 68% 掉到 51%，用户投诉反而变多了。 我把 200 条低点击率的 query
数据量涨到 2300 万，向量检索 P99 从 60ms 崩到 1.8 秒 我们的商品语义搜索，7 月份上线时是 420 万条向量，P99 稳定在 60 毫秒。到 10 月底商品库扩到 2300 万条，接口 P99 涨到 1820 毫秒，同时 Milvus 集群的内存水位长期在 91%，隔三差五触发
我们的内部知识库 RAG 上线第一周，产品拿了个真实问题测试："年假怎么休？"模型一本正经地答了去年的旧政策。查下来，召回的文档里既有新政策也有旧政策，模型没分清哪个是现行有效的。RAG 的难点从来不在"接上模型"，而在"召回准不准、排得对不对"。 第一板斧：切分策略 最初按固定 500 字符硬切，
用 Spring AI（1.0 GA 稳定版）做 RAG，最早我是在业务代码里手写"先检索、拼 prompt、再调模型"三段式。逻辑散落、难复用、难插拔。后来发现 Spring AI 的 Advisor 机制就是为这事设计的——把"检索增强"做成可串联的拦截器。 Advisor 是什么：请求响应之间
中文向量化的尴尬 做知识库检索时，第一步就是把文档切块转成向量。英文世界有现成的 sentence-transformers，中文呢？2023 年初这块还很青涩，我踩了一圈坑，记下来给后来者省时间。当时我们想给内部 Wiki 做语义搜索，先用英文模型试，中文召回烂得一塌糊涂，才意识到"中文 embe
