因为我发现：minimax-01居然能凭一己之力，完全拯救dify的原生知识库！
关注我的朋友应该都知道，我之前专门写了两篇针对dify知识库的"曲线救国"文章，一篇是外接fastgpt，一篇是外接ragflow。这两个方案虽然都能达到目的，但都需要额外维护一套平台，终究还是比较麻烦。今天这个方案仅需接入一个开源模型，可以说是最简单，效果最直接的了。在又叒拯救dify知识库之前，我们得先简单了解一下minimax-01。minimax-01是MiniMax在1月份开源的旗舰大模型（比DeepSeek R1早4天）。github地址：https://github.com/MiniMax-AI/MiniMax-01参数量没有DeepSeek R1大（DeepSeek是671b，minimax-01是456b），但是实测各方面能力相差不大（性能同样直追GPT-4o和Claude-3.5-Sonnet）1.价格感人：原本DeepSeek的API就已经是白菜价了，但是minimax-01的API价格居然比DeepSeek还低（100万tokens仅需1元）。2.最关键的能力：支持处理400万(4M)tokens的超长上下文（目前全球最长），是Claude-3.5-Sonnet的20倍，GPT-4o的32倍，DeepSeek的62.5倍！这项能力上对其他模型来说是降维打击了。在400万token的"大海捞针"检索任务中，MiniMax-01全绿！这意味着即使在海量信息中，它也能精准找到关键内容，不会像其他模型一样"记忆力衰退"。
加上kimi支持的上下文长度还不够，所以在当时结合kimi的这个方案并不适合大多数人，土豪可以当我没说。
但是现在出现了一个上下文长度是kimi的30倍，价格是kimi的60分之一，性能还直逼gpt-4o和Claude3.5的开源模型，就大不一样了。
好了，介绍差不多了，我们开始实操~
顺便提一下，dify在两天前又更新到了v1.1.0版本
修复了不少bug，还增强了一些功能
最大的更新是新增了元数据功能，感兴趣的朋友可以去看dify官方blog：
https://dify.ai/blog/dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata
不清楚怎么升级dify的朋友可回顾上上篇内容：dify升级v1.0.1并外接ragflow
dify最新的v1.1.0 docker-compose.yml文件可在公众号后台私信：“dify1.1.0” 获取
要把minimax-01接入dify，我们还是老规矩，需要获取minimax-01的apikey
apikey创建地址：
https://platform.minimaxi.com/user-center/basicinformation/interface-key
PS：模型供应商安装是从github拉取，最好开启科学上网，不过我实测没有科学上网的情况下，多试几次也能成功安装
如下图，需要填写MiniMax的apikey和Group id，然后保存保存成功后，展开模型，MiniMax-Text-01就是上面所说的minimax-01模型的全称。这套方案还有另外一个关键点：RAG检索到的相关内容，需要尽可能全面、丰富，就算当中有不太相关的信息也没关系，只要相关信息都在就行。采用的策略非常简单粗暴：直接一个chunk（块）放一整篇文章，这样完全不需要担心检索到的内容出现不连贯的问题。dify中刚好有一个父子分块的方式能够在父块中存放整篇文章。我们先新建一个知识库，导入公众号文章的txt文件，并进入下一步分段设置选择【父子分段】父块设置为全文，子块不用填分段标识符，分段最大长度直接上最大4000tokens索引方式选择高质量-混合索引，索引模型和重排模型我选择硅基流动里面的两个免费模型。topK拉满，score阈值拉到0.1（这是最省事的配置），如果你还是心疼消耗的tokens，可以自行调整参数。点击保存并处理，然后等待文件解析接下来我们创建一个应用，把这个知识库关联到应用上。经常看我文章的朋友应该知道，我每次测试知识库问答效果，基本上都是用这套公众号文章作为资料，而这个问题也是知识库的试金石。我用这个问题测试过fastgpt、ragflow、coze、dify、等等其他一推带知识库的LLM应用平台。但是说实话，到目前为止，用这套方案，得到的回答是最优秀的。我测试了很多问题，回答的都很棒，都是既全面、又详细，而且minimax-01有自己的一套逻辑来总结表达，不是照搬原文。可能有人会觉得，这个方案下，换一个模型效果是不是也一样呢。还真不太一样，比如下图，我用DeepSeek V3，它在这个问题上就产生了幻觉，我上传的文档中只有kimi、智谱、gpt4o接入微信的文章，而它把其他文章中提到的大模型都列出来了。。。所以，大模型的上下文长度以及"大海捞针"的能力其实是非常重要的。就像人一样，领导给你一件任务，如果你能了解整个任务背景，各种详细信息，上下文非常充足的情况下，相信会执行的很容易。相反，当你上下文不足，做起来就会束手束脚，各种错误，效率低下。所以，当你给大模型指派一个任务时，能给到足够丰富的上下文，那么结果都一定不会差。而当这个上下文非常庞大的时候，minimax-01的400万tokens上下文就能发挥它的最大作用了。最关键的还是它价格太香了，100万tokens才1元，意味着处理几百万字才几块钱，随便造~用它来续写小说效果也非常棒，在上篇文章中，我把辰东最新的小说（还未连载完）《夜无疆》丢给MiniMax-01（共108万字），让它续写，续写出来的内容是文风一致，情节合理，我估计原作者看到都会恍惚吧。以及非常适合应用到 AI Agent：想象一下，当AI需要处理复杂任务时，往往需要长时间的"思考链"，需要持续记忆大量信息。无论是单Agent系统需要持续记忆，还是多Agent系统中Agent之间的大量相互通信，都需要越来越长的上下文支持。最后补充一下，除了API调用之外，minimax网页端也可以免费使用minimax-01，地址就不贴了，大家自己百度。如果你还想到别的应用场景，可以发到评论区，大家一起沟通学习~
本站不参与任何软件的破解及开发存储，所有资源均通过合法渠道获取，售价仅是对资源查找及整理的加工费用。如喜欢作品，请支持正版。本站一切教程均为原创，未经授权，禁止用于商业用途，转载需以超链接形式注明出处，否则将依法追究责任。如发现侵权内容不妥，请联系我们，我们会及时核实并处理。感谢您的支持与理解！
发表评论取消回复