原创 孔某人 2024-11-01 12:52 北京
十月下半月的个人主观感受
这已经是时评杂感类文章的第二篇了，看起来可能会成为一个系列。上一篇是：最近对LLM模型层的一些感受 V1.1
这类文章承载的是一些碎片性的内容，单独不足以成篇，写作成本又比较低，时效性也相对好一些。上一篇的读者反馈也是超乎我意料的。
本系列的文章不会追求完整性，上一篇提到的内容本篇不会再提。
1.1、关于LLM API进展系列文
本专栏其实是有一个LLM闭源API进展的季度报告系列的，这个系列的素材库我目前自己仍然在更新，但暂时并没有打算更新下一期，原因有：
最近一段时间的LLM模型层在新功能上的进展不大，o1模型已经有了专题系列讨论，剩下的更多是降价和性价比模型的更新。
该系列主要是让已经不太关注API方面进展的读者能够快速了解这方面进展。但目前从我自己的角度，API现在只在用Claude 3.5 Sonnet，偶尔还有o1-preview。其他的模型我自己都几乎不用，也感觉没必要推荐给读者。
所以可能会等到下一波新模型发布时再进行更新。
1.2、国内模型厂（只）更新性价比模型
相对于之前一段时间的停滞，国内各家模型厂开始高调的更新模型，反驳对自己已经躺平的怀疑。
但从近期的Yi-Lighting和Baichuan4-Turbo/Air，以及百度和豆包的持续更新来看，国内模型厂近期的动作只有中低价的模型。这些新模型的能力如何，我目前并没有兴趣去测，但从定价反推模型规模的角度来看，有一种“理解面壁（面壁智能）、走向面壁”的趋势。
当然从应用层的角度，能改善目前模型矩阵的“价格-能力”帕累托最优边界的新模型都是重要的。
但我最近在研究的都是高难度、高准确性的场景，跟Claude 3.5 Sonnet 20240620的badcase做斗争，这些中低档模型的进展很难让我相信能够对我最近研究的事情有改善。（本来是打算第一时间迁移到Sonnet 20241022的，但目前由于其供给和成本问题，我仍不得不继续等待。）
1.3、何时该在API场景使用o1模型
自从o1发布之后，大家已经有了一些在To C web端场景上合适使用o1的经验，但何时该在API调用场景使用o1系列模型一直都是一个问题。前一段时间Cursor团队的访谈也提到，他们还没有搞明白这点。
在此方面我最近有一些发现，o1系列模型的一个长处是其优秀的改错能力，不止对于代码和数学领域，对于普通的文字处理也有显著提升。自o1发布以来，它就已经成为我修改文章错字的专用模型，而我最近验证了它在workflow构建场景中也有类似的表现，现在阻碍我在实际应用中使用它的原因只有其价格。这类场景中，如果Claude 3.5 Sonnet都不能让你满意，那么就请考虑尝试o1-preview。虽然它目前还很贵，但当它降价到接近GPT-4o早期版本的时候，它会成为最优选择。我估计这可能在未来2-5个月左右发生。
我很期待Claude系列的o1范式的模型，这可能会大幅提升目前最强模型的能力上限。
我认为：国内模型厂，即使只想更新1元/M token的模型，也应该去跟进o1的范式，做一个o1-mini也能实现明显的能力上限提升。
2.1、关于Speech To Text
ASR是一个挺久的领域了，但这方面可用的API/开源模型的效果并没有达到大家的期待。目前还有几方面问题：
ASR中使用的语言模型能力还没有达到目前LLM的水平，对于新词的识别也很差。甚至很多API不支持单请求级别的新词表配置。只有当你认真的研究ASR方案的时候，才会注意到语音也是一种语言形式，它面对的很多问题和解决方案与LLM很像。
在多个说话人抢话、交替发言频率较高时，说话人的识别非常糟糕。目前的说话人发声重叠区域识别已经有了方案，但开源模型方面还没有比较普适的开箱即用的说话人重叠语音的分离方案。这些方面虽然已经有了一些模型架构看起来很有希望，但并没有看到有公司认真的准备数据去搞一个闭源方案来提供服务。
现在LLM已经成熟，多模态大模型也在快速发展，大家已经能够大规模系统性的处理语音数据了，而ASR的效果无疑是目前的主要瓶颈之一。我真的很希望大厂和在此方面有积累的团队能够去认真搞一下，填补整个链路上的这个短板。
2.2、模态的发现
最近不断的意识到，很多类型的东西其实也是一种模态，例如：
示意图也是一种模态
可以作为视频背景的简单动画也是一种模态
这些并不是单纯的生图或者生视频，从技术方案上它应该被视为一种单独的模态。
在应用场景中，所有的模态之间的互转都是这一轮大模型时代的新生态位。
3.1、LLM的生成长度限制 max_tokens
一直以来，max_tokens都是像是一个随便设的数值，无论是模型厂设置的4k上限，还是API调用者的配置都是如此。但让我意外的是，我最近居然撞上了这个限制，也让我明白了为什么是Claude 3.5 Sonnet最先把它提升到8k作为一个feature认真的进行交付。
这个场景具有如下特点：复杂任务、人工指定的5步左右的CoT、足够强的模型。
人工指定的CoT可以有效的改进一些复杂任务的成功率，但在修复case的过程中，随着步骤逐步增加，它需要的输出token量也会增加。另外如果使用的模型不够强，中间执行时容易出现错误，开发者也会最终将流程分解为多次LLM调用，并在其中增加外部检测环节。
但当你使用足够强的模型时，它可以高准确率的执行多个步骤，所以唯一制约你的就是max_tokens了。而这也是我在使用Claude 3.5 Sonnet时候遇到的情况。也就是，只有足够强的模型才配得上“有足够多的用户要求一个更大的max_tokens上限”。
在使用Claude 3.5 Sonnet的时候，我也发现了一些有意思的情况，例如有些生成token较长（接近或超过4k）时，Claude 3.5 Sonnet在中间步骤出现偷懒（某个步骤的结果输出为[省略]等）的概率也明显变高了，我不得不做了个检查规则来识别这种情况。这并不是模型真的变懒了，而是反映出其训练数据中有不少这样的内容且没有被清洗掉，Claude 3.5 Sonnet的训练数据也很大程度上受到4k左右的影响，当试图让其拓展到更长的输出时仍然会遇到各种问题。
3.2、LLM输出过程中的“惯性”
当我们使用足够强的LLM时（Claude 3.5 Sonnet与GPT-4o），其不错的能力经常让人忘记它仍然只是在执行某种机械的处理。但LLM仍然存在很多问题，甚至在很简单的文字层面也是如此，例如：
在翻译中，如果原文中出现连续多个的相同拟声词，在输出的翻译后很容易进入无限循环。（我在GPT-4o上仍然经常遇到）
当试图逐个句子地处理某个文本时，即使原始输入是经过分句的，在输出时仍然很容易在输出一句话后无视中断直接开始生成后续连贯的句子。（我在所有最强一级的模型上都时常遇到）
这时候就很容易区分人和LLM的表现，LLM就像是完全不看整体任务，连当前这段的处理应该到哪里结束都不知道。
当然对LLM来说没有太多文字层面和抽象层面的差别，同样的问题在各个层面应该都有，这仍然是LLM的一大特点，我们可以通过few-shots的方式进行利用，也经常被这种case困扰。
近期推荐文章
Anthropic官方 深入探讨prompt工程 | 全文脱水中文版
Lex Fridman采访Cursor创始团队 全文 中文版
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，获取联系方式请点击 -> 联系方式。
本文于2024.11.1首发于知乎与微信公众号
知乎链接 https://zhuanlan.zhihu.com/p/4434687357
