这一档模型的参数意味着什么
Groq 提供的模型，其上下文长度高达 196608 token，这意味着在单次请求中可以处理极长的输入内容，为复杂的知识召回和多轮对话提供了充足的空间。引用上限 190000 token 明确了知识库召回内容可占据的最大token量。模型支持工具调用功能，允许其与外部系统进行交互，执行特定任务，从而扩展其能力边界。当前版本不支持图片输入，因此在设计多模态应用时需要考虑其他方案。单次最大输出未标注，但通常足以应对常规对话和总结任务。
配 PostgreSQL（pgvector） 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
PG_URL | postgresql://user:password@host:port/database | FastGPT 连接 PostgreSQL 实例的通用格式，确保数据库可访问。 |
ef_construction | 64 | HNSW 索引构建参数，影响索引质量与构建速度。较低值可加快索引构建，但可能牺牲召回精度。 |
ef_search | 30 | HNSW 索引查询参数，影响查询召回精度与速度。较高值可提升召回精度，但会增加查询延迟。 |
m | 32 | HNSW 索引层数参数，影响索引内存占用与查询性能。适中值可在内存与性能间取得平衡。 |
vector_ip_ops | true | 启用向量内积操作，与模型的向量嵌入方式匹配，提高相似度计算的准确性。 |
这两者互相约束的地方
模型的上下文长度与 PostgreSQL（pgvector） 的召回结果紧密相关。召回条数与每段长度的乘积必须小于模型的 196608 token 上下文长度，以避免截断或超限错误。引用上限 190000 token 进一步约束了知识库内容的实际可用量，即使向量库返回了大量结果，最终送达模型的引用内容也受此限制。当 PostgreSQL（pgvector） 的 ef_search 参数调大时，虽然可能提高召回精度，但也会增加查询延迟。对于 Groq 这种追求极致推理速度的模型，过高的向量检索延迟可能会抵消其计算优势，导致整体响应时间不理想。因此，需要在召回精度与查询速度之间找到一个平衡点。
容易做错的三处
- 日志中出现
Context window exceeded错误，原因通常是召回的知识段落总长度超过了模型的上下文长度。 - 界面显示知识库引用为空，但查询结果实际存在，原因是引用上限设置过低或召回条数过多导致引用截断。
- 查询响应时间显著增加，原因是
ef_search或ef_construction参数设置过高，导致向量索引查询或构建耗时过长。
怎么确认配好了
- 执行一次包含知识库查询的对话，检查日志中是否有
Context window exceeded错误。 - 在 FastGPT 界面上观察知识库引用是否正常显示，并检查引用内容是否完整。
- 通过 FastGPT 的调试接口，记录并分析不同查询条件下的端到端响应时间，与基准值进行比较。
- 模拟高并发请求，观察 PostgreSQL（pgvector） 的资源占用情况和查询延迟，确保系统在高负载下表现稳定。