015、RAG在智能客服、知识库、代码助手等场景的落地案例从一次深夜告警说起某天夜里线上客服系统触发了大量“答非所问”的告警。爬起来查日志发现用户问“如何重置A型设备的出厂密码”系统返回的却是B型设备的固件升级步骤。问题出在传统的语义检索模块它把“重置密码”和“固件升级”都识别成了“设备操作类”意图直接从向量库捞了个最相似的答案压根没管设备型号这个关键约束。这个场景太典型了传统检索要么靠关键词匹配漏掉语义相似问题要么靠纯向量检索忽略硬性约束。那天夜里我边修边想是时候把折腾了半年的RAG方案推上线了。智能客服当检索需要“带条件查询”我们先看智能客服场景的痛点。用户问题往往包含多层约束“帮我查去年买的旗舰款手机的保修政策”“海外版路由器怎么设置中文界面”如果只用向量检索很可能把“去年”“旗舰款”这些关键过滤条件淹没在语义相似度计算里。我们的落地方案做了三层混合检索# 实际生产环境的简化示例defhybrid_retrieval(query,filtersNone):# 第一层传统BM25过一遍抓关键词匹配keyword_resultsbm25_search(query,top_k5)# 第二层向量检索这里有个坑——别直接用原始query# 我们先用NER抽实体再用去实体后的文本做向量化entitiesextract_entities(query)# 抽出“旗舰款”“海外版”这类约束stripped_queryremove_entities(query,entities)vector_resultsvector_search(stripped_query,top_k10)# 第三层把实体当硬过滤条件filtered_results[]fordocinvector_results:ifmatch_filters(doc.metadata,entities):# 必须匹配设备型号、时间等filtered_results.append(doc)# 这里加了个降级策略如果过滤后结果太少放宽条件但打低分# 实际业务中宁可说“不知道”也不能给错误答案# 合并结果按加权分排序returnrerank(keyword_results,filtered_results)这个方案上线后客服场景的准确率从68%提到了89%。核心经验是在客服场景RAG里的R检索必须支持结构化过滤纯向量检索走不远。知识库处理长文档和表格数据公司内部知识库有大量产品手册、技术白皮书很多是PDF格式。早期方案简单粗暴——按页切分结果用户问“XX芯片的功耗参数”返回的整页内容里还混着封装尺寸、价格信息生成答案经常串字段。我们后来改成多粒度切分大块按章节切保持上下文连贯表格单独提取存成结构化数据关键参数列表拆成独立片段# 知识库文档处理流水线defchunk_manual(pdf_path):chunks[]# 先按章节切用规则匹配标题sectionssplit_by_heading(pdf_text)forsectioninsections:# 遇到表格就单独处理tablesextract_tables(section)fortableintables:# 表格转成“字段: 值”的文本描述方便检索chunkdescribe_table(table)chunk.metadata[type]tablechunks.append(chunk)# 非表格部分按语义切保持段落完整paragraphssplit_by_paragraph(section)forparainparagraphs:iflen(para)500:# 太长的段落再按句子切# 但这里要小心别在中间切断引用关系# 我们用了句间依存关系分析找到切割点sub_chunkssmart_split(para)chunks.extend(sub_chunks)else:chunks.append(para)returnchunks还有个细节知识库更新后旧答案要能同步更新。我们给每个片段加了版本哈希用户提问时优先检索最新版本但生成答案时会标注“该信息基于2024年11月版手册请以最新文档为准”。知识库场景的核心是平衡检索精度和上下文完整性——切太碎丢上下文切太整混噪声。代码助手当检索目标是函数和API做代码助手时我们踩过一个坑用户问“Python里怎么递归遍历目录”直接返回了os.walk的官方文档片段但用户实际想在Spark环境下操作HDFS路径。问题在于代码检索不能只看文本相似度得考虑技术栈上下文。现在的方案是从对话历史提取技术栈线索Python/Java、Spark/Hadoop等检索代码片段时优先匹配技术栈返回时带上依赖说明和常见坑点# 代码检索增强示例defsearch_code_snippet(query,tech_stackNone):# 技术栈感知的查询改写iftech_stack:enhanced_queryf{query}{tech_stack}示例else:enhanced_queryquery# 检索代码库我们建了高质量的开源代码片段库snippetsvector_search(enhanced_query,indexcode_index)# 过滤掉过时API比如Python2的代码filteredfilter_deprecated(snippets)# 对每个片段关联常见错误模式# 这是从Stack Overflow问题里挖出来的经验数据forsnippetinfiltered:snippet.common_pitfallsget_pitfalls(snippet.api_name)returnfiltered生成答案时我们让模型按“示例代码避坑指南替代方案”的结构输出。比如返回os.walk时会补充一句“如果在Spark集群环境建议用hadoopFileSystem.listStatus因为os.walk读不到HDFS路径”。代码助手的关键是检索要有技术栈感知生成要有坑位意识。几个跨场景的通用经验检索不是越准越好——有时候需要故意放宽召回让大模型去做判断。比如用户问“设备连不上网”严格检索可能只匹配到网络配置文档但实际可能是电源问题。我们设了个“相关但不完全匹配”的阈值保留一些宽泛结果。生成环节的提示词要带业务约束。我们会在提示词里埋业务规则“如果涉及设备操作必须分步骤说明如果涉及价格政策必须标注生效日期”。这比事后过滤生成内容更可靠。评估别只看准确率——我们设了四个指标答案准确率、引用准确率别引用无关文档、安全合规性、用户追问率如果用户老追问说明第一次没讲清楚。冷启动数据从日志里挖。早期没标注数据时我们从客服日志里自动构造〈问题相关文档人工回复〉三元组虽然噪声大但比纯合成数据管用。最后说点实在的RAG落地像装修房子——框架就那些但细节决定住得舒不舒服。别追求一步到位的完美方案先在一个场景打透再横向复制。我们是从智能客服切入的因为它的评估最直观用户要么满意要么投诉。等检索、生成、评估的流程跑顺了再扩展到知识库和代码助手很多组件可以直接复用。还有RAG系统里最脆弱的不是模型是数据管道。文档解析、文本切分、元数据提取这些脏活累活占了我们70%的调试时间。建议早期就投入做数据质量监控比如检测切分后的片段是否完整、表格提取是否错位。这些事不起眼但比换更大的embedding模型管用。