NL2SQL 在超大规模数仓场景的架构突破与工程实践

本文作者：薛飞跃

01前言

在高德的数据驱动运营体系中，产运同学有大量的日常取数需求：“昨天美食行业的 GMV 是多少”“按城市看一下上周的广告消耗”“本月新客订单数趋势如何”，等等。这些问题看起来不复杂，但要得到一个准确的答案，传统路径是：提交需求给 BI 分析师 → 分析师理解口径、写 SQL、跑数 → 返回结果。一个简单的取数请求，从提出到拿到答案往往需要数小时甚至跨天。

我们面对的数仓并不简单。高德的数仓覆盖交易、业财、广告、流量、内容、供给（门店）、商品、服务、搜索归因转化等 9 个业务域，涉及数千张 ODPS 表，同一个「收入」在广告域和业财域的口径完全不同，同一个"供给"在门店和商品两个粒度各有定义。这种业务复杂度，让「让 AI 帮你写 SQL」这件事从技术可行到业务可用之间，横亘着巨大的鸿沟。

我们基于 QoderWork Agent Skill 构建了一套 NL2SQL 智能取数系统，系统定位很明确：以元数据为权威、以规则为约束、以 LLM 为规划器、以 ODPS 为执行引擎。它是一个深度绑定业务数仓的智能体系统：理解高德的业务术语，知道每张表该怎么用、不该怎么用，能在口径歧义时主动澄清，能在结果返回时附上完整的口径说明。

这篇文章记录了系统从 V1 到 V2 的架构演进过程，以及在这个过程中沉淀下来的知识工程方法论。如果你也在做面向企业数仓的 NL2SQL 系统，或者在用 Agent Skill 架构解决需要大量领域知识的问题，希望这些经验能提供一些参考。文章的三个重点是：架构设计与演进（第二、三章）、知识工程方法论（第四章）、以及从实践中提炼的设计原则（第六章）。

02V1：分域独立 Skill—快速验证与瓶颈暴露

2.1 V1 的设计

V1 阶段，我们用最朴素的方式起步：按数仓的业务域拆分，每个域部署一个独立的 QoderWork Skill。8 个取数 Skill 分别对应交易、业财、广告、流量、内容、供给、商品、服务 8 个域，再加 1 个 odpscmd 工具 Skill 负责 SQL 执行，总共 9 个 Skill。

每个 Skill 是完整自包含的：有自己的 SKILL.md（提示词）、自己的 references/ 知识库（表结构、指标口径、业务知识），彼此独立迭代。这个架构的优点是边界清晰：交易域的 Skill 只管交易的表，不会干扰广告域的逻辑。我们快速覆盖了约 40 张最核心的结果层（ADS）表，大量产运同学开始试用。

从结果来看，V1 验证了一个核心假设：当知识库质量足够高、提示词约束足够严格时，LLM 确实能够在企业数仓场景下生成准确的 SQL。域内的取数准确率很快达到了可用水平。但当用户规模扩大、表覆盖范围开始从 40 张向 352 张扩展时，V1 暴露了一系列结构性问题，这些问题不是「优化 V1」就能解决的，它们指向了架构层面的根本局限。

2.2 五个结构性问题

问题一：用户安装与选择成本高。 用户需要从 9 个取数 Skill 中自行判断安装哪几个，使用时通过 @Skill 手动指定调用。但产运同学并不理解数仓的域划分逻辑，例如“我想看收入”，应该 @ 广告 Skill 还是业财 Skill？如果是“我要查供给数据”，是门店还是商品？当用户安装了多个 Skill 后，每次提问都要先做一次领域判断，这个心智负担不应该转嫁给用户。

问题二：Skill 间路由天花板低。 QoderWork 在用户未手动指定 Skill 时，依赖 Skill 的 description 文本做语义匹配来自动路由。这种机制在 Skill 数量少、语义边界清晰时能工作，但在我们的场景下很快遇到了上限。「收入」「供给」「DAU」「留存」这些业务术语在不同域中有不同含义，一句 description 无法承载足够的消歧信息。更关键的是，这层路由在 Skill 外部完成，我们无法介入调试——既看不到路由决策过程，也无法针对特定易混淆场景写规则。

问题三：表规模扩充加剧域间冲突。 V1 阶段每个 Skill 只覆盖少量结果层（ADS）表，域间重叠较少。但当我们把覆盖范围从 40 张扩展到 352 张，特别是加入大量明细层（DWD）和汇总层（DWS）表之后，域间的概念边界变得模糊。明细表天然涉及跨域关联（比如交易订单表需要 JOIN 流量归因表来分析转化漏斗），这种跨域查询在多 Skill 架构下根本无法支持，用户的一个问题被路由到了交易 Skill，但它还需要读取流量域的知识才能正确生成 SQL。

问题四：维护成本指数膨胀。 公共逻辑在 9 个 SKILL.md 中各维护一份：日期计算规则、odpscmd 执行配置、权限处理流程、SQL 安全约束、节假日判断。每次更新一条公共规则，需要在 9 个文件中同步修改，容易漏改，事实上也确实多次因为漏改导致某个域的行为与其他域不一致。

问题五：后续扩展和迭代不便。 当我们需要新增一个业务域，或者因为业务调整需要重新划分域边界时，多 Skill 架构的变更成本很高——不仅要创建/重组 Skill 本身，还需要所有用户重新安装、重新适应。这让架构的演进变得僵硬。

2.3 认知转折

V1 的五个问题指向一个共同的根因：Skill 间的路由决策发生在我们的控制范围之外。当路由准确率成为系统天花板，而我们对路由机制既无法调试也无法增强时，就必须把路由逻辑收回到 Skill 内部。

这就引出了 V2 的核心命题：如何在一个 Skill 内，既实现统一入口和智能路由，又避免把 9 个域的全部知识一次性塞进上下文窗口？

03V2：统一 Skill + 确定性两级路由

3.1 四层架构设计

V2 的核心决策不是简单地“把 9 个 Skill 合并成 1 个超大 SKILL.md”，那样会导致上下文窗口溢出、域间规则冲突、维护时的合并地狱。真正的设计是在一个统一 Skill 内部建立分层架构，每一层解决一个明确的问题。

L1 · 域路由层（SKILL.md 内置）： 从用户问题中提取意图（想看什么指标、从什么视角看），查域路由表判定所属业务域。路由表是一张确定性规则表，用“典型指标关注点 + 判断要点”来区分域，比如“看交易结果（实际成交了多少）”走交易域，“看财务数据（公司赚了多少钱）”走业财域。当检测到歧义术语时，主动向用户发起澄清。

L2 · 知识加载层（references/ 目录结构）： 路由判定域之后，只读取该域的 reference 文件，而非一次性加载全部知识。9 个域的知识库合计约 30,000 行，但单次查询只需要加载 200-400 行，路由用少量 Token 开销换取了上下文空间的极大节省。

L3 · 标准工作流层（SKILL.md 内置）： 所有域统一遵循 6 步标准流程：前置检查 → 域路由 → 知识加载 → 口径确认 → 选表+SQL 生成（含 5 点自检）→ 执行+结果解读。这结束了 V1 中“有的域会细致确认口径、有的域直接出 SQL”的质量参差。

L4 · 公共服务层（references/common/ + SKILL.md 公共规则）： 日期计算、SQL 安全约束、odpscmd 执行协议、权限处理流程、节假日判断，这些公共逻辑只编写维护一份，所有域共享。

四层架构的本质是关注点分离：L1 决定「去哪个域」，L2 决定「加载什么知识」，L3 定义「怎么做」，L4 提供「公共基础设施」。每一层都可以独立迭代，优化路由规则不影响工作流，增加新域只需在 L2 加一个目录、在 L1 加几条路由规则。

3.2 为什么选确定性路由而非 RAG？

这是我们被问到最多的设计决策。既然有 352 张表，为什么不用 RAG（向量检索）来做表选择？

原因有三：

• 第一，业务术语的语义重叠让 embedding 相似度不可靠。「收入」在广告域指广告投放收入，在业财域指财务结算收入——这两个「收入」的 embedding 几乎一模一样，但对应的表和口径完全不同。类似的情况还有「供给」（门店 vs 商品）、「DAU」（大盘 vs 业务线）、「补贴」（预估 vs 结算）等。在我们的业务场景下，模糊检索反而是最容易出错的环节。

• 第二，352 张表按域分组后是可枚举的。9 个域，每个域内的表数量在 3-96 张之间。域路由是一个有限分类问题，完全可以用规则穷举。域内的表选择也是如此，每个域的 DOMAIN.md 维护着“问题类型 → 推荐表”的映射表，高频场景直接命中，低频场景按优先级链回退。这种确定性路径的好处是可调试、可追溯，每一次路由决策都能回答“为什么选了这个域/这张表”，出了问题可以定位到具体的规则行。

• 第三，关于未来的扩展性考虑。我们当然思考过“如果表规模增长到 2000+ 怎么办”，答案是混合架构：域路由层保持确定性规则（域的数量不会爆炸），域内的表选择层可以引入 embedding 辅助排序。但在当前 352 张表的规模下，纯规则方案的准确率已经足够高（详见第七章落地数据），引入向量检索带来的工程复杂度和可解释性损失不值得。

3.3 两级路由详解

两级路由是 V2 架构的核心机制。

一级路由（SKILL.md 域路由表，~200 行） 负责跨域消歧。它不是简单的关键词匹配，而是基于"用户想看什么指标、从什么视角看"的意图判断：

路由表同时维护一组易混淆术语消歧规则。比如当用户提到「收入」时：如果上下文包含「投放」「消耗」「广告主」等词，路由到广告域；如果包含「结算」「净收入」「UE」等词，路由到业财域；如果无法判断，触发澄清“你说的’收入’是指 A. 广告投放收入 还是 B. 财务结算收入？”。澄清机制的原则是不问开放问题，只给 2-3 个候选选项，最大限度降低用户认知负担。

二级路由（{domain}/DOMAIN.md，~100 行/域） 负责域内选表。每个域的 DOMAIN.md 包含以下内容：域边界定义（什么属于/不属于本域）、可用表清单及迁移状态、常见问题到推荐表的映射、选表优先级链（ADS > DWS > DWD）、跨域边界指引（什么时候应该转到其他域）。

比如交易域的 DOMAIN.md 会写明：问订单量/GMV 的标准问题，优先使用 ads_gd_info_order_biz_trade_overview_di（结果层总览表）；如果需要按非标维度交叉分析，降级到 dws 层；只有在需要明细排查时才使用 dwd 层表。

3.4 渐进式知识加载

9 个域的 reference 知识库合计约 30,000 行。如果一次性全部加载到上下文窗口，不仅远超 LLM 的有效处理能力，还会因为信息噪音严重降低准确率。渐进式加载是 V2 架构的另一个核心设计。

加载过程分四级，由粗到细：

这意味着一个典型的取数查询，实际加载量在 200-400 行之间，和 V1 阶段单个域 Skill 的负载基本持平。我们用路由逻辑的少量 Token 开销（约 200 行域路由表），换取了管理 352 张表知识的能力，同时保持了每次查询的上下文效率。

这种设计的一个额外好处是加载路径即推理路径。当系统出错时，我们可以追溯“它读了什么文件”，如果是该读没读，说明路由规则有缺漏；如果是读了但理解错了，说明文档本身需要优化。这让问题定位变得非常高效。

3.5 统一 6 步标准工作流

V1 中各域 Skill 的工作流质量参差不齐，有的域会仔细确认口径，有的域直接生成 SQL；有的域在结果中标注了数据来源，有的域只返回一张表格。V2 定义了一套所有域统一遵循的 6 步流程：

• Step 1 · 前置检查： 识别问题是否涉及节假日（如春节、国庆），如涉及则加载节假日日历辅助时间计算。

• Step 2 · 一级路由（域判定）： 提取指标意图、维度、过滤条件、时间范围，查域路由表判定所属域。歧义时触发澄清。

• Step 3 · 二级路由（知识加载）： 读取目标域的 DOMAIN.md，定位候选表，按需加载表文档。

• Step 4 · 口径确认： 检查是否存在时间口径（自然月 vs 近 30 天？）、指标口径（支付金额 vs 下单金额？）、维度层级（一级类目 vs 二级类目？）等歧义。存在歧义时，输出候选选项供用户选择；用户已明确全部条件则跳过。

• Step 5 · 选表 + SQL 生成 + 自检： 按 ADS > DWS > DWD 的优先级选表，生成 SQL 后执行 5 点自检——分区条件是否存在？字段是否来自所选表？CUBE 表维度是否正确约束？JOIN 键是否合法？LIMIT 是否设置？

• Step 6 · 执行 + 结果解读： 通过 odpscmd 执行 SQL，将结果整理为 Markdown 表格，用业务语言解释含义，附上口径说明（来源表、计算公式、时间范围、过滤条件）。

统一工作流带来的最大收益是质量基线可控，不是「流程规范」本身：每个域、每次查询的输出标准是一致的，这让评测和迭代变得有章可循。

04知识工程方法论—让 352 张表 「AI-Friendly」

如果说架构设计决定了系统的上限，那么知识工程决定了系统能在多大程度上逼近这个上限。在整个项目中，知识库建设是最重的投入：352 张表、约 30,000 行结构化文档，占据了 60% 以上的工作量。这个过程中我们最深刻的认识是：NL2SQL 系统的天花板在于知识质量（不在于模型能力）。

4.1 表文档标准化：6 节知识卡片

每张表对应一个 Markdown 文件，文件名与表名一致，长度控制在 50-130 行。所有表文档遵循统一的 6 节结构，我们内部称之为「知识卡片」：

• S1 · 表元数据： 全表名（含 project 前缀）、数仓层级（ADS/DWS/DWD）、数据粒度、分区字段、更新频率、出数时间。这些信息决定了“这张表能不能用，比如用户问的是今天上午的数据，但表是 T+1 日更新的，就需要提前告知。

• S2 · 字段列表： 每个字段标注 KEY（主键/分区键）、DIM（维度字段）、IDX（指标字段）前缀，附中文释义和使用说明。前缀标注看起来是小事，但对 LLM 的影响很大，它让模型能快速区分“哪些字段该放在 GROUP BY 里，哪些该放在聚合函数里”。

• S3 · 场景映射： 明确标注这张表“适用什么问题”和“不适用什么问题”。比如一张 ADS 层的总览表，适用于标准指标查询，但不适用于明细排查或非标维度交叉分析。这个信息在选表阶段至关重要，它帮助系统在多个候选表之间做出正确选择，也避免了「用错表」导致的口径偏差。

• S4 · 关联方式： 如果这张表需要 JOIN 维度表才能支持某些查询（比如按城市名而非城市 ID 过滤），这里标明关联哪张维度表、用什么键关联。关联规则被集中管理在 common/DIM_INDEX.md 中，单表文档只做指引。

• S5 · 指标口径定义： 这是整个知识卡片中最关键的一节。每个指标的计算公式、口径说明、注意事项都在这里定义。比如“GMV = SUM(pay_amt)，口径为已支付订单实付金额，不含退款；如需包含退款请使用 dws 层表”。口径来自知识库、不得由模型编造，这是系统的硬约束。

• S6 · SQL 模板： 针对高频查询场景提供参考 SQL，让模型不必从零构造，而是在模板基础上做参数化调整。模板不是硬编码的答案，而是“最佳实践的参考”，模型可以在模板的结构基础上适配用户的具体条件。

为什么是 6 节而不是更少？因为少于这 6 节，会导致信息缺失，比如没有场景映射，选表就会出错；没有口径定义，生成的 SQL 可能语法正确但语义错误。为什么不是更多？因为每多一节都在增加单表文档的长度，而知识加载的 Token 预算是有限的。6 节是我们在信息完整性和加载效率之间找到的平衡点。

4.2 元数据产出 Pipeline

352 张表、30,000 行文档，靠纯手工编写不现实。我们设计了一条半自动化的产出 Pipeline：

• 第一步 · 技术元数据拉取（自动化）。 通过 Data Map 的 MCP API 批量拉取 ODPS 表的技术元数据：表名、字段名、字段类型、分区信息、数据行数、Owner 等。这一步完全自动化，能在几分钟内完成 352 张表的基础信息采集。

• 第二步 · 初版文档生成（半自动化）。 利用 LLM 基于技术元数据自动生成表文档的初版，推断字段的中文含义、判断表的数仓层级和数据粒度、生成初步的场景映射。这一步能完成约 60% 的文档内容，但产出质量参差不齐，尤其是业务含义的推断经常不准确。

• 第三步 · 业务知识注入（人工）。 这一步无法自动化，也是整个 Pipeline 中最耗时的环节。BI 数仓同学需要为每张表补充：指标口径的精确定义（DDL 注释中的口径说明往往不够精确）、业务规则和注意事项（比如 CUBE 表的维度过滤必须写 = 'all' 而不能省略）、场景适用性的准确判断、SQL 模板的最佳实践。这些知识存在于数仓同学的头脑中，需要逐域逐表地提取和结构化。

• 第四步 · 标准化校验（自动化）。 对生成的文档进行格式规范检查：字段覆盖率是否达标（DDL 中有的字段是否都在文档中出现）、6 节结构是否完整、命名规范是否一致。不合格的文档返回修正。

为什么不能全自动？因为 DDL 只包含技术元数据：字段名和类型。但“pay_amt 这个字段是含退款的总额还是扣除退款后的净额？”“这张表的 is_new_buyer 字段，'新客’的定义是首次支付还是首次注册？”这些业务口径信息不在 DDL 里，必须来自领域专家。元数据的宽度决定了系统能覆盖多少表，元数据的深度决定了系统能答对多少问题。

4.3 知识分层与变更频率对齐

30,000 行知识不是铁板一块，不同类型的知识有不同的变更频率。如果把高频变更的规则和低频变更的元数据混在一起维护，每次改动都可能引发不必要的回归风险。V2 架构按变更频率把知识分为三层：

• 静态层（表结构、字段定义）： 随 DDL 变更低频更新。当线上表新增字段或调整类型时，通过 DDL 一致性监控自动检测漂移，触发文档更新。这层知识的特点是「一次写好、长期不动」。

• 规则层（路由规则、域内选表映射、口径消歧规则）： 按业务需求中频调整。比如新上线一个业务活动，需要在路由表中增加相关的指标关键词；或者发现某个消歧规则不够精确，需要增补判断条件。这层知识的维护主要由 Skill 开发者负责。

• 公共层（日期计算指令集、维度表索引、执行协议、节假日）： 全域共享、高度稳定。每年更新一次节假日日历，执行协议在架构确定后基本不变。

分层的一个关键洞察是写粒度和读粒度的分离。维护者按域批量更新文档（“把广告域所有表的字段前缀统一标注一遍”），但 LLM 在查询时按单表按需读取（“只加载 ads_gd_info_ad_consume_di.md 这一张表的文档”）。知识库的目录结构，每个域一个子目录、每张表一个文件，天然支持这种分离。

4.4 AI-Friendly 标准分

知识质量是一个模糊的概念，我们需要把它量化。「AI-Friendly 标准分」是我们设计的知识质量评分体系，从以下维度对每个域的知识库打分：

字段覆盖率——DDL 中的字段是否都在文档中有对应描述？口径完整度——核心指标是否都有明确的计算公式和口径说明？SQL 模板覆盖率——高频查询场景是否有参考 SQL？场景标注率——表文档中是否标注了「适用/不适用」的场景？路由规则完备度——域路由和表路由中的映射关系是否覆盖了主要问题类型？

标准分驱动了整个知识库的迭代循环：评测发现准确率低的域 → 检查该域的标准分 → 定位薄弱维度 → 针对性补强 → 重新评测。这让「提升准确率」从一个模糊的目标变成了可执行的 checklist。

05质量保障与持续演进

架构和知识库搭建好之后，系统的持续运转依赖一套质量保障体系。这里简要介绍三个关键机制。

5.1 评测驱动迭代

我们维护了 900+ 道测试题覆盖全部业务域，通过自动化评测 Skill（automated-evaluation）批量执行：依次向取数 Skill 发送问题，对比生成的 SQL 和执行结果与标准答案，输出通过率报告。每一次知识库更新或路由规则调整后，都会跑一轮回归测试。

评测不只看「对不对」，还做错误归因分析，把每道错题归类为：选表错误（选了错误的表）、SQL 语法错误（生成的 SQL 无法执行）、口径理解错误（用了错误的指标定义）、用户语义模糊（问题本身需要澄清但系统未触发）。这种分类让迭代有的放矢，如果一轮测试中 30% 的错误来自选表，那就优先优化 DOMAIN.md 中的选表映射规则；如果 20% 来自 SQL 语法，就优化表文档中的 SQL 模板和约束说明。

5.2 DDL 一致性监控

线上数仓表的结构不是一成不变的，字段可能新增、删除、改类型、改注释。如果知识库中的表文档与线上实际表结构不一致，就会出现「沉默失败」，生成的 SQL 引用了一个已经不存在的字段，执行报错，用户体验极差。

cici_monitoring 是我们开发的 DDL 一致性监控工具。它定期对比线上 ODPS 表结构（通过 MCP 接口获取 DESC 信息）与知识库中的表文档，检测字段新增、删除、类型变更、注释不一致等漂移情况，输出差异报告。这确保了知识库与线上数仓保持同步，防止元数据腐化。

5.3 用户反馈闭环

除了主动的评测和监控，用户的使用反馈也是重要的迭代输入。我们关注三类沉默信号：用户在系统返回结果后做了纠正（“不对，应该是……”）、同一个问题被多个用户重复提问但结果不一致、用户放弃了对话（提问后没有追问也没有确认）。这些信号通过规则匹配自动检测，进入问题池。

配套的值班管理机制保证每周有人 review 问题池，把高频问题转化为知识库更新或路由规则修正。同期维护的 FAQ 册子将已解决的高频问题沉淀为自助服务资源。这套反馈闭环使得问题解决率稳定在 70% 以上。

06核心设计原则

两个月的架构演进和知识工程实践，让我们沉淀了五条设计原则。这些原则是在踩坑和修正中逐渐形成的认知。

• 原则一：确定性优于模糊性。 路由、选表、SQL 关键约束，这些决定系统可靠性的环节，走确定性规则而非依赖模型的概率输出。规则可调试、可追溯、可精确修正；而模型的「猜测」即使 90% 的时候是对的，那 10% 的错误你无法预测、无法定向修复。LLM 的价值在于理解自然语言、做灵活的推理和表达，而不是做本该用规则解决的分类决策。

• 原则二：按需加载优于全量灌入。 上下文窗口是稀缺资源。把 30,000 行知识一次性塞进去，模型不是读不了，而是读了之后注意力被稀释、准确率反而下降。用路由逻辑的少量 Token 开销（~200 行路由表）换取按需加载能力（单次 200-400 行），是 Token 经济学下的最优解。这个原则的推论是：知识库的组织结构不是为人设计的，而是为 LLM 的加载路径设计的。

• 原则三：知识分层对齐变更频率。 把变化快的规则和变化慢的元数据混在一起，每次修改都是高风险操作。按变更频率分层之后，静态层可以「写一次用半年」，规则层可以「随时调、快速验」，公共层「全域共享、一改全改」。这降低了维护成本，也降低了回归风险。

• 原则四：标准化优于自由发挥。 统一的 6 节表文档结构、统一的 6 步工作流、统一的路由表格式，这些标准化约束看起来限制了灵活性，但实际上是质量基线的保障。在多域、多人协作的场景下，自由发挥意味着质量不可控。标准化让每个新域的接入有章可循，让评测有统一的标尺。

• 原则五：评测驱动优于经验判断。 准确率和 AI-Friendly 标准分是迭代的唯一指南针。“我觉得这个路由规则应该这样写”不如“改完之后回归测试准确率提升了 2 个百分点”有说服力。评测驱动的另一个好处是让团队建立了共同的质量语言，不用争论「好不好」，直接看分数。

07落地成效与展望

7.1 关键成效

截至 2026 年 4 月底，系统在三个业务方向落地，均采用同一套架构设计，统一迭代。

在覆盖规模上，业务方向 1 实现了大量产运同学的覆盖。在能力指标上，多个业务方向的 NL2SQL 准确率超过 95%。在效率提升上，智能问数场景覆盖率超过 90%，相比传统手动取数流程（约 8 小时）缩短 30 倍以上。

这些数据说明了两件事：第一，确定性路由 + 知识工程的技术路线在当前的表规模下是有效的；第二，同一套架构能够低成本地横向复制到不同业务方向，新方向的接入主要是知识库的建设工作，架构层面几乎不需要改动。

7.2 未解决的问题与展望

坦率地说，系统还有明显的能力边界。

第一个未解决的问题是取数 Skill 与分析 Skill 之间的跨 Skill 知识共享。取数解决「查到数」的问题，分析解决「看懂数」的问题，比如“GMV 为什么下降了？按城市拆解归因”。目前两个 Skill 的知识库是独立维护的，分析 Skill 需要重复引用取数 Skill 中的表画像和口径信息。如何让两个 Skill 的知识高效协同，是一个架构层面待解决的问题。

第二个方向是知识库的平台化管理。当前的 30,000 行知识文档散落在 references/ 目录结构中，依赖人工维护，且为了路由效率被组织成树形结构（域 → 表 → 字段）。但知识本身的关联关系是图状的：一张表的口径定义可能引用另一张表的字段、一个业务规则可能跨越多个域生效、维度表被数十张事实表共享。树形结构是对路由友好的妥协，不是知识的自然形态。更现实的挑战是知识的过时与冲突检测：当一张表的口径定义更新了，引用它的其他文档是否同步更新了？当两个域对同一个术语给出了不同定义，系统能否自动发现？目前这些依赖人工 review，效率低且容易遗漏。我们正在探索基于 KBase 搭建结构化知识平台，目标是让知识以图的形式管理、以树的形式加载，同时具备过时检测和冲突发现的自动化能力。

第三个方向是建立端到端的 Agent 评测机制。当前的评测聚焦于 SQL 准确率，但用户的真实体感还包括回答的清晰度、口径解释的可理解性、交互的流畅度等维度。我们计划建立一套覆盖端到端使用体感的 Agent 评测体系。

NL2SQL 不是一个模型问题，是一个知识工程问题。模型能力在进步，但企业数仓的复杂性、业务口径的精确性、用户信任的建立，这些不会因为模型更强就自动解决。架构设计和知识工程，才是这类系统真正的技术壁垒。