做 RAG 时，第一个容易陷进去的参数是 chunk_size。500 字还是 1000 字、overlap 取 50 还是 100，大家常凭几个问答效果争论。这个讨论缺少一个前提：我们希望每个 chunk 保住什么证据。

我不会先从字数出发，而是整理真实问题，为每个问题标注“最小充分证据”。切块策略能让这些证据稳定被召回，条件和结论没有被拆散，同时不带进大段无关内容，才算有效。

把大模型接进数据平台时，我不建议第一版就让它“自动完成数据操作”。企业数据查询本身已经包含权限、成本和口径风险；再开放 INSERT、DDL 或任务发布，错误会从一条答案扩散到真实系统状态。

第一版更合适的目标是只读数据助手：根据用户权限理解问题，生成候选查询，在受控环境执行，并把 SQL、结果依据和限制交给人复核。这里的“只读”不是 Prompt 里写一句“禁止修改”，而是从身份、解析、数据库权限到运行资源的多层约束。

把文档切块、算 embedding、写进向量索引，再接一个生成模型，几天就能搭出知识问答 Demo。这个 Demo 会让人产生一个错觉：只要相似度搜得准，企业知识库就建成了。实际运行一段时间后，问题往往不在向量库，而在知识从哪里来、何时失效、谁能看、答案引用了什么。

我把向量检索当成候选召回器。它回答的是“哪些片段在表示空间里接近这个问题”，不负责证明片段仍然有效，也不负责解决权限、冲突和业务口径。知识库是包含摄取、治理、检索、生成和反馈的一整条链路。

NL2SQL 演示很容易做出效果：准备几张表，把 schema 放进上下文，模型很快能生成一条能跑的 SQL。真正接到企业数据平台后，问题不再是“有没有 SQL”，而是这条 SQL 为什么可信。字段名写对、语法能执行，只通过了最浅的一层检查。

我把 NL2SQL 的交付物定义为“可验证查询”，不是一段字符串。除了 SQL，还要带上所用口径、对象版本、权限范围、执行计划风险和结果断言。模型负责提出候选，平台负责决定它是否有资格执行和回答。