dify v1.1.0接入这个开源LLM，知识库效果直接起飞，真可以封神了！【喂饭级教程】

在又叒拯救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全绿！这意味着即使在海量信息中，它也能精准找到关键内容，不会像其他模型一样”记忆力衰退”。

看到这里，部分朋友应该已经大概知道，MiniMax-01为什么能拯救dify的知识库问答效果了。

其实就是靠模型自身的超长上下文”大海捞针”的能力，在这种情况下，即便不用RAG搭建知识库，直接把所有资料内容放在system prompt中都能达到良好的问答效果。

PS：但是我们现阶段还是会结合RAG来使用，有两个好处：1.利用RAG的能力缩小内容范围，节约tokens（节约成本）2.当知识库内容超出模型支持上下文长度时，还是需要借助RAG缩小范围。

这种抛弃RAG的方案其实早在去年Kimi爆火的时候我就分享过了

但这个方案的缺点是非常消耗token，一直以来kimi API的价格也不算低（tokens成本高）

加上kimi支持的上下文长度还不够，所以在当时结合kimi的这个方案并不适合大多数人，土豪可以当我没说。

但是现在出现了一个上下文长度是kimi的30倍，价格是kimi的60分之一，性能还直逼gpt-4o和Claude3.5的开源模型，就大不一样了。

好了，介绍差不多了，我们开始实操~

MiniMax-01拯救dify知识库

顺便提一下，dify在两天前又更新到了v1.1.0版本

修复了不少bug，还增强了一些功能

最大的更新是新增了元数据功能，感兴趣的朋友可以去看dify官方blog：

https://dify.ai/blog/dify-v1-1-0-filtering-knowledge-retrieval-with-customized-metadata

说明一下：不用升级dify也能往下操作

要把minimax-01接入dify，我们还是老规矩，需要获取minimax-01的apikey

apikey创建地址：

https://platform.minimaxi.com/user-center/basicinformation/interface-key

创建好apikey，复制备用

接下来访问dify页面

点击右上角头像->设置

在模型供应商中，找到MiniMax，点击安装

PS：模型供应商安装是从github拉取，最好开启科学上网，不过我实测没有科学上网的情况下，多试几次也能成功安装

弹框如下图，就代表安装成功了

刷新一下页面，点击MiniMax的设置

如下图，需要填写MiniMax的apikey和Group id，然后保存

group id在账户信息这里获取

保存成功后，展开模型，MiniMax-Text-01就是上面所说的minimax-01模型的全称。

这套方案还有另外一个关键点：RAG检索到的相关内容，需要尽可能全面、丰富，就算当中有不太相关的信息也没关系，只要相关信息都在就行。

我还是以我的文章搭建知识库为例。

采用的策略非常简单粗暴：直接一个chunk（块）放一整篇文章，这样完全不需要担心检索到的内容出现不连贯的问题。

dify中刚好有一个父子分块的方式能够在父块中存放整篇文章。

我们先新建一个知识库，导入公众号文章的txt文件，并进入下一步

分段设置选择【父子分段】父块设置为全文，子块不用填分段标识符，分段最大长度直接上最大4000tokens

索引方式选择高质量-混合索引，索引模型和重排模型我选择硅基流动里面的两个免费模型。

topK拉满，score阈值拉到0.1（这是最省事的配置），如果你还是心疼消耗的tokens，可以自行调整参数。点击保存并处理，然后等待文件解析

等待所有文件状态变成可用，就ok了

接下来我们创建一个应用，把这个知识库关联到应用上。

并指定使用MiniMax-Text-01模型

测试一下问答效果：

AUTUMN

这个回答，可以说堪称完美！即全面又详细。

经常看我文章的朋友应该知道，我每次测试知识库问答效果，基本上都是用这套公众号文章作为资料，而这个问题也是知识库的试金石。

我用这个问题测试过fastgpt、ragflow、coze、dify、等等其他一推带知识库的LLM应用平台。

但是说实话，到目前为止，用这套方案，得到的回答是最优秀的。

我测试了很多问题，回答的都很棒，都是既全面、又详细，而且minimax-01有自己的一套逻辑来总结表达，不是照搬原文。

AUTUMN

可能有人会觉得，这个方案下，换一个模型效果是不是也一样呢。

还真不太一样，比如下图，我用DeepSeek V3，它在这个问题上就产生了幻觉，我上传的文档中只有kimi、智谱、gpt4o接入微信的文章，而它把其他文章中提到的大模型都列出来了。。。

所以，大模型的上下文长度以及”大海捞针”的能力其实是非常重要的。

就像人一样，领导给你一件任务，如果你能了解整个任务背景，各种详细信息，上下文非常充足的情况下，相信会执行的很容易。相反，当你上下文不足，做起来就会束手束脚，各种错误，效率低下。

所以，当你给大模型指派一个任务时，能给到足够丰富的上下文，那么结果都一定不会差。

而当这个上下文非常庞大的时候，minimax-01的400万tokens上下文就能发挥它的最大作用了。

最关键的还是它价格太香了，100万tokens才1元，意味着处理几百万字才几块钱，随便造~

用它来续写小说效果也非常棒，在上篇文章中，我把辰东最新的小说（还未连载完）《夜无疆》丢给MiniMax-01（共108万字），让它续写，续写出来的内容是文风一致，情节合理，我估计原作者看到都会恍惚吧。

以及非常适合应用到 AI Agent：想象一下，当AI需要处理复杂任务时，往往需要长时间的”思考链”，需要持续记忆大量信息。无论是单Agent系统需要持续记忆，还是多Agent系统中Agent之间的大量相互通信，都需要越来越长的上下文支持。

最后补充一下，除了API调用之外，minimax网页端也可以免费使用minimax-01，地址就不贴了，大家自己百度。