关于LLM代码风格和标记成本的发现
花费输出标记来分享这一点。在价格飙升之前。Jim从哪里开始的?过去一年,我一直在与Claude一起创建和审查功能。看到标记消耗和遗留模式之间的紧张局势真是令人惊讶。每当我觉得某件事情完成时,问题就会浮现——回归、边缘案例等等。与此同时,观察逐渐稳定、自然朝着最终全价率的迈进。在这一现象的同时,我还在努力保持在现代Web工作的务实边缘。几乎无处不在的功能消除了代码行,提升了质量的甜蜜点——我不断想:我为什么得到了那个输出?为什么那行代码出现,而不是多年来可用的东西?我通常会把它搁置,因为Claude在最佳情况下实际上是初级水平,是对面试中要求的百科全书知识的有用近似。在试图取得进展的时候,我发现自己在审视自己的实践,看看那些离谱的标记使用从何而来。每一个输出标记,都是那些在API定价中成本是输入标记几倍的(3倍到5倍!!!)。更长、更脆弱、更不安全的模式,解决了一些平台已经解决的问题——通常是几年前解决的。足以让我开始想象,有某种阴谋试图让整个Web平台倒退,正当Ryan Dahl、Alex Russell、Dimitri Glazkov(以及其他许多人)创造了Web组件等。他们确实让整个Web平台重新伟大。只是为了在标记上榨取一些回报。因此,就阴谋而言,这就是我发现的。因为我作为一个人类的背景,使用语言,设计排版,早期编程,以及绘画和许多其他古怪的事物,我实际上认为像制表符这样的东西是一种非凡的创新。我可以将缩进减少到1个字符,而不是去询问别人如何定义或获取使用权限的某种抽象。(我想我过于平等主义,无法欣赏整个软件社区的排外态度。)我关心人类,希望事情能在某种精简的基线上运作。而将东西乘以4或某个任意数字对我来说真的没有意义。我本可以继续,但也许这确立了方向——一个在实际媒体上使用实际语言的人,并对某些东西何时有效何时无效有自己的看法。这部分往往不言自明。我提到这一点,因为它影响了我从纯务实的角度所研究的内容。我并不是主张一个大家都使用制表符的具体立场(尽管这本身就不言自明)。我正在披露形成我所持观点的背景——我一直保留的一个经济论点,现在在实际API成本中显现出来。关于约定的观点不是本文的重点。而标记使用优化才是我来这里分享的内容。这样你也可以受益。如果你想继续使用多个空格,我会提醒自己文献中说这似乎还可以,而LLM不懂得更多。全球最简单的标记优化已经在运行时中实现了。Deno和Cloudflare Workers等运行时原生实现了Web API表面——URL、URLSearchParams、fetch、FormData、Headers、Request、Response、AbortController、ReadableStream、crypto等——这些都是在浏览器中运行的相同对象。这是Deno故意做出的架构选择,而WinterCG已经作为跨运行时的最小公共API表面进行了形式化,而且这具有重要的实际意义:相同的API表面覆盖了浏览器和服务器端代码。没有翻译层,没有适配层,没有适配成本。该平台已经正确、安全地解决了一个大的问题类别,并且没有依赖。Deno尤其显著,因为它包括一个标准库,在某些情况下可能缺失,需要跨平台解决方案。除非你提到,否则LLM对你环境并不清楚它的知识库以Node.js代码为主,并且在这些API普遍之前——require('url')、querystring.parse()、express中间件模式、带有自定义超时包装的axios、用于表单解析的multer。这些模式在模型学习的内容中占据了统计上的主导地位。这就是它所达到的目标。模型的默认值和平台已经提供的内容之间的差距是输出标记成本的主要来源。我一直在估算这方面的标记经济学。这些只是近似值——基于模式的实际长度,而不是来自正式研究——但比例足够一致,可以提供帮助。查询参数解析 // 模型默认-手动解析(约140个标记)const parts = rawUrl.split('?');const pairs = parts[1] ? parts[1].split('&') : []; const params = {}; pairs.forEach(p => { const [k, v] = p.split('=');
本站免费、广告极少。如果觉得有帮助,可以请我们喝杯咖啡 —— 任何金额都对持续运营有实际帮助。
☕请我喝杯咖啡