这一档模型的参数意味着什么
ERNIE-Lite-8K 模型提供了 8000 tokens 的上下文长度，这意味着在单次对话中，模型可以处理的输入信息总量（包括用户查询、历史对话和知识库召回内容）存在上限。引用上限 6000 tokens 规定了知识库内容在被模型引用时所能占据的最大上下文空间。模型未标注单次最大输出，通常需要通过实际测试来确定其输出长度的上限。该模型不具备图片输入能力，因此不支持多模态RAG链路。同时，工具调用功能缺失，意味着无法通过Function Calling等方式扩展模型能力，需要纯粹依赖文本内容进行问答。
配 openGauss 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OPENGAUSS_URL | postgresql://user:password@host:port/database | 数据库连接字符串，确保可达性与权限 |
ef_construction | 100 - 200 | 影响索引构建时的图连接数，数值越大索引质量越高，构建时间越长，用于优化召回准确性 |
ef_search | 60 - 120 | 影响查询时的图遍历范围，数值越大召回率越高，查询耗时越长，用于平衡召回与响应速度 |
m (HNSW参数) | 32 | HNSW图每层节点的最大连接数，影响索引结构与查询性能，需与 ef_construction 配合 |
chunk_size | 500 - 800 字符 | 单个知识块的文本长度，影响召回粒度与模型上下文利用率 |
top_k | 3 - 5 条 | 向量检索返回的相似度最高的文档块数量，直接影响模型可引用的信息量 |
这两者互相约束的地方
ERNIE-Lite-8K 的 8000 tokens 上下文长度是核心约束。知识库召回的 top_k 条文档块的总长度，加上用户查询和历史对话的长度，必须严格控制在 8000 tokens 以内。如果 top_k 设为 5 且每个 chunk_size 为 800 字符，那么仅知识库内容就可能占用 4000 字符，接近 6000 tokens 的引用上限。openGauss 的 ef_construction 和 ef_search 参数调高，可以提升向量检索的准确性，从而为模型提供更相关的上下文。但这也可能导致检索时间增加，间接影响整个RAG链路的响应速度。引用上限 6000 tokens 是模型对知识库内容的最大接受量，即使 openGauss 返回了更多条目，最终送入模型的知识内容也会被裁剪至此上限。因此，top_k 的设定应综合考虑 chunk_size 和模型的引用上限。
容易做错的三处
- 日志显示
Error: Context window exceeded，原因：召回内容与用户输入总长度超过了 8000 tokens 上下文限制。 - 模型回答中知识引用不足，原因：openGauss 的
top_k设置过低，或者ef_search参数太小导致召回相关性不足。 - 查询响应时间过长，原因：openGauss 的
ef_construction或ef_search参数设置过大，导致向量索引构建或查询计算量过高。
怎么确认配好了
- 执行一次包含知识库查询的对话，检查日志中模型输入 token 计数，确保其不超过 8000。
- 通过 FastGPT 界面查看模型引用内容，确认召回的知识段落数量与
top_k设置一致，且内容与问题相关。 - 使用 openGauss 客户端工具，检查
pg_stat_activity表，确认连接数和查询延迟在预期范围内，以评估ef_search参数的性能影响。 - 对不同类型的查询进行测试，观察模型回答的准确性和完整性，以此评估
ef_construction和ef_search组合参数下的召回质量。