第 1 章 导论：Agentic BI 与 TTD

本章学习目标 - 理解从"会出 SQL 的聊天机器人"到"Agentic BI"的演进脉络与技术驱动力 - 明确 TTD 在技术版图中的定位与能力边界 - 掌握 TTD 与主流方案（ChatGPT Data Analyst、Snowflake Cortex Analyst、Text2SQL 学术基准）的差异 - 理解本项目"学习与工程实践结合"的定位

前置知识：无（本章是全书起点） 关联代码：backend/app/agents/builder.py（编排全景）、semantic-plane/（治理资产）

---

1.1 背景与动机：从 NL2SQL 到 Agentic BI

1.1.1 问题的本质

"让业务人员用自然语言查数据库"是一个存在了二十年的老问题。它的吸引力显而易见：SQL 是分析师的母语，却不是业务人员的母语；如果能用"上个月华东区 GMV 同比增长多少？"直接得到答案，就能把数据能力下放到一线决策者。

但这个问题之所以难，不在于"把自然语言翻译成 SQL"这一步——大语言模型（LLM）已经把这一步做到了相当可用。真正的难点在于翻译之外的事：

难点	说明	举例
术语消歧	同一术语在不同部门有不同定义，LLM 不知道你的"GMV"是哪一种	"GMV"在 A 部门含退款、在 B 部门不含
表路径选择	同一指标可能来自多张事实表，走不同 join 路径，选错会重复计数或丢数据	fact_sales 直查 vs 关联 dim_region
幻觉防护	LLM 会编造不存在的表名、列名，尤其 schema 模糊时	生成 dim_sales.price（不存在）
执行安全	生成的 SQL 可能扫全表、可能泄露 PII、可能执行写操作	SELECT * FROM fact_transaction（无 LIMIT）
结果可信	跑出数字容易，让用户相信数字对——难	需要 SQL 可解释、依据可追溯

这些问题不是靠"换一个更强的模型"能解决的——它们是工程治理问题，需要系统化的约束、校验、可观测机制。这正是 Agentic BI 兴起的根本原因。

1.1.2 NL2SQL 技术的三个阶段

NL2SQL 技术演进可清晰划分为三个阶段，每个阶段解决上一阶段的核心痛点：

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#e8f0fe','primaryTextColor':'#202124','primaryBorderColor':'#1a73e8','lineColor':'#5f6368','secondaryColor':'#e0f2f1','tertiaryColor':'#f8f9fa'}}}%%
flowchart LR
    A["阶段一：Prompt-Only<br/>(2020-2023)<br/>全 schema 入 prompt"] --> B["阶段二：Schema-Aware RAG<br/>(2023-2024)<br/>检索相关表/列/示例"]
    B --> C["阶段三：Agentic BI<br/>(2024-)<br/>多步 Agent + 语义治理"]
    A -.->|"把 schema 塞进 prompt<br/>让 LLM 自由生成"| SQL1["SQL<br/>语法对但业务错<br/>幻觉多 · 不安全"]
    B -.->|"检索相关子集<br/>约束 LLM 生成空间"| SQL2["SQL<br/>准确率提升<br/>但无强制约束"]
    C -.->|"语义治理 + 图规划<br/>+ 五层护栏 + 自愈"| SQL3["可信 SQL + 洞察<br/>可治理 · 可解释<br/>可审计 · 安全"]

    classDef bpProcess  fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,color:#202124
    classDef bpData     fill:#e0f2f1,stroke:#0d7377,stroke-width:2px,color:#202124
    classDef bpSuccess  fill:#e6f4ea,stroke:#1e8e3e,stroke-width:2px,color:#202124
    classDef bpExternal fill:#f8f9fa,stroke:#dadce0,stroke-width:2px,color:#5f6368

    class A,B bpProcess
    class C bpSuccess
    class SQL1,SQL2 bpExternal
    class SQL3 bpData

    linkStyle 0,1 stroke:#1a73e8,stroke-width:2px

阶段一 · Prompt-Only（2020-2023）

把数据库 schema（或部分）塞进 prompt，让 LLM 直接生成 SQL。代表是早期 Spider/WikiSQL 基准上的微调模型（如 T5、TaBERT），以及 ChatGPT 出现后的 zero-shot prompt。

核心问题：

• schema 规模瓶颈：真实数仓动辄数百张表，全 schema 进 prompt 超出 token 上限；随机截断又丢失关键表。
• 术语全靠猜：LLM 的世界知识不知道你的"GMV"含不含退款，只能按常识猜——而企业术语恰恰是反常识的。
• 无安全护栏：生成的 SQL 直接执行，无语法校验、无成本控制、无越权检查。
• 结果不可信：黑盒生成，用户不知道 SQL 为什么这样写、依据是什么。

阶段二 · Schema-Aware RAG（2023-2024）

先用向量检索找到与问题相关的表/列/示例（few-shot），再把这些约束喂给 LLM。这是 2023-2024 年大多数"NL2SQL 产品"的形态，代表有 DIN-SQL、DAIL-SQL 等学术工作。

进步：缩小了 LLM 的想象空间——从"全 schema 自由发挥"到"在相关子集内生成"。

遗留问题：

• 术语消歧仍靠 LLM 自觉，没有强制约束
• join 路径选择没有确定性保证，多事实表场景易出 chasm trap
• 执行安全仍是空白
• 检索质量本身未评估——检索召回不全时，LLM 在残缺上下文下生成，错误更隐蔽

阶段三 · Agentic BI（2024-）

把 NL2SQL 嵌入一个多步 Agent 工作流——意图解析、检索、图规划、生成、校验、自愈、可视化、洞察——每一步都可治理、可解释、可回退。这正是 TTD 所处的位置。

关键突破：

• 语义治理从"文档说明"变为"机器可读的强制约束"
• join 路径从"LLM 自由发挥"变为"确定性图算法规划"
• SQL 安全从"无"变为"五层纵深校验"
• 错误处理从"一次失败即终止"变为"自愈循环重试"
• 过程从"黑盒"变为"全链路 SSE 流式透明 + 审计追踪"

AI Agent 理论关联：为什么 Agentic 而非单次生成

单次 LLM 调用是"感知→行动"的退化形态。Agentic 范式的核心是把复杂任务拆解为可控的多步循环，每步可观测、可纠错。

学术脉络上，这与三个里程碑一脉相承：

• ReAct（Reasoning + Acting，2022）：提出 LLM 交替进行"推理（Thought）"与"行动（Action）"的循环，让模型能调用工具并根据观察结果调整推理。这是 Agent 的基本范式（arxiv.org/abs/2210.03629）。
• Plan-and-Execute（2023）：先让 LLM 制定完整计划再逐步执行，适合需要全局规划的任务，避免 ReAct 的"走一步看一步"导致的短视（arxiv.org/abs/2305.04091）。
• Reflexion（2023）：在行动后引入"自我反思"，基于反馈修正后续行为，让 Agent 能从失败中学习（arxiv.org/abs/2303.11366）。

TTD 选择了"确定性 DAG + 条件路由"而非纯 ReAct 自主循环——这是工程上的取舍：NL2SQL 场景对安全性与可审计性的要求高于灵活性，一条错误的 SQL 可能扫垮生产库。第 4 章会深入讨论这个取舍的利弊。

1.1.3 为什么需要"语义治理"

许多 NL2SQL 系统失败，不是因为 SQL 写不对，而是因为同一个业务问题在不同上下文有不同答案，而系统不知道该用哪个。

"GMV 同比增长多少？"——要可靠回答，系统至少需要知道：

1. GMV 的精确定义：是 SUM(amount) 还是 SUM(amount - refund)？在哪张表？（Layer 1 指标资产）
2. "同比"的时间口径：本月 vs 去年同月，还是本周 vs 去年同期？（Layer 3 业务规则）
3. "华东区"的映射：华东区包含哪些省份？在哪个字段判断？（Layer 2 术语绑定）
4. 应该走哪条 join 路径：fact_transaction 直接查，还是要关联 dim_region？（join 规则 + 图规划）

这些知识无法靠 LLM 的世界知识补全——它们是你的企业特有的。语义治理就是把这些知识结构化为机器可读、可校验、可版本控制的资产，在生成 SQL 之前就约束住 LLM。

这也是为什么 TTD 把语义治理称为"一等公民"——它不是事后补充的文档，而是内嵌于查询管道的核心约束（第 9 章）。

---

1.2 TTD 是什么

TTD（The Talk-to-Data Project）是一个企业级 NL2SQL + Agentic BI 平台，核心使命是把用户的自然语言问题转化为可治理、可解释、安全执行的 SQL 查询与分析洞察。

它不是一个"会出 SQL 的聊天机器人"，而是一个把以下能力组织成工程系统的平台：

TTD 不是什么

为避免读者对 TTD 能力边界产生误解，以下明确列出 TTD 不是什么：

• 不是通用聊天机器人——TTD 不擅长闲聊、知识问答以外的开放式对话。它的核心是"自然语言 → 可信 SQL → 执行 → 洞察"，超出数据分析域的问题会走 clarification_required 路由（第 4 章）。
• 不是 BI 可视化工具——TTD 不替代 Tableau/Metabase/Superset。它的可视化是查询结果的轻量呈现（ECharts 折线/柱/饼等），而非拖拽式仪表盘构建平台。
• 不是数据管道 / ETL 工具——TTD 不做数据集成、清洗、调度。它消费已治理好的语义层与业务数据，产出是查询结果与洞察，不是数据资产本身。
• 不是多租户 SaaS 平台——当前治理叠加层只是上下文注入，数据库层无 row-level security 强制（见 1.3.3 改进项 #4）。多租户隔离是演进方向，非现状。

C4Container
title TTD 系统全景 — Container Diagram

    Person(analyst, "业务分析师", "企业业务部门", "使用自然语言查询数据库，获取数据分析洞察")

    System_Ext(dashscope, "DashScope API", "阿里云·百炼平台", "提供 LLM 推理与 Embedding 的外部模型服务，TTD 唯一的模型依赖")

    System_Boundary(ttd_platform, "TTD 平台") {
        Container(web_frontend, "Web 前端", "Next.js 16 · React 19 · shadcn/ui", "用户交互层：SSE 流式展示 Agent 思考过程，Better Auth 托管于此签发 RS256 JWT")
        Container(agent_runtime, "Agent 运行时", "FastAPI 0.115 · LangGraph · Python 3.12", "编排层+智能层：20+ 节点 Agent 管线，含意图解析、R/V/G/D 检索、语义规划、SQL 生成、五层护栏")
        Container(pg_supernode, "PG Supernode", "PostgreSQL 18 · pgvector · Apache AGE", "数据层语义存储：承载 R/V/G 引擎，存储语义资产、会话检查点、长期记忆、SQL 缓存")
        Container(data_plane, "Data Plane", "Redshift Serverless / pg_mooncake", "数据层业务执行：执行 SQL 查询，生产走 Redshift，开发走 pg_mooncake 列存")
    }

    Container_Boundary(governance_pipeline, "离线发布管道") {
        Container(yaml_assets, "YAML 资产", "semantic-plane/ · Git 仓库", "治理层：语义资产以 YAML 编写，经 pre-commit hooks + CI 校验 + PR Review 后发布到 S3")
    }

    System_Ext(s3_storage, "S3 对象存储", "AWS S3 / MinIO", "接收语义资产快照，作为治理态到执行态的中间介质")

    Rel(analyst, web_frontend, "输入自然语言问题，查看流式结果", "HTTPS · SSE")
    Rel(web_frontend, agent_runtime, "发起 Chat BI 查询，携带 JWT", "HTTPS · SSE")
    Rel(agent_runtime, pg_supernode, "RAG 检索·会话持久化·检查点·锁", "asyncpg · psycopg 3")
    Rel(agent_runtime, data_plane, "执行 SQL 查询，返回结果行", "redshift-connector / psycopg")
    Rel(agent_runtime, dashscope, "调用 LLM 推理与 Embedding", "HTTPS · DashScope SDK")
    Rel(yaml_assets, s3_storage, "发布语义资产快照到 S3", "HTTPS · S3 API")
    Rel(s3_storage, pg_supernode, "Backend 检测变更·自动同步索引", "R+V+G Pipeline")

    UpdateElementStyle(analyst, $fontColor="#202124", $bgColor="#f8f9fa", $borderColor="#5f6368")
    UpdateElementStyle(dashscope, $fontColor="#5f6368", $bgColor="#f8f9fa", $borderColor="#dadce0")
    UpdateElementStyle(web_frontend, $fontColor="#202124", $bgColor="#e8f0fe", $borderColor="#1a73e8")
    UpdateElementStyle(agent_runtime, $fontColor="#202124", $bgColor="#e8f0fe", $borderColor="#1a73e8")
    UpdateElementStyle(pg_supernode, $fontColor="#202124", $bgColor="#e0f2f1", $borderColor="#0d7377")
    UpdateElementStyle(data_plane, $fontColor="#202124", $bgColor="#e0f2f1", $borderColor="#0d7377")
    UpdateElementStyle(s3_storage, $fontColor="#5f6368", $bgColor="#f8f9fa", $borderColor="#dadce0")
    UpdateElementStyle(yaml_assets, $fontColor="#202124", $bgColor="#f3e8fd", $borderColor="#9334e6")

    UpdateRelStyle(analyst, web_frontend, $textColor="#1a73e8", $lineColor="#1a73e8")
    UpdateRelStyle(agent_runtime, pg_supernode, $textColor="#0d7377", $lineColor="#0d7377")
    UpdateRelStyle(agent_runtime, data_plane, $textColor="#0d7377", $lineColor="#0d7377")
    UpdateRelStyle(agent_runtime, dashscope, $textColor="#5f6368", $lineColor="#dadce0")

    UpdateLayoutConfig($c4ShapeInRow="4", $c4BoundaryInRow="2")

1.2.1 六大技术支柱

支柱	解决的问题	详见
三层语义治理	术语消歧、业务规则约束、上下文显式化	第 9 章
R/V/G/D 四引擎检索	精确匹配 + 语义召回 + 关系推理 + 经验复用	第 5 章
LangGraph 编排	确定性 DAG + 条件路由 + 修复循环，20+ 专职节点	第 4 章
语义查询规划器	KMB Steiner 树做 join 路由 + 代数重写提供建议	第 6 章
四层记忆系统	短期 + Profile/Episodic/Correction 长期 + SQL 缓存 + 动态 few-shot	第 7 章
五层 SQL 护栏	语法 → 策略 → AST 列校验 → 术语绑定 → EXPLAIN 成本	第 6 章

1.2.2 一条查询的完整生命周期

以"上月华东区 GMV 同比增长多少？"为例，简化的执行链路：

1. Supervisor：计算问题 embedding，解析治理叠加层（tenant/region）
2. Query Understanding：LLM 解析出 intent=trend_analysis、entities=[GMV, 华东区]、temporal=上月 vs 去年同月
3. Router：映射到 nl2sql_query 路由
4. Data Retrieval：四引擎并行检索——Engine R 精确匹配"GMV"术语、Engine V 向量召回相关表/列、Engine D 找历史成功 few-shot
5. Reranker：术语"GMV"绑定到 metric_gmv，其源表 fact_transaction 提权
6. Semantic Planner：Steiner 树规划出 fact_transaction ⋈ dim_region 的最小 join 路径
7. SQL Generation：LLM 在约束下生成 SQL
8. Guardrails：五层校验通过（列引用合法、术语绑定正确、EXPLAIN 成本达标）
9. SQL Executor：在 Redshift/pg_mooncake 执行
10. Visualization + Insights：规则推荐折线图，LLM 生成"同比增长 12.3%"的洞察
11. SSE 流式返回：前端渐进式渲染

上表是 11 步的逻辑功能分解（每一步对应一个可独立讨论的职责）。第 2 章 的序列图则聚焦 9 个核心组件间的交互时序（合并了部分同属一处的逻辑步骤，如 Reranker 并入检索阶段、Visualization 与 Insights 合并）——两者描述的是同一链路，粒度不同，互为补充。

---

1.3 与主流方案对比

1.3.1 方案选型对比

维度	ChatGPT Data Analyst	Snowflake Cortex Analyst	通用 Text2SQL 基准（Spider/BIRD）	TTD
形态	通用助手 + 代码解释器	数据库内置 Copilot	离线评测基准	端到端 Agentic BI 平台
语义治理	无（靠用户上传说明）	弱（语义视图，手动维护）	无	三层治理 + Git 版本控制 + CI/CD
检索方式	无（全 schema 进 prompt）	Schema 检索	无	R/V/G/D 四引擎
Join 路径规划	LLM 自由发挥	LLM + 语义视图	LLM 自由发挥	Steiner 树 + 代数重写
SQL 安全	代码沙箱（但无 SQL 护栏）	数据库权限	无	五层护栏 + EXPLAIN
可解释性	黑盒	中（显示 SQL）	无	全链路 SSE + 审计 + Langfuse
自愈能力	无	无	无	corrective retrieval + 修复循环
记忆/个性化	无	无	无	四层记忆 + 动态 few-shot
部署形态	SaaS	SaaS（绑定 Snowflake）	N/A	可自部署（Docker Swarm）

1.3.2 各方案深度分析

ChatGPT Data Analyst：优势是通用性强、代码解释器能处理非 SQL 分析（如 Python 数据处理）；劣势是完全没有语义治理——它不知道你的"GMV"定义，每次都要用户解释；SQL 直接在沙箱执行，无成本控制，生产数仓上风险高。

Snowflake Cortex Analyst：优势是深度集成 Snowflake、有语义视图层；劣势是绑定 Snowflake 生态、语义视图维护成本高且无 Git 版本控制、无确定性 join 规划、无自愈能力。

Text2SQL 学术基准（Spider/BIRD）：这些是离线评测数据集，关注"给定 schema 生成正确 SQL"的准确率，不涉及治理、安全、执行、可观测性。TTD 若要量化自身效果，可引入这些基准做回归测试（详见 第 15 章、第 16 章）。

1.3.3 TTD 的差异化与边界

TTD 真正的差异化在于：它把"语义治理"和"确定性规划"作为一等公民，而非把全部智能交给 LLM。这换来的是可治理、可解释、安全——代价是前期需要投入语义资产的编写与维护。

当前实现可改进之处

需要客观指出的是，TTD 在以下方面仍有演进空间：

1. 语义资产编写成本高——三层治理的 YAML 资产需要人工编写，没有自动发现/推荐机制。生产中数百张表时，冷启动成本较高。改进方向：基于 schema 自动生成候选资产 + LLM 辅助补全业务描述，人工只做校验。
2. 只在单一数据集（H&M）上验证——缺乏跨行业、跨 schema 规模的回归基准，泛化能力未经验证。TTD 当前使用 Kaggle H&M Personalized Fashion Recommendations 数据集（零售/时尚领域，3 表星型拓扑，详见 附录 E）作为端到端验证基线；它能验证链路完整性，但无法证明大规模 schema 下的泛化能力。改进方向：引入 Spider/BIRD 等公开基准做离线评测。
3. 依赖单一 LLM 供应商（DashScope）——虽然 ModelRegistry 支持多 provider，但内置配置和 embedding 都绑死 DashScope，迁移成本高。改进方向：抽象 provider 层，支持 OpenAI/Anthropic/本地模型无缝切换。
4. 无真正的多租户隔离——治理叠加层只是上下文注入，数据库层无 row-level security 强制。改进方向：PG RLS 或 schema 级隔离。

改进方向

上述每项都在 第 16 章 演进路线 中给出了具体的改进方案与优先级。它们不是缺陷，而是工程演进的明确方向。

---

1.4 预期结果与阅读指南

1.4.1 预期结果

TTD 是一个学习与工程实践结合的项目，本书以设计目标而非实测数字来呈现性能与质量预期。

性能与质量指标（设计目标）

本书各章出现的延迟、准确率、触发率等数字，均为设计目标值，TTD 尚未进行系统化实测。我们选择诚实标注而非编造数字——这与项目"工程诚实性"的价值观一致（见 1.5 项目定位）。

• 查询链路延迟：主路径（nl2sql_query）目标 < 3s 端到端；各节点延迟分解见 第 4 章。
• 检索质量：Engine V 召回 precision/recall 目标阈值见 第 5 章；守卫触发率目标见 第 6 章。
• 评估体系：第 15 章 定义了 LLM-as-a-Judge 四维评估与 Ragas 指标，但评估基础设施尚未产出系统化评估报告。

评估方法论与改进路线分别见 第 15 章 与 第 16 章。

1.4.2 阅读指南

不同角色的读者可按需选择阅读路径：

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#e8f0fe','primaryTextColor':'#202124','primaryBorderColor':'#1a73e8','lineColor':'#5f6368','secondaryColor':'#e0f2f1','tertiaryColor':'#f8f9fa'}}}%%
flowchart LR
    CH01["第 1 章<br/>导论"] --> CH02["第 2 章<br/>整体架构"]
    CH02 --> CH03["第 3 章<br/>ADR 设计决策"]
    CH02 --> CH04["第 4 章<br/>Agent 编排"]
    CH02 --> CH05["第 5 章<br/>RAG 检索"]
    CH02 --> CH10["第 10 章<br/>Data Plane"]
    CH04 --> CH06["第 6 章<br/>SQL 生成"]
    CH05 --> CH06
    CH06 --> CH07["第 7 章<br/>记忆系统"]
    CH05 --> CH09["第 9 章<br/>Semantic Plane"]
    CH04 --> CH08["第 8 章<br/>工具调用"]
    CH09 --> CH13["第 13 章<br/>开发流程"]
    CH10 --> CH13
    CH02 --> CH11["第 11 章<br/>Backend"]
    CH11 --> CH12["第 12 章<br/>Web 前端"]
    CH03 --> CH14["第 14 章<br/>安全运维"]
    CH06 --> CH15["第 15 章<br/>质量评估"]
    CH15 --> CH16["第 16 章<br/>路线图"]

    classDef bpProcess  fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,color:#202124
    classDef bpInfo     fill:#f3e8fd,stroke:#9334e6,stroke-width:2px,color:#202124

    class CH01,CH02,CH04,CH05,CH06,CH07,CH08,CH09,CH10,CH11,CH12,CH13,CH14,CH15 bpProcess
    class CH03,CH16 bpInfo

你的角色	推荐阅读路径	重点章节
AI Agent 学习者	先建立编排全景，再看内核细节	第 1 → 4 → 5 → 6 → 7 章，重点理解 第 4 章 编排范式与 第 5 章 四引擎 RAG
NL2SQL 实践者	聚焦 SQL 生成与治理	第 1 → 6 → 9 → 5 章，重点理解 第 6 章 语义规划与护栏、第 9 章 治理资产
数据治理 / 语义层	聚焦治理体系	第 1 → 2 → 3 → 9 → 10 章，重点理解 第 9 章 发布管道与 第 3 章 ADR
运维 / 平台	聚焦部署与安全	第 2 → 10 → 11 → 14 章，重点理解 第 14 章 安全与 第 10 章 数据面
研究者 / 评估	聚焦评估与演进	第 1 → 4 → 15 → 16 章，重点理解 第 15 章 评估体系与 第 16 章 路线图
想贡献改进的人	从路线图入手	直接看 第 16 章，按优先级选择改进项

---

1.5 项目定位

TTD 是一个学习与工程实践结合的项目。这意味着：

• 设计有明确取舍：每个架构决策都有其适用场景与代价。例如四引擎 RAG 在小规模数据上显得 over-engineered，但在理解 RAG 范式演进、为生产规模做准备上有长远价值。本文档会讲清每个取舍的"为什么"。
• 文档诚实面对改进空间：本文档不会把每个设计都说成最优实践。每章的"方案选型对比"小节会客观指出当前实现可改进之处——这是工程实践的一部分，也是学习的价值所在。
• 面向演进设计：第 16 章 系统梳理了所有已知的改进方向，按优先级排序，是动手贡献的入口。

1.5.1 适合谁

你是	这本文档对你的价值
AI Agent 学习者	看到一个完整的、非玩具的 Agent 系统如何拆解编排、检索、生成、记忆
NL2SQL 实践者	理解语义治理、图规划、护栏如何提升 SQL 可信度
RAG 进阶者	学习四引擎混合检索、重排、补偿检索的工程实现
LangGraph 学习者	看到确定性 DAG + 条件路由 + 修复循环的真实用法
想贡献改进的人	第 16 章 给了清晰的改进入口

---

1.6 小结与延伸阅读

本章要点：

1. NL2SQL 已从"Prompt-Only"演进到"Agentic BI"，难点不在生成 SQL 而在治理、规划、安全、可信。
2. TTD 用三层语义治理 + R/V/G/D 四引擎 + 确定性图规划 + 五层护栏，把 LLM 的"自由发挥"约束成"可治理的可信生成"。
3. TTD 是学习与工程实践结合的项目，文档会客观指出改进空间并给出演进方向。

延伸阅读：

• ReAct: Synergizing Reasoning and Acting in Language Models — arxiv.org/abs/2210.03629
• Spider: A Large-Scale Human-Labeled Dataset for Text-to-SQL — yale-lisp.github.io/text2sql
• BIRD: A Big Bench for Large-Scale Database Grounded Text-to-SQL — bird-bench.github.io

下一章：第 2 章 整体架构与设计哲学——从全局视角看 TTD 的五层逻辑模型、在线查询链路、离线发布管道与八项架构原则。

---

1.7 读者自检清单

读完本章后，尝试回答以下问题以检验理解程度。若某题无法回答，建议回看对应小节。

#	自检问题	对应小节
1	NL2SQL 经历了哪三个阶段？每个阶段的痛点和突破分别是什么？	1.1.1
2	"非翻译难题"的五类问题是什么？为什么单纯提升 LLM 能力无法解决它们？	1.1.2
3	TTD 的两个平面分别是什么？它们为什么必须分离？	1.2.1
4	一条查询从用户输入到结果返回经过哪些步骤？（至少说出 8 步）	1.2.2
5	TTD 与 ChatGPT Data Analyst / Snowflake Cortex Analyst 的核心差异在哪三个维度？	1.3.1
6	TTD 不是什么？请列出至少 3 条边界。	"TTD 不是什么"警示框
7	TTD 当前的 4 项主要局限是什么？为什么它们是工程演进方向而非缺陷？	1.3.3
8	本书呈现的性能/质量数字是什么性质？为什么不提供实测数据？	1.4.1

如何使用本清单

自检不是考试——无法回答某题很正常，它只是帮你定位需要重读的章节。建议在读完后续章节后回头检验，看理解是否加深。