AI测试开发实战：RAG与智能体的工程化验证体系

1. 这不是“学AI”的速成班，而是一套能立刻上手写测试脚本的工程化训练体系

“人工智能测试开发”这八个字，最近半年在招聘平台和内推群里出现频率直线上升，但绝大多数人点开岗位JD后第一反应是懵的——它既不像传统功能测试那样有明确的用例执行路径，也不像算法岗那样要求扎实的数学功底，更不像运维岗那样围着服务器打转。它卡在一个特别真实的缝隙里：业务方急着上线大模型应用，开发团队刚跑通一个RAG流程，产品经理甩过来一份“支持多轮对话+知识库检索+结果可验证”的需求，而测试工程师打开Postman，发现连请求体该填什么字段都得先读三遍文档。我带过7期测试团队转型AI项目，最常听到的抱怨不是“不会”，而是“不知道从哪下手”——工具链太散、概念太新、验证逻辑太模糊。这个训练营标题里藏着两个关键信号：“六大模块”不是知识罗列，而是按真实交付节奏切分的工程阶段；“10大实战项目”不是Demo堆砌，而是覆盖了从单点能力验证（比如用LangChain读Excel测试用例生成Playwright脚本）到端到端闭环（比如搭建一个能自动回归验证RAG召回准确率的智能体）。它解决的不是“要不要学AI”，而是“明天晨会就要汇报测试方案，今天下午怎么写出第一行可运行代码”。适合三类人：干了3年功能测试想突破瓶颈的工程师、刚毕业但简历里只有Selenium基础的应届生、以及技术负责人——你不需要自己写代码，但必须能判断测试方案是否覆盖了Embedding漂移、Prompt注入、上下文截断这些真实风险点。核心关键词就五个：人工智能、测试开发、大模型、RAG、智能体，它们不是并列关系，而是层层嵌套的验证对象：你要测的不是“AI”，而是“跑在特定架构上的AI服务”，它的输入输出、状态流转、错误边界，全由RAG或智能体框架定义。所以这个训练营的起点，从来不是Python语法，而是读懂一份LangChain调试日志里那行Retriever returned 3 documents, top_k=5意味着什么。

2. 内容整体设计与思路拆解：为什么必须用“模块+项目”双轨制？

2.1 拆解“六大模块”的底层逻辑：拒绝知识搬运，聚焦验证动作

市面上90%的AI测试课程把模块设计成“大模型原理→LangChain入门→RAG构建→智能体开发→评估方法→部署监控”，看似完整，实则致命。我去年帮某金融客户做AI测试能力建设时发现，他们的测试工程师花两周学完Transformer结构，回到工位面对一个已上线的信贷审批RAG系统，依然不知道该测什么——因为模型结构和业务验证之间隔着三层抽象：第一层是向量数据库的索引策略（比如HNSW vs IVF），第二层是检索器的重排序逻辑（比如Cohere Rerank vs 自研BM25+语义混合），第三层才是业务规则（比如“拒贷理由必须包含‘收入不足’或‘负债过高’”）。所以这个训练营的六大模块，本质是六类必须亲手操作的验证动作：

• 模块一：AI服务接口契约验证
  不是教你怎么调API，而是训练你用OpenAPI Schema反向生成测试用例——当开发给你一份Swagger文档，你能立刻识别出哪些字段是必填、哪些是枚举值、哪些字段组合会产生冲突（比如top_k=0和return_metadata=true同时出现）。重点练的是Postman的Tests脚本和JSON Schema校验，而不是背HTTP状态码。

• 模块二：RAG流水线断点诊断
  把RAG拆成“文档加载→文本分割→Embedding→向量存储→检索→重排序→LLM生成”七个环节，每个环节配一个故障模拟环境。比如故意把ChromaDB的n_results参数设为1，但业务要求返回3个最相关片段，你得用Python脚本抓取检索日志，对比retrieved_docs和expected_docs的相似度得分分布，而不是只看最终回答对不对。

• 模块三：大模型输出稳定性压测
  重点不是QPS，而是同一问题连续100次请求的输出一致性。我们用真实业务问题（如“根据这份合同摘要，列出3条甲方违约风险”）跑LangChain的RetryPolicy，记录每次生成的JSON结构是否符合Schema、关键字段（如risk_items数组长度）是否恒定。这里会暴露很多隐藏坑：比如某些开源模型在温度值设为0时反而更不稳定，或者当输入token接近上限时，LLM会随机截断输出。

• 模块四：智能体状态机验证
  智能体不是“更聪明的聊天机器人”，它是有明确定义的状态迁移图。训练营里用LangGraph搭一个客服工单处理Agent，你必须手动绘制它的状态图（awaiting_user_input → analyzing_issue → querying_kb → drafting_response → waiting_approval），然后用JUnit写状态迁移测试——比如当用户输入“我要投诉”，Agent必须进入analyzing_issue状态，而不是直接跳到drafting_response。这比背诵Agent框架API重要十倍。

• 模块五：评估指标工程化落地
  拒绝“人工打分”。教你怎么把业务指标翻译成可计算的函数：比如“回答准确性”不是主观评分，而是定义为len(extract_entities(answer) ∩ extract_entities(ground_truth)) / len(extract_entities(ground_truth))，其中实体抽取用spaCy而非LLM，确保评估过程不引入新噪声。所有评估脚本都封装成CLI工具，一键跑完生成HTML报告。

• 模块六：生产环境可观测性植入
  测试不是上线前的最后一步，而是贯穿生命周期。模块里教你在LangChain链路里埋点：比如给每个RunnablePassthrough加on_chain_start回调，记录输入token数、耗时、下游服务响应码；用Prometheus暴露rag_retrieval_latency_seconds_bucket指标；当llm_output_length突增200%，自动触发告警并保存上下文快照。这才是真正的“测试左移”。

提示：所有模块的练习数据都来自真实脱敏项目——某电商的售后知识库RAG、某政务热线的智能体工单系统、某银行的信贷报告生成服务。没有虚构的“Hello World”，只有“昨天刚上线的接口，今天要回归的用例”。

2.2 “10大实战项目”的筛选标准：每个项目必须解决一个具体交付阻塞点

项目不是为了炫技，而是为了破局。我们筛掉所有“用Streamlit搭个UI”的项目，只保留那些测试工程师在真实项目中卡住超过2小时的场景：

1. 项目1：从Excel测试用例自动生成Playwright脚本
   输入：销售部门提供的200行Excel用例（含URL、操作步骤、预期结果）
   输出：可直接执行的.spec.ts文件，且能动态注入测试数据（如用例中的客户ID自动替换为当前环境可用ID）
   关键难点：Excel里“点击搜索按钮”这种自然语言描述，如何映射到Playwright的page.getByRole('button', { name: '搜索' })选择器？我们用小型微调模型（LoRA on Qwen）做指令微调，不是为了生成完美代码，而是生成90%可用的骨架，剩下10%人工补selector。

2. 项目2：RAG知识库变更影响范围分析
   当法务部更新了100份合同模板，如何快速定位哪些问答对会受影响？项目教你用Sentence-BERT计算新旧文档的语义距离矩阵，结合业务规则（如“涉及‘违约金条款’的问答必须重测”），生成影响报告和回归测试集。

3. 项目3：大模型幻觉检测沙盒
   构建一个对抗测试环境：给LLM输入“请列出2023年诺贝尔物理学奖得主”，故意在提示词里埋入错误信息（如“根据《自然》杂志2023年10月报道…”），观察模型是否复述错误。用Diffusers生成对抗样本图片测试多模态模型，重点练的是如何设计“诱导性提示”。

4. 项目4：智能体循环调用熔断机制验证
   某客服Agent在用户反复说“我不明白”时，会不断调用知识库检索→LLM生成→重试，导致API调用雪崩。项目要求你用Locust模拟并发，监控agent_loop_count指标，当单次会话循环超3次时，强制触发降级策略（返回预设FAQ列表）。

5. 项目5：本地化RAG性能基线测试
   在4GB显存的RTX4060上部署Llama3-8B+ChromaDB，测量不同chunk_size（128/256/512）下的首字延迟、召回率、内存占用三者平衡点。不是跑一遍就完事，而是用Py-Spy抓取CPU火焰图，定位瓶颈在Embedding还是向量检索。

6. 项目6：Prompt注入攻击面测绘
   针对一个医疗问诊Agent，系统性测试12类Prompt注入变体（角色扮演、XML注入、Base64编码绕过等），记录每种攻击的成功率和泄露信息类型（如系统提示词、知识库路径）。产出物是可导入Burp Suite的测试用例集。

7. 项目7：多租户RAG隔离性验证
   某SaaS平台为不同客户部署独立RAG实例，但共享同一个向量数据库。项目要求你构造跨租户查询（如用客户A的API Key访问客户B的知识片段），验证Embedding命名空间隔离是否生效。

8. 项目8：LLM输出格式强校验工具链
   开发一个CLI工具：输入JSON Schema和LLM原始输出，自动修复格式错误（如将"items": ["a","b"]补全为{"items": ["a","b"]}），并标记不可修复的语义错误（如"price": "free"违反"type": "number"）。这比写100个正则表达式更可靠。

9. 项目9：智能体决策链路回溯
   当Agent给出错误建议时，如何还原它“为什么选这条路”？项目教你用LangGraph的StateSnapshot机制，保存每步调用的输入输出、调用时间、所用工具，生成可交互的决策树可视化（用Mermaid语法生成，非图表渲染）。

10. 项目10：AI服务混沌工程实验
    在K8s集群里对RAG服务注入网络延迟（tc qdisc add dev eth0 root netem delay 1000ms）、内存泄漏（stress-ng --vm 1 --vm-bytes 2G），观察智能体是否优雅降级（如切换到缓存答案），并用Jaeger追踪失败请求的完整链路。

注意：所有项目都提供“最小可行交付物（MVDO）”标准——不是“代码能跑”，而是“交付物能直接插入CI/CD流水线”。比如项目1的输出必须是符合Playwright v1.42规范的TypeScript文件，项目5的报告必须包含latency_p95: 1240ms这样的Prometheus兼容指标。

3. 核心细节解析与实操要点：从LangChain调试日志开始的第一课

3.1 真正的起点：读懂LangChain的DEBUG日志，比写代码更重要

很多测试工程师卡在第一步：连环境都起不来。不是因为不会装Python，而是看不懂启动日志里的关键信号。比如这段典型日志：

DEBUG:langchain_core.runnables:Invoking runnable with config={'callbacks': [<langchain.callbacks.tracers.langchain.LangChainTracer object at 0x7f8b1c0d2e50>], 'run_name': 'Retriever'} DEBUG:langchain_community.vectorstores.chroma:Searching with query: '如何申请退款' and k=3 DEBUG:langchain_community.embeddings.huggingface:HuggingFaceEmbeddings: Using model 'BAAI/bge-small-zh-v1.5' INFO:langchain_community.vectorstores.chroma:Found 3 documents in ChromaDB DEBUG:langchain_core.runnables:Invoking runnable with config={'callbacks': [...], 'run_name': 'LLM'} DEBUG:langchain_community.llms.ollama:Ollama: Using model 'qwen2:7b' INFO:langchain_community.llms.ollama:Ollama response took 2.34s, tokens: 156

新手会盯着Ollama response took 2.34s觉得慢，但老手第一眼扫的是k=3和Found 3 documents——如果业务要求召回5个片段，这里就存在配置错位。再往下看tokens: 156，结合模型上下文窗口（Qwen2-7B是32K），能预判当用户输入长文档时是否触发截断。训练营第一课就是带学员逐行解析这类日志，建立三个检查清单：

• 检索层检查：k值是否匹配业务需求？Found X documents是否等于k？如果不等（比如k=5但只找到2个），说明知识库覆盖率不足或Embedding质量差；
• LLM层检查：response took Xs是否在SLA内？tokens是否接近模型上限？如果tokens持续>25K，需预警上下文溢出风险；
• 链路层检查：run_name是否按预期顺序出现？比如Retriever后应该接LLM，如果中间插了Router，说明路由逻辑被触发，需检查路由条件是否合理。

实操中我们会故意制造日志异常：比如把ChromaDB的k参数硬编码为1，但业务用例要求返回3个答案，让学员通过日志定位问题，而不是靠猜。这比教100个API参数更有效。

3.2 RAG测试的黄金三角：召回率、相关性、时效性，缺一不可

RAG测试最容易陷入的误区是只测“最终答案对不对”。但真实项目中，90%的问题出在中间环节。我们用“黄金三角”模型定义RAG健康度：

• 召回率（Recall）：知识库中所有相关文档，被检索器找出来的比例。计算公式：TP / (TP + FN)，其中TP是正确召回的文档数，FN是漏召的文档数。测试方法：人工标注100个问题的“黄金文档集”，用chroma.get(where={"question_id": "Q1"})查出实际召回文档，比对交集。
• 相关性（Relevance）：检索器返回的文档中，真正相关的比例。计算公式：TP / (TP + FP)，FP是误召的无关文档。测试方法：对每个召回文档打分（0-3分），>2分才算相关，统计平均分。
• 时效性（Timeliness）：从用户提问到返回答案的端到端延迟。但关键不是P95，而是长尾延迟——比如90%请求<1s，但10%卡在3s以上。用Prometheus的histogram_quantile(0.99, rate(chroma_query_duration_seconds_bucket[1h]))抓P99。

这三个指标必须联动分析。比如某次测试召回率95%但相关性仅40%，说明检索器过于激进（召回了很多弱相关文档）；如果相关性90%但时效性暴跌，可能是重排序模型（如Cohere Rerank）拖慢了流水线。训练营里会带学员用Python脚本批量计算这三个指标，并生成雷达图——当某个角塌陷时，立刻知道该优化哪个组件。

实操心得：别信开发说的“我们用了最先进的Embedding模型”。我见过用text-embedding-3-large的项目，召回率还不如用bge-small-zh-v1.5，原因在于前者对中文长尾词泛化差。测试时必须用业务真实query测试，而不是通用benchmark。

3.3 智能体测试的核心：状态验证比输出验证更关键

智能体测试最大的陷阱是把Agent当成“高级LLM”来测。比如一个工单处理Agent，测试用例写成“输入‘我的订单没收到’，期望输出‘已为您创建工单#12345’”。这完全错了。Agent的本质是状态机，它的价值在于状态迁移的确定性。正确测试方式分三步：

1. 状态定义：明确每个状态的进入/退出条件。比如waiting_approval状态的进入条件是LLM_output.contains("请主管审核")且user_role == "manager"；
2. 状态观测：在LangGraph中启用checkpointer，每次状态变更时保存StateSnapshot，包含next（下一步状态）、messages（当前消息历史）、tool_calls（调用的工具）；
3. 状态断言：用Pytest写断言，不是断言输出字符串，而是断言状态属性。例如：

def test_agent_moves_to_approval_state(): state = run_agent("我的订单没收到") assert state["next"] == ["waiting_approval"] assert len(state["messages"]) == 3 # system + user + assistant assert state["tool_calls"][0]["name"] == "create_ticket"

这样测试的好处是：当开发把waiting_approval改成pending_review时，测试会立刻失败，而不是等上线后才发现流程断了。训练营里所有智能体项目都强制要求先画状态图，再写测试，最后才写实现代码——倒逼开发思维结构化。

3.4 大模型评估的避坑指南：为什么BLEU分数毫无意义

很多团队用BLEU、ROUGE这些NLP传统指标评估LLM输出，结果发现分数很高但业务效果很差。根本原因是这些指标只算表面token匹配，不关心语义正确性。比如问题“苹果公司CEO是谁”，标准答案是“蒂姆·库克”，但LLM回答“蒂姆·库克，他于2011年接替史蒂夫·乔布斯”，BLEU分数可能高达0.9，可如果业务场景是“提取CEO姓名用于表单填充”，多余信息反而导致解析失败。

训练营教四类业务导向的评估法：

• 结构化提取评估：用正则或spaCy提取关键字段，比对是否匹配。比如从回答中提取{"ceo": "Tim Cook"}，再和Ground Truth JSON比对；
• 事实核查评估：调用外部API验证事实。比如回答“珠穆朗玛峰海拔8848.86米”，用地理信息API查证；
• 逻辑一致性评估：对多步推理题，验证中间步骤是否自洽。比如“如果A>B且B>C，那么A>C吗？”回答“是”，但若追问“为什么”，回答“因为A最大”，这就是逻辑断裂；
• 业务规则评估：把业务规则编译成可执行函数。比如保险条款问答，规则是“所有回答必须包含免责条款引用”，写个函数检查输出是否含"依据《XX条款》第X条"。

所有评估脚本都封装成evaluate.py --task=ceo_extraction --model=qwen2:7b，输出标准化JSON报告，直接对接Jenkins。不追求学术指标，只关注业务指标能否达标。

4. 实操过程与核心环节实现：以“Excel用例生成Playwright脚本”为例

4.1 项目目标与约束条件：不是AI生成，而是AI辅助的确定性工程

这个项目常被误解为“用大模型写自动化脚本”，实则核心是确定性工程。我们的目标不是让AI写出100%完美的Playwright代码，而是构建一个管道：Excel用例 → 结构化解析 → 选择器映射 → 脚本生成 → 人工校验 → CI集成。关键约束有三条：

• 选择器必须可维护：不能生成page.locator("div:nth-child(3) > button")这种脆弱选择器，必须基于语义（如page.getByRole('button', { name: '提交' })）；
• 数据注入必须安全：Excel里的测试数据（如邮箱、手机号）要自动脱敏，生成脚本时替换为process.env.TEST_EMAIL这样的环境变量；
• 输出必须可执行：生成的.spec.ts文件要通过TypeScript编译，且能被Playwright Test Runner直接执行。

这意味着AI只负责“理解自然语言意图”，不负责“生成最终代码”。我们用Qwen2-1.5B做微调，训练数据是1000对样本：左边是Excel里的操作描述（如“在搜索框输入‘iPhone15’，点击搜索按钮”），右边是对应的Playwright代码片段。微调目标不是100%准确，而是90%生成语义正确的骨架，剩下10%由规则引擎补全。

4.2 核心实现步骤：四步管道，每步都有防错机制

步骤1：Excel解析与结构化建模

不用Pandas直接读Excel，而是用openpyxl逐行解析，因为测试用例常含合并单元格、批注等非结构化信息。关键处理：

• 用例ID提取：从第一列非空单元格读取TC-001这类ID，作为脚本文件名；
• 操作步骤拆解：用正则r'([①②③]|[1-9]\.)\s*(.*)'匹配编号步骤，避免AI误判“点击搜索按钮（快捷键Ctrl+S）”为两个操作；
• 预期结果标准化：将“页面显示‘未找到商品’”转为expect(page.getByText('未找到商品')).toBeVisible()这样的断言语句。

实操技巧：Excel里常有“截图附件”列，我们不处理图片，而是提取图片文件名（如TC-001_step3.png），生成脚本时自动添加await page.screenshot({ path: 'screenshots/TC-001_step3.png' })，方便后续比对。

步骤2：自然语言到选择器的映射引擎

这是最易出错的环节。AI可能把“搜索按钮”映射到page.getByText('搜索')，但实际页面是<button aria-label="搜索">🔍</button>。我们构建三层映射：

• 语义层：用spaCy对操作描述做依存分析，提取动词（click）、宾语（search button）、修饰语（primary）；
• DOM层：爬取目标页面HTML，用CSS选择器生成器（如SelectorGadget）提取所有按钮的aria-label、>- name: Run generated tests run: npx playwright test --project=chromium --grep=${{ github.event.inputs.test_id }} - name: Upload test report uses: dorny/test-reporter@v1 if: always() with: name: Playwright Test Report path: playwright-report/index.html reporter: playright

  当测试失败时，自动触发Issue创建，附带失败截图、控制台日志、以及原始Excel用例链接。这样测试工程师看到Issue，就知道是脚本问题还是应用BUG，而不是在日志里大海捞针。

  4.3 参数选择与性能权衡：为什么选Qwen2-1.5B而不是更大模型

  项目初期我们试过Llama3-8B，生成质量略高（92%骨架正确），但推理速度太慢（单次生成平均8秒），无法满足“编辑Excel后10秒内生成脚本”的需求。最终选Qwen2-1.5B，原因有三：

  • 量化友好：用AWQ量化到4-bit，显存占用从3.2GB降到1.1GB，可在消费级显卡运行；
  • 中文适配好：在中文测试用例数据集上，微调后准确率比Llama3高3个百分点；
  • 推理稳定：Llama3在长上下文（>2000 token）时偶发OOM，Qwen2-1.5B无此问题。

  参数调优实录：

  • max_new_tokens=256：足够生成Playwright代码，再长容易引入冗余；
  • temperature=0.1：降低随机性，保证相同输入总是生成相同输出；
  • top_p=0.95：保留一定多样性，避免死板重复。

  踩过的坑：曾用temperature=0.7，导致同一用例多次生成不同选择器（如有时用getByText，有时用getByRole），破坏了脚本一致性。后来强制设为0.1，并加规则校验，问题解决。

  5. 常见问题与排查技巧实录：来自7个真实项目的故障库

  5.1 RAG召回率骤降：不是模型问题，而是向量数据库的“幽灵索引”

  现象：某政务知识库RAG上线后，召回率从95%跌到60%，但Embedding模型和文档都没变。

  排查过程：

  • 第一步：确认ChromaDB版本。发现从v0.4.20升级到v0.4.24，新版本默认启用hnsw:space=cosine，而旧版本用l2距离。两种距离算法对同一向量集的排序结果差异可达40%；
  • 第二步：检查索引重建日志。发现运维同学用chroma.reset()清库后，没重新add_documents()，而是直接persist()，导致索引元数据损坏；
  • 第三步：验证向量一致性。用collection.get(ids=["doc1"])取出向量，与原始Embedding比对，发现数值有微小漂移（浮点精度误差）。

  解决方案：

  • 回滚ChromaDB到v0.4.20；
  • 重建索引时强制指定distance_function="l2"；
  • 加入CI检查：每次部署前，用10个固定query跑召回，P95召回率低于90%则阻断发布。

  经验：RAG问题80%出在基础设施层，不是模型层。永远先查向量数据库日志，再查LLM日志。

  5.2 智能体无限循环：状态机缺失“超时退出”状态

  现象：客服Agent在用户连续发送“？”时，不断调用知识库→LLM→重试，直到API限流。

  根因分析：

  • 状态图里只有awaiting_user_input → analyzing_issue → querying_kb → drafting_response，缺少max_retry_exceeded状态；
  • LangGraph的interrupt机制没启用，无法在循环次数超限时强制中断；
  • LLM的system prompt里写了“请始终尝试回答”，没加“最多尝试3次”。

  修复方案：

  • 在状态图中增加retry_count字段，每次循环+1；
  • 当retry_count > 3时，自动跳转到fallback_to_human状态；
  • 在LangGraph里配置configurable={"max_concurrent": 1, "max_retries": 3}。

  实操心得：所有智能体必须有“熔断开关”。我们给每个Agent加max_retries参数，测试时用Locust模拟1000并发“？”请求，验证熔断是否生效。

  5.3 大模型输出截断：不是显存不足，而是Tokenizer的“隐形截断”

  现象：Qwen2-7B在处理长合同文本时，输出总在第2000字左右突然中断，且无报错。

  深度排查：

  • 查llm.invoke()返回的response对象，发现content字段末尾是...，但usage里completion_tokens显示已用满32768；
  • 检查Tokenizer：Qwen2用Qwen2TokenizerFast，其encode()方法默认truncation=True，但llm.invoke()没传max_tokens参数，导致tokenizer按自身最大长度截断；
  • 验证：手动调tokenizer.encode(long_text, truncation=True, max_length=32000)，果然截断。

  解决方案：

  • 在LLM调用时显式设置max_tokens=32000；
  • 或改用truncation=False，由LLM自身处理截断（但需确保LLM支持）；
  • 最佳实践：所有LLM调用必须带max_tokens参数，且值=模型上下文窗口-预留空间（如32768-1024）。

  提示：不同模型Tokenizer行为差异极大。Llama3用LlamaTokenizer，截断逻辑不同，必须针对每个模型单独验证。

  5.4 Playwright脚本执行失败：不是选择器错误，而是Shadow DOM穿透问题

  现象：生成的page.getByRole('button', { name: '提交' })在本地Chrome能跑，但在CI的Docker容器里失败。

  真相揭露：

  • CI用的是Playwright自带的Chromium，版本v112；
  • 本地Chrome是v118，新版本对Shadow DOM的attachShadow()支持更好；
  • 目标页面用Web Components，提交按钮在Shadow Root里，旧版Chromium无法穿透。

  解决路径：

  • 升级CI的Playwright到v1.42（支持Shadow DOM）；
  • 或改用page.locator('shadow=submit-button >> button')这种Shadow DOM专用选择器；
  • 最终方案：在脚本生成时，自动检测页面是否有Shadow DOM（用page.evaluate(() => document.querySelector('my-component').shadowRoot !== null)），有则用专用选择器。

  教训：自动化测试环境必须和生产环境一致。我们后来在CI里加了playwright version检查，版本不匹配直接失败。

  5.5 评估指标失真：人工标注的“认知偏差”污染数据集

  现象：RAG评估报告显示相关性95%，但业务方反馈答案质量差。

  调查发现：

  • 评估用的“黄金文档集”由3个测试工程师人工标注，他们习惯性给技术文档打高分，但业务用户更关注操作步骤是否清晰；
  • 某个问题“如何重置路由器密码”，标注员认为“查看说明书第5页”相关，但用户需要的是“按Reset键10秒”这样的具体动作。

  改进措施：

  • 引入业务方参与标注，用“用户视角打分表”（1-5分，1分=完全无法指导操作）；
  • 对标注员做一致性校验：随机抽20%用例，让3人独立打分，Kappa系数<0.7则重新培训；
  • 评估时加权：操作类问题权重0.8，概念类问题权重0.2。

  关键认知：评估指标不是客观真理，而是业务共识的量化。没有业务方参与的评估，都是空中楼阁。

  6. 工具链与生态选型：为什么坚持用LangChain+Playwright+ChromaDB组合

  6.1 LangChain：不是因为它“最火”，而是因为它“最可控”

  很多人质疑“LangChain太重，不如直接调API”，但测试开发恰恰需要它的“重”。原因有三：

  • 可观测性内置：LangChainTracer能自动记录每个Runnable的输入输出、耗时、错误，无需额外埋点；
  • 调试友好：invoke()方法支持debug=True，直接打印完整执行链路，比自己写日志省力十倍；
  • 生态统一：所有组件（Retriever、LLM、Tool）都遵循Runnable协议，测试代码可以复用——测RAG的invoke()方法，和测智能体的invoke()方法，调用方式完全一样。

  我们对比过LlamaIndex，它在检索性能上略优，但调试日志碎片化，很难追踪“为什么这个文档没被召回”。而LangChain的LangChainTracer日志是线性的，一眼就能看出断点在哪。

  6.2 Playwright：超越Selenium的“确定性”保障

  选Playwright不为新潮，为两点硬需求：

  • 自动等待：page.getByRole('button').click()会自动等待元素可见、可点击，不用写waitForSelector，大幅降低脚本脆弱性；
  • 多浏览器一致性：在Chromium、Firefox、WebKit上行为一致，避免“Chrome能跑，Firefox失败”的尴尬。

  实测数据：同样100个用例，Playwright脚本维护成本比Selenium低60%，因为90%的等待逻辑由框架自动处理。

  6.3 ChromaDB：轻量级向量数据库的“够用就好”哲学

  不选Milvus或Weaviate，因为：

  • 部署简单：单进程启动，pip install chromadb即可，CI环境零配置；
  • Python原生：不用REST API，直接collection.add()，调试时可collection.peek()查数据；
  • 够用性能：百万级文档下，P95召回延迟<100ms，满足RAG实时性要求。

  当然，它不适合亿级数据，但训练营所有项目都在10万文档规模内，ChromaDB是性价比最优解。

  最后分享一个小技巧