企业级AI知识库系统（RAG）产品系统Vibe Coding

保险行业 PaaS 系统下企业级 RAG 中台建设背景
一、行业痛点：知识密集型业务的"三重困境"
保险是典型的强监管、重知识、高合规行业。以某大型保险集团为例，其知识资产呈现"三多三散"特征：
文档形态多：保险条款、监管规定（偿二代/IFRS17）、理赔案例库、医疗知识图谱、产品说明书、销售话术库等异构数据并存，仅条款类文档就超过 10 万+ 份，且版本迭代频繁；业务条线多：寿险、财险、健康险、养老险、再保险等 10+ 业务线各自沉淀知识库，形成严重的数据孤岛，同一"免赔额"概念在健康险和车险中定义差异巨大；
合规约束多：监管对销售误导"零容忍"，传统客服/销售凭经验回答，极易因理解偏差导致条款解释错误，引发理赔纠纷和监管处罚。
这导致一线业务人员面临"找不到、看不懂、不敢用"的困境：核保员需跨 5+ 个系统检索规则，理赔员处理复杂案件时平均查阅文档耗时 40 分钟以上，客服面对专业咨询时首次解决率不足 60%。
二、PaaS 系统的定位困境：通用 AI 难以适配保险场景
集团层面已建设统一 PaaS 中台，旨在为各业务线提供共享技术能力。但在 AI 赋能环节，早期试点暴露了通用方案的行业水土不服：
幻觉风险不可接受：通用大模型直接回答保险条款问题时， hallucination 率高达 15%，对"等待期""免责条款""赔付比例"等关键信息的编造，可能直接触发监管问责；
检索精度不足：单一向量检索无法处理保险领域的"精确匹配"需求（如特定产品代码、监管文号、金额阈值），而传统 ES 关键词检索又无法理解客户白话问询（如"得了甲状腺结节还能买重疾险吗"）；
重复建设严重：各业务线（寿险、健康险、车险）曾分别采购或自研问答系统，Embedding 模型、Chunk 策略、Prompt 工程各自为战，既浪费算力又无法沉淀统一标准。

架构方案：
检索层：设计混合检索架构，ES8负责元数据过滤+BM25关键词精确匹配 + Milvus（向量相似度）负责语义泛化召回，双路召回互补，解决单一检索模式的召回盲区；
精排层：引入BGE Rerank模型对召回结果重排序，过滤低质量上下文，提升生成输入的准确性；
生成层：通过CloseAI接入GPT-4o/Qwen3.5-plus/DeepSeek-V3.2，设计Prompt模板与生成边界约束机制；
治理层：建立RAG效果评估流水线（准确率/幻觉率/延迟），持续优化Embedding模型与Chunk策略。

1.架构设计及所有模块的功能开发
2.组件集群部署方案及高可用
3.复杂问答准确率从72%提升至91%，幻觉率从15%降至4%；作为平台级组件支撑10+业务线接入，避免各业务线重复建设。