这一档模型的参数意味着什么
Hunyuan 28K 上下文模型，其 28000 的上下文长度，决定了单次请求中可输入的最大文本量，直接影响知识召回内容的丰富程度。模型未标注单次最大输出，意味着在实际应用中，需要通过实验来确定其稳定输出范围。28000 的引用上限，设定了模型在生成回复时可引用的知识段落总长度的天花板。此外，图片输入 false 和 工具调用 false 明确了该模型不支持图像理解和外部工具集成，因此在设计 RAG 链路时，无需考虑这些功能。
配 PostgreSQL（pgvector） 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
PG_URL | postgresql://user:password@host:port/database | 数据库连接字符串，确保可访问性和权限正确性，是所有操作的基础。 |
ef_construction | 80–120 | 控制索引构建时的邻居数量，值越大索引质量越高，召回准确性越好，但构建时间增加。 |
ef_search | 60–100 | 控制查询时的邻居数量，值越大召回结果越全面，召回率越高，但查询耗时增加。 |
m | 32 | HNSW 算法中每个节点的最大连接数，影响索引结构和查询效率，m = 32 是一个常见且均衡的选择。 |
vector_ip_ops | true | 启用内积距离计算，适用于需要衡量向量相似度的场景，符合语义搜索需求。 |
recall_k | 5 | 向量库查询返回的 top-k 向量数量，直接影响模型可引用的段落数量。 |
这两者互相约束的地方
Hunyuan 28K 上下文模型与 PostgreSQL（pgvector） 的结合，核心在于如何有效管理上下文预算和召回效率。模型 28000 的上下文长度是硬性约束，这意味着召回条数与每段召回内容的长度乘积，必须严格控制在此范围内。如果 recall_k 设定的召回条数乘以每条文档的平均字符数超过此限制，模型将无法处理全部输入。模型的引用上限 28000 限制了最终可被引用的知识段落总长度，而 recall_k 设定的向量库返回条数则决定了候选引用的上限。在实际应用中，recall_k 需小于等于引用上限所能容纳的最大段落数。当 ef_construction 或 ef_search 等索引参数调大时，虽然能提升召回的准确性和全面性，但会增加向量索引的构建时间和查询延迟，对于模型响应速度有直接影响。
容易做错的三处
- 日志中出现
ERROR: value too long for type character varying(...)：尝试插入的向量或元数据字符串长度超过了pgvector列的定义长度。 - 模型回复中知识点缺失，但知识库中存在相关内容：
ef_search值设置过低，导致向量库召回不足或recall_k设置过小。 - 查询响应时间过长，模型等待超时：
ef_search或ef_construction值设置过高，导致向量索引查询或构建效率低下。
怎么确认配好了
- 执行一次包含复杂查询的 RAG 流程，检查模型响应中是否准确引用了知识库中的相关段落，并核对引用原文。
- 监控 PostgreSQL（pgvector） 的慢查询日志，分析
ef_search和ef_construction参数对查询耗时的影响，并根据实际负载调整。 - 在 FastGPT 界面上，检查知识库连接状态是否正常，无
PG_URL连接错误提示。 - 通过向量相似度查询工具，手动查询几个向量，确认
pgvector返回的 top-k 结果与预期语义相关度一致，以验证m和ef_search的有效性。