Kotaemon在保险行业智能核保中的尝试-编程阁

Kotaemon在保险行业智能核保中的尝试

在保险行业的数字化浪潮中，一个看似简单的问题却长期困扰着从业者：“我有甲状腺结节，能买重疾险吗？”这个问题背后，是复杂的医学判断、分散的政策条款和高度依赖人工经验的核保流程。传统方式下，这类咨询可能需要数小时甚至更久才能给出答复——而用户期待的是即时、准确且合规的回答。

正是在这种高要求、高风险的业务场景下，Kotaemon 应运而生。它不是一个通用聊天机器人，也不是简单的问答系统，而是一个专为生产环境设计的智能体框架，致力于解决像智能核保这样对事实准确性、过程可追溯性和系统稳定性都极为敏感的关键任务。

RAG 架构：让生成更有依据

我们常听说大模型“一本正经地胡说八道”，这在医疗、金融等专业领域是不可接受的。纯生成式AI容易产生“幻觉”——即编造看似合理但实际不存在的信息。而在保险核保中，哪怕是一条错误的建议，也可能导致赔付风险或监管问责。

这时候，检索增强生成（Retrieval-Augmented Generation, RAG）的价值就凸显出来了。它的核心思想很朴素：不要凭空猜测，先查资料再回答。

当用户提问“糖尿病患者投保寿险有哪些限制？”时，系统不会直接让大模型自由发挥，而是先从预构建的知识库中查找相关文档。这些知识源包括《某保险公司健康险核保手册》《重大疾病保险疾病定义指南》《医保诊疗目录》等权威文件，经过分块、向量化后存储于向量数据库中。

以 BAAI/bge 系列嵌入模型为例，问题被编码成向量，在 Chroma 或 FAISS 中进行近似最近邻搜索，返回最相关的3~5个文本片段。这些片段与原始问题拼接成 prompt，送入生成模型（如 Mistral-7B-Instruct），最终输出的答案不仅内容准确，还能附带引用来源。

这种机制带来的好处是显而易见的：

降低幻觉率：所有回答都有据可依，避免凭空捏造
满足审计需求：每一条结论都可以回溯到具体条款或指南
支持动态更新：新产品上线或政策调整后，只需重新索引知识库，无需重新训练模型

相比微调（Fine-tuning），RAG 更适合保险这类知识频繁变更的行业。毕竟没人愿意为了每季度一次的产品迭代去跑一遍全量训练。

from langchain.retrievers import VectorStoreRetriever from langchain.chains import RetrievalQA from langchain_community.llms import HuggingFaceHub # 初始化检索器 retriever = VectorStoreRetriever(vectorstore=db) # 构建RAG链，确保返回引用文档 rag_chain = RetrievalQA.from_chain_type( llm=HuggingFaceHub(repo_id="mistralai/Mistral-7B"), chain_type="stuff", retriever=retriever, return_source_documents=True ) query = "乙肝小三阳可以购买医疗险吗？" result = rag_chain.invoke(query) print("回答:", result["result"]) print("依据来源:", [doc.metadata.get("source") for doc in result["source_documents"]])

这段代码虽简洁，却体现了 RAG 的精髓：分离检索与生成，强调证据支撑。尤其return_source_documents=True这一设置，在金融合规场景中几乎是必备项。

不过也要注意，RAG 并非万能。如果知识切分不合理——比如把多个不同疾病的核保规则合并在一个 chunk 里——就可能导致检索结果混杂，反而误导模型。因此，我们在实践中通常按“条款粒度”切分文档，确保每个段落聚焦单一主题，提升检索精准度。

智能对话代理：不只是问答，更是交互式决策

核保从来不是一次性的问答。真实场景中，用户往往只提供模糊信息：“我之前住过院。” 接下来该怎么办？是不是要拒保？显然不能草率下结论。

这就需要系统具备主动追问、状态管理、工具调用的能力——也就是我们所说的智能对话代理（Dialogue Agent）。

Kotaemon 的代理架构允许开发者定义一套完整的会话逻辑。它不仅能理解当前输入，还能记住上下文、识别缺失字段，并在适当时机触发外部操作。

举个例子：

用户：“我想投保终身寿险。”
系统：“请提供您的身份证号和过往病史。”
用户：“身份证号是11010119900307XXXX。”

此时，系统已掌握身份标识，便可自动调用医院联网接口验证其真实就诊记录。这个过程不需要人工干预，也不依赖固定流程脚本，而是通过插件化工具实现动态调度。

from kotaemon.agents import DialogueAgent from kotaemon.tools import ToolPlugin, APIInvoker class MedicalHistoryVerifier(ToolPlugin): def invoke(self, patient_id: str) -> dict: return APIInvoker.call( url="https://api.hospital.gov.cn/v1/history", method="GET", params={"id": patient_id} ) agent = DialogueAgent( prompt_template="你是一名专业核保员，请根据用户提供信息判断是否可承保。", tools=[MedicalHistoryVerifier()], memory_window=5 # 维护最近5轮对话记忆 ) conversation = [ {"role": "user", "content": "我想投保终身寿险"}, {"role": "assistant", "content": "请提供您的身份证号和过往病史"}, {"role": "user", "content": "身份证号是11010119900307XXXX"} ] response = agent.run(conversation) print("代理回复:", response)

在这个流程中，DialogueAgent内部完成了多项工作：
- 解析用户意图（投保申请）
- 判断槽位完整性（缺少病史）
- 生成引导性回复
- 在获得关键ID后，自动触发MedicalHistoryVerifier工具调用

这种能力使得系统不再是被动应答者，而是成为具备行动力的数字员工。它可以调用OCR识别投保单、查询征信评分、甚至发起内部审批流，真正融入企业业务闭环。

更重要的是，整个过程可追踪、可审计。每一次工具调用的时间、参数、返回值都会被记录，为后续复盘和模型优化提供数据基础。

模块化设计：面向生产的工程哲学

很多AI原型系统在demo阶段表现惊艳，但一旦进入生产环境便暴露出种种问题：性能波动、结果不一致、部署困难……根本原因在于缺乏工程级的设计思维。

Kotaemon 的一大亮点就在于其模块化与可复现性优先的架构理念。它不像某些闭源平台那样把所有功能打包成黑盒，而是将系统拆解为独立组件，每个部分都可以替换、测试和监控。

例如，你可以轻松切换不同的嵌入模型：

# config/pipeline_nuclear.yml retriever: type: vector_store config: embedding_model: BAAI/bge-small-en-v1.5 vector_db: Chroma top_k: 3 generator: type: hf_hub config: repo_id: mistralai/Mistral-7B-Instruct-v0.2 temperature: 0.3 max_new_tokens: 512 evaluator: metrics: - faithfulness - answer_relevancy - context_precision

只需要修改配置文件，就能在 BGE 和 E5 之间做A/B测试，评估哪种模型在特定病种检索上表现更好。生成端也可以灵活选用本地部署的 Qwen，或是云上的 GPT 接口。

这种“组件即服务”的设计带来了几个关键优势：

技术选型自由：不绑定特定厂商或模型，规避 vendor lock-in
持续优化路径清晰：可以单独优化检索模块而不影响生成逻辑
团队协作高效：算法、前端、运维各司其职，基于接口协同开发

同时，Kotaemon 自动记录每次运行的日志与指标，支持 Faithfulness（忠实度）、Answer Relevancy（答案相关性）等自动化评估。这意味着每一次迭代都不是靠感觉，而是有数据支撑的科学决策。

实际落地：从架构到流程的完整闭环

在一个典型的保险智能核保系统中，Kotaemon 扮演的是核心推理引擎的角色，连接前端交互层与后端数据系统。

graph TD A[用户终端] --> B[API网关] B --> C{身份认证} C --> D[Kotaemon 对话代理] D --> E[意图识别模块] D --> F[对话状态管理器] D --> G[RAG引擎] D --> H[工具调度中心] G --> I[向量数据库<br>保险条款/医学指南] H --> J[外部API<br>医保/OCR/风控模型] D --> K[日志与监控系统<br>Prometheus + Grafana]

整个系统的运作流程如下：

用户提问：“我有甲状腺结节，能买重疾险吗？”
系统识别出“疾病问询”意图，提取关键词“甲状腺结节”
RAG 引擎在《核保指引》中检索相关政策，找到 TI-RADS 分级标准
生成初步回应：“TI-RADS 低于3级且无恶性特征者可标准体承保”
发现缺少检查报告，主动追问：“请上传最新的超声报告”
用户上传PDF，系统调用 OCR+NLP 提取结节大小、边界、血流信号等关键指标
结合内部风控模型输出，做出综合判断
返回正式核保意见，并将全过程写入审计日志

这一流程模拟了真人核保员的工作方式，但效率更高、标准更统一。更重要的是，它解决了三个长期存在的痛点：

核心痛点	Kotaemon 解决方案
信息分散难查找	RAG 从海量非结构化文档中精准定位条款
人工判断差异大	基于统一知识库与推理逻辑，保障一致性
过程不可追溯	完整记录检索结果、工具调用与生成依据

当然，实际部署还需考虑一些细节：