深入理解需求分析与架构设计

可视化演示

用户旅程映射

你决定开一家智能餐厅。开业前，你做了件让合伙人看不懂的事：站在门口拿小本子记笔记。顾客从哪进来？等位时在刷手机还是干瞪眼？报菜名时磕巴了吗？菜端上来先看颜色还是先问分量？别笑，这些细节决定了你要不要设外卖窗口、要不要排队叫号系统、菜单要不要配图。在买任何厨具之前，你得先把“顾客的一天”完整画出来。

这套方法在 RAG 客服系统里叫用户旅程映射（User Journey Mapping）。它把一次完整的人机对话拆成一个个触点（Touchpoint）：用户从哪个入口进来、输入问题时是否犹豫、等待检索结果时会不会催促、得到答案后是否满意、不满意时会不会追问或转人工。每个触点都是一次体验的评分点，也都是架构设计要支撑的服务点。

旅程映射要产出三类东西：场景剧本，描述“用户在什么情境下带着什么意图来提问”，比如“深夜十一点，用户刚收到破损快递，怒气冲冲来索赔”；痛点清单，标注每个触点的摩擦点，比如“超过三十秒没有首响，用户直接流失”；价值目标，把体验量化为可验收的指标，比如“首响时间小于两秒、一次解决率大于八成”。

还记得你站在门口的小本子吗？第一次和顾客说“您好”的时机、递菜单的方式、上菜的节奏，都是触点。需求分析阶段不画这张旅程图，架构师就只能靠拍脑袋决定厨房多大、装几个传菜窗口——等开业再改，代价是拆墙重砌。

知识域划分

智能餐厅的后厨不能是一个大平间。凉菜、热菜、汤品、甜品，各有各的食材、调料和保存温度。你把后厨分成四个独立小间：凉菜间恒温冷藏、热菜间猛火快炒、汤品间文火慢炖、甜品间深冷锁鲜。每间配独立冰箱和案板，互不串味，厨师闭着眼都知道去哪间拿什么。

对应到 RAG 客服系统，这就是知识域划分。企业的知识库同样五花八门：商品参数、价格政策、售后规则、物流时效、活动玩法。如果全部倒进一个“大杂烩”索引，用户问“能退款吗”时，检索结果会同时混入活动规则和商品介绍，模型只能对着四不像的素材胡编，答非所问。

知识域划分包含四个决策。第一是业务模块：按组织架构和用户意图切分知识，如商品域、订单域、物流域、售后域。第二是知识分类：域内部再按类型分，政策、FAQ、操作指南各自归位。第三是权限边界：区分对客可见与仅内部可见的知识，防止模型把内部赔付规则当话术讲给用户。第四是检索粒度：决定知识切片（Chunk）的大小——切太粗命中噪声多，切太细上下文断裂。这四条线，就是架构图上“厨房隔间”的边界线。

回到餐厅：知识域划分决定了冰箱贴什么标签、案板放哪个位置。看似是收拾屋子的小事，却决定了高峰时段厨师能不能三秒摸到一块姜。架构层面，“想清楚每个域的数据源、更新节奏、访问权限”比急着堆字库重要得多——分类不清的厨房，菜越多越混乱。

技术栈选型

现在该买厨具了。你走进厨具城，导购热情推荐一台能连 WiFi、会跳舞的顶级电灶——但你后厨电压只有 220 伏，团队里没人用过触屏灶，坏了还要等三周进口配件。你最后选了那台皮实耐操的大火灶：够用、好修、团队闭着眼都会操作。买完你才明白，选厨具不是选广告，是选“十年不换的伙计”。

技术栈选型是同样的逻辑。RAG 客服系统的核心选型点有四个：数据存储——关系型数据库存订单状态，向量数据库存知识切片，Redis 做热点缓存；向量检索——FAISS 适合离线小规模召回，Milvus 或 Elasticsearch 适合在线大规模服务；模型部署——调用云端大模型 API 起步快，私有化部署开源模型则数据不出域；应用框架——LangChain 等框架的成熟度，必须与团队的熟悉程度匹配。

选型不是追最新，而是同时画两张表：延迟预算和运维账本。每个环节都会往链路里加时间、加故障点：一次提问要经过“检索、重排、生成”三站。如果产品要求首响两秒内，检索必须控制在 200 毫秒、重排 100 毫秒、生成最多一秒半——预算超了就得砍环节、加缓存或换方案。运维账本同理：每个组件都是一份要人保养的保修单，新框架社区小、招人难、踩坑没人答，都是隐性成本。

厨具城的教训在架构里同样成立：最好的技术不如最合适的组合。选每一件“厨具”前，先问三个问题——团队会用吗、坏了修得起吗、放进链路后总时间还够吗？三个答案都是“是”，这东西才配进你的厨房。

容量规划

你开始算账：预计一天来 2000 个客人，但没人会均匀分布——工作日中午十一点半到一点是高峰，周末晚上六点到八点是另一个高峰。如果按“平均每小时 83 人”布置 10 张桌子，高峰时段 300 人同时涌进来，前厅瞬间失控。你意识到，餐厅的规模不能按平均值定。

容量规划解决的就是这个问题：不算平均，算峰值，再乘上余量。对 RAG 客服系统，核心指标是 QPS（每秒查询数）。你要估算：日活跃用户（DAU）多少人、人均每天问几次、请求集中在哪几个小时、峰值因子是多少（通常取 3 到 10 倍）。还要考虑重试放大——一旦系统变慢，用户会疯狂重试点击，流量自己会膨胀，等于在伤口上撒盐。

容量规划还要覆盖存储和成本测算：知识切片的向量索引占用空间、对话日志的归档成本、GPU 实例的规模与费用。这些数字直接决定架构形态——是上一台大机器还是三台小机器、要不要加缓存层、日志保留三十天还是九十天。成本核算不是财务的事，是架构师的事：每一个 QPS 背后都是真金白银。

回到餐厅的账本：容量规划不是算“平均每天多少人”，而是算“最挤的那十分钟多少人”，再预留三成空位和一叠备用折叠桌——折叠桌就是架构里的限流和降级方案。算错了，不是在高峰期崩盘，就是在淡季浪费租金。

风险评估

开业前最后一晚，你把合伙人拉来开会：“如果停电怎么办？如果主厨请病假怎么办？如果冷冻柜坏了、三百斤牛肉全臭了怎么办？”合伙人说你乌鸦嘴，你却说：问题迟早会来，我们赌的不是它来不来，而是它来的时候我们倒不倒。

风险评估就是提前问“什么会杀死这个系统”。RAG 客服系统有四类常见风险。依赖风险：大模型 API 抖动、被限流、突然涨价甚至下架；数据风险：知识库内容过期，模型却自信地把错答案讲给用户；性能瓶颈：检索在数据量翻倍后从 200 毫秒恶化到 2 秒；合规风险：用户隐私数据未经脱敏就进向量库，一旦泄露就是事故。

每个风险都用两个维度打分：发生概率 P 和影响程度 I，二者相乘得到风险值 R。风险值高的先做预案：API 可能挂就配一个本地小模型兜底；知识可能过期就建每周巡检任务；检索可能变慢就上分片和缓存；隐私数据敏感就做脱敏与权限隔离。风险值低的也要记入监控清单，防止它某天悄悄升级。

风险评估不会让风险消失，但它让团队从“赌徒”变成“消防员”——提前知道哪栋楼最容易起火，把灭火器放在正确的走廊里。餐厅后厨的灭火器和备用发电机，就是架构里的熔断器、降级开关和备用模型。

迭代路线图

你没有立刻租 500 平的店面，而是推着一辆小推车，在学校后门口支了个摊，只卖三样：牛肉面、凉皮、酸梅汤。验证一周后发现，牛肉面排队最长，凉皮几乎无人问津。你砍掉凉皮，租下 30 平的小店，菜单扩到十样。六个月后，才敢开大店。小摊看似寒酸，却用最低成本换来了最真实的答案。

这就是迭代路线图的核心思想：最小可行版（MVP）先行。RAG 客服系统的 MVP 是一条纵向打通的最小链路——只覆盖最高频的两三个知识域（比如物流查询和订单状态），用最简单的“检索加生成”架构跑通，配上基础日志。它的目标不是完美，而是验证三件事：回答质量用户买不买账、延迟能不能接受、维护成本是否可控。

路线图还要拆里程碑与发布策略。里程碑按“可演示、可验证”来拆：第一周搭好知识导入和检索，第二周接入模型生成，第三周上线灰度。发布采取灰度：先放 5% 的流量，观测质量指标，确认无误再逐步放到 100%。每一步都带上反馈回路——把“回答失败、用户转人工、用户点踩”这些信号回流到需求池，成为下一轮迭代的输入。

小推车之后的每一步，你都在验证而不是赌博：先小后大、先窄后宽、每一版都带着真用户的声音往前走。“先开小摊”不是怂，而是用最小成本换最真实的答案——这正是从技术原型到规模生产的正确姿势。

持续优化

餐厅开业第 30 天的晚上，打烊后你没有走。你翻看数据：牛肉面卖了 200 碗，但备注“微辣”的顾客里有三成在评价里写“太辣”；酸梅汤复购率高得离谱，备货却只备了昨天的量，晚上八点就售罄了。你掏出本子记下两行字：调低辣度、加大酸梅汤备货。第二天，营业额涨了 8%。

持续优化就是这套“每日复盘”的工程化版本。RAG 系统上线后，真正的战斗才开始。你需要一套质量指标体系：答案匹配率（检索是否召回正确知识）、首答采纳率（用户是否直接满意）、转人工率、回答置信度。每个指标都要能从线上日志里自动算出来，而不是靠客服主管拍脑袋。

优化循环包含四个动作。日志分析：从失败的会话里挖出共性问题——如果所有“发票”类问题都答错，多半是知识库里的发票政策过期了；知识更新：建立知识库的定期刷新机制，业务一变库必须跟着变；A/B 实验：同一批流量分成两组，对比不同的提示词策略、检索 Top-K 数量或重排阈值，用数据而不是感觉做决策。四步循环往复，直到质量指标收敛到当初定下的价值目标。

餐厅的秘诀不是开业那晚的烟花，而是每个打烊后的复盘。RAG 系统也一样：上线只是马拉松的发令枪，需求分析、架构设计、容量规划、风险评估，最终都要落到这个日夜循环的优化飞轮上——越转越快，越转越准。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""RAG客服系统需求分析与容量规划演练."""  USER_JOURNEY = [    {"touchpoint": "进入页面", "weight": 0.2, "score": 8},    {"touchpoint": "发起提问", "weight": 0.3, "score": 7},    {"touchpoint": "等待回复", "weight": 0.3, "score": 5},    {"touchpoint": "获取答案", "weight": 0.2, "score": 9},] KNOWLEDGE_DOMAINS = [    {"domain": "商品咨询", "needed": 120, "covered": 100},    {"domain": "订单售后", "needed": 80, "covered": 60},    {"domain": "物流查询", "needed": 60, "covered": 58},] RISKS = [    ("模型API抖动", 0.4, 8),    ("知识库过期", 0.6, 6),    ("检索慢查询", 0.3, 7),]  def weighted_experience(steps):    total = sum(s["weight"] * s["score"] for s in steps)    return round(total, 2)  def coverage_rate(domains):    need = sum(d["needed"] for d in domains)    have = sum(d["covered"] for d in domains)    return round(have / need, 3)  def peak_qps(daily_active_users, requests_per_user, peak_factor, busy_hours):    daily_requests = daily_active_users * requests_per_user    return round(daily_requests * peak_factor / (busy_hours * 3600), 2)  def risk_exposure(probability, impact):    return round(probability * impact, 1)  def main():    print("== 1 用户旅程体验分 ==")    exp = weighted_experience(USER_JOURNEY)    print("加权体验总分:", exp, "(满分10)")     print("\n== 2 知识域覆盖率 ==")    cov = coverage_rate(KNOWLEDGE_DOMAINS)    print("当前覆盖率:", cov, "(目标>=0.9)")    for d in KNOWLEDGE_DOMAINS:        print(" -", d["domain"], "缺口:", d["needed"] - d["covered"])     print("\n== 3 容量规划(QPS) ==")    qps = peak_qps(dau=200000, requests_per_user=3, peak_factor=3, busy_hours=8)    print("峰值QPS估算:", qps, "建议预留3倍余量:", round(qps * 3, 2))     print("\n== 4 风险排序 ==")    risks = sorted(RISKS, key=lambda r: risk_exposure(r[1], r[2]), reverse=True)    for name, prob, impact in risks:        print(" -", name, "风险值R =", risk_exposure(prob, impact))  if __name__ == "__main__":    main()

1. weighted_experience(steps)对应公式 S = Σw·e，把用户旅程每个触点的体验分按权重汇总成整体体验分。
2. sum(s["weight"] * s["score"] for s in steps)用生成器表达式累加“权重乘分数”，是加权求和公式的直接翻译。
3. coverage_rate(domains)计算知识库对所有业务需求的总体覆盖率，对应公式 C = K_支撑 / K_需求。
4. peak_qps(daily_active_users, requests_per_user, peak_factor, busy_hours)用日活、人均请求、峰值因子和高峰小时数估算峰值 QPS，对应容量规划公式。
5. risk_exposure(probability, impact)用 R = P × I 计算单个风险的风险值，供排序使用。
6. sorted(RISKS, key=lambda r: risk_exposure(r[1], r[2]), reverse=True)按风险值从大到小排序，先处理最危险的项。

常见误区

面试题