不改用户现有系统，通过 API 调用 MBE 实现 Self-Critical Sequence 应用

本文档说明如何不修改用户现有系统，通过 HTTP API 调用 MBE，实现 Self-Critical Sequence 在业务流程（如客服系统）中的应用。

一、集成架构：外部调用模式

用户的客服系统（不改动）
        │
        │  HTTP 请求
        ▼
┌─────────────────────────────────────┐
│  MBE API 服务（独立部署）              │
│  - 专家路由 + RAG + Self-Critique     │
│  - 知识检索                           │
│  - 反馈记录                           │
└─────────────────────────────────────┘
        │
        │  JSON 响应
        ▼
用户的客服系统（只做 HTTP 调用）

原则：用户系统仅通过 HTTP 调用 MBE，不引入 MBE 代码、不改变原有业务逻辑。

二、MBE 现有可用的 API 端点

2.1 对话/问答（含 Self-Critique）

说明：专家试用接口需先通过 GET /api/experts/available 获取 expert_id，再调用 trial 接口。

请求示例（专家试用，等价于指定专家问答）：

POST /api/experts/market/{expert_id}/trial
{
  "user_input": "客户的退款问题如何解决？",
  "user_id": "cs_agent_001",
  "device_id": "cs_system"
}

响应：包含 answer、expert_name、remaining_trials 等，答案已通过 Self-Critique 验证。

请求示例（法律咨询，通用问答入口，自动路由）：

POST /api/civil-lawyer/consult
{
  "question": "客户的退款问题如何解决？",
  "context": []
}

响应：包含 answer、expert、confidence、references 等，答案已通过 Self-Critique 验证。

2.2 专家匹配（路由验证）

请求示例：

POST /admin/knowledge/expert/test-match
{
  "question": "客户投诉物流延迟"
}

响应：matches 列表（expert_id、score、keywords），可用于客服系统的工单路由决策。

2.3 知识检索（RAG 上下文）

请求示例：

POST /admin/knowledge/search
{
  "query": "退款政策",
  "kb_ids": ["kb_cs_policy"],
  "top_k": 5
}

2.4 反馈与学习

请求示例（答案反馈）：

POST /api/feedback/answer
{
  "query": "退款流程",
  "expert_id": "dynamic_kb_cs",
  "rating": 5,
  "has_hallucination": false  // 若有 QA 检测结果可传入
}

2.5 Critique 状态

三、客服系统集成流程示例

3.1 模式 A：MBE 作为问答引擎（推荐）

用户系统把 MBE 当「黑盒问答服务」：

客服收到客户问题
    → 调用 MBE POST /api/civil-lawyer/consult（通用问答）
        或 POST /api/experts/market/{expert_id}/trial（指定专家）
    → 获取答案（已含 Self-Critique、RAG 验证）
    → 展示给客服/客户

无需改动用户系统结构，仅增加一个 HTTP 调用。

3.2 模式 B：MBE 作为路由建议

用户系统保留自己的回答逻辑，用 MBE 做路由建议：

工单/问题进入
    → 调用 MBE POST /admin/knowledge/expert/test-match
    → 获取推荐专家/队列
    → 用户系统按建议路由工单

3.3 模式 C：MBE 作为检索 + 自建生成

用户系统自己调 LLM 生成回答，用 MBE 做知识检索：

客户问题
    → 调用 MBE POST /admin/knowledge/search
    → 获取 top-k 知识块
    → 用户系统将知识块拼成 prompt 给自有 LLM
    → 生成回答

检索结果已由 MBE 侧处理，用户系统只需按需使用。

3.4 模式 D：反馈闭环

用户系统在交互结束后，把反馈回传 MBE：

会话结束
    → 调用 MBE POST /api/feedback/answer
    → 传入 query、expert_id、rating、has_hallucination（若有）
    → MBE 记录并做 FeedbackCritique，用于学习

四、实现要点：不改用户系统

4.1 认证方式

• API Key：Authorization: Bearer {API_KEY} 或 X-API-Key: {API_KEY}
• Token：用户登录后获取的 JWT

具体以 MBE 部署的认证配置为准。

4.2 调用方式

• 同步：普通 HTTP 请求
• 异步：在用户系统内用异步 HTTP 客户端（如 aiohttp、fetch）调用，不阻塞主流程

4.3 错误与超时

• 设置合理超时（如 10–30 秒）
• 失败时回退到原有逻辑（如默认客服、预设话术）

4.4 数据映射

用户系统只需做简单映射：

• 问题 → query / user_input
• 专家/队列 → expert_id（若 MBE 侧有对应专家）
• 分数 → rating（1–5）

五、可扩展的 MBE 端 API（可选）

若需要更细粒度的 Self-Critique 能力，可在 MBE 侧增加独立 API，供外部系统按需调用：

当前 MBE 已将这些能力集成在 route_and_answer、知识检索等流程中。通过对话/检索/反馈等现有 API，即可使用 Self-Critique 能力，而无需新增独立 API。

六、总结

用户系统只需按上述方式调用 MBE API，即可利用 Self-Critical Sequence 能力，实现客服等业务流程的优化与校验。