目标
"数据"走向"知识"，提高数据在大模型中应用效果
背景
1，dify 配置的智能体，核心的功能是取到患者的相关业务数据，比如取检验结果还是取检查结果，现在某个需求取哪些数据项是人工配置的
2，现在数据开发核心产生是数据表，具体查询指标是人工新建指标查询sql或者通过可视化报表工具配置维度和度量，配置报表，直接使用表字段注释生成查询sql ，准确率和人工还是有差距
三，解决方案
1,元数据增强器
"元数据增强器"作为一种重要工具，正在帮助企业有效管理和利用信息。它的核心在于通过丰富和优化数据的元数据，提升数据的可用性、可理解性和检索性。
元数据增强器:它的主要功能是分析现有数据，并将相应的元数据进行补充或优化。元数据是描述数据的数据，包含信息结构、属性和管理规范等内容。通过对数据标签、分类、描述等信息的增强，元数据增强器可以将原本孤立的数据变得互联互通，从而提升数据分析的效率和深度。这样的过程，不仅优化了数据的利用效率，同时通过提升数据的上下文信息，帮助用户更好地理解数据的潜在价值。
使用元数据增强器，企业可以具体实现很多功能，比如自动化的标签添加、高效的搜索优化、数据标准化等。例如，在数据标签管理中，增强器能够自动分析数据内容，识别其特征，并为其添加精准的标签。这对于后续的数据检索和利用非常重要，因为打上合适标签的数据，在被搜索引擎索引时，能够获得更高的排名和可见度。特别是在涉及复杂数据操作时，元数据增强器的引入，能够大幅提升操作的透明度和准确性
给大模型建立所有业务数据的二级索引知识库
举例如下：
指标分析宽表，增加业务标签----支持哪些维度和指标的分析
标准语义层：指标名称，维度名称需统一规范
减少大模型只知道表结构，不知道数据内容，导致的判断错误
增加或者变更字段时，需要同时更新知识库
举例： vte 的表
开源框架-cube：统一定义语义层 https://cube.dev/
|-------------------------|-------------------------------------------------------------------------|------|-----------|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 指标名称 | 指标sql 函数 | 指标类型 | 中文表名 | 英文表名 | 维度 |
| VTE-患者例数 | count(distinct record_id) | 数值型 | VTE指标数据模型 | dw.ads_vte_patient_result | patient_gender=性别,patient_organization=院区,superior_doctor=主管医生,medical_doctor_group=医疗小组,inpatient_department=在院科室,inpatient_area=在院病区,admission_date=入院日期,admission_department=入院科室,admission_area=入院病区,discharge_date=出院日期,discharge_department=出院科室,discharge_area=出院病区,days=住院天数,total_medical_expenses=住院总费用,current_bed_code=当前床号,admission_diagnose=入院诊断,discharge_diagnose=出院诊断,in_hospital=是否在院,is_invalid=是否需要排除,day_patient=是否日间患者,is_invalid_word=是否满足排除识别词,is_out_vte=是否是院外VTE,is_dead=是否死亡,is_operation=是否手术患者,is_transfer=是否转科患者,is_jxyfjj=机械预防禁忌类型 |
| VTE-评估指标-已完成VTE风险评估患者例数 | count(distinct case when high_vte_result <> '未评估' then record_id end) | 数值型 | VTE指标数据模型 | dw.ads_vte_patient_result | patient_organization=院区,superior_doctor=主管医生,medical_doctor_group=医疗小组,inpatient_department=在院科室,inpatient_area=在院病区,admission_date=入院日期,admission_department=入院科室,admission_area=入院病区,discharge_date=出院日期,discharge_department=出院科室,discharge_area=出院病区,days=住院天数,total_medical_expenses=住院总费用,current_bed_code=当前床号,admission_diagnose=入院诊断,discharge_diagnose=出院诊断,in_hospital=是否在院,is_invalid=是否需要排除,day_patient=是否日间患者,is_invalid_word=是否满足排除识别词,is_out_vte=是否是院外VTE,is_dead=是否死亡,is_operation=是否手术患者,is_transfer=是否转科患者,is_jxyfjj=机械预防禁忌类型,vte_examination_name=VTE检查名称,vte_examination_result=VTE检查结果,examination_name=检查名称,examination_result=检查结果,test_name=检验名称,test_result=检验结果 |
数据表-元数据字典知识库
建立表结构数据字典知识库，明确分类增加结构化知识和非结构化知识类型和业务解释等标签字段，这个知识库当做大模型解析需求生成检索任务依赖的知识库，即
1，大模型解析需求必须对应到该知识库的字段上，如果找不到要明确指出（比如我们没有建采集表的情况）
2，结构化知识使用sql查询返回结果，非结构化知识，使用sql 查询返回后使用大模型分析内容返回结果
3，检索优先使用结构化类型的字段，没有返回值时，再使用非结构化文书，除非明确指出使用非结构化字段
大模型解析需求结果：明细各个条件需要到哪个表中哪个字段查找
举例：
|-----------------|---------------------------------------------------------------------------------|-------------------------|--------------|--------|---------------------|---------|
| 字段中文名 | 字段业务补充解释 | 字段英文名 | 字段类型 | 数据类型 | 来源表英文表名 | 来源表中文表名 |
| 身份证 | | id_card | varchar(50) | 结构化数据 | mt_patient_info | 患者信息 |
| 住院号 | | registration_no | varchar(64) | 结构化数据 | mt_patient_info | 患者信息 |
| 其他证件号 | | other_documents | varchar(50) | 结构化数据 | mt_patient_info | 患者信息 |
| 医保号 | | insurance_card_id | varchar(50) | 结构化数据 | mt_patient_info | 患者信息 |
| 医保类型 | 1城镇职工基本医疗保险、2新型农村合作医疗、3城镇居民基本医疗保险、4无 | insurance_type | int(2) | 结构化数据 | mt_patient_info | 患者信息 |
| 就诊次唯一标识 | | record_id | bigint(20) | 结构化数据 | mt_patient_info | 患者信息 |
| 母亲编号 | | mother_no | varchar(128) | 结构化数据 | mt_patient_info | 患者信息 |
| 患者名字 | | patient_name | varchar(128) | 结构化数据 | mt_patient_info | 患者信息 |
| 患者当前年龄 | | patient_age | double(11,3) | 结构化数据 | mt_patient_info | 患者信息 |
| 年龄单位 | | patient_age_type | varchar(20) | 结构化数据 | mt_patient_info | 患者信息 |
| 出生日期 | | patient_birth_date | datetime | 结构化数据 | mt_patient_info | 患者信息 |
| 国籍 | | patient_nationality | varchar(20) | 结构化数据 | mt_patient_info | 患者信息 |
| 民族 | | patient_nation | varchar(20) | 结构化数据 | mt_patient_info | 患者信息 |
| 性别编码 | 1.男，0.女 | patient_gender | int(1) | 结构化数据 | mt_patient_info | 患者信息 |
| 婚姻状态编码 | 1.结婚，2.未结婚 | marital | int(1) | 结构化数据 | mt_patient_info | 患者信息 |
| 是否怀孕编码 | 1.怀孕，2.未怀孕 | pregnancy | int(1) | 结构化数据 | mt_patient_info | 患者信息 |
| 籍贯 | | birth_place | varchar(200) | 结构化数据 | mt_patient_info | 患者信息 |
| 现住地 | | present_place | varchar(200) | 结构化数据 | mt_patient_info | 患者信息 |
| 职业 | | profession | varchar(200) | 结构化数据 | mt_patient_info | 患者信息 |
| 电话 | | phone | varchar(200) | 结构化数据 | mt_patient_info | 患者信息 |
| 是否在院 | 0:出院，1:在院 | in_hospital | int(2) | 结构化数据 | mt_patient_info | 患者信息 |
| 记录时间 | | record_time | datetime | 结构化数据 | mt_patient_info | 患者信息 |
| 接诊时间 | | visit_date | datetime | 结构化数据 | mt_patient_info | 患者信息 |
| 出生地（省直辖市） | | birth_place_province | varchar(256) | 结构化数据 | mt_patient_info | 患者信息 |
| 出生地（市） | | birth_place_city | varchar(256) | 结构化数据 | mt_patient_info | 患者信息 |
| 户口所在地（省直辖市） | | domicile_place_province | varchar(256) | 结构化数据 | mt_patient_info | 患者信息 |
| 户口所在地（市） | | domicile_place_city | varchar(256) | 结构化数据 | mt_patient_info | 患者信息 |
| 现工作单位名称 | | work_unit_name | varchar(256) | 结构化数据 | mt_patient_info | 患者信息 |
| 现工作地址 | | work_address | varchar(256) | 结构化数据 | mt_patient_info | 患者信息 |
| 联系人姓名 | | contacts_name | varchar(32) | 结构化数据 | mt_patient_info | 患者信息 |
| 医保类型代码 | | insurance_type_code | varchar(64) | 结构化数据 | mt_patient_info | 患者信息 |
| 医保类别代码 | | insurance_class_code | varchar(64) | 结构化数据 | mt_patient_info | 患者信息 |
| 医保类别名称 | | insurance_class | varchar(64) | 结构化数据 | mt_patient_info | 患者信息 |
| 联系人关系 | | contacts_relationship | varchar(32) | 结构化数据 | mt_patient_info | 患者信息 |
| 联系人地址 | | contacts_address | varchar(256) | 非结构化数据 | mt_patient_info | 患者信息 |
| 联系人电话 | | contacts_phone | varchar(32) | 结构化数据 | mt_patient_info | 患者信息 |
| 社保号 | | social_security_card | varchar(64) | 结构化数据 | mt_patient_info | 患者信息 |
| 教育程度 | | education | varchar(64) | 结构化数据 | mt_patient_info | 患者信息 |
| 患者状态, 0:无效 1:有效 | | patient_state | int(2) | 结构化数据 | mt_patient_info | 患者信息 |
| 病程唯一标识 | | progress_guid | varchar(128) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 病程类型类型编码 | 门诊病历：0 入院记录：1 首次病程：2 日常病程：3 查房记录：4 手术前记录：5 手术后小结：6 讨论小结：7 阶段小结：8 会诊记录：9 出院小结：10 | progress_type | int(11) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 客户文书名称 | | progress_type_name | varchar(255) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 文书标题 | | progress_title_name | varchar(255) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 文书模版名称 | | progress_template_name | varchar(255) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 病程内容 | | progress_message | longtext | 非结构化数据 | mt_patient_progress | 医院患者病程 |
| 文书状态 | 1.已保存 2.已提交 3.已审核 9. 已删除 | progress_status | int(2) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 医生姓名 | | doctor_name | varchar(128) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 医生编码 | | doctor_guid | varchar(128) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 记录时间 | | record_time | varchar(256) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 就诊次唯一标识 | | record_id | bigint(20) | 结构化数据 | mt_patient_progress | 医院患者病程 |
| 文书完成时间 | | finish_time_format | datetime | 结构化数据 | mt_patient_progress | 医院患者病程 |
2，推荐落地顺序（面向「生产可用」）
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| （1）先收口数据面：白名单表/视图 + 指标目录（你们已在规划）→ 再接到 Cube 或等价语义层。 （2）再上本体轻量版：核心指标清单 + 同义词 + 禁止歧义项（不必一上来做完整知识图谱）。 （3）Agent 编排：意图分类 → 是否需澄清 → 生成 结构化计划（指标 ID、维度、过滤）→ 转 Cube 查询 → 执行。 （4）评测闭环：每周用固定题集回归；线上对低置信度、大结果集、敏感域强制人工确认。 （5）最后放大缓存：在「查询计划级」缓存，并带 schema/指标版本。 |
|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 用户自然语言 ↓ [业务本体] 消歧、同义词、业务规则、指标注册 ID ↓ [Cube 语义层] 合法 measures/dimensions、join、权限、预聚合路由 ↓ [执行与护栏] 只读沙箱、超时、行级权限、结果行数限制 ↓ [语义缓存] 仅加速「已校验」的解析结果或查询计划（带版本） |
|------|---------------|---------------|---------|
| 手段 | 主要提升 | 对「准确率」 | 典型风险 |
| 语义缓存 | 速度、成本、重复稳定性 | 间接（稳定对的或稳定错的） | 过期、错案固化 |
| Cube | 口径一致、可执行子集、权限 | 直接 | 建模成本 |
| 业务本体 | 消歧、术语对齐、规则 | 直接（意图层） | 治理成本 |
3，开源的chatBI 方案-包括构建标准语言层的工具模块
|---------|--------------------------------------------|-----------------------------------------|--------------------------------------|
| 评估维度 | WrenAI | Supersonic | DB-GPT |
| 上手难度 | 中等 | 较高 | 较高 |
| 查询复杂度支持 | 单层查询最优 | 多层嵌套最优 | 扩展场景最优 |
| 部署成本 | 2CPU/4GB | 4CPU/8GB | 4CPU/16GB |
| 二次开发 | 语义层定制 | Agent行为调整 | 插件开发 |
| 核心点 | GenBI：自然语言 → SQL / 图表，强调语义层（MDL） grounding | AI+BI：Chat BI + Headless BI，语义模型 + 对话分析 | AI 原生数据智能体平台：库表、文件、知识库、多 Agent、可扩展技能 |
| 技术栈 | 多服务（含向量库等），偏产品化一体机体验 | Java，可插拔（SPI），偏企业 BI 平台 | Python 为主，组件多，偏"平台 + 框架" |
| 适合场景 | 标准报表 | 探索式分析 | 复杂企业环境 |
| 典型用户 | 分析师 / 数据团队，已有数仓语义建模习惯 | 数据治理 + 业务自助分析，需要权限与语义统一 | 研发 / 数据平台团队，要深度定制 Agent 与工具链 |