企业的收入定义、财年规则和组织映射，往往藏在内部文档里。EntSQL把这种长上下文业务知识作为显式任务输入，帮助区分"没有规则"和"有规则却用不好"两种失败。
论文信息 ：Chengxi Liao、Tao Xu等，EntSQL: A Benchmark for Grounding Text-to-SQL in Long-Context Enterprise Knowledge ，2026预印本。本篇依据2026年7月v3，阅读§2---3的构建、设置、消融与专家分析。书目版本、全文、作者数据页。
1、论文试图解决什么问题？
论文评价模型能否利用长篇企业知识，把业务问题转成正确SQL。规则涉及内部指标、报告约定、财年、组织和产品映射，不能仅由表字段或公共知识恢复。
自拟例子是同比收入比较：财年从四月开始，某部门代码又发生调整。若只按自然年和当前部门表查询，SQL合法且返回数字，却没有实现实际经营问题。
2、这是否是一个新问题？
外部知识不是首次进入Text-to-SQL：BIRD包含短证据，Spider 2.0包含文档和工作流。EntSQL强调长篇私有企业知识与中英对齐样例。
因此新意在任务条件和标注对象，而不是首次提出"给模型文档"。长文本里寻找相关规则，与使用已经选好的短证据，是不同难度的能力。
3、文章要验证什么科学假设？
可重构为：企业知识是必要输入，但提供完整文档并不保证模型能正确选择和应用；精确证据条件能进一步揭示知识定位的作用。
三种输入条件为无文档、完整文档和专家短证据。最后一种接近给定相关知识的诊断条件，不能把它的成绩直接当成自动检索系统在真实场景的结果。
4、有哪些相关研究？如何归类？关注哪些研究员？
相关研究可分为schema泛化、值与外部知识、企业工作流和文档增强查询。本文与前三条线互补。
可沿Chengxi Liao、Tao Xu、Zulong Chen、Zeyi Wen等署名继续阅读；先读BIRD原文能够理解短证据前史。不同基准覆盖相交，不宜划成完全互斥的代际。
5、解决方案的关键是什么？
构建流程包含真实业务问题收集、专家标注参考SQL与证据、基于业务材料形成领域文档、匿名化和多阶段质检。任务输入是问题、schema和可选长文档。
核心不只是增加上下文长度，而是让规则是否存在、位于哪里、能否应用变成可分析变量。我们也应为自己的业务约束记录来源和适用条件，不能事后按输出修改规则。
6、论文中的实验或综述方法如何设计？
基准覆盖1,066个中英对齐语义样例、五个领域。v3主要在英文全量上比较七个独立模型和一个交互编码Agent，采用pass@1执行准确率。
论文还做知识输入消融、复杂度和领域分析，并在212个样例上提供专家参考。Agent没有与独立模型完全对齐交互预算，因此优劣不能只归因于某一个规划机制。
中英对齐不意味着两种语言的评价已完全覆盖。论文主实验以英文输入为主，若我们要用于中文经营场景，还应独立检查术语翻译、财年表述和组织名称映射。增加中文任务后，也要保证业务规则相同，才能区分语言差异与任务内容差异。
7、定量评估使用什么数据？代码是否公开？
五个领域包含财务、资金、经营管理、组织事务与人力资源，样例配有数据库与知识文档。执行用SQLite，对最终结果规范化比较。
作者数据页可访问，但论文同时说明敏感标注或专有材料可能保留私有。公开入口不等于全量训练、测试、参考答案与评测服务均可直接使用，本篇未下载并执行完整评测。
8、证据是否支持论文主张？
表2中最佳Agent从无文档6.8%提高到完整文档15.9%，给定专家证据为21.4%。这些是该版作者报告的英文任务结果，支持知识有帮助，也显示知识定位后仍有推理和生成困难。
专家子集也随证据条件变化，不能当作全量不可超越上界。参考SQL长短只是难度代理；执行一致也不构成对全部业务解释正确的充分证明。
9、这篇论文到底有什么贡献？
贡献是让企业私有业务知识的长上下文落地成为可评价问题，并用三种知识条件区分瓶颈。它为"业务规则应显式进入查询"提供直接任务基础。
这意味着我们的创新不能停留在给Agent一份指标字典。必须进一步说明规则如何被多个分析步骤共同遵守，以及报告如何保留规则限定的含义。
10、下一步有什么工作可以深入？
值得推进的是把选出的业务规则形成结构化约束，附到查询与派生计算，再检查跨步骤兼容；这是待验证方向，不是本文已经给出的机制。
公平对照应向直接Agent和带检查Agent提供同样的业务知识，并另设"理想相关证据"条件。这样才能区分收益来自更好的信息、更多预算，还是跨步骤约束本身。
本文为论文阅读与研究讨论，AI辅助整理；论文结果均指作者报告，本文未运行复现实验。