大模型 LLM 应用测试面试题

本文档包含 22 道大模型应用与 RAG 系统测试方向的高频面试题，覆盖 LLM 应用基础、Prompt 测试、参数与稳定性、幻觉检测、成本与延迟、RAG 端到端评估、向量检索、上线后监控等。

一、LLM 应用测试基础（10题）

Q1: 什么是 LLM 应用测试？主要测什么？

答案：

LLM 应用测试指的是对基于大语言模型构建的产品（聊天机器人、问答系统、文档助手、Agent、智能编程工具等）做端到端的质量验证，对象是「应用」而不是「模型本身」。

主要测的内容可以归成几块：

功能正确性。给定用户输入，能不能给出符合期望的回答，关键点是定义"符合期望"的标准。

事实性与准确性。回答是否符合事实，是否有幻觉，引用的内容是否真实存在。

一致性与稳定性。同样输入多次跑，结果是否在合理范围内稳定，跨版本跨模型是否回归。

安全性。是否能拒绝恶意指令、是否能抵抗 Prompt 注入、是否输出违规内容。

性能与成本。响应延迟、Token 消耗、并发能力、缓存命中率，跟商业模式直接挂钩。

体验与可用性。回答的语气、格式、长度、可读性是否满足产品定位。

跟传统应用测试相比，最大不同是「正确性边界模糊 + 输出不确定」，所以方法论和工具都要相应调整。

Q2: LLM 应用与传统应用最大的测试差异是什么？

答案：

差异主要集中在四个方面：

输出确定性。传统应用同样输入给同样输出，可以用 assertEquals；LLM 输出有概率性，需要用相似度、关键词命中、JSON Schema、LLM-as-Judge 等"软"断言。

正确性的定义。传统应用有明确预期值；LLM 很多场景没有唯一正确答案，需要靠评估指标 + 人工评判组合判断。

测试对象边界。传统应用测代码逻辑；LLM 应用要测 Prompt、上下文、模型版本、检索内容、工具调用、采样参数等多个"动态变量"。

回归成本。传统应用回归靠跑用例脚本；LLM 应用回归既要跑功能，也要跑评估集，还要做指标对比，单次回归往往要几十分钟到几小时，且每次都消耗 Token 成本。

应对的关键是把"不可控"逐步收敛：固定模型版本、固定温度、固定种子、版本化 Prompt、建立评估集、做缓存。

Q3: 什么是 Prompt 测试？怎么做 Prompt 的回归测试？

答案：

Prompt 测试是把 Prompt 当成代码来测，每次 Prompt 修改前后都要验证：能力没退化、新场景按预期改善、其他场景没受影响。

回归测试的常见做法：

建立评估数据集。覆盖核心业务场景、常见用户输入、已知会出问题的 corner case，每条数据带预期输出或评估规则。数据集要持续更新，把线上发现的问题持续回流。

定义评估指标。根据场景选合适的指标：分类任务用准确率、问答用 LLM-as-Judge + 关键词、JSON 输出用 Schema 校验和字段精确匹配、对话用人工评分。

固定环境。锁定模型版本、温度、采样参数，让评估结果可复现。

跑对比。新旧 Prompt 在同一数据集上各跑一遍，对比每条用例和总体指标，重点看劣化的用例。

CI 阻断。把 Prompt 评估接入 CI，关键指标低于基线就阻断合并。

工具上 Promptfoo、DeepEval、LangSmith 都能做这件事，差异在于配置形式（YAML / 代码 / 平台）和指标库丰富度。

落地几个坑：评估集太小不可信、阈值定得太严经常红、评估本身也消耗成本要控制规模、Prompt 改动同时改了多个变量难以归因。建议每次只改一个变量，逐步迭代。

Q4: 温度（temperature）、top_p、top_k 等采样参数对结果的影响？测试时如何控制？

答案：

这几个参数都控制大模型在生成时的"随机性"，理解它们的作用对测试设计很关键：

温度（temperature）。控制概率分布的平滑度，温度越低分布越尖锐（高概率词更突出），温度为 0 时基本是贪心解码。范围通常 0-2，0.7 左右是常见的对话温度。

top_p（Nucleus Sampling）。从累计概率前 p 的词里采样，p=1 时不限制，p=0.9 时只在概率最高的那部分词里选。

top_k。只在概率最高的 k 个词里选，跟 top_p 类似但更直接。

它们影响的是输出的多样性和稳定性。温度高、top_p 大输出更有创意但更不稳定，温度低、top_p 小输出更稳定但更"机械"。

测试时如何控制：

评估稳定性时温度调到 0（如果模型支持）或固定种子（部分模型如 OpenAI 的 seed 参数），让结果尽量复现。

评估真实体验时用线上实际参数，跑多次取分布而不是单次结论。

回归测试通常用低温度做基线对比，A/B 实验用真实参数看用户感受。

不同模型对这些参数的敏感度不同，本地模型的温度 0 可能跟 API 不一样，跨模型对比时要注意。

注意有些 LLM 的 temperature=0 仍然有少量随机性（实现细节），不能完全保证可复现，必要时跑多次取众数或平均。

Q5: 如何测试 LLM 输出的稳定性与一致性？

答案：

稳定性测试核心是回答「同样输入下输出是否在可接受范围内一致」，常规做法：

固定环境跑多次。同一组输入跑 N 次（N 通常 5-10），看输出的变化幅度。用相似度（cosine、ROUGE、BERTScore）量化变化，定义可接受的离散度。

跨版本对比。模型版本升级、Prompt 改动、温度调整后，跑同一评估集，对比通过率、关键指标分布。允许微调，但不能有结构性退化。

跨场景一致性。相同信息以不同方式表述（中英文、问句陈述句、长短不一），看回答核心信息是否一致。

冲突场景。给两个相似但有差异的问题，看模型是否能识别差异；给两次同样问题中间夹一个误导问题，看模型是否会被带偏。

输出格式稳定性。要求 JSON 输出时跑批量样本，校验 Schema 通过率和字段完整率，这是 LLM 应用最常见的不稳定问题。

工具上可以用 Promptfoo 配 multiple assertions、DeepEval 的 ConsistencyMetric，或自建脚本批量跑取分布。

Q6: 什么是幻觉（Hallucination）？如何检测幻觉？

答案：

幻觉指 LLM 输出看起来合理但实际不符合事实的内容，比如编造不存在的论文、虚构 API 接口、错误的统计数字。幻觉是 LLM 应用最常见也最难根治的问题。

检测幻觉的常见方法：

参考标注集。对每条测试用例标注"事实性事实"，跑模型后比对，是否所有事实陈述都有依据。适合知识库可控的场景。

LLM-as-Judge。用一个更强的模型作为裁判，把回答和参考材料一起喂进去，让它判断是否有不符合参考的陈述。Prompt 要明确判断标准，避免裁判自己也幻觉。

引用校验。要求模型在回答时引用具体来源（页面、段落、URL），后处理时校验引用是否真实存在、内容是否匹配。

事实抽取对比。从模型输出抽取事实陈述（人物、时间、数字、关系），跟权威数据源比对。

一致性自检。让模型对同一问题用不同方式提问几次，看核心事实是否一致；不一致的内容大概率是幻觉。

检测的难点是「不知道什么是对的」，所以 RAG 应用相对好检测（有参考文档），开放域问答幻觉检测最难，常常需要人工抽审作为补充。

业界常用指标如 Faithfulness（基于参考的真实性）、HallucinationRate、SelfCheckGPT 等。

Q7: 如何测试长上下文与 token 截断的影响？

答案：

长上下文是 LLM 实际落地最常见的雷区之一，因为模型对上下文不同位置的信息使用并不均匀，常见现象包括"中间遗忘"（Lost in the Middle）。

测试方法：

针孔测试（Needle-in-a-Haystack）。在长文本中故意插入一个特定信息（"针"），让模型回答和这个信息相关的问题，测试不同位置（开头、中间、结尾）和不同长度下的检索能力。Anthropic、OpenAI 都用这种方法测过自家模型。

边界测试。把上下文拼到接近模型上限（128K、200K、1M token），看输出质量是否退化、延迟和成本是否暴涨、是否触发截断。

截断行为测试。当上下文超过窗口时，应用是怎么处理的（前截、后截、智能裁剪、报错），不同截断策略对结果影响差多少。

多文档干扰测试。塞入多份相似文档，看模型能不能聚焦到正确文档；塞入冲突信息，看模型如何取舍。

成本敏感性测试。同样问题用 4K、16K、64K 上下文跑，看成本和质量曲线，找到性价比最优点。

落地建议：建立标准长文本评估集，每次模型升级或上下文策略改动都跑一遍；监控线上长上下文请求的失败率和成本，及时优化。

Q8: 如何测试流式输出（streaming）？

答案：

流式输出（Server-Sent Events / WebSocket）是 LLM 应用提升体验的标配，但也带来一些独特的测试需求：

首字延迟（Time To First Token, TTFT）。从用户发请求到收到第一个 Token 的时间，是流式体验的核心指标。一般要求 1 秒以内为优秀，3 秒以上明显有体感卡顿。

字间延迟（Inter-Token Latency, ITL）。Token 之间的间隔时间，影响"打字感"是否流畅。

完整输出延迟。从首字到结束的总时长，跟非流式接近但要单独测。

流式中断处理。客户端断连、超时、取消请求时，服务端是否正确释放资源、Token 是否照常计费、能否优雅恢复。

格式拼接正确性。流式输出可能在 Token 边界切断 JSON 或 Markdown，前端拼接和渲染是否正确，特殊字符（emoji、CJK 字符）是否会乱码。

并发压力。流式请求会保持长连接，测试在高并发下连接池、内存、CPU 是否吃得消。

降级与兜底。流式失败时是否能降级到非流式、是否给用户友好提示、错误日志是否完整。

工具上可以用 Locust、k6、JMeter 加自定义脚本测延迟和吞吐，前端用 Lighthouse 或 RUM 工具监控真实用户体验。

Q9: 如何测试 LLM 应用的延迟与 Token 成本？

答案：

LLM 应用的延迟和成本直接关系商业可行性，必须从一开始就纳入测试。

延迟测试主要看：

端到端延迟。从用户发请求到收到完整响应的时间，按 P50/P90/P99 看分布。

各阶段拆分。流式 TTFT、检索（RAG）耗时、模型推理耗时、后处理耗时，找瓶颈用。

并发下的延迟变化。低并发延迟低没用，要看 QPS 上升时延迟曲线，识别拐点。

成本测试主要看：

每次请求的 Token 消耗。Input Token + Output Token 分开统计，按模型单价算成本。

不同模型的成本对比。同样场景用 GPT-4 / Claude / Gemini / 国产模型对比，权衡质量和成本。

缓存命中率。重复或相似请求用缓存（精确缓存或语义缓存）能省多少成本。

异常成本。超长上下文、Agent 多轮调用、循环陷阱可能导致单次请求成本飙到几美元，要做单次成本上限保护。

落地建议：把成本和延迟监控接到 LLMOps 平台（LangSmith、Helicone、Langfuse），日报周报跟踪趋势；上线前做性能压测，预估生产环境成本和承载力；为每个用户/会话设成本上限，避免被恶意刷流量。

Q10: LLM 应用的回归测试有哪些常见做法？

答案：

LLM 应用的回归测试比传统应用更复杂，因为变量更多（Prompt、模型、参数、检索、工具），但核心思路还是「建立基线 + 持续对比」：

建立评估集。覆盖核心场景、典型问题、已知 corner case、来自线上的真实样本。数据集分层（冒烟集 + 回归集 + 长尾集），不同层级跑频率不同。

固定基线。某个版本的 Prompt + 模型 + 参数作为基线，记录这个组合在评估集上的指标分布。

每次变更跑回归。Prompt、模型、参数任何一项变了就跑一次回归，跟基线对比。多个指标各自有阈值。

差异分析。重点看哪些用例从通过变成失败、哪些从失败变成通过、哪些指标退化、哪些指标改善。失败用例要逐条看，找模式。

人工抽审。完全自动化评估总有盲点，关键场景每次回归都抽样人工看一遍。

数据集持续更新。线上新发现的问题、用户反馈的 case 都要回流到评估集，让数据集越来越能代表真实分布。

工具上 DeepEval / Promptfoo / LangSmith 都支持"基线-对比-阈值-阻断"工作流，按团队习惯选一个集成进 CI。

二、RAG 系统测试（12题）

Q11: 什么是 RAG？为什么 RAG 应用要专门测试？

答案：

RAG（Retrieval-Augmented Generation，检索增强生成）是把外部知识库通过检索的方式喂给 LLM 来生成回答的一种架构。典型流程是：用户提问 → 把问题转成向量 → 在向量库里检索相关文档 → 把检索结果拼到 Prompt 里 → 让 LLM 基于这些资料生成回答。

RAG 是当前企业落地 LLM 最主流的形态，因为它解决了几个核心问题：知识更新（不用重训模型）、可追溯（能引用来源）、可控成本（小模型 + 大知识库）、避免幻觉（基于事实回答）。

RAG 应用要专门测试是因为它的质量取决于多个环节，任何一环出问题都会让最终回答跑偏：

文档质量。原始资料是否完整、准确、最新、可读。

切分策略。文档怎么切 chunk、chunk 多大、是否有重叠，影响检索粒度。

向量化。用什么 Embedding 模型、向量维度、距离度量，影响检索准确性。

检索策略。Top-K、相似度阈值、混合检索（向量 + 关键词）、重排，影响召回质量。

Prompt 拼接。检索结果怎么排版、怎么提示模型基于资料回答、怎么处理冲突信息。

生成模型。基础能力、参数设置、对长上下文的处理。

只测最终回答会"知其然不知其所以然"，必须分层测试才能定位问题。

Q12: RAG 系统的测试可以分成哪几个层次？

答案：

通常分四层，每层有自己的指标和方法：

数据层。测试知识库本身的质量，包括文档完整性、版本一致性、敏感信息是否脱敏、是否有重复或过时内容。

检索层。测试给定问题，向量库能不能找到正确的文档片段。常用指标 Recall@K、Precision@K、MRR、nDCG。

生成层。测试给定问题和正确的检索内容，模型能不能生成准确回答。常用指标 Faithfulness（不离开参考材料）、Answer Relevance（回答切题）。

端到端层。测试整个流程从问题到回答的整体表现，常用指标 Context Precision、Context Recall、Answer Correctness 以及业务指标（用户满意度、解决率）。

分层测试的价值是定位问题：如果端到端效果差，先看是检索没找到（检索层问题）还是找到了但模型没用好（生成层问题）；如果检索差，再往下看是 Embedding 问题还是切分问题。每层独立可测，问题定位才高效。

Q13: 检索质量怎么评估？常用指标有哪些？

答案：

检索质量评估的核心是「相关文档有没有被找出来、找出来的文档有没有排在前面」，常用指标包括：

Recall@K。前 K 个检索结果里包含相关文档的比例。比如 Recall@5=0.8 表示 5 条结果里有 80% 的概率包含目标文档。

Precision@K。前 K 个结果里相关文档的占比。Precision 和 Recall 通常此消彼长。

MRR（Mean Reciprocal Rank）。第一个相关文档出现位置的倒数的平均值，关注"第一条相关结果排第几"。

nDCG（Normalized Discounted Cumulative Gain）。考虑相关性等级（不只是相关/不相关）和位置的综合指标，越靠前权重越高，通常用于多级相关性的场景。

Hit Rate。Top-K 里至少有一个相关结果的比例，比 Recall 更宽松。

测试时需要先准备评估集：每个 Query 标注哪些文档是相关的（可以分等级：高度相关、部分相关、不相关）。然后用不同检索策略跑，对比指标。

实战建议：单一指标会误导，多个指标一起看；评估集要覆盖不同类型的问题（事实查询、长尾查询、模糊查询）；定期用线上日志更新评估集。

Q14: 生成质量怎么评估？常用指标有哪些？

答案：

生成质量评估比检索复杂，因为没有唯一正确答案。常用指标分两类：

基于参考的指标。需要标注标准答案，跟生成结果对比。

• ROUGE：n-gram 重合度，常用于摘要评估。
• BLEU：跟翻译评估同源，看 n-gram 精度。
• BERTScore：用 BERT 把答案和参考都编码，算语义相似度。
• 精确匹配 / F1 Token Overlap：适合事实型问答。

无参考指标（基于 LLM 评判）。不需要标准答案，让另一个 LLM 当裁判：

• Faithfulness：回答是否忠于检索到的材料，不编造。
• Answer Relevance：回答是否切题。
• Coherence：表达是否连贯。
• Completeness：是否覆盖了所有相关信息。

业务指标。从用户角度看：

• 满意度评分（用户打分）。
• 解决率（用户是否满意没追问）。
• 转人工率（智能客服场景）。

实战中通常多种指标组合用：基于参考的指标做底线评估、LLM-as-Judge 做主观评估、业务指标做最终验证。

注意 BLEU/ROUGE 这类传统指标在 LLM 评估场景里参考价值有限（同样含义不同表达分数差很多），更推荐 BERTScore 和 LLM-as-Judge。

Q15: 什么是 Faithfulness、Answer Relevance、Context Precision、Context Recall？

答案：

这是 RAGAS 框架定义的四个核心指标，已经成为 RAG 评估的事实标准：

Faithfulness（忠实度）。回答是否完全基于检索到的上下文，不编造也不引入外部知识。计算方法是把回答拆成多个事实陈述，每条用 LLM 判断是否能从上下文中推出，能推出的比例就是 Faithfulness。低分意味着模型在"幻觉"。

Answer Relevance（答案相关性）。回答是否切题，是否回应了用户的实际问题。计算方法是用 LLM 从答案反推几个可能的问题，跟原始问题做相似度对比。低分意味着回答跑题或太啰嗦。

Context Precision（上下文精确度）。检索到的上下文中，对回答有用的部分占比。如果检索回 5 个 chunk 但只有 1 个跟问题相关，Precision 就低。

Context Recall（上下文召回率）。生成正确答案所需的所有信息，是否都在检索到的上下文里。如果答案需要的某个信息没被检索到，Recall 就低。

四个指标分别覆盖不同维度：Faithfulness 看模型有没有乱说，Answer Relevance 看回答切不切题，Context Precision 看检索是否精准，Context Recall 看检索是否完整。RAG 整体表现要四个指标一起看。

落地时需要标注评估集（问题、上下文、参考答案），然后用 RAGAS、TruLens 或 DeepEval 这类工具批量跑。

Q16: RAGAS 框架是什么？怎么用？

答案：

RAGAS（RAG Assessment）是开源的 RAG 评估框架，提供前面提到的 Faithfulness、Answer Relevance、Context Precision、Context Recall 等核心指标的开箱即用实现，是当前 RAG 评估的标杆工具之一。

核心特性：

无参考评估。多数指标基于 LLM-as-Judge，不需要事先标注标准答案，降低评估门槛。

指标丰富。除了核心四指标，还有 Answer Correctness、Answer Similarity、Context Entity Recall、Noise Sensitivity 等。

数据集兼容。支持 HuggingFace Dataset 格式，跟现代 ML 工作流无缝集成。

合成数据生成。支持从知识库自动生成评估数据集，省去人工标注大量样本的成本。

框架集成。原生集成 LangChain、LlamaIndex，主流 LLM Provider 都支持。

典型使用流程：

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall

dataset = ...  # 包含 question / answer / contexts / ground_truth
result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
print(result)

落地几个注意点：

LLM-as-Judge 的稳定性受裁判模型影响，建议固定裁判模型版本和参数。

评估本身有成本（每条评估调用裁判模型 N 次），大数据集要做采样和缓存。

跨版本对比时确保评估配置一致，否则数据没有可比性。

合成数据集是个好起点，但关键场景仍需要人工标注的高质量评估集兜底。

Q17: 向量库召回的测试要注意哪些点？

答案：

向量召回是 RAG 的核心环节，测试时几个常见关注点：

Embedding 模型选型。不同 Embedding 模型对同一查询返回的相似度差别大，要在自己的数据上做对比测试。常见对比 OpenAI text-embedding-3、BGE、M3E、Voyage、Cohere 等，国内场景中文模型通常表现更好。

向量维度与索引类型。维度越高表达能力越强但存储和检索成本也高；索引算法（FLAT、IVF、HNSW、ScaNN）的精度和速度有 trade-off，要按数据规模选。

距离度量。Cosine、Dot Product、Euclidean，不同 Embedding 模型推荐的度量不同，用错效果会差很多。

Top-K 的影响。K 太小召回不够、K 太大噪声多还增加 Token 成本，需要在评估集上调优。

混合检索。纯向量检索对术语精确匹配差，常需要混合 BM25 等关键词检索（Hybrid Search），权重要调。

重排（Rerank）。用 Cross-Encoder 模型对初筛结果做精排，能显著提升 Precision，常见模型如 bge-reranker、Cohere Rerank。

边界测试。空查询、超长查询、纯特殊字符、多语言混合查询的行为。

性能与扩展性。索引构建时长、查询延迟、内存占用，数据量翻倍时的表现。

测试时建议把每个变量独立改一次跑评估，再做组合实验，避免变量太多无法归因。

Q18: chunk 切分策略对 RAG 测试的影响？怎么测？

答案：

chunk 切分是 RAG 中影响最容易被忽视也最容易踩坑的环节。切得太大检索不精准、太小又丢上下文，需要专门测试。

常见切分策略：

固定长度切分。按字符数或 Token 数切，简单但容易切断语义。

基于分隔符切分。按段落、句子、Markdown 标题切，保留语义结构。

递归切分（Recursive Splitter）。按多个分隔符层级递归切，常见 LangChain 默认实现。

语义切分。用 Embedding 找语义边界，把语义相近的内容聚到一起。

按结构切分。表格、代码、图片各自处理，避免被切断。

重叠（overlap）。chunk 之间保留一定重叠，避免边界信息丢失。

测试方法：

对同一份文档用不同策略切，跑同一组 Query 看检索质量（Recall@K、Precision@K）和生成质量（Faithfulness、Answer Relevance）。

对长尾问题（答案分布在多个段落、需要跨段推理）专门设计测试集，看不同策略表现差异。

监控线上召回的 chunk 长度分布、内容完整性、是否有"断头"chunk（开头就是半句话）。

测试不同 chunk size（256、512、1024、2048 tokens）对成本和质量的曲线，找到性价比最优。

实战中没有"最佳"切分策略，跟文档类型、查询模式都强相关，只能在自己的数据上测。

Q19: 如何测试 RAG 系统的知识更新与版本变更？

答案：

RAG 的核心价值之一是知识可更新，但每次更新都可能破坏已有能力，需要专门的回归测试：

知识更新前的基线。在更新前跑一遍标准评估集，记录关键指标和典型回答。

增量更新测试。新增文档后跑评估集，看新文档相关问题表现是否改善、原有问题表现是否退化。

删除/修改测试。修改或删除文档后，相关问题回答是否同步更新，是否还有"幽灵知识"残留。

时效性测试。给"当前 X 是什么"这类有时效性的问题，看模型是否正确反映最新信息而不是依赖训练数据。

冲突信息测试。新旧文档信息冲突时，模型如何选择，要符合业务约定（通常应优先用最新文档）。

索引重建测试。大批量更新可能需要重建索引，测试重建前后的检索一致性、性能变化、停机时间影响。

灰度更新策略。生产环境通常不会一次性切流，要支持新旧索引并存灰度，测试灰度过程中的一致性。

工具上可以做"知识快照 + 评估快照"组合，每次重大更新前后都生成快照，方便对比和回滚。

Q20: RAG 系统中的相关性问题（找回但不准）如何排查？

答案：

"找回但不准"是 RAG 最常见的问题，排查思路按链路从头到尾走：

先看 Embedding。检查问题和目标文档的 Embedding 相似度是不是合理（通过余弦相似度量化），太低说明 Embedding 模型对该领域语义理解差，可能需要换模型或微调。

再看 chunk。看检索回的 chunk 是否包含答案所需的完整信息，如果 chunk 太碎或被断开，需要调整切分策略。

看 Top-K 设置。当前 K 是不是太小漏了相关 chunk，可以临时调大 K 看看正确文档排第几。

看检索策略。是不是只用了向量检索，对术语精确匹配差。试试加 BM25 混合检索或加 Rerank。

看 Prompt 拼接。检索回的 chunk 是不是因为顺序、格式或 Prompt 设计导致模型没用好。试试改变 chunk 顺序、加引用要求。

看模型本身。同样上下文换更强的模型试试，如果效果显著好说明是模型能力问题。

看是否需要 Query Rewrite。原始问题表述跟文档差异大，先用 LLM 改写问题再检索，效果会好很多。

排查时建议固定其他变量，每次只调一个，避免改了一堆不知道哪个起作用。

Q21: 多轮对话中的 RAG 怎么测？

答案：

多轮 RAG 比单轮复杂，因为每一轮都要考虑历史对话和指代消解。测试要点：

指代消解。"它支持哪些功能" 这种问句，"它"是上文提到的某个产品，RAG 检索时要把指代展开成完整查询，否则检索结果会不相关。

上下文窗口管理。多轮对话历史会越来越长，超过窗口时如何截断（保留系统 Prompt + 最近 N 轮 + 关键检索）需要测试。

话题切换。对话中突然切换话题（"换个话题，问一下…"），RAG 是否能正确识别并丢弃前面的上下文。

记忆一致性。模型在之前几轮提到的事实（"我刚才说了我用的是 v2 版本"），后续回答是否能保持一致。

历史重写（History Rewriting）。常见做法是用 LLM 把当前问题 + 历史对话改写成独立查询再去检索，要测改写质量和延迟成本。

错误恢复。前面有错回答时，用户纠正后能不能正确调整后续回答。

测试时建议设计一些典型多轮场景作为评估集（5-10 轮的对话），每一轮都标注预期行为，跑回归时一轮一轮验证。

工具上 LangSmith、DeepEval 都支持多轮 trace 评估，能看清每一轮的检索和回答细节。

Q22: RAG 系统上线后如何做线上监控与持续评估？

答案：

RAG 上线后必须有持续监控，否则数据更新、模型漂移、用户行为变化都可能让效果悄悄退化：

实时监控。每次 RAG 调用记录 Query、检索内容、回答、延迟、成本、用户反馈。仪表盘看核心指标趋势（响应时间、Token 消耗、错误率）。

采样回流离线评估。每天/每周从线上采样一批真实 Query，离线跑 RAGAS 等指标，看 Faithfulness、Relevance 等是否有趋势性变化。

用户反馈收集。在产品里加点赞/点踩、追问率、转人工率等显式或隐式反馈，作为线上质量信号。

异常检测告警。延迟突增、错误率上升、负反馈率上升、关键指标突变要自动告警。

数据漂移监控。Query 的语义分布、检索文档的分布是否发生显著变化，可能预示业务或用户行为变化。

模型与索引版本管理。线上要清楚当前用的是哪个模型、哪个索引快照、哪个 Prompt 版本，出问题能快速回滚。

对照实验。新版本灰度时跟基线版本同时在线，按比例分流，对比两边指标决定是否全量。

持续迭代评估集。把线上发现的 bad case 持续回流到评估集，让评估集越来越能代表真实流量。

工具上 LangSmith、Langfuse、Helicone 这类 LLMOps 平台都提供 trace、监控、评估三件套，自部署的话 Langfuse + 自建采样脚本是常见组合。