大型语言模型与数据库交互时易产生“静默幻觉”，即生成语法正确但语义错误的查询，导致数据不准确。这源于SQL方言差异、混乱的模式和模糊的沟通。文章探讨了MCP、AGENTS.md和Agent Skills等多种提供上下文的解决方案，以提高LLM的准确性。
译自：How your LLM is silently hallucinating company revenue
作者：Alasdair Brown
大型语言模型正在加速跨工程学科的工作，从生成React组件、构建后端API到处理SQL。但我们都知道大型语言模型会犯错，而且这些错误的性质在不同领域差异巨大。将大型语言模型与数据库一起使用具有欺骗性的容易出错。
当大型语言模型生成React组件时，错误往往会很快浮现。代码要么编译失败，要么呈现出明显错误的东西：一个按钮位置不对，一个无法关闭的模态框，或者一个在移动设备上会崩溃的布局。你看着屏幕，就会发现有些地方明显不对劲。
但数据库并非如此。当大型语言模型生成SQL查询时，它要么执行失败，要么成功运行。问题就在这里：一个成功运行的查询仍然可能完全错误。如果你正在通过某个条件过滤行，如何验证返回的4,000行中的每一行都确实匹配？如果你正在计算聚合，当你无法看到哪些行对最终数字有贡献时，如何验证这个数字？这些都是不透明的答案，人类很难快速或轻松地验证。
“一个成功运行的查询仍然可能完全错误。……这些都是不透明的答案，人类很难快速或轻松地验证。”
这会产生一种危险的故障模式。大型语言模型在生成语法正确的查询方面表现出色。但在生成语义正确的查询方面，它们的可靠性要差得多。
语义正确性问题的严重性
对50,000多个生产查询的分析表明，大多数“损坏的”查询实际上都能成功执行并返回数据。用户要求“按产品类别划分的收入”，并使用产品表中的“revenue”列，尽管它实际上存在于order_items表中。查询运行。数字出现。首席财务官根据那些悄无声息地、完全错误的指标做出决策。
通常，大型语言模型会采取第一个看似正确的路径，而未能探索替代方案，完全错过了实际正确的路径。在研究大型语言模型是否可以对可观测性数据执行根本原因分析时，也看到了类似的结果，研究发现大型语言模型会经常陷入隧道视野，最终在错误的地方给出错误的答案。
这些不正确的假设通常源于语义上下文的缺失，这尤其影响与数据库相关的工作。
为什么大型语言模型需要数据库上下文
三个特点使得数据库工作特别容易受到大型语言模型“静默”故障的影响。
首先，SQL方言的差异是大型语言模型无法预料的。关于SQL有大量的知识，你可能会认为这能为大型语言模型提供所需的所有训练数据。但即使在人类中，SQL也常被误解为一种统一、完全标准化的语言（鉴于大型语言模型是根据人类输出进行训练的，它们的困惑我们只能怪自己）。虽然SQL的基础知识通常可以在不同数据库之间移植，但大多数数据库会根据SQL创建自己的方言。这些差异可能很微妙，即相似的意图通过略微不同的语法实现；也可能非常显著，使得许多“普遍经验”变得无用。
其次，现实世界是混乱的，我们的数据库模式（schemas）也是如此。像“amount”这样的列名可能意味着总收入、净收入或数量。名为“users”和“customers”的表可能重叠，也可能完全不同。可能还有一堆废弃的模式、表和列，因为某些遗留用例而被保留。大型语言模型会尽力将它们所看到的内容与训练数据进行模式匹配，但最终会做出经常出错的自信猜测：凭空捏造不存在的列，或者使用错误的键连接表。
最后，人类倾向于模糊不清地沟通，这导致误解。其中一部分源于我们的懒惰，希望机器人能替我们解决问题；另一部分源于我们假设听者拥有与我们相同的背景和理解。例如，在一些国家，财政年度与日历年一致，但并非所有国家都如此。那么，2026财年第一季度是何时？如果你是欧洲的一家银行，十亿是百万百万（万亿），但对于美国的一家银行来说，它是一千百万（十亿）。大型语言模型可能知道这些差异的存在，但它们怎么知道哪一个适用于你？
它们需要上下文！
提供上下文的方法有很多
许多这些故障都源于一种常见设置：开箱即用最前沿的大型语言模型，但对你的特定环境几乎没有上下文。模型抽象地了解SQL，但对你的模式、方言的怪异之处或业务逻辑一无所知。
“模型抽象地了解SQL，但对你的模式、方言的怪异之处或业务逻辑一无所知。”
过去一年，为现成的大型语言模型提供个性化上下文的方法取得了快速发展。2024年底，Anthropic发布了模型上下文协议（MCP），实现了大型语言模型与数据库等外部工具之间的标准化连接。2025年中，OpenAI引入了AGENTS.md约定：一个提供领域特定上下文的Markdown文件，随你的代码库一起传输。2025年末，Anthropic接着推出了代理技能（Agent Skills），它提供了模块化、按需调用的功能，代理可以在需要时调用。
每种方法都提供了不同的功能和解决上下文问题的方式。
MCP服务器提供结构化的工具访问，使你的大型语言模型能够直接与数据库交互。MCP让你暴露特定功能，例如查询执行、模式自省和表元数据，而不是仅仅让大型语言模型生成一些SQL并给你文本。有大量MCP服务器涵盖了你几乎能想象到的任何数据库，例如ClickHouse、Postgres和MongoDB。通过MCP，大型语言模型可以在系统内部搜索上下文。
AGENTS.md将上下文嵌入到一个Markdown文件中，你可以将其与代码一起存储在你的仓库中。你只需在一个文件中记录你的模式约定、业务逻辑和任何其他值得注意的信息。它开销很小，只是一个文本文件，并且非常高效。然而，上下文膨胀是大型语言模型的一个众所周知的问题，而AGENTS.md的缺点是文件总是完全加载。一个大文件可能会占用大量上下文。
代理技能（Agent Skills）类似于AGENTS.md，但它是模块化的，允许上下文的渐进式加载。知识不是单个文件，而是分解成名为“技能”（Skills）的单独文件。代理可以列出可用的文件，构建其技能的轻量级索引，并在与当前任务相关时选择读取某个技能。
技能的优点是未使用的知识不会占用大型语言模型有限的上下文窗口。但这假设大型语言模型能够正确且一致地知道何时调用某个技能并选择正确的技能。Vercel维护着一个代理技能市场，其中包括针对ClickHouse和PostgreSQL等数据库的特定于数据库的技能。
我们也不需要仅仅依赖这些“大型语言模型原生”的答案。像ClickHouse、PostgreSQL和MySQL这样的数据库在大型语言模型出现之前就支持通过表和列上的COMMENT语法存储上下文。这些元数据随模式一起传输，这意味着无论大型语言模型是在Git仓库中看到它，还是通过MCP描述实体，它都可以帮助大型语言模型。这是一种优雅的、你可能已经拥有的添加上下文的方式。
那么，如何选择？
Vercel最近评估了 AGENTS.md与其自身框架文档的代理技能，结果相当有趣。AGENTS.md达到了100%的通过率，而技能最高只有79%。在56%的测试案例中，代理从未调用过可用的技能。文档存在；代理可以访问它，但它从未这样做。
大型语言模型很可能会在它们的工具调用能力上有所改进，这将使代理技能更加一致。但模型也很可能会继续推出越来越大的上下文窗口。目前尚不清楚AGENTS.md或代理技能是否会胜出并成为事实上的解决方案，或者我们是否会选择最适合我们情况的那个。即便如此，将语义上下文保留在数据库对象本身中仍然是一个引人注目的理由。
