这一档模型的参数意味着什么
MiniMax-Text-01 模型提供高达 1000000 的上下文长度，这意味着在单次交互中可以处理极大量的输入信息，为复杂的问答和长文本理解提供了基础。引用上限 90000 规定了知识库召回内容在模型处理时能够被引用的最大 Token 数，直接影响知识库段落的有效利用。该模型不支持图片输入和工具调用，因此基于图像内容的 RAG 链路和外部工具集成能力需通过其他模型或组件实现。单次最大输出未标注，通常表示模型会根据输入和任务智能控制输出长度，但仍需注意避免生成过长内容导致额外成本或系统负载。
配 Milvus 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
MILVUS_ADDRESS | milvus-cluster-ip:19530 | 指向 Milvus 服务的具体网络位置，确保 FastGPT 能够访问。 |
MILVUS_TOKEN | 按实际部署设定 | Milvus 身份验证凭据，保障数据访问安全。 |
index_type | HNSW | HNSW 索引在召回性能和准确性之间提供了良好平衡，适合大规模向量搜索。 |
metric_type | IP | IP (内积) 距离度量适用于衡量文本嵌入向量之间的相似度，与多数 embedding 模型兼容。 |
| 召回条数 | 30-50 条 | 在 90000 引用上限内，兼顾召回广度与模型处理效率，避免不必要的 Token 消耗。 |
| 单条文本长度 | 200-500 字符 | 确保每条召回内容包含足够信息，同时避免过长导致上下文预算浪费。 |
这两者互相约束的地方
MiniMax-Text-01 模型的 1000000 上下文长度与 Milvus 的召回策略存在紧密关联。召回条数与每段长度的乘积必须远小于模型的上下文预算，以预留空间给用户输入和模型输出。引用上限 90000 决定了知识库内容被模型实际利用的上限，即使 Milvus 返回了更多条目，最终模型也只会处理不超过此上限的 Token。因此，Milvus 的召回条数配置应与引用上限综合考量，避免过度召回造成资源浪费。索引参数如 HNSW 的 M 和 efConstruction 增大，虽然可能提升召回精度，但也会增加 Milvus 的索引构建和搜索延迟，需要在实际部署中进行性能测试以找到平衡点。
容易做错的三处
- 日志显示
context_exceeded错误：原因在于 Milvus 召回内容的总长度加上用户输入超过了模型 1000000 的上下文长度限制。 - 模型回答中知识库引用不充分或遗漏关键信息：原因可能是 Milvus 召回条数过少，或者单条文本长度不足以覆盖完整语义，导致引用上限 90000 未能被有效利用。
- Milvus 查询响应时间过长，导致 FastGPT 接口超时：原因可能是
HNSW索引参数设置过于激进（如efSearch过大），或者 Milvus 部署资源不足。
怎么确认配好了
- 在 FastGPT 知识库管理页面，上传测试文档并进行预览，检查分段是否符合预期单条文本长度。
- 通过 FastGPT 的调试模式，观察模型在不同查询下的实际引用 Token 数，确认其未超过 90000 且能有效利用召回内容。
- 使用 Milvus 客户端工具，对 Milvus 向量数据库进行模拟查询，监控查询延迟和资源占用，确保其在可接受范围内。