这一档模型的参数意味着什么
Doubao 1024K 上下文模型具备 1024000 的上下文长度，这意味着单次请求中可承载的输入信息量极大，包括用户查询、历史对话、以及从知识库召回的内容。引用上限 1024000 进一步强调了模型处理大量引用段落的能力，为复杂的知识问答提供了基础。图片输入能力支持多模态场景，允许将图像作为输入的一部分进行理解与处理。工具调用功能则赋予模型与外部系统交互的能力，使其能够执行特定动作或获取实时信息，扩展了应用边界。这些参数共同决定了系统在处理大规模、多模态、需要外部协作的任务时的潜力和约束。
配 PostgreSQL（pgvector） 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
PG_URL | postgresql://user:password@host:port/database | 连接 PostgreSQL 数据库实例的必要凭证，确保 FastGPT 能访问向量存储。 |
ef_construction | 800 | 控制 HNSW 索引构建时的邻居搜索范围，数值越大，索引质量越高，召回准确率提升，但构建时间增加。 |
ef_search | 200 | 控制 HNSW 索引查询时的邻居搜索范围，数值越大，召回准确率越高，但查询耗时增加。 |
m = 32 | 32 | HNSW 图中每个节点的最大连接数，影响索引结构密度和查询性能，32 是常见的平衡值。 |
vector_ip_ops | cosine 或 inner_product | 向量相似度计算方法，需与模型嵌入向量的归一化方式匹配，以确保相似度计算的准确性。 |
这两者互相约束的地方
Doubao 1024K 上下文模型的巨大上下文窗口为知识召回提供了广阔空间，但实际召回条数和每段长度仍受限于此。系统在召回时，应确保所有召回段落的总长度，加上用户查询和系统提示词，不超过 1024000 的上下文限制。引用上限 1024000 与向量库返回条数之间存在联动：尽管模型支持大量引用，但最终传递给模型的条数应在向量库配置的召回条数与引用上限中取最小值。PostgreSQL（pgvector）的 ef_construction 和 ef_search 等索引参数调大，能够提升向量召回的准确率和召回数量，这意味着模型能获得更精准、更丰富的上下文信息，从而提高问答质量。然而，参数过高会增加向量搜索耗时，需要根据实际业务响应时间要求进行权衡。
容易做错的三处
- 日志显示“上下文长度超出限制”，原因是召回的段落总长度加上查询文本超出了模型的 1024000 上下文上限。
- 返回结果中知识引用段落不足，原因是向量库
limit参数设置过低或ef_search值太小导致召回不足。 - 查询响应时间过长，原因是 PostgreSQL（pgvector）的
ef_search或ef_construction参数设置过大，导致向量检索计算量剧增。
怎么确认配好了
- 执行一次包含大量知识引用的查询，检查日志中模型输入总长度是否在 1024000 上下文限制内。
- 在 FastGPT 界面或数据库日志中，确认 PostgreSQL（pgvector）的
ef_search和ef_construction参数是否已按预期生效。 - 进行多轮对话测试，观察系统返回的知识引用数量是否符合预期召回条数，并与模型引用上限进行比对。
- 通过压力测试工具，评估在高并发场景下，包含向量检索的查询响应时间是否满足业务 SLA 要求。