这一档模型的参数意味着什么
OpenAI 的这一档模型，如 gpt-4o-mini 和 gpt-4o，提供了 128000 tokens 的上下文长度，这意味着模型在单次交互中能够处理和理解的文本量非常大，可以直接输入大量召回内容。引用上限 60000 tokens 划定了知识库引用段落总长度的天花板，超出此限制的引用内容将不被模型考虑。图片输入能力允许模型直接处理图像信息，拓宽了应用场景，例如图像内容的问答或分析。工具调用能力则使得模型能够与外部系统或自定义工具进行交互，以执行特定任务或获取实时信息。
配 PostgreSQL（pgvector） 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
PG_URL | postgresql://user:password@host:port/database | FastGPT 连接 PostgreSQL 数据库的标准格式，确保数据库可访问。 |
ef_construction | 64 | HNSW 索引构建参数，影响索引质量和构建时间。此值在 16 到 128 之间通常能平衡性能与精度。 |
ef_search | 32 | HNSW 索引搜索参数，影响搜索召回率和查询速度。此值应大于或等于 k (召回条数)，并通常在 16 到 64 之间。 |
m | 32 | HNSW 索引的每层最大邻居数。此值越大，索引占用空间越大，查询精度越高，但构建时间也越长。 |
vector_ip_ops | true | pgvector 默认使用欧氏距离，设置此项为 true 启用内积距离（inner product），更适用于某些嵌入模型。 |
search_limit | 前 5-10 条 | 向量搜索返回的条目数量，应根据模型上下文长度和单段文本长度综合考量。 |
这两者互相约束的地方
模型的 128000 tokens 上下文长度是核心约束。在 RAG 场景中，这意味着召回的文本条数乘以每段文本的平均长度，其总和不能超过这个上限。如果单次召回的文本总量超出，模型将无法完全处理所有信息。引用上限 60000 tokens 进一步限制了实际可以被模型引用的知识库内容总量，即使向量库返回了更多条目，也只有不超过此上限的部分会被用于引用。PostgreSQL（pgvector）的 ef_construction 和 ef_search 参数调大，虽然可以提升向量搜索的召回精度，但如果导致返回的相似文本条目过多，仍然需要通过应用层的逻辑裁剪，以适配模型的引用上限和上下文窗口。因此，向量库的召回条数需要与模型的上下文容量和引用上限协同配置，避免冗余信息传输。
容易做错的三处
- 日志显示
ERROR: context window exceeded：原因在于向量库召回的文本总长度或引用段落总长度超过了模型的 128000 tokens 上下文或 60000 tokens 引用上限。 - 搜索结果的相关性不佳，但
ef_search已设为较大值：原因可能在于向量索引的m或ef_construction参数设置过低，导致索引质量本身不高，即便搜索参数调大也无法弥补。 - 查询响应时间过长，尤其在大量数据上：原因在于
ef_search值设置过大，导致向量库在查询时需要遍历更多的邻居节点，增加了计算开销。
怎么确认配好了
- 在 FastGPT 知识库测试界面，使用不同长度的查询文本进行召回测试，观察返回的文档片段数量和总长度，确保其在模型上下文和引用上限内。
- 通过 FastGPT 的模型推理日志，检查
prompt中的input_tokens数量，确保其稳定在 128000 tokens 以下，且引用部分不超过 60000 tokens。 - 使用 PostgreSQL 的
EXPLAIN ANALYZE命令对 pgvector 索引查询进行分析，确认 HNSW 索引被有效利用，且查询耗时在可接受范围内。 - 进行多轮对话测试，观察模型回答的准确性和完整性，特别关注是否能有效利用知识库中的信息，且没有出现因上下文不足导致的信息丢失。