Kotaemon保险理赔咨询机器人逻辑设计

Kotaemon保险理赔咨询机器人逻辑设计

在保险服务一线，一个常见的场景是：客户焦急地打开手机APP，输入“车险被水淹了赔不赔？”系统却回复一句模棱两可的“根据条款可能属于保障范围”。这种体验不仅让用户失望，更暴露出传统客服系统的深层问题——知识分散、响应迟缓、缺乏依据。

而今天，借助像Kotaemon这样的生产级智能体框架，我们正有机会构建真正懂业务、讲得清、靠得住的保险理赔顾问。它不只是换个语气聊天的机器人，而是融合了精准检索、多轮对话控制和插件调度能力的专业助手。它的核心，是一套以RAG 架构为基座、对话管理为中枢、插件化扩展为触手的完整技术体系。

想象这样一个流程：用户说：“我昨天撞树了，车头坏了。”系统立刻识别出这是“交通事故报案”意图，并主动引导：“您已报警很好，请提供保单号以便启动理赔。”当用户输入保单号后，系统自动调用后台接口验证投保状态，同时从向量知识库中检索《车损险理赔操作指南》，生成分步指引：保留现场照片、上传证件、预约定损时间。随后，用户上传驾驶证图片，系统通过 OCR 插件提取信息并核验真实性。整个过程无需人工介入，每一步回答都有据可依。

这背后的关键，正是检索增强生成（RAG）技术的实际落地。RAG 不再依赖大模型“凭记忆作答”，而是让它“边查资料边回答”。比如面对“发动机进水是否赔付”这类高风险问题，系统会先从条款文档中检索相关段落，再将原文作为上下文送入大模型，确保输出严格基于合同约定，避免因模型幻觉导致误导性结论。

其工作流可以简化为三步：
1. 用户提问 → 2. 向量数据库语义匹配最相关的知识片段 → 3. 拼接成 Prompt 输入 LLM 生成最终回复

相比直接微调大模型的做法，RAG 的优势非常明显：知识更新不再需要重新训练，只需替换或新增文档即可；所有答案都可追溯到具体来源，便于审计纠错；而且能快速迁移到新险种或新规发布后的场景中。

from kotaemon.retrievers import VectorDBRetriever from kotaemon.llms import OpenAI from kotaemon.storages import ChromaVectorStore vector_store = ChromaVectorStore(persist_dir="./insurance_knowledge_db") retriever = VectorDBRetriever(vector_store=vector_store, top_k=3) llm = OpenAI(model="gpt-4-turbo") def rag_query(question: str): retrieved_docs = retriever.retrieve(question) context = "\n".join([doc.text for doc in retrieved_docs]) prompt = f""" 请根据以下资料回答问题，若资料不足以回答，请说明无法确定。 资料： {context} 问题： {question} """ response = llm(prompt) return response.content, retrieved_docs answer, sources = rag_query("车辆被水淹了，车损险赔吗？") print("回答：", answer) print("参考来源：", [src.metadata['source'] for src in sources])

这段代码看似简单，实则体现了 RAG 的工程精髓：解耦知识与模型。我们在实际部署时发现，使用通用 embedding 模型（如 text-embedding-ada-002）在保险术语上的表现并不理想。后来切换为经过中文金融文本微调的bge-small-zh-v1.5后，召回准确率提升了近 40%。这也提醒我们：领域适配比模型参数量更重要。

但仅有 RAG 还不够。真实的理赔咨询往往是多轮交互的长链条任务。用户不会一次性把所有信息说完，可能会中途跳转话题，比如正在提交材料时突然问起“能不能改受益人”。如果系统记不住上下文，就会反复索要相同信息，体验极差。

这就引出了另一个关键技术——对话管理引擎（Dialogue Management）。Kotaemon 提供的DialogueAgent并非简单的“一问一答”模式，而是具备状态追踪能力的代理。它可以维护一个全局的对话状态（Dialogue State），记录用户已经提供的保单号、事故时间、是否报警等关键槽位，并据此决定下一步动作。

from kotaemon.agents import DialogueAgent from kotaemon.tools import Tool class ClaimStatusTool(Tool): def run(self, policy_id: str): result = backend_api.get_claim_status(policy_id) return { "status": result["status"], "update_time": result["last_updated"], "next_step": result["instructions"] } agent = DialogueAgent( tools=[ClaimStatusTool()], system_prompt=""" 你是一名保险理赔顾问，请协助客户查询理赔进展。 若未提供保单号，请主动询问；若已提供，则调用工具查询并反馈。 """ ) history = [] user_input_1 = "我想查一下我的理赔进度" response_1 = agent.chat(user_input_1, history=history) # → 回复：“请提供您的保单号。” history.extend([{"role": "user", "content": user_input_1}, {"role": "assistant", "content": response_1}]) user_input_2 = "我的保单号是INS202405001" response_2 = agent.chat(user_input_2, history=history) # → 自动触发 ClaimStatusTool 查询并返回结果

这个例子展示了什么叫“有记忆的对话”。更进一步，我们可以定义标准的状态转移图，比如报案 → 材料提交 → 定损 → 结案，每个环节设置校验规则，防止跳步或遗漏。对于长时间未完成的操作，系统还能主动推送提醒，实现真正的闭环服务。

然而，最让我看中的，其实是 Kotaemon 的插件化架构。它让 AI 推理层与业务执行层彻底分离。换句话说，LLM 只负责“思考该做什么”，而不必关心“怎么做”。

举个典型场景：用户上传了一张维修发票图片。系统如何处理？
传统的做法是写死逻辑：收到图片 → 调 OCR → 解析金额 → 填入表单。一旦流程变化就得改代码。

而在 Kotaemon 中，我们可以把 OCR 封装成一个独立插件：

from pydantic import BaseModel from kotaemon.tools import Tool class OCRInput(BaseModel): image_url: str class OCROutput(BaseModel): text: str confidence: float class InsuranceOCRToll(Tool): name = "ocr_invoice" description = "识别用户上传的维修发票图片内容" args_schema = OCRInput return_schema = OCROutput def run(self, image_url: str) -> OCROutput: img_data = download_image(image_url) ocr_result = ocr_service.recognize(img_data) return OCROutput( text=ocr_result["text"], confidence=ocr_result["confidence"] ) agent.register_tool(InsuranceOCRToll())

一旦注册，LLM 就能在适当时候自动调用它。例如当用户说“这是我的修车发票”并附上图片时，模型会判断需要调用ocr_invoice工具，并将结果用于后续定损评估。这种“发现-注册-调用”的机制，极大提升了系统的灵活性。多个团队可以并行开发不同的插件——身份核验、征信查询、视频定损、第三方气象数据接入……就像搭积木一样组合功能。

在真实项目中，我们曾遇到这样的挑战：某地区暴雨引发大量涉水报案，客户集中询问“发动机进水是否赔付”。由于历史条款存在歧义，单纯依靠 RAG 检索容易产生争议。我们的解决方案是：在检索阶段加入版本控制标签，确保只返回当前有效期内的解释说明；同时，在生成提示词中强制要求“引用最新版《家庭自用汽车损失保险条款》第X条”；最后，对涉及拒赔的回答添加免责声明：“以上解读仅供参考，具体以正式核定为准。”

这些细节设计，恰恰体现了 Kotaemon 面向生产环境的核心理念：稳定、可控、可观测。我们集成了 Prometheus + Grafana 监控 QPS、延迟、工具调用成功率；所有对话日志加密存储，满足 GDPR 和《个人信息保护法》要求；高频问题启用 Redis 缓存，将常见问答响应时间压缩至 800ms 以内。

整个系统架构也呈现出清晰的分层结构：

+------------------+ +---------------------+ | 用户终端 |<----->| Kotaemon Agent | | (微信/APP/网页) | HTTP | (对话管理 + RAG + 工具调度) | +------------------+ +----------+----------+ | | API 调用 +--------------------v---------------------+ | 外部服务与数据源 | | • 保单管理系统 | | • 理赔数据库 | | • 向量知识库（条款/FAQ/案例） | | • OCR/人脸识别服务 | | • 第三方征信平台 | +--------------------------------------------+

Kotaemon 居于中枢位置，像一位经验丰富的理赔主管，协调各方资源，做出合规决策。它既不会越权处理敏感操作（如更改受益人必须转人工），也不会在用户等待时“失联”——超时机制和异常恢复策略保证了服务连续性。

回顾整个设计过程，有几个经验值得分享：
-知识库建设必须前置：我们花了整整两周时间清洗 PDF 条款，按章节切片、标注生效日期、建立索引。没有高质量的知识源，再强的模型也只是空中楼阁。
-不要迷信 top-k=3：初期我们设定了固定返回3个文档片段，但在复杂问题上经常漏掉关键信息。后来改为动态调整：简单问题用较小的 top-k 减少噪声，复杂问题扩大检索范围并引入重排序（rerank）模块。
-安全边界要明确：所有涉及资金、隐私变更的操作一律拦截并转接人工，AI 只做信息辅助。这不仅是技术选择，更是合规底线。

这种高度集成的设计思路，正引领着智能客服从“能说话”走向“懂业务、守规矩、可信赖”。未来，随着行业知识库的持续沉淀和自动化工具链的完善，类似的智能代理有望成为垂直领域的基础设施。它们不再是锦上添花的功能点缀，而是重塑服务效率与用户体验的核心引擎。

“真正的智能，不是代替人类决策，而是在正确的时间，把正确的信息，交给正确的人。” —— 这或许就是 Kotaemon 给我们带来的最大启示。