Kimi掀起大模型长文本之战(2)

月之暗面在这轮“长文本之争”的特殊之处在于，杨植麟此前在接受采访时曾明确表示，不会采用小模型、降采样、滑动窗口等形式来提升上下文窗口。在200万字上下文对外发布时，月之暗面工程副总裁许欣然也多次强调，此次上下文长度的提升是“无损”前提下进行的，不会影响模型的智能水平。

在Kimi宣布将上下文窗口拓展至200万汉字时，Anthropic所发布的Claude3上下文窗口为200K（Claude2 100K上下文窗口实测约8万汉字），百川智能发布Baichuan2-192K大模型能够一次处理约35万个汉字。从这一点上看，Kimi站稳了长文本能力这一产品定位。 

Gangtise投研分析师表示，目前Kimi模型的日活跃用户数已达100万人，预计月活跃用户数约为500万人。其中小程序端日活跃用户数达60万人，网页端达34万人，APP端达5万人，留存率也在持续上涨。若Kimi模型保持当前增长趋势，小程序端市场地位可能显著提升。 

从基础模型本身的上下文窗口来看，Kimi在一众大模型厂商中表现突出。但从长线来看，融易新媒体消息，这能否构成核心壁垒仍有待讨论。

除去算法层面的优化，多位从业者告诉界面新闻，拓展上下文窗口的另一个限制在于显存容量与显存带宽。

“这其实是一个工程优化的问题。”周王春澍说，在计算资源相同的前提下，上下文窗口的增大会对能够处理的Token数产生影响。换言之，增加计算资源或者使计算资源的利用更高效，是达成长上下文窗口的最直接方案。

受Kimi模型的火热市场反应影响，阿里通义千问、百度文心一言、360迅速公布或预告自己的长文档处理功能。尽管在业内的普遍猜测中，上述产品的长文档处理能力是出自RAG辅助的结果，但是实际效果也证实RAG的路线能够实现与超长文本能力相近的效果。 

“如果能确保知识定位的准确性，比如长文本的Chunking（分块）做的比较好、RAG工程优化也比较好的话，其实在涉及到一些推理的Benchmark（基准）上，RAG和长下文的方案在效果上没有本质性的区别。”周王春澍说。

在C端场景中，百万字级别的长文本能力可以延伸出财报解读、总结论文等多种需求，但是在更为广泛的B端（企业端）场景，模型本身过于长的上下文窗口反而会成为ROI的负累。 

“上下文再长也不大可能长过动辄GB、TB级别的企业级数据，”叶懋认为，“在私有化部署过程中，长上下文很难一下覆盖这些非结构化数据，即使能覆盖，响应速度和算力需求方面的问题也会更加突出。”

月之暗面官网显示，大致来说，对于一段通常的中文文本，1Token大约相当于1.5至2个汉字。如果按200万字粗略计算，使用moonshot-v1-128k的API接口的费用约在60元左右。而据周王春澍所说，如果使用RAG方案，可能需要的成本就只在一分钱或者一毛钱以内。

RAG与长文本能力之间的补足关系在B端场景中体现得尤为明显。在波形智能的商业实践中，与200K左右上下文窗口的模型方案相比，企业客户更倾向于选择RAG外挂数据库+8K左右上下文窗口的模型方案。

“在使用量比较多的场景下，很难想象大家会完全抛弃RAG，然后把上下文全给用起来。”周王春澍将RAG与长文本能力形容作个人计算机领域的CPU高速缓存和内存，两者相互配合完成运算任务。  

而当一种更具性价比、且效果相近的方案存在时，基础模型是否有必要持续扩充上下文窗口就成了有待考虑的问题。

诚然，在追求AGI的路上，足够长的上下文窗口必不可少，但在目前这个阶段，成本、性能与长文本之间的“不可能三角”也确实为长上下文窗口的基础模型的实用性打上了问号。 

一名关注AI大模型技术领域的投资人表示，当他看见行业出现这种普遍表征的时候，内心实感是各家公司确实在为抢入头部阵营做成绩，但这件事本质上还是“秀肌肉”。