P1 AIP

AIP 限制与边界

NLQ 不是万能工具：歧义口径会答错、跨数据源 JOIN 做不了、数据质量差就不可靠。这 3 个故事把边界摊开讲——知道哪里会踩坑，才好在真正需要时给出正确姿势。

业务分析师数据工程师歧义跨源数据质量边界共 3 个故事

能 / 不能速览

✅ 这个主题能做

单数据源内 NLQ：意图识别 → RAG → Text2SQL → 执行 → 可视化一次走通
返回 SQL 与中文说明（sql_query / sql_explanation），可人工核对口径
最多 100 行结果，超限截断
可视化按列类型推荐（line / bar / pie / metric_card / table），失败回退 table
每次查询写 NLQ_QUERY 审计日志，可追溯

⛔ 这个主题做不了

无 Agent 框架 / 多智能体 / 多轮复杂任务；工作流编排已实现（8 节点 DAG + 三触发），但无循环 / 并行 / 人工审批等高级节点
无跨数据源 JOIN（一次查询只落一个数据源，工作流同样受限）
意图识别是关键词规则，歧义问题可能答错口径
RAG 是关键词匹配非向量检索，口语化 / 新词可能命中不了
知识库已接入 RAG 通道，但 knowledge_qa 知识问答仍返回占位；NLQ 本身无写操作 / 数据回写（写路径经 OAG 动作代理走 Foundry）
数据质量差时 NLQ 结果不可靠

适用角色

本主题面向两个角色：

业务分析师（王姐）：要懂边界，避免把 NLQ 当万能工具，学会"看 SQL 说明 + 换问法"。
数据工程师（张工）：负责把数据与元数据整理好，让 NLQ 真正可用。

IT 管理员（赵工）关注降级与审计；销售总监等业务决策者对结果负责，需要知道"什么时候别信 AI"。

能力速览（能做什么）

单源 NLQ 全链路

一句话查单数据源内的数，orders + customers + products 这类多表 join 在单个源内是支持的。

SQL 可解释

每次查询返回 sql_query 与 sql_explanation，结果不黑盒，口径可人工核对。

结果与可视化

最多 100 行结果；可视化按列类型推荐（line / bar / pie / metric_card / table），失败自动回退表格。

降级与兜底

LLM 不可用时沿降级链切备用或本地规则，保证链路可诊断、不"假死"。

审计留痕

每次查询写 NLQ_QUERY 审计日志，问题可追、命中率可统计。

调整指南（怎么调整）

歧义修正：换问法、补充表名 / 列名（"订单"→"orders 表的订单数"），或直接用 ai_generate_descriptions 补元数据口径。
跨源需求：拆成多次单源查询人工汇总，或让数据工程师先建宽表 / 汇总表。
数据质量：先清洗字段（去重 / 补空值 / 统一单位），再补元数据描述与同义词。
关键口径兜底：重要报表用数据团队口径交付，NLQ 用于快速探索。
怀疑结果：先看 sql_explanation，再核对行数 / 金额，别被"错得自信"的图表带偏。

做得好的场景

把 NLQ 当"自助探索工具"而不是"万能 BI"时，它以下场景很称职：

简单问题快：单源、口径明确的问题，一句话几秒出结果，演示稳定。
SQL 可见可核对：结果不黑盒，错了看得见、说得清。
降级与审计兜底：LLM 挂了有备用，查了什么都有据可查。

限制与不足

以下是明确的边界，使用前先知道：

无 Agent / 多智能体 / 跨源 JOIN：工作流编排已实现（模块 11：8 节点 DAG + 手动 / cron / Webhook 三触发），但无循环 / 并行 / 人工审批等高级节点；跨数据源联合查询仍不支持。
关键词意图 + 关键词 RAG：理解力有限，歧义和口语化是硬伤。
知识库只做 RAG 通道、NLQ 无写操作：知识库（模块 13）能把口径注入查询，但 knowledge_qa 问答仍占位；NLQ 只读，对象写路径需走 OAG 动作代理（依赖 Foundry）。
数据质量敏感：脏字段 + 缺描述 → 结果"错得自信"。
结果上限 100 行：明细类大结果需要自己加条件。

场景故事

故事 1 歧义"订单的平均金额"——模型把单价当金额，靠补充信息两分钟修正

场景：歧义修正角色：业务分析师耗时：约 5 分钟

背景: 王姐想算订单平均金额，输入"订单的平均金额是多少"。返回的 SQL 用的是 price（单价）而不是 sales_amount（销售额），平均下来 99.5 元，明显不对。原因：orders 表里 price 和 sales_amount 都像"金额"，元数据描述不全时模型只能按列名猜。

传统做法对比: 以前口径对不上要开会对齐、写进数据字典，1~2 天；现在 2 分钟就能换问法重问修正，但前提是元数据里有清晰描述，否则会反复踩坑。

角色: 业务分析师（王姐）。

操作步骤

输入"订单的平均金额是多少"
查看返回的 sql_explanation（发现用的是 price）
换问法："按销售金额算订单平均金额"
或直接点名列："用 sales_amount 平均订单金额"
重发并核对数值

系统响应

两次查询的对比：

-- 第一次：模型选了 price（单价）
sql_query: "SELECT AVG(price) FROM orders"
explanation: "订单的平均单价"
-- 修正后：显式点名 sales_amount
sql_query: "SELECT AVG(sales_amount) FROM orders"
explanation: "订单的平均销售金额"

结果洞察: 第一次算的是平均单价 99.5；修正后算平均销售金额 1296（995+995+1990+998+1492.5 再除以 5）。模型在"名字像"的列之间靠上下文猜测，RAG 上下文里没有口径说明时猜错是常态而非异常——所以核对 sql_explanation 是必做动作。

调整建议: 让张工用 ai_generate_descriptions 重导元数据，把 sales_amount 描述成"销售额（订单实付总额，非单价）"、price 描述成"单价"，从源头消除歧义；问法里直接带"销售金额"或列名；关键指标对不上时以数据团队口径为准。

动手试一试: 登录：admin / admin1。输入内容："订单的平均金额"与"订单的平均销售金额"。预期结果：对比两次 sql_query / sql_explanation，数值应分别是约 99.5 与约 1296。

限制提示: 意图识别不参与口径判断；RAG 上下文里没有的列模型不会用；歧义是模型固有缺陷，正确姿势是"看说明、换问法、补元数据"三连。

故事 2 跨数据源 JOIN 答不了——先拆成两步单源查，再人工汇总

场景：跨源边界角色：销售总监耗时：约 10 分钟

背景: 李经理想"把订单和库存拼起来看哪些商品要补货"。订单在 aip_demo_warehouse，库存在他另一个数据库里。他在 AIP 里试了几次，系统始终只在一个数据源内生成 SQL——因为 MVP 不支持跨数据源 JOIN。

传统做法对比: 以前跨库 JOIN 要 DBA 建 dblink 或物化视图，1~2 周排期；现在 AIP 明确"做不到"，但不代表不能解决问题——拆成单源分步查 + 人工汇总，几分钟出结论。

角色: 销售总监（李经理）+ 数据工程师（张工）。

操作步骤

明确问题拆解：先看"各商品的订单量"（在 aip_demo_warehouse 内）
再到库存系统 / 库里查"各商品库存量"
用表格工具按商品合并，算缺口
或让张工在目标库建好"订单 + 库存"宽表，再接入 AIP 用 NLQ 查

系统响应

即使问句提到两个数据源，NLQ 也只基于默认数据源（aip_demo_warehouse）的 schema 生成 SQL，data_source_name 恒为单源：

{
  "intent": "data_query",
  "data_source_name": "aip_demo_warehouse",
  "sql_query": "SELECT p.product_name, COUNT(o.order_id) AS cnt FROM orders o JOIN products p ON o.product_id = p.product_id GROUP BY p.product_name"
}

结果洞察: NLQ 一次查询只落一个数据源，跨源是硬边界。但单源内的多表 JOIN（orders + products + customers）完全支持——"各商品的订单量"一次就能查出来；跨源需求在数据工程侧把宽表 / 汇总表建好并导入元数据后，NLQ 就能直接消费。

调整建议: 常用跨源需求固化成语义层 / 宽表（数据工程师做）；临时需求先查主表再查关联表，人工用 Excel 汇总；大批量 / 高频的跨源报表走数据团队正式交付。

动手试一试: 登录：admin / admin1。输入内容："订单加库存"这类跨源问法。预期结果：data_source_name 始终是单源；再体验单源内的"各商品订单量"，确认多表 JOIN 是可行的。

限制提示: 无跨源 JOIN；单数据源内的多表 JOIN 支持良好；工作流（模块 11）的 query_data / nlq_query 节点同样只落在单个数据源；跨源不是调参能解决的，需要先在数据侧合并。

故事 3 数据质量差——字段脏、缺元数据时 NLQ 不可靠，该回头清理数据

场景：数据质量角色：数据工程师耗时：约 15 分钟

背景: 张工把一个销售源表接入 AIP：email 有乱填、city 有大量空值、sales_amount 有的记美元有的记人民币。他问"各城市的销售"，结果分组出现空白城市、金额口径混乱——问题不在模型，在数据本身。

传统做法对比: 以前这种问题常在月报期才暴露，返工 1~3 天；现在 NLQ 几分钟就暴露问题，但前提是有人愿意核对——否则脏数据被 AI"包装"得整整齐齐，反而更危险。

角色: 数据工程师（张工）+ 业务分析师（王姐）。

操作步骤

发现结果异常（空分组、金额离谱）
核对 sql_explanation 与元数据描述
检查源数据：去重、补空值、统一单位
重导元数据，补齐表 / 列描述与同义词
重问验证

系统响应

脏数据下的响应示例——city 空值导致空白分组、金额单位不一导致数值失实：

{
  "sql_query": "SELECT city, SUM(sales_amount) FROM orders GROUP BY city",
  "query_result": { "columns": ["city", "SUM(sales_amount)"],
    "rows": [["", 12450], ["北京", 500], ["上海", 30], ["上海", 220000]] }
}

结果洞察: NLQ 的可靠性上限 = 数据质量 × 元数据质量。脏字段 + 缺描述 → 模型只能按列名猜 → 结果"错得自信"。正确姿势是数据工程先清洗、补齐描述再谈 NLQ 提效；探索性分析用 NLQ，关键口径用数据团队兜底。

调整建议: 把常用表的描述 / 同义词补全（用 ai_generate_descriptions），命中率直接上升；建立"NLQ 结果抽检"习惯，大额决策人工复核；对敏感表收紧权限点，避免脏数据经 AI 放大后外流。

动手试一试: 环境：测试数据源。操作：故意给某列清空描述再问，对比 rag_context 变化；或插入一条脏数据（空 city / 单位混乱金额）。预期结果：NLQ 结果与预期偏差，清理重导后恢复。

限制提示: 平台不校验数据正确性，结果准不准由数据决定；结果上限 100 行；知识问答占位、无写操作、无跨源 JOIN 等硬边界始终不变。

常见问题

AIP 能跨数据源查询吗？

不能。MVP 一次查询只在一个数据源内执行；orders / customers / products 这种单源多表 JOIN 是支持的，跨源需求先在数据工程侧建宽表。

为什么答案有时候不对？

三条主要原因：意图识别是关键词规则（歧义会分错）、RAG 是关键词匹配（口语化命中不了）、数据质量差（字段脏 / 缺描述）。对策是换问法 + 补元数据 + 人工核对 sql_explanation。

结果最多多少行？

最多 100 行，超出截断。聚合类查询（COUNT / SUM / GROUP BY）一般不受影响，明细类大结果要自己加条件缩小范围。

有写操作吗？

NLQ 查询链路本身只读。但若配置了 OAG 对象路（foundry.oag.enabled=true 且连上 Foundry），可经动作代理端点 POST /oag/actions/:name/validate|execute 对 Foundry 对象执行动作（写路径在 Foundry 侧执行并受其 RBAC 约束）；未启用 OAG 时代理端点返回 404。AIP 侧没有直接的 SQL 写操作。

NLQ 结果可靠吗？

取决于数据质量与元数据质量。探索性分析可用；关键决策务必核对 sql_explanation，并用数据团队口径兜底。

主题小结

一句话：AIP 最小链路的边界很清晰——单数据源、只读、关键词理解。它擅长把"说得好的人话"变成 SQL，不擅长歧义、跨源和脏数据。知道边界，把它当"自助探索工具"而不是"万能 BI"。