这一档模型的参数意味着什么
MiniMax 196K 上下文模型提供高达 196000 token 的上下文长度，这意味着一次交互中可以处理大量的输入信息，包括历史对话和检索到的文档内容。引用上限为 190000 token，这限定了模型在生成回复时可以引用的外部知识内容的总体大小。段落条数由检索系统决定，与引用上限是不同的量纲。模型不支持图片输入，表明其处理能力局限于文本模态。工具调用能力的提供，则允许模型在特定场景下执行外部操作或调用外部API，扩展了其功能边界。
配 PostgreSQL（pgvector） 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
PG_URL | postgresql://user:pass@host:port/dbname | 标准连接字符串，确保可访问性和权限正确性 |
ef_construction | 64–128 | 影响索引构建时的图连接数，越大则搜索质量越高，构建时间越长 |
ef_search | 40–80 | 影响查询时的邻居搜索范围，越大则召回质量越高，查询时间越长 |
m = 32 | 16–32 | HNSW 算法的层级参数，影响图的宽度，数值越大内存消耗越高但查询可能更快 |
vector_dimensions | 1536 | 向量维度需与 MiniMax 嵌入模型输出维度保持一致 |
max_connections | 100–200 | 数据库最大并发连接数，根据应用负载和服务器资源调整 |
这两者互相约束的地方
MiniMax 196K 上下文模型的上下文长度与 PostgreSQL（pgvector）检索结果的结合使用，需要仔细平衡。召回条数乘以每段内容的 token 长度，其总和不能超过模型的上下文预算。引用上限按 token 数量进行限制，而向量库返回的是独立的段落条数。这意味着，如果每段内容较长，可能在达到引用上限之前就触及了模型的总上下文限制；反之，如果每段内容较短，则可能在达到引用上限时返回了更多条段落。PostgreSQL（pgvector）的 ef_construction 和 ef_search 等索引参数调大，可以提升向量检索的准确性和召回率，这对于需要高质量引用内容的 MiniMax 模型至关重要，能够确保模型获取到更相关的上下文信息。
容易做错的三处
- 日志中出现
pq: too many connections错误：PostgreSQL 的max_connections参数设置过低，无法支撑高并发检索请求。 - 模型回复中引用内容与问题相关性差：
ef_search参数设置过小，导致 pgvector 检索时未能充分搜索邻居，召回质量不佳。 - 向量搜索响应时间过长：
ef_construction参数设置过高，导致索引构建过于耗时，或者硬件资源不足以支撑高负载查询。
怎么确认配好了
- 模拟高并发检索请求，观察 PostgreSQL 数据库的连接数和 CPU 利用率，确保在可接受范围内。
- 对比不同
ef_search参数设置下，模型引用内容的准确性和相关性，找到一个平衡点。 - 在实际运行环境中，通过监控工具观察 pgvector 索引的查询延迟，确保满足业务响应时间要求。
- 构造包含长文本的测试用例，验证模型在引用上限附近的处理行为，确认不会因上下文溢出而中断。