「我们的知识库问答准确率只有 71%,要不要做微调」 去年 11 月,业务方拿着一份评测报告来找我:客服问答准确率 71%,离可用的 85% 差得远。他们的结论是「做微调,把行业知识训进模型」。 我说先别急,让我把两条路都跑一遍再决定。这篇是三个月实测的结果,包括所有成本数字。结论先放:我们最后选了
8.6 万份文档,Tika 抽出来的表格全是乱码 去年底接了个企业知识库的项目,要把公司十年积累的技术文档、产品手册、标书、合同模板全部灌进 RAG。总量 8.6 万份,PDF 占 45%,Word 30%,Excel 15%,剩下是 PPT 和 HTML。 第一版我图省事,直接用 Apache T
AI 应用开发:大模型与 RAG 实战 随着大语言模型(LLM)的快速发展,构建 AI 应用变得越来越容易。检索增强生成(RAG)是提升大模型回答质量的关键技术。 什么是 RAG? RAG(Retrieval-Augmented Generation)结合了信息检索与文本生成的优势: 从外部知识库中
我们的内部知识库 RAG 上线第一周,产品拿了个真实问题测试:"年假怎么休?"模型一本正经地答了去年的旧政策。查下来,召回的文档里既有新政策也有旧政策,模型没分清哪个是现行有效的。RAG 的难点从来不在"接上模型",而在"召回准不准、排得对不对"。 第一板斧:切分策略 最初按固定 500 字符硬切,
用 Spring AI(1.0 GA 稳定版)做 RAG,最早我是在业务代码里手写"先检索、拼 prompt、再调模型"三段式。逻辑散落、难复用、难插拔。后来发现 Spring AI 的 Advisor 机制就是为这事设计的——把"检索增强"做成可串联的拦截器。 Advisor 是什么:请求响应之间
给内部文档做个能问答的机器人 公司几百份技术文档散在 Wiki,搜起来费劲——关键词搜只能匹配字面,问"怎么处理订单超时"搜不到"订单 30 分钟未支付自动关单"的那段。我想用 RAG(检索增强生成)做个问答,让模型"先查资料再回答"。2023 年初这套链路在 Java 侧得自己拼,没有现成框架,正