这一档模型的参数意味着什么
mistral-small-latest 模型档位具有 32000 的上下文长度，这意味着在单次对话中，模型可以处理的输入信息总量（包括用户查询、历史对话、系统指令和检索到的知识）上限为 32000 token。单次最大输出长度未标注，通常表示模型会根据输入和上下文生成尽可能完整的回答。引用上限为 32000，这直接影响到知识库检索结果可以提供的最大 token 数量，是控制 RAG 召回内容规模的关键指标。模型不支持图片输入，因此无法处理多模态的视觉信息。支持工具调用，允许模型通过外部工具执行特定任务，扩展其能力边界。
配 openGauss 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OPENGAUSS_URL | postgresql://user:password@host:port/database | FastGPT 连接 openGauss 数据库的通用格式 |
ef_construction | 100–200 | 构建 HNSW 索引时，控制搜索效率与索引质量的平衡，影响构建速度和查询精度 |
ef_search | 80–150 | 查询 HNSW 索引时，控制搜索精度与查询速度的平衡，影响召回率 |
m | 32 | HNSW 图层中每个节点的最大邻居数量，影响内存占用和查询性能，此处为 openGauss 默认值 |
| 检索条数 | 5–10 | 结合模型引用上限，避免单次召回内容过多溢出上下文 |
| 分段长度 | 500–800 字符 | 确保知识库每个段落信息完整，且能被模型有效处理，避免单段过长或过短 |
这两者互相约束的地方
模型 32000 token 的上下文长度是硬性限制，知识库召回的“召回条数 × 每段长度”之和必须严格控制在此预算内，否则会导致部分信息被截断或模型报错。mistral-small-latest 的引用上限与上下文长度相同，均为 32000 token，这表明在理论上，知识库可以填满整个上下文窗口。然而，实际应用中，向量库的返回条数（即上述表格中的“检索条数”）通常会更小，因为它还需要为用户输入、历史对话和模型生成预留空间。当 openGauss 的 ef_construction 或 ef_search 参数调大时，通常会提高向量搜索的召回精度，这意味着模型能获得更相关的知识段落，但同时也会增加索引构建时间或查询延时，需要权衡。
容易做错的三处
- 日志显示
context window exceeded：知识库召回内容加上用户输入超过了模型 32000 token 的上下文限制。 - 检索结果相关性差，模型回答质量低：
ef_search参数设置过低，导致 openGauss 在向量搜索时未能找到最相关的知识段落。 - 知识库导入耗时过长或索引构建失败：
ef_construction参数设置过高，增加了 openGauss 构建 HNSW 索引的计算负担。
怎么确认配好了
- 通过 FastGPT 平台查看知识库导入状态，确认所有文档分段均成功入库 openGauss，且无报错信息。
- 针对特定查询，观察 FastGPT 的 RAG 召回结果，确认返回的知识段落数量与预期“检索条数”一致，且内容与查询高度相关。
- 监控 FastGPT 与 openGauss 的连接状态，确保
OPENGAUSS_URL配置正确，连接稳定无中断，可通过数据库日志确认。 - 执行多次典型查询，对比模型回答与预期答案，评估回答的准确性和完整性，并检查是否有因上下文不足导致的回答截断现象。