业务流程 — 谁在何时做什么
AI 栈在组织中如何运作的总结文档。AI 不是「装好就能自动运行的东西」，而是需要人输入资料、判断结果才能真正发挥价值。
与教程不同
教程的目标是「用一份文档获得第一个答案」，而本文档是「持续保持可用状态」。
角色
| 角色 | 账户 | 职责 |
|---|---|---|
| AI 运营者 | 管理控制台账户(env) | 服务状态·文档索引·管道管理 |
| 现场用户 | Platform 账户体系 | 向聊天机器人提问并判断答案 |
| 系统管理员 | 服务器访问 | 安装·密钥轮换·备份 |
控制台账户是团队共享的单个账户 → 初始密码修改。
整体流程
箭头跨越泳道的地方是交接点。
这个循环是关键
현장 피드백 → 문서 보강 → 재색인 如果它不运转，AI 就会停留在最初输入的文档水平。
建立反馈渠道 — 通常就是因为没有反馈渠道，循环才会中断。
1. 上线 — 达到可用状态
| 步骤 | 任务 | 负责人 |
|---|---|---|
| 1 | 安装 → 一键安装 | 系统管理员 |
| 2 | 控制台账户·密钥设置 → 初始密码修改 | 系统管理员 |
| 3 | 首页全绿确认 → 管理控制台 | AI 运营者 |
| 4 | 选择要输入哪些文档 | AI 运营者 + 现场 |
| 5 | 文档索引 + Query Test 验证 | AI 运营者 |
| 6 | 向现场公开 | — |
第 4 步是上线的关键决策
随意输入大量文档不会带来改进。从现场实际经常提问的内容开始 — 通常的优先级是：设备手册、作业标准书、故障排除历史。输入陈旧文档会导致聊天机器人自信地给出错误答案。
2. 运营 — 定期工作
| 周期 | 任务 | 负责人 |
|---|---|---|
| 每日 | 首页状态摘要(中断数为 0) | AI 运营者 |
| 每周 | 管道状态·执行历史 | AI 运营者 |
| 每周 | GPU 使用率·XID、LLM 响应速度(P95) | AI 运营者 |
| 每月 | 文档更新重新索引，整理错误答案案例 | AI 运营者 + 现场 |
| 季度 | 密钥轮换 → 密码·API 密钥变更 | 系统管理员 |
全部在管理控制台查看。
XID 不为 0 时立即上报
这是 GPU 硬件·驱动程序错误。即使当前运行，也通常预示节点即将宕机。
3. 答案错误时 — 从哪里修复
「聊天机器人答案异常」有多个层面的原因。按以下顺序逐步缩小范围。
| 检查项 | 如果是 |
|---|---|
| 1. 根据文档是否已索引 | 没有 → 添加文档(Documents) |
| 2. 搜索是否能找到 | 找不到 → 尝试改变搜索方式(hybrid/local/…) (Query Test) |
| 3. 能找到但答案错误 | 原始文档可能陈旧 — 更新文档 |
| 4. 答案缓慢或中断 | LLM·GPU 问题 → LLM · GPU 屏幕 |
在怀疑模型之前，先怀疑资料
现场反映「AI 不聪明」的大多数情况，实际上是文档缺失或陈旧。
常见偏差点
| 症状 | 通常原因 |
|---|---|
| 「上线了但没人用」 | 输入的文档与现场实际提问不符 |
| 「分析界面为空」 | 特征管道停止 — 检查管道而非模型 |
| 「自信地给出错误答案」 | 陈旧文档仍在索引中 |
| 「变慢了」 | GPU 竞争或 LLM 等待 — 检查 P95 |
相关文档
- 教程 — 让聊天机器人用我们的文档回答
- AI 管理控制台 — 每日查看的界面
- 异常检测·事件响应
- 数据库模型 — 什么存在哪里