这一档模型的参数意味着什么
Hunyuan 128K 上下文模型档位中的模型，其 上下文长度 128000 决定了单次请求中可输入的最大 Token 数量，这直接影响了知识库召回内容的总量。引用上限 128000 意味着在RAG（检索增强生成）流程中，模型能够处理的引用段落总 Token 数的理论上限。图片输入 false 和 工具调用 false 表明该档模型不具备处理图像输入和执行外部工具的能力，因此在构建 Agent 流程时，需要将这两类能力从设计中排除。单次最大输出 未标注，通常意味着需要通过实验确定其合理输出长度，以避免截断或不必要的资源消耗。
配 openGauss 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OPENGAUSS_URL | postgresql://user:password@host:port/database | FastGPT 连接 openGauss 数据库的标准连接字符串格式。 |
ef_construction | 80 | 控制 HNSW 索引构建时的邻居搜索范围，提高召回质量与索引构建时间之间的平衡。 |
ef_search | 60 | 控制 HNSW 查询时的邻居搜索范围，提高查询召回率，兼顾查询速度。 |
m | 32 | HNSW 索引中每个节点的最大连接数，影响索引的内存占用和查询性能。 |
| 召回条数 | 10-20 条 | 在 128K 上下文限制下，为模型留出充足的思考空间和生成长度。 |
| 单条召回长度 | 500-1000 字符 | 兼顾信息密度与上下文总量，避免单条过长导致无效信息过多。 |
这两者互相约束的地方
Hunyuan 128K 上下文模型与 openGauss 向量库的配合，核心在于对上下文预算的精确管理。召回条数与每段长度的乘积，必须严格控制在模型 上下文长度 128000 的预算之内。超出此限制，模型将无法处理全部输入，导致信息丢失或回答不完整。引用上限 128000 设定了模型能接受的引用内容总 Token 数的上限，而 openGauss 向量库的返回条数则直接决定了实际提供给模型的引用段落数量。两者取其小者作为最终生效的引用段落数量。当 openGauss 的 ef_construction 或 ef_search 等索引参数调大时，通常意味着向量召回的准确性会提升，但同时也会增加索引构建时间或查询延时，这需要在保证模型性能的前提下进行权衡。
容易做错的三处
- 日志显示
Context window exceeded：这是由于召回的总 Token 数（召回条数 × 单条召回长度）超过了模型上下文长度 128000的限制。 - 模型回答缺乏相关性或信息不足：可能原因是在 openGauss 中
ef_search参数设置过低，导致召回的向量段落相关性不足。 - 知识库查询耗时过长，导致请求超时：原因可能是 openGauss 的
ef_construction或m参数设置过大，导致索引构建或查询开销过高。
怎么确认配好了
- 在 FastGPT 知识库管理界面，调整单条召回长度和召回条数，观察模型在不同设置下的回答质量与上下文Token消耗情况，确定一个符合业务需求的阈值。
- 通过 FastGPT 的调试功能，观察模型实际接收到的引用内容，确认其与 openGauss 返回的向量段落一致，且未被截断。
- 在 openGauss 数据库中，执行 HNSW 索引的查询语句，通过
EXPLAIN ANALYZE分析查询计划和执行时间，确保查询性能符合预期，并根据实际负载调整ef_search参数。