这一档模型的参数意味着什么
AntLing 64K 上下文模型（Ming-lite-omni）的上下文长度为 64000 token，这决定了模型在单次交互中能处理的总信息量。引用上限 60000 token 意味着模型在生成回复时，用于引用的召回内容合计不能超过这个预算。段落条数由向量库检索结果决定，与引用上限是两个独立的量。图片输入为 true 允许模型处理图像信息，工具调用为 false 则表示模型不具备主动使用外部工具的能力，所有业务逻辑需通过系统指令或前置处理完成。
配 openGauss 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OPENGAUSS_URL | postgresql://user:password@host:port/database | FastGPT 连接 openGauss 数据库的必要凭证，需包含完整的连接信息。 |
ef_construction | 100–200 | HNSW 索引构建参数，影响索引质量和构建速度。高值提升召回精度，但会增加索引时间。 |
ef_search | 60–120 | HNSW 索引查询参数，影响检索精度和查询速度。高值提升召回精度，但会增加查询时间。 |
m | 32 | HNSW 索引图层连接数参数，影响索引结构紧密程度。过低可能导致召回质量下降，过高增加存储和计算开销。 |
| 召回条数 | 前 5–10 条 | 结合模型上下文长度和平均段落长度，控制召回内容总量，避免超出模型预算。 |
这两者互相约束的地方
模型上下文长度与向量召回内容之间存在直接制约。向量库检索出的召回条数乘以每段平均长度，其总和必须控制在 64000 token 的上下文长度之内，以确保模型能够完整处理所有输入。引用上限 60000 token 是对引用内容总 token 量的预算，向量库返回的则是按条数计量。当每段召回内容较短时，可能在达到引用上限前就触及了召回条数限制；反之，若每段内容较长，则可能在召回条数不多时就已达到引用上限。openGauss 的 ef_construction 和 ef_search 参数调大，会提升召回内容的质量和相关性，这意味着模型在处理相同数量的召回条目时，更有可能获得高质量的输入，从而可能在更少的召回条数下达到引用上限，但也可能增加检索耗时。
容易做错的三处
- 日志显示
Context window exceeded，原因是召回内容总长度加上用户输入超出模型 64000 token 上下文限制。 - 界面返回的回答内容过短或不完整，原因是引用内容总 token 量超过 60000 的引用上限，导致模型无法引用所有相关信息。
- 检索速度明显变慢，原因是 openGauss 的
ef_search参数设置过高，导致查询时计算量大幅增加。
怎么确认配好了
- 执行一次包含长文本的问答，检查模型返回的回答内容是否充分引用了召回信息，并核对日志中无上下文超限提示。
- 通过 FastGPT 的调试界面，查看单次问答中实际引用的 token 数量，确保其接近但未超过 60000 的引用上限。
- 模拟高并发场景，观察 openGauss 的查询响应时间，并与基准测试结果进行对比，确定
ef_search参数的合理性。 - 调整召回条数并多次测试，验证在不同召回条数下，模型回答质量与响应速度的平衡点。