这一档模型的参数意味着什么
此档模型，如 gpt-oss-120b 和 gpt-oss-20b，具备 131000 的上下文长度，意味着单次请求中可处理的输入内容总量（包括指令、历史对话、检索结果等）非常可观。引用上限为 100000 token，专门用于限制从知识库检索并注入模型作为参考的文本预算。工具调用能力的开启，表明模型能够与外部工具进行交互，扩展其处理复杂任务的能力。图片输入为 false，表示此档模型不支持直接处理图像信息。这些参数共同定义了模型在处理长文本、RAG应用及复杂逻辑时的工程边界。
配 OceanBase 要定哪些
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
OCEANBASE_URL | jdbc:mysql://<host>:<port>/<db>?user=<user>&password=<pass> | 连接 OceanBase 数据库的 JDBC URL 格式，确保正确指向实例。 |
ef_construction | 64 | 索引构建质量与速度的平衡点，高于默认值可提升召回精度。 |
m | 16 | HNSW 算法中每个节点的最大连接数，影响召回效率与内存占用。 |
chunk_size | 800-1200 字符 | 单个文本块的理想长度，兼顾语义完整性与模型上下文利用率。 |
retrieval_limit | 5 | 每次向量检索返回的条数，与引用上限共同限制输入。 |
embedding_model | text-embedding-ada-002 | 与此档模型兼容且性能稳定的嵌入模型。 |
这两者互相约束的地方
此档模型 131000 的上下文长度为输入提供了宽裕的空间，但引用上限 100000 token 专门用于知识库检索内容。这意味着，虽然模型能处理大量信息，但从 OceanBase 检索出的内容总量不能超过此预算。向量库返回的是固定条数的文档片段，每段的实际 token 数量取决于其长度。因此，是“总引用 token 预算”先触顶，还是“检索条数”先达到上限，取决于 chunk_size 的设定。若 chunk_size 较大，即使检索条数不多，也可能迅速耗尽引用 token 预算。反之，若 chunk_size 较小，则可能需要更多检索条数才能填充引用预算。OceanBase 的 ef_construction 和 m 等索引参数调大，通常会提升检索精度，从而为模型提供更高质量的上下文，但也会增加索引构建和查询的资源消耗。
容易做错的三处
- 日志显示
Error 400: Context window exceeded：原因通常是检索出的所有段落总 token 数超出了模型的总上下文长度，或超出了引用上限。 - 模型回答缺乏相关信息，但知识库中明明有：原因可能是
retrieval_limit设置过低，导致 OceanBase 返回的有效信息不足以覆盖问题所需。 - 向量检索耗时过长，影响端到端响应速度：原因可能是
ef_construction或m值设置过高，导致 OceanBase 在查询时计算量过大。
怎么确认配好了
- 对典型业务问题进行多次提问，检查模型回答中引用的知识点是否准确且全面。
- 监控模型每次请求的实际输入 token 数量，确保检索内容加上指令和历史对话后未超过 131000 的上下文长度限制。
- 在 OceanBase 数据库中执行向量检索查询，通过
EXPLAIN命令分析查询计划，确认索引是否被有效利用。 - 在生产环境中，持续观察系统日志中是否有
Context window exceeded或其他与 token 限制相关的警告信息。