这一档模型的参数意味着什么
AntLing 这一档模型，包含 Ring-1T 和 Ring-flash-2.0。其 128000 的上下文长度，决定了单次请求中模型能够处理的输入信息总量，包括指令、历史对话和检索到的知识片段。引用上限 120000 意味着在 RAG 场景下，用于支撑回答的知识片段总字符数不应超过此值。此档模型不支持图片输入和工具调用，因此基于这些功能的 RAG 链路或 Agent 流程将无法执行。单次最大输出未标注，通常需要通过实际测试或查阅模型文档来确定其生成回答的长度上限。
配 openGauss 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OPENGAUSS_URL | postgresql://user:password@host:port/database | FastGPT 连接 openGauss 数据库的通用格式。 |
ef_construction | 128 | 影响索引构建时的图拓扑结构，数值越大，索引质量越高，召回准确度提升，但构建时间增加。 |
ef_search | 64 | 影响查询时的邻居搜索范围，数值越大，召回率越高，但查询延迟增加。 |
m = 32 | 32 | HNSW 图中每个节点的最大连接数，影响索引的内存占用和查询性能。 |
| 召回条数 | 10-15 条 | 在 128K 上下文长度下，为确保模型接收到足够信息，同时避免信息冗余。 |
| 单段字符数 | 800-1200 字符 | 结合模型引用上限与召回条数，平衡信息颗粒度和模型处理效率。 |
这两者互相约束的地方
AntLing 模型的 128K 上下文长度是其处理能力的上限。在 RAG 场景中，召回条数与每段知识的字符数直接决定了模型输入总长度。例如，如果召回 15 条，每条 1000 字符，总计 15000 字符，这远低于 128000 的上下文上限，确保了模型有足够的空间处理指令和生成回复。引用上限 120000 则进一步约束了实际用于引用的知识片段总字符数。向量库 ef_construction 和 ef_search 参数的调整，直接影响召回的准确性和效率。当这些参数调大以提高召回质量时，虽然可能增加 openGauss 的计算负担，但能为 AntLing 模型提供更相关、更准确的输入，从而可能提高模型的回答质量，减少幻觉。
容易做错的三处
- 现象：RAG 模式下模型回答内容空泛或与知识库无关。原因：openGauss
ef_search参数设置过低，导致召回的向量与查询向量匹配度不足。 - 现象：FastGPT 界面显示“上下文长度超出限制”错误。原因：知识库召回条数与单段字符数之积，加上指令和历史对话长度，超过了 AntLing 模型的 128000 上下文长度。
- 现象：知识库检索时响应时间过长。原因：openGauss 的
ef_construction或m参数设置过大，导致索引构建或查询时的计算量过高。
怎么确认配好了
- 检查 FastGPT 系统日志，确认 openGauss 连接
OPENGAUSS_URL是否成功建立，无连接失败或超时报错。 - 通过 FastGPT 的调试接口，模拟一次 RAG 查询，观察返回的知识片段数量和内容，确保与预期召回条数和相关性一致。
- 在知识库中上传大量文档后，监控 openGauss 数据库的 CPU 和内存使用情况，确认
ef_construction和m参数设置下的资源消耗在可接受范围内。 - 执行多次 RAG 查询，对比不同
ef_search值下的召回准确率和查询延迟，以确定满足业务需求的平衡点。