RAG 在保险产品问答中的落地方式

1. 对应简历段落

这篇文章对应简历中“在公司内部 AI 客服系统中，基于 RAG 构建保险产品知识问答能力，支持产品条款、投保规则、续保政策、理赔材料、客服 FAQ 等多源知识检索，并通过引用溯源、版本控制和人工反馈闭环降低大模型幻觉”的经历。

面试时不要把这段说成“把 PDF 切片后丢进向量库”。资深 Java / AI 工程化面试更关心的是：保险产品知识为什么难，RAG 怎么和产品版本、渠道、地区、生效日期绑定，召回结果怎么评估，回答怎么受控，如何接入传统内容系统和客服工作台，以及出现错误回答后如何追责和修复。

推荐的简历复述可以是：

负责内部 AI 客服产品问答模块的 RAG 架构设计与落地，将产品条款、销售手册、运营公告、FAQ 和制度文档统一治理为可检索知识库；通过结构化切分、元数据过滤、混合召回、rerank、引用溯源和人工反馈闭环，提高保险产品问答准确率，并在合规边界内支持客服坐席快速解释产品规则。

这段经历的价值在于，它不是一个玩具级知识库，而是在金融业务上下文里把非结构化知识变成可控、可审计、可持续运营的问答能力。

2. 业务背景

保险产品问答有几个典型难点。

第一，文档复杂。一个产品往往同时存在条款、费率说明、销售手册、核保规则、理赔指引、运营公告和客服 FAQ。条款强调法律表达，销售手册强调业务解释，FAQ 强调话术，公告强调临时调整。用户问一句“这个产品还能续保吗”，背后可能涉及产品版本、保单年度、停售公告、渠道政策和客户年龄。

第二，版本复杂。同名产品可能有 2022 版、2024 版、互联网渠道版、银保渠道版，不同版本的等待期、责任免除、续保规则并不完全一致。如果 RAG 只按文本相似度召回，很容易拿旧版本回答新问题。

第三，问题表达不标准。坐席或业务人员不一定使用条款里的标准术语。他们会问“甲状腺结节能不能买”“百万医疗断缴了还能接着交吗”“这个病算不算重疾”“小孩买要不要体检”。系统必须把口语问题映射到条款概念、产品配置和业务规则。

第四，合规压力高。保险客服回答不能夸大保障，不能承诺一定赔付，不能把核保和理赔结论提前说死，也不能在证据不足时编造解释。AI 问答系统必须做到“有依据才回答，依据不足就拒答或转人工”。

第五，知识运营成本高。产品、公告、FAQ 会持续变化，客服质检也会不断发现不准确回答。RAG 如果没有知识更新、评测和反馈机制，很快就会变成一个“上线时可用、三个月后不可信”的系统。

所以保险产品 RAG 的核心目标不是炫技，而是建立一套稳定机制：让模型回答时绑定正确知识、正确版本、正确边界，并且能够被运营人员持续维护。

3. 核心原理

RAG 的基本链路是：问题理解、知识召回、证据重排、上下文构造、模型生成、引用溯源、反馈回流。保险场景要在每一步增加业务约束。

问题理解阶段，系统需要识别问题中是否包含产品名、产品代码、疾病名称、保单号、渠道、地区、时间、客户身份等要素。比如“尊享百万医疗去年买的还能不能续”至少要识别产品、续保意图和时间条件；如果当前会话绑定了保单，还要从上下文里拿到产品版本。

知识召回阶段，不能只依赖向量相似度。向量召回适合处理语义相近问题，但产品代码、条款号、病种名称、公告编号更适合全文检索。工程上通常采用混合召回：向量检索负责语义，BM25 或 Elasticsearch 负责关键词，元数据过滤负责版本边界，再通过 reranker 对候选片段排序。

证据构造阶段，要把召回结果转换成模型可理解的上下文。保险文档切片时必须保留标题路径、文档类型、版本号、生效日期、来源链接。否则模型即使答对了，客服也不知道依据来自哪里。

生成阶段，Prompt 必须明确约束模型：只能基于给定证据回答；证据不足要说明无法确认；涉及赔付、核保、退保金额时不能做最终承诺；必须给出引用来源；面向客户和面向内部坐席的话术要区分。

评测阶段，要建立黄金问题集。不能只看“回答像不像”，还要看证据是否正确、版本是否正确、有没有越权引用、有没有承诺性话术、是否给出转人工边界。保险 RAG 的评测更接近合规质检，而不是普通闲聊体验评分。

4. 项目落地

落地时可以拆成四个模块：知识治理、索引服务、问答编排、运营评测。

知识治理模块负责把 PDF、Word、HTML、FAQ 表格、公告系统内容统一转成标准文档。每份文档进入知识库前，需要记录 productCode、productName、docType、version、effectiveDate、expireDate、channel、region、ownerDept、riskLevel、sourceUrl 等元数据。对于保险条款，解析时要尽量保留章节编号和标题路径；对于表格，要转成“行列语义明确”的文本，不要简单拼接。

索引服务负责切片、向量化和全文索引。切片策略建议“结构优先、长度辅助”：先按章节、条款号、FAQ 问答对切分，再对过长片段做二级切分。每个 chunk 保留父标题和相邻上下文摘要。向量库可以用 Milvus、pgvector、Elasticsearch vector 或云厂商向量检索，全文检索可以复用 Elasticsearch。Java 工程里可以把索引写入做成异步任务，避免运营上传大文档时阻塞后台。

问答编排模块负责接收客服问题，读取会话上下文，识别意图，执行检索，调用大模型生成回答。这里要注意一个关键点：如果问题绑定了具体保单，RAG 不能只按产品名检索，而要先通过保单查询拿到 productCode、version、channel、effectiveDate，再把这些作为检索过滤条件。

运营评测模块负责持续修正。每次回答都记录问题、召回片段、模型回答、引用来源、用户反馈、人工改写结果。运营人员可以把差评样本加入评测集，也可以把人工确认过的问答沉淀为 FAQ。这样 RAG 才能从“检索系统”变成“知识运营系统”。

一个实际落地链路可以是：客服工作台发起问题，AI 网关注入用户和工单上下文，RAG 服务按产品和权限召回证据，LLM 生成带引用的回答，前端展示回答与来源，坐席可一键标记“有帮助”“不准确”“需转人工”，反馈再进入运营后台。

5. 流程或伪代码

public Answer ask(ProductQuestion question, UserContext user) {
    ConversationContext ctx = conversationService.load(question.conversationId());

    Intent intent = intentClassifier.classify(question.text(), ctx);
    ProductScope scope = productScopeResolver.resolve(question, ctx);

    SearchFilter filter = SearchFilter.builder()
        .productCode(scope.productCode())
        .version(scope.version())
        .channel(scope.channel())
        .region(scope.region())
        .effectiveAt(scope.effectiveAt())
        .readableBy(user.roles())
        .build();

    List<DocumentChunk> vectorHits = vectorSearch.search(question.text(), filter, 30);
    List<DocumentChunk> keywordHits = keywordSearch.search(question.text(), filter, 30);
    List<DocumentChunk> merged = chunkMerger.merge(vectorHits, keywordHits);
    List<DocumentChunk> evidence = reranker.rank(question.text(), merged).top(8);

    if (evidenceGuard.isInsufficient(evidence)) {
        return Answer.needHuman("当前知识库没有找到足够依据，建议查看原始条款或转人工。");
    }

    Prompt prompt = promptBuilder.buildRagPrompt(question.text(), evidence, intent, user);
    String content = llm.generate(prompt);

    Answer answer = answerPostProcessor.withCitations(content, evidence);
    auditLogger.record(question, user, evidence, answer);
    return answer;
}

这个伪代码背后有几个重点：检索过滤条件来自业务上下文，不是只有用户问题；证据不足时直接拒答；回答后必须审计；引用来源不是模型自由生成，而是后处理基于 evidence 绑定。

6. 安全边界

保险产品问答的安全边界主要有六类。

第一，知识权限边界。不是所有文档都能被所有坐席检索。内部培训资料、核保规则、渠道政策、投诉处理口径可能有岗位权限。RAG 检索前就要按用户角色过滤，不能检索后再让模型决定是否展示。

第二，版本边界。失效条款、历史公告、旧版 FAQ 不能随意参与当前回答。可以允许内部人员查询历史版本，但回答中必须标明“历史版本”，不能混到当前产品解释里。

第三，话术边界。涉及理赔、核保、退保、现金价值、收益演示时，模型不能给最终结论，只能基于条款说明规则和办理路径。最终结果必须以业务系统或人工审核为准。

第四，隐私边界。纯产品问答不应该暴露客户信息；如果问题混入保单号、身份证号，日志和模型上下文要做脱敏。向外部模型发送请求前，要确认不包含不必要的个人敏感信息。

第五，来源边界。回答必须来自受控知识库，不能让模型引用互联网页面或不可信来源。保险产品解释尤其不能混入竞品材料或过期宣传。

第六，责任边界。AI 回答是辅助坐席，不是正式合同解释。前端可以在内部系统里标识“AI 建议”，并保留引用证据，便于质检和追责。

7. 常见坑

第一个坑是只做向量库，不做文档治理。短期看能回答，长期看版本混乱、来源不清、运营无法维护。

第二个坑是切片太碎。保险条款很多限定条件在前后文里，切得太碎会导致召回片段缺条件，模型容易过度概括。

第三个坑是只评估最终回答，不评估证据。RAG 的核心是“用正确证据回答”，如果证据错但答案碰巧像真的，风险反而更大。

第四个坑是把 Prompt 当作唯一安全手段。Prompt 可以约束模型风格，但权限、版本、脱敏、审计必须在后端确定性实现。

第五个坑是忽略无答案场景。一个成熟 RAG 系统必须会说“不确定”，否则保险客服场景中最危险的问题就是模型自信地胡说。

第六个坑是没有反馈闭环。上线后如果差评样本、人工修正、知识更新不能回流，系统质量会逐渐下降。

8. 面试追问

面试官常问：为什么不用模型直接回答保险产品问题？回答要抓住“内部知识、版本变化、合规追溯”三个点。

还会问：文档怎么切分？要强调结构化切分、标题路径、表格语义、元数据继承，而不是固定长度切片。

可能继续问：如何解决召回不准？可以讲混合召回、元数据过滤、rerank、query rewrite、同义词词库和评测集。

如果问：如何防止幻觉？要说明证据门槛、Prompt 约束、引用绑定、拒答策略、敏感话术后处理和人工兜底。

如果问：如何评估 RAG 效果？不要只说准确率，可以说召回命中率、证据正确率、回答忠实度、引用准确率、拒答合理率、人工采纳率、客服平均处理时长。

如果问：Java 系统怎么集成？可以讲 Spring Boot 编排服务、异步索引任务、向量库客户端、Elasticsearch、Redis 会话、统一审计日志和 SSE 前端输出。

9. 推荐回答

可以这样回答：

我们没有把保险问答做成简单的向量库 Demo，而是先做知识治理。保险产品有版本、渠道、地区和生效日期，同名产品不同版本规则可能不同，所以每个文档和 chunk 都带 productCode、version、docType、effectiveDate 等元数据。检索时先结合当前工单或保单上下文确定产品范围，再做向量和关键词混合召回，最后用 reranker 排序。

生成回答时，我们要求模型只能基于召回证据回答，证据不足必须拒答或转人工。涉及理赔、核保、退保金额这类高风险问题，只能解释规则和办理路径，不能承诺最终结果。回答会展示引用来源，后台记录问题、证据、回答和用户反馈，便于质检追溯。

从工程上看，RAG 的难点不是调一个 embedding 接口，而是让知识可治理、可过滤、可评估、可审计。尤其在保险场景里，版本控制和安全边界比模型本身更关键。

这个回答既体现业务理解，也体现工程能力，比较适合资深 Java / AI 工程化面试。

10. 延伸学习路线

第一阶段学习 RAG 基础：embedding、向量检索、chunk、召回、rerank、Prompt grounding。建议自己用一批 PDF 做端到端实验，观察不同切片策略对召回的影响。

第二阶段学习搜索工程：Elasticsearch、BM25、同义词、query rewrite、混合召回、召回评测。很多生产级 RAG 问题其实是搜索问题。

第三阶段学习知识治理：文档解析、元数据建模、版本管理、知识发布流程、人工审核、反馈闭环。保险、银行、政企场景尤其重视这一层。

第四阶段学习 LLM 评测：构造黄金问题集，评估 answer faithfulness、context precision、context recall、citation accuracy，以及如何做人工质检。

第五阶段学习 Java 落地：Spring Boot 编排服务、异步任务、消息队列、Redis 会话、向量库客户端、审计日志、权限过滤和前端 SSE 输出。

最后可以把学习成果沉淀成一个面试项目：用保险产品条款构建一个 RAG 问答系统，支持文档上传、版本过滤、混合召回、引用溯源、反馈标注和评测报表。这个项目比单纯调用大模型接口更能体现工程化深度。