这一档模型的参数意味着什么
DeepSeek 提供的这一档模型，其 1000000 的上下文长度为处理大量信息提供了基础，意味着单次请求中可以包含更多的历史对话或检索到的知识内容。960000 的引用上限则直接限定了知识库召回内容在模型输入中的最大字符数，这决定了单次 RAG 流程中能有效利用的知识片段总量。模型支持工具调用，使得其能够与外部系统进行交互，执行特定任务。不支持图片输入，表明此模型主要处理文本信息，不适用于多模态场景。单次最大输出未标注，则需要通过实际测试来确定其生成回复的长度限制。
配 PostgreSQL（pgvector） 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
PG_URL | postgresql://user:password@host:port/database | 连接数据库的必要参数，确保 FastGPT 能正确访问 PostgreSQL 实例。 |
ef_construction | 100 | 构建 HNSW 索引时的邻居数量，影响索引质量与构建速度。较高的值能提升召回准确率，但会增加索引构建时间。 |
ef_search | 60 | 查询 HNSW 索引时的搜索路径长度，影响搜索速度与召回准确率。较高的值能提升召回准确率，但会增加查询延迟。 |
m | 32 | HNSW 索引中每个节点的最大连接数，影响索引大小和搜索性能。此值通常在 16-64 之间。 |
| 向量维度 | 1024 或模型输出维度 | 向量维度需与 DeepSeek 模型嵌入向量的维度保持一致，确保数据匹配。 |
vector_ip_ops | true | 使用内积（Inner Product）作为相似度度量，通常适用于文本嵌入向量。 |
这两者互相约束的地方
在 DeepSeek 1000K 上下文模型与 PostgreSQL（pgvector）的组合中，召回条数与每段知识长度的乘积必须严格控制在模型的 1000000 上下文长度预算之内。同时，知识库召回的总字符数不能超过模型 960000 的引用上限。这意味着即使 pgvector 返回了大量高相关的段落，最终输入给模型的也会受到引用上限的约束。如果 pgvector 的查询返回条数超过了系统配置的限制，或超过了模型实际能处理的有效引用上限，多余的段落将被截断或忽略。此外，调整 pgvector 的 ef_construction 或 ef_search 等索引参数，虽然可以优化向量搜索的准确性或速度，但其效果最终仍受限于模型本身的上下文处理能力和引用上限。例如，即使 pgvector 能快速召回更多高质量段落，模型也只能处理其引用上限内的部分。
容易做错的三处
- 日志中出现
ERROR: value too long for type character varying(...)：原因通常是知识库段落分块过大，超过了 PostgreSQL 对应字段的存储限制。 - 模型回复中未包含关键信息，但知识库中存在：原因可能是 pgvector 的
ef_search值过低，导致召回的段落相关性不足或数量不够，未能命中关键信息。 - API 请求返回
413 Request Entity Too Large：原因可能是知识库召回内容加上提示词的总长度超过了模型或网关的请求体大小限制。
怎么确认配好了
- 在 FastGPT 知识库管理界面，上传测试文档并进行分段预览，确认分段策略是否符合预期。
- 执行一次包含知识库检索的对话，观察 FastGPT 后台日志，确认 pgvector 的查询语句是否正常执行，以及返回的向量 ID 是否与预期一致。
- 通过 FastGPT 的调试模式，查看模型实际接收到的上下文内容，检查召回的知识段落数量和总字符数是否在 960000 的引用上限内。
- 使用不同的查询语句，反复测试知识库召回效果，并根据实际业务场景调整
ef_construction和ef_search参数，直到召回结果满足业务需求。