这一档模型的参数意味着什么
MiniMax-M1 模型具备 1000000 的上下文长度，这意味着在单次对话中，模型可以处理极大量的信息输入。虽然单次最大输出未明确标注，通常会根据应用场景进行限制以避免过长的回答。引用上限为 900000，这限定了模型在生成回复时可以引用的内容总量（以 token 计），确保了引用内容不会过度消耗上下文。引用内容的总 token 预算与召回的段落条数是两个不同的概念，引用上限限制的是所有引用内容的总量，而检索侧返回的条数则决定了有多少独立信息段落被送入模型。该模型支持工具调用，允许与外部系统进行交互以获取实时信息或执行特定操作，但不支持图片输入，因此不适用于处理视觉信息。
配 PostgreSQL（pgvector） 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
PG_URL | postgresql://user:password@host:port/database | 数据库连接字符串，确保可访问性和权限 |
ef_construction | 64 | HNSW 索引构建参数，影响索引质量与构建时间，通常取 m * 2 或更高 |
ef_search | 32 | HNSW 索引搜索参数，影响搜索召回率与查询速度，按实测标定 |
m = 32 | 32 | HNSW 索引的邻居数，影响索引结构和搜索性能 |
vector_ip_ops | true | pgvector 向量操作符，确保使用内积距离计算 |
max_connections | 100 | PostgreSQL 最大连接数，根据并发请求量调整 |
这两者互相约束的地方
MiniMax-M1 模型的 1000000 上下文长度为引入大量召回内容提供了空间。然而，向量库返回的召回条数与每段内容的长度共同决定了实际消耗的上下文 token。引用上限 900000 token 是对所有引用内容的总量限制，并非直接限定召回条数。向量库返回的每条数据段落，其长度累计起来不能超过引用上限，并且所有输入（包括用户查询、历史对话、引用内容）的总和不能超出 1000000 的上下文长度。当 PostgreSQL（pgvector） 的索引参数 ef_construction 和 ef_search 调大时，通常意味着召回的准确性会提高，但在查询延迟上会有所增加。这对于需要大量精确引用的模型来说是积极的，因为更准确的召回能够更好地利用模型的引用上限预算，减少无效信息的引入。
容易做错的三处
- 模型返回空回答或不相关信息：原因可能是向量召回条数过少，导致模型没有足够信息进行推理。
- 日志显示
context_window_exceeded错误：原因在于发送给模型的总 token 数量（用户输入 + 历史对话 + 召回内容）超过了 1000000 的上下文限制。 - 向量搜索响应时间过长：原因可能是
ef_search设置过大，导致向量检索效率低下，或索引未正确建立。
怎么确认配好了
- 通过 FastGPT 平台测试，观察模型在复杂问题下是否能准确引用 PostgreSQL（pgvector） 召回的内容。
- 监控 PostgreSQL 数据库的查询日志，确认
vector_ip_ops正确启用且查询延迟在可接受范围内。 - 在平台界面观察引用的内容长度和数量，确保其在 900000 的引用上限内且召回条数适中。
- 模拟高并发场景，观察 PostgreSQL 的
max_connections是否能满足需求，以及整体系统稳定性。