Token Optimization Strategies for LLM-Based Oracle-to-PostgreSQL Migration
本文将基于大语言模型的 Oracle 到 PostgreSQL 迁移中的令牌优化形式化为多目标约束变换问题，通过评估十二种策略证明：虽然激进压缩会大幅降低语义保真度，但自适应路由与轻度上下文剪枝能在令牌效率与代码质量之间提供最优权衡。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正试图将一座庞大而古老的图书馆从一栋建筑搬迁到另一栋建筑。旧建筑（Oracle）中的书籍是用一种非常具体且复杂的方言写成的，而新建筑（PostgreSQL）则使用一种略有不同的语言。你聘请了一位才华横溢的翻译（人工智能或大型语言模型），要求它重写每一本书，使其在新建筑中也能通顺可读。
然而，这里有一个陷阱：翻译是按其阅读和撰写的字数（或“词元”）来收费的。如果你交给它一座字数过多的图书馆，账单将变得天文数字般高昂，翻译者可能会不堪重负，在堆积如山的书堆中忘记故事的重要部分。
本文探讨的是在将书籍交给翻译之前，如何以最聪明的方式剔除冗余，同时又不意外删掉故事情节。
问题：过多的噪音
作者发现，当你直接把原始的 Oracle 代码扔给 AI 时，就像给翻译提供了一本充斥着以下内容的书籍：
- 注释：原作者写给自己看的笔记（例如，“稍后修复此问题”）。
- 物理细节：关于书籍如何在书架上物理存放的说明（例如，“请存放在干燥房间”），这些在新建筑中并不重要。
- 多余空白：单词之间巨大的间隙。
这些东西占用了空间（词元），但无助于翻译理解故事（即业务逻辑）。
实验：12 种缩减书籍的方法
研究人员测试了12 种不同的策略来缩减 AI 的输入量。可以将这些策略想象为编辑手稿的不同方式：
- “彻底清理”（上下文剪枝）：他们直接删除了作者的笔记和书架存放说明。
- 结果：这是最稳妥的选择。它节省了一点费用，并且实际上让翻译效果更好，因为 AI 不再被垃圾信息分散注意力。
- “挤压”（代码压缩/Minification）：他们移除了所有额外的空格和换行符，将文本像压缩文件一样挤在一起。
- 结果：节省了一些字数，但对故事内容的提升不大。
- “秘密代码”（DSL/标识符掩码）：他们将冗长且描述性的名称（如
CustomerOrderProcessingTable）替换为简短的代码（如X_1）。- 结果：这节省了大量字数，但让翻译者感到困惑。由于缺乏真实名称，AI 无法推断表的用途，导致翻译质量低下。
- “仅保留梗概”（模式蒸馏）：他们几乎丢弃了所有内容，只保留了结构的基本骨架。
- 结果：这节省了巨额费用（词元），但故事变得面目全非。AI 生成的句子看起来有效，但在逻辑上毫无意义。
- “智能编辑”（自适应路由）：这是获胜者。系统不是对每本书使用同一条规则，而是先查看每本书。如果书籍简单，就采用轻处理；如果书籍复杂，则采用不同的策略。
- 结果：它节省了大量费用（字数减少了约 8-9%），同时保持了 99% 的故事准确性。
重要教训（“权衡”）
这篇论文教会了我们关于 AI 迁移的一个关键教训：你不能仅仅为了省钱而随意删减字数。
- “中间迷失”效应：如果你让提示词（Prompt）过长，AI 就会忘记埋藏在中间的重要指令。
- “虚假经济”陷阱：那些删减字数最多的策略（如“蒸馏”或“掩码”）往往会破坏含义。这就像翻译小说时只保留每个单词的首字母；虽然简短，但完全是胡言乱语。
- 语法与含义：有时 AI 能写出语法完美（有效语法）但含义完全错误（语义漂移）的句子。你必须同时检查这两者。
解决方案：“智能路由器”
论文得出结论，最佳方法并非单一的“魔法橡皮擦”，而是一个智能路由器。
想象一下机场的交通管制员：
- 如果飞机小而简单，他们会将其送往快速、轻量的安检通道。
- 如果飞机巨大且复杂，他们会将其送往更彻底、更专业的通道。
同样，最佳策略是先分析代码。如果代码简单，就剔除冗余；如果代码复杂，就要温和处理，保留重要细节。这种“自适应路由”方法在节省费用的同时，没有丢失代码的含义。
总结
利用 AI 迁移数据库，就像雇佣付费翻译来搬迁图书馆。
- 不要把一切都扔给翻译；这既昂贵又令人困惑。
- 不要为了省几分钱就删掉重要的名称和细节；那样你会失去故事。
- 要使用一个智能系统，根据特定代码片段的复杂程度来决定剔除多少冗余。这样既能省钱，又能保持翻译的准确性。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。