[{"data":1,"prerenderedAt":153},["ShallowReactive",2],{"ai-capability-bi-ai-fusion":3},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":9,"slug":10,"order":11,"color":12,"kicker":13,"h1Main":14,"h1Sub":15,"pitch":16,"duration":17,"heroKpis":18,"scenariosTitle":30,"scenarios":31,"archLabel":44,"archNodes":45,"archExtra":63,"deliverables":64,"caseA":72,"caseB":84,"longformTitle":98,"faqs":99,"relatedCaseSlugs":112,"body":114,"_type":147,"_id":148,"_source":149,"_file":150,"_stem":151,"_extension":152},"\u002Fai-platform\u002Fbi-ai-fusion","ai-platform",false,"","BI + AI · 让数据自己讲故事","浩途为企业构建 BI + AI 自然语言数据分析层,含语义层映射、SQL 生成审计、字段血缘追溯等。","bi-ai-fusion",4,"amber","№ 04 · BI + AI · SEMANTIC","让数据\u003Cem>自己讲故事\u003C\u002Fem>，","让业务同事不再排队等分析师。","业务部门用\"上个月华东大区的退款率\"问出图表,而不是排队等分析师写 SQL。语义层兜底,AI 不能瞎编字段;全部 SQL 可审计,默认只读不能跑 UPDATE。已交付 2 个项目,6–10 周可上线。","6 – 10 周",[19,22,25,28],{"value":20,"label":21},"2 +","已交付项目",{"value":23,"label":24},"5 ×","分析师产能",{"value":26,"label":27},"0","SQL 误执行",{"value":17,"label":29},"标准交付周期","什么时候该考虑 BI + AI?",[32,35,38,41],{"title":33,"desc":34},"业务部门想看数据,分析师是瓶颈","财务、运营、市场每周都在排队找分析师写 SQL。希望业务能自己问出数据。",{"title":36,"desc":37},"数仓建好了,但用得很少","几百万的数据仓库,最后只有数据团队在用。业务想看的指标永远是下周再说。",{"title":39,"desc":40},"怕 AI 瞎编字段或错聚合","看过 AI 写 SQL 把退款率算成退款单数 \u002F 总订单数——表面对,实际错。希望 AI 不能瞎来。",{"title":42,"desc":43},"敏感数据怕被乱查","财务、人力数据涉密。希望 AI 只能查授权的字段,且全程留痕。","BI + AI 查询流",[46,49,52,55,58,60],{"kind":47,"label":48},"input","自然语言",{"kind":50,"label":51},"process","语义层",{"kind":53,"label":54},"model","SQL 生成",{"kind":56,"label":57},"guard","审计 + 只读",{"kind":50,"label":59},"数据库执行",{"kind":61,"label":62},"output","图表 + 洞察","语义层是 AI 不会瞎编的关键 · 字段血缘可追溯 · 默认只读不能 UPDATE\u002FDELETE",[65,66,67,68,69,70,71],"语义层映射(业务字段 ↔ 数据库表\u002F列)","AI 查询助手前端(自然语言输入、图表输出、追问能力)","SQL 生成可审计(每条 SQL 都留日志、可回放)","默认只读机制(语法层强制,不允许 UPDATE\u002FDELETE\u002FDDL)","字段血缘可追溯(图表 → SQL → 字段 → 业务定义)","多数据源支持(PostgreSQL \u002F ClickHouse \u002F MySQL \u002F 数仓)","权限分级(按部门 \u002F 角色控制可见字段)",{"tag":73,"meta":74,"title":75,"desc":76,"kpis":77},"数据 · 自助分析","2024 · ENTERPRISE · BI","微著 BI 平台 · 自然语言查询助手","企业级数据仓库之上加 AI 查询层。财务、人力、运营三大主题域开放自助分析。语义层兜底,SQL 全部可审计。",[78,80,81],{"value":79,"label":24},"5×",{"value":26,"label":27},{"value":82,"label":83},"3 主题域","覆盖",{"tag":85,"meta":86,"title":87,"desc":88,"kpis":89},"金融 · 字段血缘","2025 · FINANCE · LINEAGE","某金融集团 · 数据治理 AI 助手","数据团队的自然语言查询入口。语义层映射 200+ 业务字段,查询全审计,敏感字段权限隔离。",[90,93,96],{"value":91,"label":92},"200+","字段映射",{"value":94,"label":95},"100%","SQL 审计",{"value":26,"label":97},"越权查询","我们对 BI + AI 的理解",[100,103,106,109],{"q":101,"a":102},"AI 会不会瞎编 SQL 字段?","结构上不会。语义层是白名单——所有业务字段、计算口径、过滤规则都在语义层显式定义。AI 只能从语义层里选字段,没法瞎编。如果 AI 想用一个不存在的字段,系统会直接拒绝并返回未定义。",{"q":104,"a":105},"跟开源 Text-to-SQL 方案有什么区别?","开源 Text-to-SQL 让 AI 自由生成 SQL,浩途的方案是AI 只能调语义层提供的字段。前者准确率 60-70%,后者准确率接近 100%——代价是要前期定义语义层(这部分浩途负责)。",{"q":107,"a":108},"支持哪些数据库?","PostgreSQL \u002F MySQL \u002F ClickHouse \u002F Greenplum 已经实战过。其他主流 OLAP(Doris \u002F StarRocks \u002F TiDB)理论上都支持,需要做小规模测试再确定。",{"q":110,"a":111},"字段血缘怎么追溯?","每张图表都能反向追溯:图表 → 生成 SQL → 用到的字段 → 字段在语义层的定义 → 字段的业务负责人。这套追溯链让为什么这个数字是这样永远有答案。",[113],"weizhu-bi",{"type":115,"children":116,"toc":144},"root",[117,125],{"type":118,"tag":119,"props":120,"children":121},"element","p",{},[122],{"type":123,"value":124},"text","Text-to-SQL 这两年很热,但\"让 AI 直接写 SQL\"是错误的产品形态 —— AI 会把字段名瞎编、把聚合方式弄反、把时区算错。每一个错都比\"写不出 SQL\"更可怕。",{"type":118,"tag":119,"props":126,"children":127},{},[128,130,135,137,142],{"type":123,"value":129},"浩途坚持把",{"type":118,"tag":131,"props":132,"children":133},"strong",{},[134],{"type":123,"value":51},{"type":123,"value":136},"放在 AI 和数据库之间:业务字段、计算口径、过滤规则全部在语义层显式定义,AI 只能从语义层里选 —— 它",{"type":118,"tag":131,"props":138,"children":139},{},[140],{"type":123,"value":141},"不可能瞎编一个不存在的字段",{"type":123,"value":143},"。这套架构让 AI 输出的 SQL 100% 可审计、可解释、可追溯。",{"title":7,"searchDepth":145,"depth":145,"links":146},2,[],"markdown","content:ai-platform:bi-ai-fusion.md","content","ai-platform\u002Fbi-ai-fusion.md","ai-platform\u002Fbi-ai-fusion","md",1780542367785]