RAG 平台的团队分工与迭代节奏：前端、算法和基建如何协作
RAG 平台的团队分工与迭代节奏：前端、算法和基建如何协作
一、RAG 项目拖了 4 个月没上线，三个团队相互指责
前端团队说："算法团队给的知识库 API 格式天天变，我们改 UI 改到崩溃。"算法团队说："基建团队不给 GPU 资源，Embedding 模型跑一次要 2 小时。"基建团队说："需求一直在变，我们不敢投入搭建正式的向量数据库集群。"
这是典型的"三角困局"——三个团队各自优化自己的效率，但整体交付被团队间的依赖和等待拖垮。RAG 产品是一个跨团队协作的重灾区，因为它的技术栈横跨前端（搜索交互）、算法（检索质量、生成效果）和基建（向量数据库、GPU 集群、数据管道）。解决三角困局的关键不是"更好的沟通"，而是"更合理的接口契约和迭代节奏"。
二、三方协作的接口契约设计
核心思路：三个团队之间的交互通过固定的 API 契约来解耦。前端只依赖 RAG Search API（不关心底层是 BM25 还是向量检索），算法只依赖 GPU API（不关心 GPU 在哪个云、几块卡），基建只依赖资源需求声明（不关心算法的具体参数）。
三、三个团队的分工和节奏
前端团队（1-2 人）：
- 负责：搜索交互体验、结果展示、反馈机制
- 关键交付物：RAG Search UI 组件（可复用的）
- 节奏：2 周一个版本，先做灰度功能（如引用标注），收集用户数据后再全量
算法团队（2-3 人）：
- 负责：Embedding 模型选型与优化、检索策略、生成策略
- 关键工作：每周做一次检索质量评估（用固定的评测集跑一遍），输出质量报告
- 节奏：按"实验周期"工作，3 周一个实验（召回优化 / Rerank / Prompt 优化），跑完 A/B 测试后再发版
基建团队（1-2 人，通常复用）：
- 负责：向量数据库维护、GPU 资源调度、数据管道
- 关键工作：文档更新流水线（增量索引、全量重建）
- 节奏：按月规划，月初敲定本月要上线的基建能力，月底交付
三方协作的同步点：
- 周一站会：15 分钟，同步本周各团队的交付物和依赖项
- 周五 Demo：30 分钟，展示本周完成的功能（不一定是上线版）
- 每月评测：算法团队输出检索质量月报，三团队一起看趋势
四、接口契约的实例
# RAG Search API 契约（三方必须遵守的接口定义） # 文件: api-contracts/rag-search-api-v2.yaml openapi: "3.0.0" info: title: RAG Search API version: "v2.1.0" description: | 本接口是前端和算法团队的契约。 任何变更需要两个团队同时签字确认。 paths: /api/v2/rag/search: post: summary: RAG 搜索 requestBody: content: application/json: schema: type: object required: [query] properties: query: type: string description: 用户原始查询 example: "Kubernetes pod CrashLoopBackOff 如何排查" # 前端透传给算法的过滤条件 filters: type: object properties: document_type: type: string enum: [all, wiki, design_doc, postmortem] default: all time_range: type: string enum: [all, week, month, year] # 算法选择的检索策略（前端不关心） strategy: type: string enum: [auto, precise, comprehensive] default: auto responses: '200': content: application/json: schema: type: object properties: answer: type: string description: LLM 生成的回答 references: type: array items: type: object properties: doc_id: { type: string } title: { type: string } snippet: { type: string } relevance_score: { type: number } # 质量信号（前端用来展示信心度） confidence: type: string enum: [high, medium, low] search_latency_ms: type: integer五、迭代节奏的反模式
反模式一：前端等算法，算法等基建
"算法把检索优化完了我们再加新功能"——这是错误思维。三个团队应该并行工作：前端可以先做 UI 优化（加载动画、错误提示、反馈按钮），算法可以在现有版本上做实验，基建可以独立建数据管道。不要串行等待。
反模式二：所有人参与每一次讨论
前端不需要知道 Embedding 模型的维度是 768 还是 1536，算法不需要知道前端用了 React 还是 Vue。讨论时坚持"需要知道的信息原则"——只有跨团队的接口变更才需要三团队参与，内部优化不需要。
反模式三：评测指标只看算法团队出
检索质量的评测（召回率、MRR）如果只有算法团队在做，就变成了"自己评自己"。健康的方式是：算法出评测方法，前端出"用户踩率"和"搜索放弃率"（用户搜完没点击任何结果就走了）作为业务指标。技术指标 + 业务指标对比看，才能发现问题。
五、总结
RAG 平台的团队协作核心是"用 API 契约解耦三方依赖"。前端、算法、基建三个团队各自有独立的迭代节奏（2 周 UI 迭代 / 3 周算法实验 / 4 周基建规划），通过固定的 API 接口契约来同步。最重要的不是"沟通频率"，而是"什么信息需要同步"——只有接口变更和跨团队依赖阻塞才需要升级到三团队讨论。质量评测应该由算法和前端各出一个视角——算法看检索指标，前端看用户行为指标，两者对齐才能发现真正的质量问题。