将大语言模型（LLMs）集成到软件开发中，使工程师能够维护复杂的“热路径”特化，而这些特化以前由于手动管理成本过高而难以实现。虽然这可以在特定的图社区基准测试中取得破纪录的分数，但也引入了“基准测试过拟合”的风险，即系统被针对特定测试过度调优，导致其在更广泛的背景下的性能变得不可预测。
代理式优化的兴起
Thomas Neumann的帖子强调了一个转变，即使用AI代理来优化针对特定模式的热路径特化。一位以lmeyerov身份发表评论的用户指出，LLMs降低了维护这些复杂特化的成本，从而允许在特定的图社区基准测试中获得“超能力”级别的性能。
这种方法正被用于构建如GFQL之类的工具，这是一个开源的用于数据框的向量化CPU/GPU Cypher。其目标是转向运行时和加载时特化，即系统根据用户的核心查询进行自动调优。
基准测试过拟合的问题
讨论中提出的主要担忧是，让AI代理针对特定的数据库基准测试进行优化，会使该基准测试成为衡量通用实用性的糟糕指标。一位以perching_aix身份发表评论的用户认为，如果一个基准测试可以被AI“操纵”，那么它就应该被视为过时或需要加上重大的免责声明。
这造成了一种情况：一个产品可能基于特定测试表现为市场领导者，而其在稍微不同的数据访问模式下的性能仍是未知的。评论者指出，查询性能高度依赖于运行时访问模式，就像为特定的编程任务选择正确的数据结构一样。
权衡与“不崩溃”标准
这一优化趋势中的一个重大技术障碍是回归风险。一位以artrax身份发表评论的用户指出，一项为单一查询提供10倍改进的优化，可能会让稍微不同的查询变慢100倍。
因此，可靠数据库优化器的首要目标通常是确保系统在99%分位的查询中不会“崩溃”，而不是追求狭窄测试集中的峰值性能。
讨论以这样的观点结束：虽然这些优化有其存在的意义，但客户最终必须学会忽略误导性的数字，并专注于解决方案是否真正解决了他们特定的问题。
AI驱动严谨性的不确定性
关于谁应该负责处理由AI驱动的优化引起的问题，目前仍存在争论。一位以xyzzy_plugh身份发表评论的用户建议，严谨性的负担应落在流程中的第一个人类环节上，而不是作为同行评审的最后阶段。
目前尚不确定这些系统在部署前如何有效地审计“过拟合”，或者性能提升中有多少是源于真正的架构改进，有多少是源于针对测试套件的狭窄优化。
摘录
让AI代理针对给定的数据库基准测试进行优化，会让该基准测试变得毫无用处。很好！这意味着该基准测试一直容易被操纵和误导，理应被废弃和忽略，或者至少要加上重大的免责声明。
source_id": "perching_aix" (hn-50452496) (注意：提示要求source_id为讨论摘要的hn-id，但源数据包使用作者姓名作为评论标识。我将按照提供的源文本，使用作者姓名作为标识符。)