这一档模型的参数意味着什么
StepFun step-1-32k 模型提供了 32000 token 的上下文长度，这意味着在单次对话中，可以输入和处理的总文本量（包括用户提问、历史对话和召回的知识内容）上限为 32000 token。引用上限同为 32000 token，这决定了知识库召回内容在模型输入中所占的最大份额。模型未标注单次最大输出，因此实际输出长度受限于整体上下文长度。该模型不支持图片输入和工具调用，因此在构建 Agent 时，无需考虑多模态输入处理和外部工具集成。
配 openGauss 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OPENGAUSS_URL | postgresql://user:password@host:port/database | 连接 openGauss 数据库的必要信息，确保可达性 |
ef_construction | 80 | 控制 HNSW 索引构建时的邻居数量，影响构建质量与速度的平衡 |
ef_search | 60 | 控制 HNSW 索引查询时的邻居数量，影响召回精度与查询速度的平衡 |
m | 32 | HNSW 索引中每个节点的最大邻居数，影响索引大小和搜索性能 |
| 召回条数 | 前 5–10 条 | 考虑到模型引用上限和单条知识长度，避免上下文溢出 |
| 单条知识长度 | 500–800 字符 | 兼顾知识完整性和模型上下文预算，避免信息碎片化或冗余 |
这两者互相约束的地方
step-1-32k 模型的 32000 token 上下文长度是核心约束。知识库召回的“召回条数 × 每段长度”之和必须远小于此上限，以预留用户提问和模型回答的空间。同时，模型的引用上限为 32000 token，意味着即使 openGauss 返回了大量向量，最终能送入模型作为引用的内容总量也受此限制。openGauss 的 ef_construction 和 ef_search 参数调大，会提升召回精度，可能导致每次召回的向量数量增多或召回内容更长，这需要与模型的上下文预算进行精细匹配。如果 ef_search 过大，虽然召回质量高，但查询延迟会增加，可能导致模型等待时间过长。
容易做错的三处
- 日志显示
ERROR: relation "vectors" does not exist：原因在于OPENGAUSS_URL配置的数据库中未创建向量存储所需的表结构。 - 模型返回的回答内容简短且缺乏相关性：原因可能是 openGauss 的
ef_search参数设置过低，导致召回的知识点不精准或数量不足。 - 界面提示“上下文长度超限”：原因通常是召回条数过多或单条知识长度过长，导致送入模型的总 token 数超过了
step-1-32k的 32000 token 上限。
怎么确认配好了
- 运行一次问答，检查 FastGPT 界面中“引用”部分是否展示了相关知识段落，且内容与问题高度相关。
- 监控 openGauss 数据库的查询日志，确认向量搜索操作 (
SELECT ... FROM vectors ... ORDER BY embedding <-> query_vector LIMIT ...) 能够成功执行，且查询耗时在可接受范围内。 - 对比不同
ef_search参数下的问答质量，通过调整ef_search和召回条数，找到在准确性与响应速度之间的平衡点。