AI 系统设计：边界、数据流与架构取舍

用需求约束组件选择

一个可管理的知识助手起点可以是 API 服务、文档存储、元数据/权限库、检索索引和后台入库任务。是否拆成微服务、引入复杂调度或多区域部署，应由负载、团队、故障隔离和业务目标说明。

先问用户、数据、时效、可见范围、质量、延迟、预算与恢复目标，再画组件。架构图需要附接口、状态所有者和失败处理，不能只罗列框架名字。

两条数据流

入库流：授权的数据源→解析/切片→稳定 ID 和版本→权限元数据→索引→版本切换。查询流：可信身份→可读范围→检索/重排→当前权限及版本复核→生成/工具→引用→结果记录。

异步入库需有任务状态与重试策略。元数据已更新而索引还未同步时，必须明确用户看到哪版、是否允许短期旧结果，以及撤权/删除如何立即阻断读取。

架构决策表

决策	比较因素	需要保留的验证
RAG / 微调	资料变化、证据需求、行为模式、成本	同任务基线，知识新鲜度与能力回归
同步 / 队列	工作时长、可重试性、交互需求	队列延迟、重复任务、失败状态
单体 / 服务拆分	团队维护、负载差异、隔离收益	可观察瓶颈与部署复杂度
租户隔离	权限语义、数据敏感性、规模	检索、缓存、引用、导出和日志越权测试
缓存策略	身份、范围、版本、命中收益	更新、撤权、删除后的回归
发布 / 回滚	模型、提示、索引和预处理版本	兼容性、旧版本恢复与质量门槛

筛选权限只放在 UI 不足以隔离数据。检索候选、详情读取、答案和引用应继续遵守当前权限；提示注入防护也不能仅交给模型自判。

原创一致性案例

元数据已标记文档删除，向量索引仍短暂返回其 chunk。读取层应检查当前文档状态，阻断返回；后台随后删除索引与缓存并核验。若只等待索引同步，删除到生效的窗口可能泄漏内容。

索引版本切换还需与 embedding 版本一致。新旧向量维度相同不保证可在同一空间比较；保存 embedding/索引/切片版本，必要时重建并验证后切换。

设计记录与练习

写一份 ADR：问题、约束、两个可行方案、选择、代价、验证和回退。为“文档量增长十倍”与“权限频繁变化”分别说明哪些决定需要重审。没有数据支持时标注假设，避免宣称无条件可扩展。

复习问题

1. 什么情况下微服务拆分收益不足以覆盖复杂度？
2. 为什么索引同步不能单独保证即时撤权？
3. 一次发布为什么要关联多个版本？

阅读依据

• README.md
• project.md
• 官方章节

2026-10-08：AI 助手协助原创组织知识点、手算和练习，核对原始资料；假设例子不作为性能或费用实测。