现在大模型发布的周期越来越快，模型也越来越强，现在很多做模型开发的在开发中都开始放弃外围系统，直接使用大模型的能力。很多系统的架构方式，就是直白的设计一个用户使用入口到大模型API的桥接，所有的数据清洗、处理等都由大模型来完成。 这让我想起SAAS云服务刚兴起的时候，很多人都说着架构师已经不值钱了，因为以前很多需要架构师依靠架构来解决的问题，可以直接使用云服务来解决：数据库表的数据量大，那么就采用云数据库，几十亿也轻松撑住，再也不用研究什么分库分表；图片OCR识别算法难以解决，直接使用API云服务，准确，开发也容易了很多。当时就出来很多公司做项目报价，报价低的离谱，我当时很不理解很多很难的系统为什么会有那么低的价格。直到好几个曾经的客户找到我，让我看看他们的新做的系统，刚开始几个月运行的很好，为什么后续运行的时候，平台需要让他交很多钱，算下来几年交下来的钱都比很多公司原来的系统报价还高。我看了源码后发现，这类系统的共同特点就是：能用云服务的地方，就不会自己实现，数据库是云数据库，消费用的云队列，OCR直接调用云API，非结构化数据使用云存储，然后再上个CDN加速。而且系统在上线后，服务商会提前充值一定额度，所以上线后，系统使用顺畅，怎么看都看不出问题来，直到几个月后整体交付后，发现原来维持这套系统运行，需要支付各种费用。
直到最近和部分AI落地开发，OPC开发聊过之后，我发现AI相关开发也是这种趋势。他们共同的特点是对大模型有极高的信任度和中层度，认为所有的外围技术开发最终都会被替代，也完全没必要，给大模型更纯粹的数据，就可以得到更准确的结果。（这个其实部分思想在Anthropic前几个月提出过一次，当时他提出的观点是：很多依据模型构建起来的外围Harness工程，最终都会被拆掉，而且他们在让模型外围的Harness越来越薄。）在这种指导思想下，AI落地项目整体的设计方案就变成了如下的设计方案：
依据我们目前大半年实践案例来说，很明显，基本上绝大部分业务都不需要很强的模型。现在很多开源的“小参数模型”，都可以很好的支撑起公司的绝大部分业务。 以我们目前使用，同时在不断迭代的企业智能体平台为例，我们在对平台进行测试的时候，都是在使用我们自己私有部署的35B的模型，而且还是INT4量化版；模型占用显存20G，买好的电脑都轻松可以部署。当然这不是没代价的，模型的参数不够大，就只能依赖于平台提供支撑，例如在实现知识库数据召回的时候，除了使用企业知识库常用的技术路径，如BM25这种常见的知识库检索方案外，在项目实践过程中为了提高检索、召回准确度，还加入了知识图谱（基于本体论）的知识召回路径。多个知识检索、召回路径相互配合和补充，目前在公司内部使用效果很好，资料的召回率基本在90%以上； 在最初开发的时候，我们也是使用商业的最好的模型，千问出最新模型，那就用千问；Deepseek出最新模型，就用Deepseek；可以说每一条数据和功能测试都是需要花钱的，每个月就只是花在平台的功能测试上就要花很多钱。在使用最好的商业模型过程中发现很多模型在语言理解，工具调用调用的确很强，那时候都不需要构建多么复杂的流程和外部系统，只需要合适的提示词即可解决绝大部分问题。当时觉得这种平台开发也太简单了，相比多年来的数字化系统开发，简直就是可以用DEMO的开发水平就可以。 但是当我们将这套系统放到客户现场试用后，发现我们系统听过知识召回的内容基本上不到一半的准确率，大量的知识内容存在混乱，答非所问的情况，更严重的是很多问题都出现“语义漂移”，或是部分会称之为“RAG幻觉”：就是我在知识库问A型号的产品知识，模型用B型号和C型号的内容，然后混合A型号的内容，形成一份答案进行回答，如果你不是这个专业人员，很多回答你甚至都发现不了，只是觉得回答的还挺专业的。客户指出问题后，我们初期以为仅仅模型的上下文被太多不相关的内容塞满之后，引起的模型注意力问题。排查整个链路后，才知道客户部署的模型还是去年年初的模型。这个模型我们测试之后，发现模型经常对于语言理解都有问题，就是它本身都可能会理解错内容。客户应该是在去年年初Deepseek风潮中上线的大模型，然后这么久也不知道干什么，就只是用它来做通用知识的问答。这算是我们去做AI落地项目遇到的第一个坑。我们本想着还为客户更换模型就可以，但是在我们更换模型之后，发现我们的平台是使用最好的商业模型做出来的系统，根本没办法在本地部署的这些"简陋的模型"中运行。 以我见过的绝大部分客户为例，很多客户都是在去年年初Deepseek那波风潮中买的算力卡，那个时期大部分都买的是A100，A100性能很好，单个卡80G，一般买两个卡，在整个算力中心建立起来应该是需要投入在40W左右。（这种客户应该在一定程度上也算是优质客户了，还是很有意愿在AI上投入）。但是160G的显存在现在的能部署的模型，和商业模型差的不是一个玄武湖，应该差的是一个太平洋。 如果我们不采用客户自身建设的算力中心，而直接采用商业模型，先不说客户的内审、信息安全等部门能不能通过，就我们这个平台方案，全公司推广使用之后，客户每个月的模型API Token账单都不会是一个小数字。那时候我意识到，要想让一个企业、一个客户使用AI，一个很重要的前提是不能让系统的日常运行成为一个企业庞大支出项目。 于是我们开始买算力服务器，开始部署自己的模型，不断的去筛选一下适合我们平台的模型，而且刻意去用多个模型来比较不同的模型在平台使用过程中的差异。 当然这整个开发过程是曲折的。因为我们在开发公司的智能体平台的过程中，发现我们在搭建的整个系统，很多程度上都不如一个提示词。当时最典型的一个例子就是：我们为摆脱模型对于文本理解能力的依赖，我们构建知识图谱去弥补模型长文本的理解能力，但是如何使用自然语言切入知识图谱的问题困扰了我们很久。我们使用了各种方式尝试方案，最后意外发现直接使用Cluade Code，然后配合一个稍微好一点的商业模型，Claude Code可以很准确的返回我们想要的准确答案。这一瞬间打击是巨大的，当时我们真的在想自己做的这种系统是否值得，我们几个月开发的平台，其实只需要一个好的模型再配合Claude Code就可以了。那我们是不是真的只需要等待模型继续升级，然后开源出来的模型会越来越强，然后使用这些开源的模型就可以了。直到我们开始一步一步的调试：查看Claude Code提示词、工具调用方式，最后才发现Claude Code居然走的是大力出奇迹的路线，它的实现方案就是读取整个知识图谱所有的数据，然后遇到和问题相关的知识内容就一行一行的记录下来，然后是最后再依据这些内容进行整理、组合形成答案。看到这个完整的处理链路后，我们总算是如释重负，不用怀疑自己做的系统是否有意义，因为这证明了在实际的企业工程实践中，并不是简单的Claude Code + 一个强大的模型就可以解决实际问题，它只是将问题掩盖了而已。 现在，我们智能体平台基本已经成熟，也在客户现场落地使用，我们也将整个平台构建到使用32G显存，就可以支撑本地运行，如果是需要公司使用，我们现在推出的主要主要产品是192G显存的方案，而且我们和部分算力厂商合作，192G显存的设备，我们可以做到3W+的价格，这里特别说明一下，并不是使用统一内存的方案，因为用过统一内存设备应该知道，统一内存的方案对模型有限制，而且实际运行的Token速度并不高。我们现在提供统一托管的服务，也就是你可以买了设备，交给我们来托管，我们按年来收托管费，如果后期自建算力中心，可以再把设备拉回去自己部署，更主要的是，托管费用也很便宜，几千块钱即可。
我这里并不是在说商业模型并不适合在企业场景中，而是在说实际上现阶段很多企业的业务并不需要这么强的模型，当然，我这里在说的是工业、制造业等领域。如果公司是软件公司、视频公司等，那自然不用说，肯定是越强的模型越有利于公司的业务。 另外，“小参数模型”只是在部分业务场景上可以做到覆盖，我们目前也在做专业领域的知识业务，例如内审、法律合同审查，医疗领域的知识模型等，这种行业很多做下来，基本上都需要很强的模型支撑，例如我们在做内审、法律合同审查的时候，需要对合同文本进行本体拆解和映射，这个过程在“小参数模型”模型跑一份合同基本上要半个多小时，放到商业模型，如Qwen3.6 Max这种模型上，只需要几分钟即可有结果，效果明显比“小参数模型”好很多，但是代价也很明显，一份50页的合同需要20块钱的API成本。我们都笑称如果一个项目赚不回来20块钱，还是不要用这个的好，这个在一定程度上是不防止了“垃圾合同”污染知识库数据。当然，我相信这只是因为目前我们还没找到更好的技术路径，另外模型也还没有足够的强，说不定等我这篇内容发出来的时候，这个问题都已经快被解决了，毕竟现在的模型更新速度是按周计算的。
