展开本页目录
开始前准备什么
- 记录版本，已有管理员权限和可用 Chat 连接。
- 准备独立 Knowledge 与虚构测试资料。
- 知道自己的 Embedding Provider 与向量库位置，先保留可用配置。
- 连接 Chat
- 配置 Embedding
- 导入与索引
- 核对召回
- 验证引用与拒答
虚构商品与规则，带固定来源编号。
3 个可回答问题与 1 个无答案问题。
填写实际答案与来源，没有预填成功结果。
检查固定事实、引用与拒答；没有 API 请求。
先确认 Chat，再进入 Documents
Verify Connection 主要检查 /models，不能代替 Chat 或 RAG。保存连接也不等于已验证。列表失败时核对准确 ID 与 Key 权限，再检查具体型号请求。
| 位置 | 填写 / 操作 | 通过标准 |
|---|---|---|
| Admin → Connections → OpenAI | URL=https://api.apizt.com/v1；自己的 Key | 准确型号的实际 Chat 成功 |
| Advanced → Model IDs | 必要时只加入目标型号 ID | 列表可见，普通用户有权限 |
| Admin → Documents → Embedding | 已验证的本地或专用远程向量服务 | 短文本向量结果与维度正确 |
| Knowledge 文档处理 | 等待索引完成 | 有状态与可查看的召回文本 |
- 位置
- Admin → Connections → OpenAI
- 填写 / 操作
- URL=https://api.apizt.com/v1；自己的 Key
- 通过标准
- 准确型号的实际 Chat 成功
- 位置
- Advanced → Model IDs
- 填写 / 操作
- 必要时只加入目标型号 ID
- 通过标准
- 列表可见，普通用户有权限
- 位置
- Admin → Documents → Embedding
- 填写 / 操作
- 已验证的本地或专用远程向量服务
- 通过标准
- 短文本向量结果与维度正确
- 位置
- Knowledge 文档处理
- 填写 / 操作
- 等待索引完成
- 通过标准
- 有状态与可查看的召回文本
本站绘制的内容说明图：官方截图是 MiniMax-M2.1 演示，只用于 URL、Auth、Model IDs 字段位置；接入时使用本页地址和准确 ID。
直接对应 Admin Connections 的 URL/Auth/Model IDs 配置；官方 MiniMax-M2.1 不是 apizt 型号或本次成功记录。
三层服务，不共用一个型号
Chat 组织答案，Embedding 将文档和问题变成向量，Reranker 对候选片段重新排序。可由不同服务提供，端点与能力分别验收。
官方说明默认 RAG 把取回的文本放入模型输入，不会直接把整份文件转发给模型原生文件 API。型号支持 PDF 输入，也不代表当前 RAG 自动使用该入口。
| 层 | 首版建议 | 远程接入注意 |
|---|---|---|
| Chat | 已验证的兼容文本型号 | 核对 Chat 路径和模型协议 |
| Embedding | 保留已可用的本地向量模型 | 确认 /v1/embeddings、ID、维度和批量 |
| Reranker | 首轮关闭可选重排 | 专用 URL、模型和鉴权，不填 Chat URL |
- 层
- Chat
- 首版建议
- 已验证的兼容文本型号
- 远程接入注意
- 核对 Chat 路径和模型协议
- 层
- Embedding
- 首版建议
- 保留已可用的本地向量模型
- 远程接入注意
- 确认 /v1/embeddings、ID、维度和批量
- 层
- Reranker
- 首版建议
- 首轮关闭可选重排
- 远程接入注意
- 专用 URL、模型和鉴权，不填 Chat URL
更换向量模型后，重建已有文档
- 文件上传完成与索引完成分开检查，等处理状态结束。
- 更换 Embedding 型号或维度后重新索引；文档与问题必须使用兼容向量配置。
- 修改 chunk size 或 overlap 后，旧文档不会自动全部重新切块，记录重建情况。
- 先看候选原文，再调整 Top K；增加片段数量也增加上下文，不保证更准确。
固定四问：先看检索，再看回答
把 rag-fixture.md 放入独立 Knowledge，索引完成后附到测试会话。一次问一条，保存原文命中和真实答案。灯座 14 厘米、退款 9 个自然日、水杯 620 毫升且不可微波，分别来自三段虚构资料；未知地址应说明资料中未提供。
将真实结果整理到空模板，另存 rag-results.json。答案正确而来源不对也不能通过，显示文件引用后还要定位对应段落。
- 检查器不访问模型或知识库，仅检查整理后的固定事实与编号。
- 新会话复跑未知问题，人工检查否定关系、来源与是否编造。
固定事实离线核对
python3 check-rag-results.py rag-results.json
本站绘制的内容说明图：本页 fixture 的事实专用于离线核对；正确答案但引用无关段落也不能通过。
无引用、乱引用与 429 的定位表
Chat、标题生成、向量和重排可能是不同请求。导入超时先查已处理文档，生成未知结果不要自动重复提交。
| 现象 | 检查证据 | 建议动作 |
|---|---|---|
| 上传后查不到 | 处理状态、Knowledge 关联与片段 | 完成索引并附到正确会话 |
| 有召回但答非所问 | 进入模型的上下文与 RAG Prompt | 保持同问题，单独调整提示 |
| 更换向量后召回差 | 旧索引与新查询的模型/维度 | 重建独立测试索引 |
| 导入遇到 429 | 向量并发、批量和已处理记录 | 降低并发，查状态后补失败项 |
| 重排报 400 / 404 | 专用 URL、模型与请求协议 | 先关闭可选重排检查基础链路 |
- 现象
- 上传后查不到
- 检查证据
- 处理状态、Knowledge 关联与片段
- 建议动作
- 完成索引并附到正确会话
- 现象
- 有召回但答非所问
- 检查证据
- 进入模型的上下文与 RAG Prompt
- 建议动作
- 保持同问题，单独调整提示
- 现象
- 更换向量后召回差
- 检查证据
- 旧索引与新查询的模型/维度
- 建议动作
- 重建独立测试索引
- 现象
- 导入遇到 429
- 检查证据
- 向量并发、批量和已处理记录
- 建议动作
- 降低并发，查状态后补失败项
- 现象
- 重排报 400 / 404
- 检查证据
- 专用 URL、模型与请求协议
- 建议动作
- 先关闭可选重排检查基础链路
怎样确认已经完成
- Chat、索引与检索有各自实际记录。
- 变更 Embedding 后完成重建，向量配置一致。
- 四问事实、来源与拒答正确。
- 普通用户权限和完整请求费用分别核对。
常见问题
RAG 必须通过 apizt 做 Embedding 吗？
不用。可以保留已可用的本地向量模型，由 apizt 提供 Chat。远程 Embedding 和重排按具体端点、型号与权限确认。
为什么换模型后需要重新索引？
不同向量模型或维度不能直接混用，问题和文档要使用兼容配置。官方要求切换 Embedding 后重建已有文档。
开 Hybrid Search 就一定准确吗？
需要自己的语料和问题验证。重排、阈值与 Top K 都影响召回和上下文，先通过基础链路再逐项调整。