假如你要开一家餐厅，绝不会第一天就冲去买锅。你会先站在街口观察：来的都是什么人？上班族多还是学生多？他们几点来、最常点什么菜？想明白了这些，才轮到定菜单、设计后厨。做 RAG 客服系统是同一个道理——第一步不是买 GPU、不是调模型，而是做需求分析与架构设计。需求分析回答“系统要解决什么问题”：谁在问、问什么、问完还要干什么；架构设计回答“系统怎么搭”：知识放哪、检索怎么做、模型怎么接。本文把 RAG 客服系统比作一家“智能餐厅”，带你从开店筹备走到后厨布局：拆业务场景、分用户意图、列功能矩阵、定非功能指标、规划知识库、选技术架构、设计演进路线。七步走完，你就拿到了这家“餐厅”的设计图纸。

岗位关联

学会需求分析与架构，等于拿到 RAG 项目的方向盘：多数失败项目不是代码写得差，而是从一开始就找错了方向。这是 AI 工程师从“能调 API”走向“能扛项目”的分水岭。

目录
  1. 可视化演示
  2. 业务场景拆解
  3. 用户意图分类
  4. 功能需求矩阵
  5. 非功能需求
  6. 数据来源规划
  7. 技术架构选型
  8. 架构演进路线
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

RAG客服系统架构流程 知识库 (FAQ+产品文档+工单) 需求边界：售前咨询 | 售后支持 | 投诉处理 非功能约束：P9999.9% | 并发>500QPS

业务场景拆解

开一家餐厅前最怕什么？怕闭着眼睛定菜单。老板不知道来的是上班族还是学生，也不知道他们几点来、爱吃什么，一口气列了三百道菜，结果厨房忙不过来、客人不买账。聪明的老板会先蹲在门口数人流、记需求。RAG 客服系统也一样，第一步不是选模型、不是买显卡，而是搞清楚“谁在什么场景下、会问什么问题”。

这个动作叫业务场景拆解：把客服系统将要面对的真实世界，拆成一张可管理的问题清单。每一条场景由三个要素组成——用户角色（游客、会员、商家）、触点渠道（App、小程序、网页）、业务动作（查物流、退款、开发票）。产出物叫场景清单，它直接决定知识库要覆盖什么、对话流程怎么设计。

拆解最常用的武器是频率分析。把历史工单、客服聊天记录汇总起来，统计每个问题的出现次数，再用帕累托法则找出覆盖 80% 流量的核心问题。注意，场景清单不是一次写死的，项目初期要靠业务访谈加数据抽样反复迭代，最终收敛成第一版边界。

就像餐厅老板最后精简出 20 道菜却创造了 80% 的营业额，客服系统的护城河也来自少数高频场景。场景清单定了，菜单就有了，后厨才有方向。

覆盖率=∣Qcore∣∣Qall∣\displaystyle \text{覆盖率} = \frac{\left| Q_{core} \right|}{\left| Q_{all} \right|}
通俗说明：覆盖率就像“招牌菜占营业额的比例”，比例越高，说明需求分析越聚焦、范围越清晰。
  1. 分子解读$Q_{core}$ 是出现频率不低于阈值 $\tau$ 的核心问题集合，这一步把高频问题挑出来。
    Qcore={q∣freq(q)≥τ}Q_{core} = \{ q \mid \mathrm{freq}(q) \ge \tau \}
  2. 分母解读$Q_{all}$ 是系统可能遇到的全量问题集合，代表需求分析的边界范围。
    Qall={q1,q2,…,qn}Q_{all} = \{ q_1, q_2, \dots, q_n \}
  3. 比值含义两个集合的元素个数相除，得到一个 0 到 1 之间的覆盖率，越接近 1 说明拆解得越完整。
    ∣Qcore∣∣Qall∣→1\frac{|Q_{core}|}{|Q_{all}|} \rightarrow 1

用户意图分类

服务员每天会听到各种话：“来碗牛肉面”（点单）、“这面辣不辣”（咨询）、“你们店开多久了”（闲聊）。高明的服务员不会对每句话都用同一个套路，而是先判断客人到底想干什么。RAG 客服系统的第一个理解模块，就是做这个判断的“服务员”。

它叫意图分类：用户一句话进来，先映射到预定义的意图类别。RAG 客服中最常用的是三分法。指令式意图：以“帮我、请、取消”为特征，要系统执行动作；查询式意图：以“是什么、多少钱、怎么”为特征，要系统给出答案；闲聊式意图：寒暄、感慨，没有业务目的，需要兜底话术优雅接住。

实现方式可以很轻：简单场景用规则加关键词，复杂场景用意图分类模型或让大模型做 few-shot 分类。特别要注意的是，意图会连续切换——用户说完“帮我退款”可能紧接着问“钱什么时候到账”。所以意图分类不是一次性动作，要跟对话管理配合，这也是需求分析阶段就要想清楚的设计点。

服务员能一秒分辨“点菜”和“问路”，靠的是长期训练；你的意图分类器也要靠真实对话数据喂养。分错类就像上错菜，客人体验瞬间崩盘，所以意图体系要在需求阶段就定义清楚。

精确率=TPTP+FP\displaystyle \text{精确率} = \frac{TP}{TP + FP}
通俗说明：精确率回答“模型说是查询的里面，有多少真的是查询”，就像服务员判断 80 桌客人要加菜，结果 70 桌真加了，准确率就是 87.5%。
  1. 真阳性$TP$ 表示实际是查询意图、模型也预测为查询意图的样本数。
    TP=∣{q∣真实意图=查询∧预测意图=查询}∣TP = \lvert \{ q \mid \text{真实意图=查询} \land \text{预测意图=查询} \} \rvert
  2. 假阳性$FP$ 表示实际不是查询意图、模型却误判为查询意图的样本数。
    FP=∣{q∣真实意图≠查询∧预测意图=查询}∣FP = \lvert \{ q \mid \text{真实意图} \neq \text{查询} \land \text{预测意图=查询} \} \rvert
  3. 比值计算真阳性除以预测为阳性的总数，取值在 0 到 1 之间，越高代表误报越少。
    P=7070+10=0.875P = \frac{70}{70 + 10} = 0.875

功能需求矩阵

菜单定了，接下来要排后厨岗位：炒锅、切配、传菜、洗碗，每个岗位管哪几道菜、谁先做谁后做。功能需求矩阵干的就是这件事——把“场景清单”和“系统能力”对应起来，看每个场景需要哪些能力支撑。

RAG 客服系统的能力项通常包括：知识库检索问答、多轮对话管理、转人工坐席、情感识别、话术兜底。矩阵的每一个交叉格都标一个优先级：P0 是缺了系统就用不了的能力，比如检索问答；P1 是影响体验的能力，比如多轮衔接；P2 是锦上添花的增强。矩阵做完，MVP 范围就自然画出来了。

后厨岗位表决定了开张第一天需要几个人、几口锅；功能需求矩阵决定了第一期版本做什么、不做什么。会做减法，才是真功夫。

优先级=V×UC\displaystyle \text{优先级} = \frac{V \times U}{C}
通俗说明：优先级 = 业务价值 × 覆盖用户数 ÷ 实现成本。得分越高越先做，就像后厨先招“救火岗位”，再招“加分岗位”。
  1. 业务价值$V$ 是功能对业务目标的贡献评分，通常由产品、运营、业务方共同打分。
    V∈{1,2,…,10}V \in \{1, 2, \dots, 10\}
  2. 覆盖用户数$U$ 是该功能影响的用户规模，来自场景拆解阶段的用户画像。
    U=∣受影响用户群∣U = \left| \text{受影响用户群} \right|
  3. 实现成本$C$ 是开发、维护、算力的综合代价，越大越要往后排期。
    C=工时+资源占用C = \text{工时} + \text{资源占用}
  4. 综合评分把三个输入代入公式，得分从高到低排序，就得到迭代顺序。
    Priority∝V×UC\text{Priority} \propto \frac{V \times U}{C}

非功能需求

客人点了菜，最关心“多久能上桌”；常来的熟客，在意“周末开不开门”；所有人都默认后厨食材安全。这些要求不写在菜单上，却是餐厅的生死线。系统的非功能需求（NFR）就是这条生死线。

NFR 不回答“系统做什么”，而回答“系统做得怎么样”，三大件是响应时间、可用性、安全合规。RAG 客服里，一次对话要经历意图识别、检索、生成多个环节，每个环节都在消耗时间。所以延迟预算必须提前算：通常设定 P95 目标，即 95% 的请求要在 3 秒内返回。

安全合规同样在设计期就要定：对话数据脱敏、知识库权限隔离、日志留存审计。这些指标会直接决定架构要不要加缓存、要不要做异步、要不要拆分服务，后期几乎没法补救。

客人在门口排长队，再有名的餐厅也会被差评。非功能需求就是你的服务标准：定低了系统崩，定高了成本失控，得拿公式和预算说话。

可用性=TupTup+Tdown×100%\displaystyle \text{可用性} = \frac{T_{up}}{T_{up} + T_{down}} \times 100\%
通俗说明：可用性是“正常营业时间占总时间的百分比”，99.9% 意味着每月大约只能停业 43 分钟。
  1. 正常运行时长$T_{up}$ 是系统对外提供正常服务的时间总和，对应餐厅正常营业的时长。
    Tup=∑itiupT_{up} = \sum_{i} t_{i}^{up}
  2. 故障停机时长$T_{down}$ 是系统不可用的累计时长，对应餐厅挂出“今日停业”的时间。
    Tdown=∑jtjdownT_{down} = \sum_{j} t_{j}^{down}
  3. 百分比换算正常时长除以总时长再乘 100%。99.9% 对应每月约 43 分钟的停机预算。
    30×24×60×0.1%≈43 分钟30 \times 24 \times 60 \times 0.1\% \approx 43 \text{ 分钟}

数据来源规划

后厨再强，没有新鲜食材也白搭。菜谱和食材是餐厅的灵魂，对 RAG 客服来说，知识库就是灵魂——没有数据，检索就是空转，模型再聪明也说不出对的话。

数据来源规划要回答三个问题：数据从哪来、覆盖什么、怎么保鲜。常见来源有四类：操作手册（怎么用产品）、FAQ（高频问答）、工单记录（真实用户问题）、政策文件（规则底线）。每个来源要评估格式——PDF、Word、网页——以及访问权限。

数据进知识库要走一条流水线：清洗、切分、向量化、入库。但入库只是开始，业务政策会变、文档会过期，“更新机制”比“导入动作”更重要：定期重爬、版本管理、失效下线。权限隔离也要在设计期做，否则员工可能问出内部薪酬这类不该答的内容。

好餐厅每天清晨进菜、晚上倒掉不新鲜的。你的知识库也要保鲜，否则系统会一本正经地说错话，而且错得很有自信。

知识覆盖度=∑k=1mwkck∑k=1mwk\displaystyle \text{知识覆盖度} = \frac{\sum_{k=1}^{m} w_{k} c_{k}}{\sum_{k=1}^{m} w_{k}}
通俗说明：知识覆盖度是各类文档覆盖情况的加权平均——不是“文档多”就好，而是“关键文档都齐了”才算好。
  1. 文档权重$w_k$ 是第 $k$ 类文档的重要程度，正比于对应场景的优先级和流量占比。
    wk∈[0,1]w_k \in [0, 1]
  2. 覆盖标记$c_k$ 表示第 $k$ 类文档是否已完成清洗和入库，1 表示已入库，0 表示未入库。
    ck∈{0,1}c_k \in \{0, 1\}
  3. 加权平均分子是带权覆盖和，分母是权重和，结果落在 0 到 1 之间，越接近 1 覆盖越完整。
    ∑wkck∑wk∈[0,1]\frac{\sum w_k c_k}{\sum w_k} \in [0, 1]

技术架构选型

食材和菜单都齐了，后厨怎么布局？灶台放哪、冰箱放哪、传菜动线怎么走，直接决定出菜效率。RAG 系统的架构选型，就是给系统“安排后厨”。

RAG 主链路是固定的：用户问题 → 意图识别 → 向量化 → 向量召回 → 重排 → 拼接提示词 → 大模型生成 → 返回。每个环节都有可选组件：向量库（FAISS、Qdrant、Milvus）、嵌入模型（bge、m3e）、LLM 服务（vLLM、云端 API）、编排框架（LangChain、Dify）。

选型原则是“按需匹配，不追新”。数据量小于百万级，开源的 FAISS 完全够用；需要高并发多租户，再上 Milvus。模型服务要考虑吞吐和成本，用 vLLM 做推理加速。链路质量用 F1 指标评估，衡量检索“既找得准、又找得全”。

米其林餐厅的后厨不是一上来就装十个灶台，而是根据菜单和客流反推。架构选型的答案永远在需求矩阵里，不在技术潮流里。

F1=2×P×RP+R\displaystyle F_{1} = \frac{2 \times P \times R}{P + R}
通俗说明：F1 是精确率和召回率的调和平均——像评价一道菜“既好吃又好看”，只占一头不算赢。
  1. 精确率$P$ 是检索返回的结果中真正相关的比例，衡量“找得准”。
    P=TPTP+FPP = \frac{TP}{TP + FP}
  2. 召回率$R$ 是知识库中相关文档被找出来的比例，衡量“找得全”。
    R=TPTP+FNR = \frac{TP}{TP + FN}
  3. 调和平均$F_1$ 同时惩罚低精确率和低召回率，只有两者都高时分数才高。
    F1=2PRP+RF_1 = \frac{2PR}{P + R}

架构演进路线

没有一家餐厅开张就是中央厨房。先摆路边摊验证口味，再租小店加桌子，火了之后才建中央厨房。系统架构也一样，一步到位往往意味着过度设计——投入巨大，却解决了一个还不存在的问题。

演进分三个阶段。第一阶段“单体原型”：用脚本把检索和生成串起来，目的只是验证“效果可行”，不追求工程化。第二阶段“模块化拆分”：把意图识别、检索、生成拆成独立服务，用 FastAPI 之类框架提供接口，方便替换组件、独立扩容。第三阶段“生产级架构”：补上可观测性、灰度发布、限流熔断、多租户隔离。

判断何时进入下一阶段，用容量和稳定性说话：当 QPS 上来、响应开始抖动、团队协作吃力时，就该重构。用吞吐量公式可以评估当前架构的容量边界，避免凭感觉扩容或凭感觉重构。

先让客人吃上一碗好吃的面，再谈开分店。先用最小架构跑通 RAG，再谈多租户和微服务——这是无数生产事故换来的经验。

吞吐量=NrequestTtotal\displaystyle \text{吞吐量} = \frac{N_{request}}{T_{total}}
通俗说明：吞吐量是“单位时间能服务多少桌客人”，它决定你能不能接住晚市高峰。
  1. 请求数$N_{request}$ 是统计窗口内系统成功处理的对话请求总数。
    Nrequest=∑l=1LnlN_{request} = \sum_{l=1}^{L} n_l
  2. 总时长$T_{total}$ 是统计窗口的时间跨度，通常取 1 小时或 1 天。
    Ttotal=tend−tstartT_{total} = t_{end} - t_{start}
  3. 吞吐换算请求数除以时长得到每秒吞吐量（QPS），用于判断架构是否进入瓶颈期。
    QPS=NrequestTtotal\text{QPS} = \frac{N_{request}}{T_{total}}

AI 应用场景

智能客服冷启动落地

阶段：业务场景拆解 + 用户意图分类

解决的问题：传统做法是直接封装大模型 API 做成聊天框，上线后发现答非所问、用户不买账。问题根源在于跳过了需求分析，不知道知识库该覆盖什么、意图该怎么划分。

具体案例：某电商平台上线 RAG 客服前，先用一周时间从工单系统提取 5000 条真实对话，归纳出“物流查询、退换货、发票、优惠券”四大高频场景，据此构建第一期知识库并定义三类意图，上线首月答准率达到 78%。

大促前容量评估

阶段：非功能需求设计

解决的问题：大促流量峰值是平时的十倍，靠上线后慌忙扩容根本来不及。通过可用性公式和延迟预算，提前设计缓存、限流与弹性伸缩策略。

具体案例：双十一前，团队根据历史峰值预估 QPS，用 F1 指标评估检索质量后确定缓存命中率目标，为 LLM 服务配置弹性伸缩策略，最终保障了大促期间 99.9% 的可用性，P95 延迟从 4.2 秒降至 2.1 秒。

多轮售后场景的意图路由

阶段：对话管理 + 功能需求矩阵

解决的问题：用户在“我要退货”之后紧接着问“怎么填单子”，意图会发生连续漂移。单一意图识别扛不住复杂售后，需要对话管理和转人工策略配合。

具体案例：部署意图分类器后，当检测到用户进入“投诉”类别时自动标记高优先级并转人工，同时把对话摘要推送给坐席，投诉处理时长缩短 40%。

Python 演示

python49 行
"""RAG 客服系统需求分析工具：意图统计 + 覆盖率 + 优先级评分"""from collections import Counter # 1. 收集业务场景中的用户问题样本：(问题, 意图, 渠道)samples = [    ("我的订单到哪了", "查询", "APP"),    ("怎么申请退款", "指令", "小程序"),    ("你们公司在北京吗", "查询", "网页"),    ("帮我取消订单", "指令", "APP"),    ("今天天气如何", "闲聊", "网页"),    ("发货用了几天", "查询", "小程序"),    ("帮我开发票", "指令", "APP"),    ("哈哈好的", "闲聊", "APP"),] # 2. 用户意图分布统计intent_counter = Counter(s[1] for s in samples)total = len(samples)print("== 意图分布 ==")for intent, cnt in intent_counter.most_common():    print(f"{intent}: {cnt} 条, 占比 {cnt / total:.1%}") # 3. 高频问题识别，覆盖率对应帕累托法则freq = Counter(s[0] for s in samples)top_k = 3core_count = sum(cnt for _, cnt in freq.most_common(top_k))coverage = core_count / len(samples)print(f"\n最高频的 {top_k} 个问题覆盖率: {coverage:.1%}") # 4. 功能需求优先级评分：价值 × 覆盖用户数 / 成本requirements = [    {"name": "知识库问答", "value": 9, "users": 1000, "cost": 5},    {"name": "多轮上下文", "value": 7, "users": 600, "cost": 8},    {"name": "转人工坐席", "value": 8, "users": 800, "cost": 3},    {"name": "闲聊兜底", "value": 3, "users": 200, "cost": 2},]print("\n== 需求优先级 ==")scored = sorted(    requirements,    key=lambda r: r["value"] * r["users"] / r["cost"],    reverse=True,)for r in scored:    priority = r["value"] * r["users"] / r["cost"]    print(f"{r['name']}: 优先级 {priority:.0f}") # 5. 输出 MVP 建议mvp = [r["name"] for r in scored[:2]]print("\nMVP 建议优先实现:", "、".join(mvp))
目的：用一份模拟客服对话样本，完成意图分布统计、高频问题覆盖率计算和功能需求优先级评分，输出 MVP 建议。
  1. samples = [...]收集业务场景中的真实用户问题样本，作为需求分析的第一手输入。
  2. intent_counter = Counter(s[1] for s in samples)按元组第二个字段（意图）统计条数，得到意图分布。
  3. coverage = core_count / len(samples)计算高频问题覆盖率，对应正文的帕累托公式。
  4. "value": 9, "users": 1000, "cost": 5给每个功能需求打分，分别是业务价值、覆盖用户数、实现成本。
  5. priority = r["value"] * r["users"] / r["cost"]用 V×U/C 公式计算优先级分数。
  6. sorted(..., reverse=True)按优先级从高到低排序，MVP 范围一目了然。

常见误区

误区以为把想到的功能全部写进需求文档就算完成需求分析，功能越多系统越强大，先把清单写满再说。

正解需求分析的核心是“场景—意图—约束”三层结构，先弄清谁在什么场景下问什么问题，再决定做哪些功能。就像餐厅，菜单再长，不知道客人在哪、点什么，后厨照样乱套。功能矩阵的价值在于“砍掉不做的”，而不是“堆上要做的”。

为何常见：功能清单看得见摸得着，容易让团队产生“工作有产出”的错觉，而场景分析需要蹲点观察、整理数据，显得慢且枯燥。

误区用了 RAG 就一定要上向量检索，关键词搜索是过时技术，提都不该提。

正解精确匹配场景——订单号、政策条款编号、型号规格——关键词搜索更快更准；向量检索擅长的是语义相似召回。生产系统普遍采用“关键词 + 向量”混合检索，先用关键词精确命中，再用向量兜底语义。就像餐厅点单，熟客报桌号是精确匹配，说“上次那道辣辣的菜”才是语义检索。

为何常见：RAG 的宣传放大了语义检索的魔力，让人忽略了客服场景里大量存在的精确匹配需求。

误区先把功能做出来，响应慢、不稳定、不安全等问题等上线后再调，反正用户看不见。

正解延迟、可用性、安全这些非功能需求由架构决定，上线后再改架构成本极高。RAG 链路每个环节都在增加延迟，如果不给架构预留缓存和并行空间，后期加缓存要动整个链路。就像餐厅装修时没留传菜通道，营业后再砸墙，代价是停业。

为何常见：非功能需求没有界面效果，赶进度的团队很容易把它排到最后，然后就没有然后了。

误区把操作手册、FAQ 导入向量库，系统就永远能用了，后续不用管。

正解业务政策会变、文档会过期，必须有更新机制设计：定期重爬、版本管理、失效下线。否则系统会一本正经地回答过时的退款规则，而且回答得很有自信。知识库的“保鲜”和“导入”同等重要。

为何常见：前期导入文档后系统表现惊艳，让人误以为数据是静止的，忽略了业务世界一直在变。

面试题

Q1. 建设 RAG 客服系统时，第一步应该做什么？

单选题 · easy

  • A.先拆解场景再分析需求← 正确答案
  • B.抢先购买集群计算设备
  • C.立刻开始编写调用代码
  • D.直接收集整库训练数据

答案：A。需求分析是项目的起点，先弄清“谁在什么场景问什么”，才能确定知识库范围和对话边界。B、C、D 都跳过了需求分析——方向错了，跑得越快越偏，就像还没定菜单就把后厨装修成了火锅店。

Q2. 用户说“帮我查一下物流”，这句话属于哪种用户意图？

单选题 · easy

  • A.指令式操作类意图← 正确答案
  • B.查询式知识类意图
  • C.闲聊式社交类意图
  • D.投诉式拒绝类意图

答案：A。“帮我”是典型的指令触发词，需要系统执行查物流这个动作，属于指令式意图。查询式要的是答案，闲聊式没有业务目的，投诉式需要转人工，都不符合这句话的性质。

Q3. 某 RAG 客服系统的可用性目标是 99.9%，按每月 30 天计算，一个月内最多允许停机多久？

单选题 · mid

  • A.约四十三分钟以内← 正确答案
  • B.约十三个小时以内
  • C.约三个小时以内
  • D.约四十五分钟每天

答案：A。可用性公式 A = T_up / (T_up + T_down)，99.9% 意味着停机时间占 0.1%。30 天 × 24 小时 × 60 分钟 × 0.1% ≈ 43.2 分钟。B、C 超过预算，D 说的是每天，全年每天 45 分钟远高于 99.9% 对应的停机预算。

Q4. 意图分类评测中，模型共预测了 80 条“查询式意图”，其中 70 条确实是查询，请问精确率是多少？

单选题 · mid

  • A.精确率约为百分之八十七← 正确答案
  • B.精确率约为百分之七十
  • C.精确率约为百分之八十
  • D.精确率约为百分之七十五

答案：A。精确率 P = TP / (TP + FP) = 70 / 80 = 87.5%。B 把精确率和召回率记混了，C 把预测总数当成了正确数，D 没有计算依据。精确率回答的是“模型说是查询的里面，有多少真的是查询”。

Q5. 关于功能需求矩阵中的优先级分档，下列说法正确的有哪些？

多选题 · hard

  • A.P0 是上线前必须完成的必备需求← 正确答案
  • B.P1 属于影响体验的重要需求← 正确答案
  • C.P2 需要在上线前全部提前完成
  • D.P3 属于锦上添花的增强需求← 正确答案

答案：ABD。P0 缺失会导致系统不可用，必须上线前完成；P1 影响核心体验但可分批发；P2 属于可后置的增强，C 说 P2 必须提前完成恰好相反；P3 是锦上添花。分档就像后厨排岗位：救火岗位先招，加分岗位等生意好了再扩。

Q6. 在 RAG 架构链路中，“重排”环节的核心作用是什么？

单选题 · hard

  • A.提升检索粗排的召回数量
  • B.对候选文档做精细化重排序← 正确答案
  • C.负责生成最终自然语言回答
  • D.把用户问题编码成文本向量

答案：B。重排（Rerank）发生在向量召回之后，用更精细的模型对 Top-N 候选文档重新打分，把最相关的排到最前。A 是召回阶段的目标，C 是生成阶段，D 是向量化阶段，都不是重排的职责。

Q7. 架构演进路线通常建议从哪里起步？

单选题 · easy

  • A.一步到位的大型生产集群
  • B.轻量单体原型快速验证← 正确答案
  • C.多租户微服务架构
  • D.分布式大数据湖仓系统

答案：B。正确路线是“单体原型 → 模块化拆分 → 生产级架构”。先用最小脚本验证 RAG 效果，再逐步拆分服务。A、C、D 都属于最后一步的过度设计，违背演进原则，就像路边摊直接雇 20 个厨师。

Q8. 下列哪些属于非功能需求？

多选题 · mid

  • A.响应时间控制在两秒以内← 正确答案
  • B.年可用性达到百分之九十九← 正确答案
  • C.支持多轮追问并记住上下文
  • D.日志留存满足安全审计要求← 正确答案

答案：ABD。非功能需求回答“系统做得怎么样”，包括延迟（A）、可用性（B）、安全合规（D）。C 描述的是系统具备多轮对话的具体能力，属于功能需求。类比餐厅：非功能需求是“上菜快、守时营业、食材安全”，功能需求是“菜单上的菜”。

Q9. 知识库数据更新机制设计的最核心目标是？

单选题 · hard

  • A.保证回答永远基于最新政策← 正确答案
  • B.提高向量化处理的吞吐率
  • C.降低模型推理的计算成本
  • D.增加知识文档的存储容量

答案：A。业务政策会变，过期文档会让 RAG 一本正经地给出错误答案。更新机制（定期重爬、版本管理、失效下线）的核心目标是让回答始终基于最新信息。B、C、D 分别关注吞吐、成本、容量，都不是“保鲜”的核心。

Q10. 需求分析阶段需要输出的成果包含哪些？

多选题 · mid

  • A.用户意图分类清单← 正确答案
  • B.功能需求优先级矩阵← 正确答案
  • C.开源组件的代码实现
  • D.非功能需求指标表← 正确答案

答案：ABD。需求分析阶段产出三类核心成果：意图分类（回答用户说什么）、需求矩阵（回答系统做什么）、非功能指标（回答做得怎么样）。C 属于技术选型与编码阶段的产物，晚于需求分析出现。