这一档模型的参数意味着什么
hunyuan-vision 模型档位具备 6000 token 的上下文长度，决定了单次请求中可携带的全部信息量，包括用户输入、历史对话以及召回内容。虽然单次最大输出长度未明确标注，通常会受限于总上下文长度，确保模型有足够的空间生成完整回复。引用上限 4000 token 意味着在总上下文内，用于填充检索内容的预算。图片输入能力表示此模型支持多模态输入，能够处理图像信息。不具备工具调用能力，意味着此模型主要用于文本生成和理解，无法直接执行外部函数或 API。
配 openGauss 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OPENGAUSS_URL | postgresql://user:password@host:port/database | 数据库连接字符串，确保 FastGPT 能正确连接 openGauss 实例。 |
ef_construction | 100–200 | 控制 HNSW 索引构建时的邻居数量，影响索引质量与构建速度。较高的值能提升搜索准确性，但会增加索引时间。 |
ef_search | 50–100 | 控制 HNSW 搜索时的邻居数量，影响搜索召回率与查询速度。较高的值能提升召回率，但会增加查询耗时。 |
m | 32 | HNSW 索引中每个节点的最大连接数。更高的值可以改善搜索质量，但会增加内存占用和索引构建时间。 |
| 单段文本长度 | 500–800 字符 | 控制向量化切分的粒度，影响召回内容的精细程度和 token 占用。 |
这两者互相约束的地方
Hunyuan 6K 上下文模型与 openGauss 向量库的配合，核心在于如何平衡引用内容在上下文中的占比。模型的 6000 token 上下文长度是硬性限制，其中 4000 token 的引用上限为召回内容预留了预算。向量库返回的是固定数量的文档段落，而这些段落转换为 token 后，其总和必须在 4000 token 预算之内。因此，检索条数与每段文本的平均 token 数共同决定了引用内容的实际总 token 量。如果向量库返回的段落过多或每段文本过长，可能导致引用内容超过模型的 4000 token 引用上限，从而触发截断或报错。openGauss 的索引参数 ef_construction 和 ef_search 调大，可以提升检索结果的质量，从而在有限的召回条数下，提供更相关的上下文信息给模型，有助于模型更好地理解和生成回答。
容易做错的三处
- 模型返回
Context window exceeded错误：召回内容加上用户输入和历史对话的总 token 数超出了 6000 token 上下文限制。 - 召回内容明显不足或不相关：openGauss 的
ef_search参数设置过低，导致搜索召回率不佳。 - 问答结果中引用信息缺失：引用内容总 token 量超过 4000 token 引用上限，导致部分召回内容被截断未送入模型。
怎么确认配好了
- 在 FastGPT 调试界面，观察每次对话的上下文 Token 占用情况，确保引用部分 Token 未超过 4000。
- 通过 FastGPT 的检索测试功能，模拟不同查询，检查 openGauss 返回的文档段落与查询的相关性。
- 在 openGauss 数据库中，执行 SQL 查询验证
ef_construction和m等 HNSW 索引参数是否已按预期配置。 - 监控 FastGPT 请求日志，检查是否存在因上下文过长或引用超限导致的错误信息。