数驭穹图 AI BI

业务问题与个人职责

业务问题：SQL 能执行 ≠ 业务答案正确——口径歧义必须澄清，结果必须可复现。我作为初创团队核心开发，主责语义层与领域路由、查询安全与证据绑定，支撑轻量湖仓。

系统链路

1. 意图路由
2. Schema 检索
3. 语义解析
4. SQL 生成
5. 安全校验
6. 证据绑定
7. 图表 / 报告

工程重点

Semantic Layer

行业领域包沉淀指标口径与术语别名，两级意图契约让业务理解与 SQL 实现可独立归因。

Query Safety

权限上下文、受治理工具、SQL AST 审查与输出脱敏分层设防，租户隔离由服务端注入。

Evidence Binding

口径歧义必须澄清；图表绑定 call_id + query_fingerprint + result_hash，失败降级不阻断。

可验证证据

Eval

端到端查询成功率约 +13pt（跨行业评测集）

Recall

Schema 召回约 +14pt（固定评测集）

Safety

对抗请求全部拦截 · 误拦约 3%

Cost

分析上下文 Token 约 -80%

Trust

图表绑定 call_id + fingerprint + hash

Python · FastAPI · PostgreSQL · DuckDB · Parquet · R2 · Univer · MCP

设计取舍

1. Workflow 管主流程，Agent 只处理局部决策

   为什么

   完全固定的 Pipeline 应付不了自然语言的变化；完全自主的 Agent Loop 又让权限、成本和业务前置条件变得不可控。

   代价

   状态与转移必须显式设计，改一条主流程比改一句 Prompt 慢得多；跨域前置条件要写死在代码里，灵活性换可控性。

2. 指标口径沉淀在语义层，而不是让模型每次现推

   为什么

   SQL 能执行不等于业务答案正确——「销售额」到底是下单金额还是支付金额，必须由业务定义一次，而不是由模型每次猜。

   代价

   领域包、指标、维度、术语别名都要持续维护；新接入一个数据源得先做语义资产，起步比直连数据库慢。

3. 图表必须绑定证据，绑定失败降级而不是阻断

   为什么

   合法 JSON 只能保证字段存在，不能保证数值来自真实查询、没有被模型补写。但因为一张图就中断整条回答，代价又过高。

   代价

   要在 Tool Call 与渲染之间维护 call_id、query_fingerprint、result_hash 三者的传递，任何一环改动都要同步；降级意味着用户偶尔会看到「不可信」的图表。

4. 数据过期时 fail closed，而不是展示旧结果

   为什么

   无法证明数据是当前的，就不该生成「当前」结论。静默展示旧数据比明确报错危险得多。

   代价

   可用性下降——数据源抖动时用户拿到的是失败原因而非答案，需要额外的缓存与重试策略来把这种情况压到最低。

系统不负责清单

刻意划出的非目标。写下来的边界才是能守住的边界。

• 不替代 ERP、CRM、电商平台与财务系统承担业务交易
• 不替代企业建设完整的离线数仓、实时数仓或大型数据治理平台
• 不自动修复源系统中缺失、错误或长期未更新的数据
• 不允许大模型绕过权限访问全部数据库、系统表或敏感字段
• 不向模型提供生产数据库的任意写入能力
• 不由 AI 单方面决定销售额、有效用户、利润等正式业务定义
• 不把模型生成的解释自动视为经过证明的因果结论
• 不在数据质量差、语义缺失或权限不足时强行生成确定答案

开放问题

目前还没有答案的部分。欢迎就其中任何一条追问。

• 语义资产的维护成本随数据源数量线性增长，还没有好办法让它自动跟上源系统的结构变更
• 指标口径冲突时系统能检测并澄清，但「谁有权最终裁定」是组织问题——技术只能把冲突暴露出来
• 结果合理性检查依赖结构特征（粒度、JOIN 膨胀、单位一致性），对物理上合法但业务上无意义的查询仍会放行
• 跨多个数据源的关联查询，在只读、限时、限量的约束下如何兼顾性能与安全，目前没有定论