AI大模型的发展日新月异，其能力也在不断更新迭代。国内目前做的比较好的有阿里的通义千问、火山的豆包、月之暗面的kimi，个人认为这三个算是第一梯队；第二梯队觉得有深度求索的deepseek、清华大学的智谱清言和腾讯的元宝。平时常用的是第一梯队的三家，三家模型也有各自的特点：通义千问像是默默无闻的学习委员，他有足够强的能力但是需要使用者有相对强的提示词能力，不过现在网上针对prompt提示词工程相关的分享也很多，不是什么难事；火山的豆包得益于他的亲爹火山引擎和他的两个哥哥抖音和今日头条，拥有最丰富的“媒体”感，表现出来的是拥有相对国内最强的多模态能力——图片生成、图片识别、语音生成和语气感知等，就像是班里的文娱委员，使用起来是最有趣的。kimi做的则比较均衡，给他打比方的话就像是班里的班长，有能力也好沟通。kimi的联网搜索能力很强，还能搜索微信公众号的内容来作为输出依据，输出的语气也做了优化让kimi的输出也多了点“人味”。当然如果能科学上网还是直接用ChatGPT就行，各方面都够强，综合体验感觉是最好的。现在也推出了ChatGPT5，用了一下相比GPT4o最直观的变化是token生成速度快了很多。

AI大模型发展带来的不可忽视的一个价值就是其在生产工作中可以部分替代一些人工。现在比较成熟的模型能力落地场景就有：电商平台AI客服、文档翻译、新闻稿/剧本编写等。这些落地场景都让AI模型完成了绝大部分工作，可能只需要人工最后调整调整，把把关就行，真正的降本增效。这些模型应用落地场景都离不开一个重要的前提——上下文。AI客服需要现了解完产品才能充当客服的角色服务消费者，文档翻译需要拿到文章原文才能给出翻译，新闻稿/剧本的编写需要知道事情的来龙去脉才能给出对应的稿件。这就是上下文的作用——模型本身有充当客服的能力，有翻译的能力，有编写稿件的能力，但是需要知道上下文才能完成工作——即“让模型学习到新的知识，让模型具备更专业的能力”。平时简单问个问题可以把上下文背景作为input的一部分告诉模型，但是在生产场景这种方式是不可用的——上下文太长，每次调用都要输入一次上下文也很麻烦。要解决生产场景中的上下文问题，提两种方式：1.模型微调，把相关的上下文资料作为数据集去做模型微调，调的是模型在输出过程中的权重倾向，最终形成一个精通微调数据的专家模型。这相当于闭卷考，知识自己吸收，问了直接就能答。2.通用模型+知识库，这相当于开卷考。把需要模型知悉的数据都放在知识库中，问了问题模型会去知识库中“查资料”，然后结合查到的资料来给出回复。

模型微调技术路线已经相对成熟，但是贸然尝试往往达不到预期效果其原因有三：1.训练算力昂贵；2.数据集构建难；3.数据集规模不够大。贸然尝试模型微调可能会遇到如训练不收敛或者过拟合等情况，最终效果不尽如人意。而且哪怕微调出了一个效果还可以的模型，但是这个微调后的模型也会随着时间逐渐展现出向原始通用模型回归的趋势，最终失去微调形成的能力。

现阶段可行度比较高的方案有二：1.使用dify或扣子等平台搭建知识库与智能体；2.搭建外挂向量知识库，手动编写业务层逻辑构建智能体。这两种方案对应的优缺点明显且使用场景不同，第一种方案适合相对没那么复杂的场景，其有点是AI Agent的逻辑编排方便，知识库搭建方便；缺点则是AI Agent的逻辑编排只能在其提供的固定框架里进行编排，复杂场景下显得不够方便，再者现在不管是dify还是扣子这些平台化的工具对于模型多并发的场景适配的也没那么好。因此在业务逻辑相对没那么复杂的场景下，使用dify、扣子等平台还是能高效的实现大模型业务落地。那么相应的第二种方案则是应对更复杂的业务场景，优缺点也很明显：上手难度高，落地速度没那么快，但是最终实现的效果会比第一种要好。第二种方案的知识库使用的是Annoy、 FAISS、hnswlib等向量知识库，效果一定是会比dify等平台提供的知识库要更好的。在使用大模型的过程中虽然input和output都是自然语言，但是在模型内部处理则全是向量的处理，所以正常使用大模型的过程应该是input(自然语言)-->向量-->output(自然语言)，其中涉及到了两次自然语言和向量之间的转化。这个过程是必不可少的，大模型当然期望的是input就是向量然后拿到手直接处理最终把处理好的向量输出出来，但是人类作为使用者当然没办法用向量来作为input然后无障碍的阅读以向量为展现形式的output。最基本的这两次向量与自然语言之间的转化显然已经是不可避免的了，但是在大模型的应用开发落地过程中可以尽可能的减少额外的转换产生，帮大模型省事，输出的效果也会更好。这就是为什么手动外挂知识库要选择向量知识库，向量知识库会把自然语言的语料数据提前转化成向量数据存储在知识库中而不是以自然语言形式存储，这样大模型在使用向量知识库中的数据拿到的就是直接的向量数据，如上所说：帮大模型省事，输出的效果也会更好。这就是对比dify的优势之一了，dify中提供的知识库是以自然语言的形式存储语料，当模型调用知识库中的数据，就会多一次自然语言到向量数据的转化。第二个优势就是所有的业务逻辑都是根据实际需求手动编写业务逻辑用代码实现的，这样在最终的业务落地过程会更加灵活、运行效率会更高，最终的结果也会更好。

综合上述两种方案，其原理其实也是一丘之貉——都是使用通用模型+知识库实现“让模型学习到新的知识，让模型具备更专业的能力”。但是同样都是知识库最终实现的效果可能也会大相径庭，这是因为上文提到知识库就相当于开卷考，用户问了问题模型去知识库里去查相关的资料。问题就出在“查资料”的过程中，我们期望的模型的查资料过程是“非对称语义检索”而不是“对称语义检索”。对称语义检索要求模型能够将问题和答案映射到同一空间，即比方说问模型“实线变道有没有责任”，我们期望的是模型能够去知识库中检索关于实线变道的法律规定及其后果最终给出“有责任，不可取”的回复，这中非对称语义检索也是最符合人类直觉的思维方式。但是往往模型的这个“查资料”的过程是“对称语义检索”即“同义句匹配”对称语义检索的目标是找相似的句子，与向量检索基于计算向量相似度的原理天然匹配，只需要模型有比较强的内容抽象能力就可以。还用问模型“实线变道有没有责任”来举例：知识库中内容是：“实现变道有没有责任如何判定：1.XXXXX；2.XXXXX”，模型按照“对称语义检索”的方式去知识库中查资料查到的是我们的问题的近似句、同义句，因此模型可能从知识库查到的资料是“实现变道有没有责任如何判定”然后就忽略了真正有价值的判定依据，最终回复可能就是“没有责任”，因为“没有责任”这四个字在模型查到的“资料”中都有出现，倾向是最高的。（只是举个例子，实际肯定不会这么草率的讲实线变道没有责任，毕竟通用模型没这么蠢，这种常识性的问题还是有自己的主观能动判断的）。