这一档模型的参数意味着什么
ChatGLM 提供的上下文长度 200000 意味着模型单次请求可处理的文本量上限极高，能够容纳大量召回内容或长篇文档。引用上限 200000 进一步强调了其处理大规模知识库引用的能力。此档模型未标注单次最大输出，通常需要根据实际应用场景进行经验性测试。支持工具调用 true 表示可以与外部系统进行交互，执行特定功能，扩展了 Agent 的能力边界。不支持图片输入 false 则表明此模型不具备多模态理解能力，无法直接处理图像信息。
配 openGauss 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OPENGAUSS_URL | postgresql://user:password@host:port/database | FastGPT 连接 openGauss 数据库的标准连接字符串格式。 |
ef_construction | 128 | 影响 HNSW 索引构建质量与速度，128 是一个平衡性能与召回率的常用起点值。 |
ef_search | 64 | 影响 HNSW 搜索时的召回率，通常 ef_search ≥ k（召回条数），这里取 64 以保证查询效率。 |
m | 32 | HNSW 索引中每个节点的最大连接数，32 在多数场景下能提供良好的查询性能。 |
| 召回条数 | 前 5 条 | 结合模型上下文长度与单段文本长度，5 条通常能覆盖核心信息且不溢出。 |
| 单段文本长度 | 800–1200 字符 | 考虑模型对长文本的理解能力及上下文窗口的有效利用，避免过短或过长。 |
这两者互相约束的地方
ChatGLM 200K 上下文模型与 openGauss 向量库的配合，核心在于确保召回内容在模型处理能力范围内。召回条数与每段文本长度的乘积，是决定是否超出模型上下文预算的关键。例如，如果每段文本平均 1000 字符，召回 150 条，总长度将达到 150000 字符，仍在 200000 上下文长度内。模型引用上限 200000 与向量库实际返回的条数，取两者中较小者生效。这意味着即使 openGauss 配置为返回更多结果，模型也只会处理其引用上限内的条目。调整 openGauss 的索引参数，如增大 ef_construction 或 m，可以提升向量检索的精度和召回率。对于此档模型而言，更精确的召回意味着输入给模型的内容质量更高，有助于模型生成更准确的回复。但同时，索引构建时间与存储空间也会相应增加，需要在运维中权衡。
容易做错的三处
- 日志显示
context_length_exceeded错误：原因在于召回的文本总长度加上 Prompt 模板内容超出了模型的 200000 上下文限制。 - 模型回答缺乏相关性，但向量库返回了大量结果：原因可能是
ef_search参数设置过低，导致向量库在查询时未能充分探索近邻，从而影响了召回质量。 - 知识库检索结果条数与预期不符：原因可能是模型配置的引用上限小于向量库实际返回的条数，模型侧进行了截断。
怎么确认配好了
- 在 FastGPT 界面测试一个典型问题，检查模型返回的引用段落数量，并与配置的召回条数进行比对，确认符合预期。
- 通过 FastGPT 的调试功能，查看发送给模型的实际 Prompt 内容，确保召回的文本片段完整且未被截断，总长度在模型上下文限制内。
- 在 openGauss 数据库中，通过 SQL 查询
pg_stat_statements或pg_stat_activity，观察向量查询的执行时间与资源消耗，确认在可接受范围内，为后续的性能基线设定提供依据。