小身材量化模型,难道不能成就大事业?
摘要:好几天没有更新文章了,有些朋友关注这MindX项目的朋友都在问我这项目是不是停了?其实代码是一直天天更新的,但这几天一直在找人探讨->思考->重构这样的高速循环中。由其是这几天一直都是集中在对【本地量化模型的控制
好几天没有更新文章了,有些朋友关注这MindX项目的朋友都在问我这项目是不是停了?其实代码是一直天天更新的,但这几天一直在找人探讨->思考->重构这样的高速循环中。由其是这几天一直都是集中在对【本地量化模型的控制让其变得更能干更省钱】与【如何充分发挥云端模型能力让MindX变得更像人更聪明】这两个方向上。前者取得了一些阶段性的成果也得到了一些非常值得分享的经验,而后者就比较长篇大论了暂时不打算放到今天的文中,不过我会在后续的文章中用比较容易让人理解的方式来介绍一下的。
MindX的双层双脑结构是我认为这个项目量大的核心亮点,至少在理论上它是行得通的,在初版中它也是能工作的而且初版的目标就是先打下一个可持续迭代的架构基础与运行环境。这几天我在直接使用MindX交流时却是碰到了非常棘手的问题:左脑的沟通能力有点【障碍】具体表现为:
问非所答 —— 我问它“今天A股走势如何?”,它会给我回复“你想查询天气的话我需要知道是里个具体地点” 【我X!我问股市你告诉我天气那是跌征兆吗?!】
编造答案(瞎猜) —— 我问它“帮我查一下Alex的电话”,它竟然根我说“Alex的电话是13011119999?” 【这很明显一看就是假的,怎么每个模型都喜欢撒谎!】
无法执行技能 —— 前面两关过了,要不就是找不到技能要不就是无法执行技能,这真是有点让人有点崩;
我都将这些问题集中地问过 Opus, Gemini 和 GLM5,它们得到的统一回答是:【由于模型太小,能力有限无法理解你的问题或者无法支持工具的调用】
如果真的如AI们所说的那样,那MindX真走不下去,因为第一点就被破题了,跑本地量化模型的根因是为了可以【省钱】,让算力做有价值的事情而不是做些代替人的毫无价值的“双击”类的任务!
所以,我得到一个答案:所有AI模型都在【骗】我!我非常坚定的知道:【qwen3:0.6b这个模型并不是AI们说得那么一无事处,而是被严重低估的】!在概念设计完我是做过可行性测试的,直接用Ollama发原生请求测试它能不能进行正常的交流,是否能执行技能。这些我是有明确答案的:能!
只是我不能问qwen3:0.6b一些比较高级或者需要数据支持的问题,但能力上是不得不佩服阿里团队的这个量化模型的,几乎全能!重点是它仅有500多M就能深度思考还不用GPU,反应速度也就是5~6秒左右,这还是加载速度,加载成了速度还更快一些,这不是牛是什么?这完全是本地使用的最佳Trade-Off方案!
问题与挑战
既然问道于盲,那就只能自己动手,祭出必杀技:【测试】。
我把上述的问题理清了一遍,将输入内容与期望得到的结果分别告诉Opus和GLM5,让它给我将相应的集成测试,端到端测试都给写了一遍。有意思的事情发生了,GLM5的答案是我所预盼的那样糟糕(印证了我之前的文章中吐槽过国内大模型在写测试方面都是垃圾的问题),写的测试不是没有测到点上就是将精力全放到Mock上(我的天啊!我写集成测试它给我去写Mock,这是能听懂人话的模型吗?这好让人恼火)。而Opus却让我惊艳到了,它写的测试质量太高了!老手都知道写一个高质量测试的难度是比普通代码要难3倍以上,至少技巧与思路都得强,所以测试工程师才配得上架构师级别的薪酬。
在果断删除GLM5写的一堆垃圾测试转为全用Opus写测试,而且我给它加了这么一条规则:“不准认为量化小模型能力有限,它能完全满足当前功能的需求,测试不过必然代码逻辑有错”。在这个Prompt的加持下,经过超10个小时以上的奋战(主要是等Opus思考)最后是将问题的根因找到了,也找到了相应的解决方案。
并且经过这次从MindX v1.0.3 → v1.0.4 的开发过程,涵盖 3400+ 行新增测试代码和多处关键架构改进中,我从直觉式的边做边更新思路,总结出一种针对LLM系统测试的新认知:
核心认知:LLM 系统的可测试性设计思路
LLM 的输出天然是非确定性的。传统软件测试追求"给定输入,断言精确输出",但在 LLM 系统中,这条路走不通。我们的核心策略是:
把系统拆成"确定性层"和"非确定性层",分别用不同策略测试。
