简介从汽车电子到工业自动化需求与测试团队正借助生成式AI重构研发流程。这份由Vector Consulting Services技术专家撰写的演示文稿PDF版本聚焦GenAI在需求工程与测试优化中的落地实践面向汽车电子、嵌入式系统及工业自动化领域的需求工程师、测试工程师、安全与网络安全专家以及关注AI工程化落地的技术管理者。内容涵盖基于小型语言模型SLM、语义搜索与RAG的知识增强方案讲解如何在保护知识产权的前提下提升需求一致性、可测性和完整性并自动生成高覆盖测试用例与边界条件同时结合ISO 26262功能安全与ISO/SAE 21434网络安全标准介绍了GenAI支持TARA分析、漏洞识别与安全合规分析的方法强调工程师需对AI输出保持审查控制。资源共1个PDF文件压缩包大小1.77MB以图文并茂的幻灯片形式呈现便于快速浏览关键方法与案例已有96人学习。适合有一定软件工程背景、希望将AI辅助融入现有工具链如CANoe、vTESTstudio的实践者参考。1. 生成式AI在需求与测试的落地先解决一半成本再谈效率革命软件工程的测试成本多年来稳定占据项目总成本的50%以上而缺陷又大量来自需求阶段的质量不足——这是Vector在2025年行业趋势调研里反复出现的结论。生成式AI在代码生成领域已经有超过50%的新代码由Copilot等工具辅助完成但真正的杠杆不在写代码而在需求工程和测试优化这两个长期被自动化忽略的环节。这份资料是Vector Consulting Services对GenAI应用于需求与测试的系统性实践总结包含需求质量检查的RAG架构、测试用例冗余消除、边界场景生成、以及AI测试AI系统的完整案例。适合从事汽车电子、嵌入式系统和工业自动化的需求工程师、测试工程师和安全从业者尤其是那些已经在用CANoe、vTESTstudio、PREEvision且想知道AI怎么嵌进现有工具链的团队。2. 需求质量检查的RAG架构从LLM选型到语义检索的参数拆解2.1 为什么需求检查需要RAG而不是直接让LLM读文档直接拿一份几百页的需求规格书丢给大模型让它找出不一致、不完整、不可测的地方结果通常不理想。原因在于通用模型缺乏项目上下文它不知道你的系统架构约束、不知道过往项目的坑、不知道这个领域有哪些隐含的物理规律。Vector的RequirementsCheck方案给出的答案是RAG检索增强生成核心流程是先把需求文档和RQ工具里的结构化信息切块、向量化然后针对每一条待检查的需求做相似性检索把相关的历史需求、上下文信息和领域知识一起拼进提示词再让模型做三类检查语义检查、句法检查、带上下文的一致性检查。这套流程里有两个关键参数直接决定效果一是嵌入模型的选择资料里明确提到了bge-m3和nomic-embed-text两个候选二是从RAG管道返回的相关结果数量这个数字太小会丢失上下文太大会把噪音带进提示词。我一般建议从5开始调根据需求文档的篇幅和相似度分布的集中程度上下浮动如果检索结果的相似度分数普遍低于0.7说明切块粒度或者嵌入模型需要调整而不是单纯增加返回数量。2.2 模型选型的边界LLM、SLM与私有化部署资料里提到的模型清单包括LLAMA 3.3、GPT-4o、DeepSeek R1和GPT-o1但重点不在于哪个模型更强而在于如何根据IP保护和性能需求做平衡。这里引出一个关键概念SLM小型语言模型在需求检查这种任务里真正决定输出质量的是有没有把可信的领域相关信息送进上下文而不是模型参数规模有多大。Vector给出的策略是内部或外部的可信领域信息、专家沉淀的启发式规则、以前项目的数据库三者共同构成SLM需要的浓缩内容——这和直接调用公有云大模型是两条完全不同的技术路线。从落地角度看选型要回答三个问题需求数据能不能出企业内网如果不能就得选可私有化部署的模型LLAMA 3.3这类开源权重模型配合内网推理服务是常见做法检查任务是否需要领域微调如果只是做语义检查和句法检查RAG加提示词工程通常就够不需要微调对延迟和吞吐的要求是什么实时交互式检查用SLM响应更快批量离线审查可以用更大模型。这里有个容易被忽略的点文档里强调通过微调确保隐私和IP保护意思是私有化部署不仅是为了合规更是为了让模型学习企业特有的需求表达习惯——通用模型对shall句式的要求规范理解得再透彻也不如一个读过你过去三年需求变更记录的模型。2.3 可复现的RequirementsCheck执行步骤把PPT里的流程落地成可执行的操作第一步是准备语料库。从需求管理工具DOORS、Jira等导出需求条目加上历史变更记录、缺陷报告、测试用例中涉及需求的部分统一格式化为JSON Lines每条记录至少包含id、text、source、timestamp四个字段注意不要带二进制附件。第二步是做切块和向量化常见做法是按条切而不是按页切因为需求条目本身就是最小的语义单元。切块后调用嵌入模型生成向量存储到向量数据库这一步的代码逻辑如下from sentence_transformers import SentenceTransformer import chromadb # 加载嵌入模型bge-m3对中文和英文需求文档的兼容性比nomic更好 model SentenceTransformer(BAAI/bge-m3) client chromadb.PersistentClient(path./req_vector_db) collection client.get_or_create_collection( namerequirements, metadata{hnsw:space: cosine} ) # 逐条向量化需求条目这里假设requirements是上一步导出的JSON数组 for req in requirements: embedding model.encode(req[text]).tolist() collection.add( ids[req[id]], embeddings[embedding], metadatas[{source: req[source]}], documents[req[text]] )这段代码里值得注意的参数是hnsw:space设置为cosine因为需求文本的相似度检索用余弦距离比欧氏距离更稳定尤其是向量维度较高时bge-m3的句向量对长文本和短文本都能处理单条需求一般不会超过512 token不需要额外做二次切分。第三步是构建检索和检查的提示词模板。RAG管道返回的Top-K相关需求需要和当前待检查需求一起拼进Prompt模板结构是角色设定、待检查需求原文、检索到的相关需求列表、检查指令。检查指令要拆成三个明确任务——语义检查关注需求是否含混、歧义、缺乏可验证性句法检查关注是否符合模板要求比如是否包含shall、是否有唯一的ID一致性检查关注与检索到的相关需求是否存在冲突或重复。这一步是整个流程中人工干预价值最大的地方模型输出的检查结果必须由需求工程师确认后才算数。def build_check_prompt(target_req, related_reqs, check_type): related_text \n.join( [f[相关需求 {r[id]}]: {r[text]} for r in related_reqs] ) instructions { semantic: 检查该需求是否存在歧义、矛盾、不可测试的表述并给出修改建议。, syntactic: 检查该需求是否符合组织需求编写规范列出缺失的强制字段。, consistency: 对照相关需求找出与该需求冲突或重复的条目。 } prompt f你是一名资深需求工程师。请对以下需求条目进行{check_type}检查。 待检查需求: {target_req[text]} {related_text} 检查要求: {instructions[check_type]} 以结构化列表输出问题项、严重程度和修改建议。 return promptcheck_type参数的三个取值对应前面提到的三类检查实际项目中建议分开调用而不是一次全部执行因为混合任务会让模型注意力分散输出质量明显下降——这是我在多个项目里对比过的结论一次性要求模型全面检查得到的报告通常还不如三次单任务检查结果的并集。2.4 一个完整的RAG需求检查场景以一条典型的汽车电子需求为例车辆在干燥沥青路面以100km/h行驶时踩下制动踏板至50%行程ABS应在200ms内激活。用RAG检索会发现历史项目中有类似的ABS相关需求、相关的制动系统架构说明、以及过往测试中发现的问题记录。语义检查会提示500ms内激活与这条需求200ms内激活的时间约束不一致——这就是通过上下文检索才能发现的问题单独看一条需求是完全正常的。一致性检查还可能发现这条需求与另一条关于湿滑路面ABS激活策略的需求存在逻辑冲突因为从物理规律看湿滑路面的激活时间要求应该更宽松而不是更严格。3. 测试用例优化冗余消除与边界场景生成的实现路径3.1 合并冗余测试用例从两条到一条参数化模板的完整操作资料里的ABS测试冗余消除案例非常典型。两条测试用例区别只在车速100km/h和105km/h前置条件、操作步骤、预期结果完全一致——这种冗余在真实项目中大量存在而且随着车型迭代会成倍增长。用GenAI处理这类任务的正确姿势不是让AI直接删用例而是让AI识别出用例之间的参数化关系生成一个带参数集的测试模板。案例中给出的方案是把两条用例合并成一个参数化模板车速${Speed}∈{100, 105}保留Apply/Release/No-Brake逻辑和时序检查。这个变换的收益很直接用例数量从2条变成1条模板加2个参数实例维护工作量下降50%一致性显著提升因为单条模板是唯一事实来源。关键是覆盖度没有损失——100和105作为边界车速仍在参数集中将来要扩展到新的路面条件只需增加一个参数维度而不是新增一条用例。实际操作中让AI识别可参数化的测试用例需要给模型提供足够的结构化输入。常见做法是把测试用例转成JSON格式让模型分析哪些字段在不同用例间变化、哪些字段保持不变然后生成参数化的模板代码# 转换前的冗余用例对注意这里只展示结构差异 tc_pair [ {id: TC1, speed: 100, brake: 50, surface: dry, expect: ABS_Active within 200ms}, {id: TC2, speed: 105, brake: 50, surface: dry, expect: ABS_Active within 200ms} ] # 让GenAI分析差异字段并生成参数化模板 # 关键提示聚焦于哪些字段是变量、哪些是常量以及参数间的约束关系 param_template { id: TC_param, params: {speed: [100, 105]}, preconditions: { ignition: ON, surface: dry asphalt, brake_position: 50 }, steps: [ Apply brake to BrakePedal_Pos50%, Release brake to BrakePedal_Pos0%, Keep ABS_ActiveFALSE for 200ms ], expected: ABS_ActiveTRUE within 200ms at ${speed}km/h }这段转换逻辑中AI真正起作用的是识别这个动作——它需要理解TC1和TC2之间的唯一差异是speed字段并且判断这个差异值得参数化而不是直接合并。这里有一个容易翻车的点如果两条用例的预期结果在不同速度下有不同的物理含义比如100km/h时要求ABS在200ms内激活但120km/h时要求300ms那它们就不应该被简单参数化。所以必须让AI在生成模板的同时输出参数化合理性说明人工确认之后再落地。3.2 边界场景生成如何让AI产出真正有价值的参数组合冗余消除是把重复变成参数边界场景生成则是从已知推向未知。案例中ABS激活鲁棒性测试的起点是现有测试只覆盖了干燥路面上单一减速度阈值的标称值没有系统地组合减速度、滑移率、路面、车速四个维度。GenAI给出的指导是生成10个参数组合覆盖Deceleration{-5.5, -6.0, -7.0}、Slip ratio{15%, 20%, 25%}、Surface{dry, wet}、Speed{40, 60, 100}。这个生成任务和普通的内容生成有本质区别它要求的是组合覆盖而不是随机采样。四维参数空间的总组合数是3×3×2×354从中选出10个能最大程度暴露边界问题的组合本身是一个覆盖度优化问题。GenAI在这个场景的价值不是算力而是它能把ABS激活鲁棒性这个语义目标翻译成具体的参数组合策略——比如把减速度的绝对值边界和滑移率边界组合在一起因为真实的极限工况往往是多个参数同时处于非标称值的状态。落地的输出格式需要和现有工具链对接Vector的做法是导出为vTESTstudio的迭代配置或CAPL参数集。这一步的格式转换逻辑可以抽象为AI生成参数的组合矩阵再映射成目标工具的循环执行结构。这里的一个关键提示是AI生成边界组合时必须明确物理约束——比如减速度-7.0m/s²配合湿滑路面是否可能同时成立如果物理上不成立这个组合就是无效的会浪费测试资源。因此我在实践中会让AI生成组合时附带每个参数组合的物理可行性说明用一个独立的验证步骤过滤掉不可行项。3.3 组合参数的过滤与优先级排序参数组合生成之后不能直接使用需要经过一轮过滤和排序。文件夹里如果提供有参数数据库或历史测试结果最好利用起来做回归对比——之前测过且通过的组合优先级降低没测过的边界组合优先级提高。排序规则建议按三个维度打分参数组合的物理可行性不可行直接淘汰、与既有测试的差异度差异越大优先级越高、对安全目标的影响程度涉及安全机制的参数组合优先级最高。比如ABS案例中涉及滑移率25%和湿滑路面的组合就打出了更高的安全相关分数。# 使用Python脚本对AI生成的参数组合做可行性过滤 combinations [ {decel: -5.5, slip: 15, surface: dry, speed: 40}, {decel: -7.0, slip: 25, surface: wet, speed: 40}, # ... 更多组合 ] def feasibility_check(c): # 基础物理约束湿滑路面上大减速度需要更长的制动距离 if c[surface] wet and c[decel] -6.5: return False # 高速低减速度组合更接近标称工况边界价值较低 if c[speed] 100 and abs(c[decel]) 5.5: return False return True valid [c for c in combinations if feasibility_check(c)] # 剩余组合按边界度排序优先执行偏离标称最多的组合 valid.sort(keylambda c: (abs(c[decel]) c[slip]) * (1 if c[surface]wet else 0.5))这段过滤逻辑看起来简单但实际上把AI生成和工程判断做了一个结合AI负责探索参数空间工程师负责把物理规律和测试经验编码成过滤规则。我习惯让过滤规则单独维护在一个配置文件里因为随着测试数据的积累哪些组合是有效的、哪些是无效的规则本身也会变化。4. 工具链集成与SLM落地从CANoe到私有化部署的完整链路4.1 Vector工具链中的AI功能布局与自带模型架构资料的一页PPT列出了Vector测试工具家族中的AI功能CANoe、vTESTstudio、PREEvision支持代码生成CAPL、Python、C#编写、配置生成、面板生成、符号数据库生成、聊天机器人、训练辅助、评审报告等功能。这些功能的共同特征是内嵌在工具链中而不是独立存在的AI助手——生成CAPL脚本的AI知道CANoe的环境对象模型、知道数据库格式、知道通信协议配置。这给我们的启示是AI在测试工具中的价值密度最大的地方是生成工具原生格式的内容。用通用ChatGPT生成一段Python脚本当然可以但生成一段能被CANoe直接编译执行的CAPL代码需要模型理解CAPL的事件驱动模型、系统变量、报文发送API。这也是为什么Vector会强调bring your own model——不是所有用户都想用Vector托管的模型企业有自己的数据合规要求和模型偏好工具链要做的是开放接口让用户把自有的私有化模型接进来在工具链内部完成提示词构造、上下文补充和输出校验。从实际部署角度看CANoe的AI助手生成了CAPL测试脚本之后人工审查这一步比生成本身更关键。CAPL代码有明确的语法规范和API约束AI生成的代码如果调试不通过报错信息往往不直观新手容易在环境配置上浪费大量时间。我的习惯做法是用AI生成初始版本再让AI解释代码中每个关键API的调用目的确保自己能理解之后才跑测试。4.2 私有化SLM的构建步骤从数据准备到启发式规则注入资料中强调SLM需要浓缩的内容适配领域和问题具体来说就是三样东西领域相关的可信信息、专家经验编码成的启发式规则、过往项目数据。构建一个私有化SLM的实际步骤可以拆成四步。第一步是数据收集与清洗从公司内部的需求库、缺陷库、测试用例库中提取与目标任务相关的数据。这里有一个经验值不是数据越多越好而是要保证数据的可信性——已关闭的缺陷和已验证通过的测试用例是高质量训练数据而仍在争议中的需求变更则不应该进入基础语料。第二步是规则编码。专家的领域知识不能直接丢给模型学而是要显式地写成规则。比如在汽车安全需求检查中如果需求中涉及ABS激活时间则必须给出路面条件和车速范围这条规则可以编码为提示词中的硬性约束也可以作为后处理脚本里的校验条件。第三步是模型微调或RAG管线搭建。如果团队有数据科学能力用开源模型做指令微调效果最好如果资源有限用RAG加提示词工程是更快落地的路径。RAG方案的关键是把第一、二步准备好的语料库和规则库变成可检索的上下文。第四步是在Vector工具链中做配置对接# vTESTstudio或CANoe中的AI助手配置示例指定私有化模型端点 ai_assistant_config { model_endpoint: http://internal-llm.service:8080/v1/completions, model_name: llama-3.3-8b-instruct, embedding_model: bge-m3, rag_config: { collection: req_corpus, top_k: 5, score_threshold: 0.7, include_rules: True }, tool_context: { can_db: project.dbc, protocols: [CAN, Ethernet], test_framework: vTESTstudio } }这个配置里最关键的是tool_context字段中传递的工程上下文信息,它告诉AI当前项目用的是CAN总线还是以太网、DBC数据库文件位置、测试框架类型。没有这些信息模型生成的测试代码很可能用了错误的报文类型或数据库API。score_threshold参数控制RAG检索结果的过滤力度设置过低会让模型读到大量不相关内容反而干扰生成质量设置过高可能漏掉有用的背景信息。4.3 数据安全边界什么数据能进公有模型什么必须留在内网这是整个方案里最需要工程师和管理者达成共识的地方。Vector的AI战略三支柱中AI支持的开发工作场所这一支柱强调内部聊天系统和基于私有化托管on-premise hosting的AI助手核心目的就是保护知识产权。在需求工程和测试领域需求规格书往往包含产品的核心功能定义和技术细节泄露给公有云模型的后果不是简单的数据流失而是竞争对手可能通过模型服务商的日志间接获取产品规划信息。我的建议是画一条清晰的分界线需求文档、测试用例、DBC数据库、AUTOSAR配置这类结构化工程资产原则上不允许出内网用私有化模型处理而标准规范、论文摘要、行业趋势报告这类公开信息可以交给公有云API处理。如果团队不具备自建模型的算力条件退而求其次的选择是使用提供私有化部署选项的商业模型服务并签订数据隔离协议。但无论如何完全依赖公有API处理核心需求数据在汽车、医疗这类受监管行业基本走不通。5. 避坑与常见问题需求与测试场景下GenAI落地中的五个典型教训5.1 现象RAG检索回来的相关内容不相关现象给需求检查流程配置好RAG之后模型输出的检查报告经常引用了与当前需求无关的历史需求导致提示词中上下文噪音过大正确性下降。原因切块策略不当。很多需求条目实际上是长文本中的一小段如果按固定长度切块会把多条需求的片段混在一起检索到的相关需求其实只有半句话是相关的其他全是干扰信息。另一个原因是嵌入模型与领域匹配度不够通用嵌入模型对汽车电子领域的术语表达不敏感。解决优先按需求条目的自然边界切块每条需求作为一个独立的向量单元嵌入模型换成bge-m3并测试该模型在内部需求语料上的检索准确率同时可以加一层关键词过滤用领域词表如ABS、ECU、AUTOSAR优先匹配后再用向量相似度精排。从那以后我每次搭建RAG都会先跑一个十条需求的检索准确率测试再进入正式流程。5.2 现象AI生成的参数化测试用例缺少边界条件现象让GenAI把冗余测试用例合并成参数化模板AI给出的参数集只包含了原有的几个值没有自动补全边界值或相邻值覆盖度没有提升。原因提示词中只要求了合并冗余没有明确要求补充边界参数。LLM在缺少明确指令时倾向于最小化变更它不会主动扩展参数范围因为那不是它的任务目标。解决在生成参数化模板的提示词中加入一步参数边界检查指令要求模型针对每个参数给出标称值、边界值和相邻值三个维度。比如车速参数如果原值是100和105那么模型的输出应该是{100, 105, 120, 80}加上合理的边界说明。这个边界检查需要在提示词中显式定义否则模型不会自主执行。另外需要跟进一个自动检查脚本把AI输出的参数和原有用例的参数做差集差集里如果没有新增参数说明提示词设计不合理直接打回重写。5.3 现象SLM在私有化部署后输出质量明显下降现象同样的检查任务用GPT-4o调用效果很好换成私有化的Llama 3.3之后语义检查的准确率明显下降出现大量误报。原因私有化SLM的参数规模小本身的推理能力就弱于GPT-4o而且缺少公有模型在海量通用语料上学到的知识。但根本原因往往不是模型本身而是RAG管线没有针对SLM做适配——小模型对上下文的利用效率低同样的RAG返回结果GPT-4o能从中提取有效信息SLM可能会被无关信息带偏。解决针对SLM场景把RAG的Top-K从5降到2或3减少上下文噪音提示词要写得更短更结构化避免长段落描述任务把检查任务拆得更细一次只让模型做一件事只做语义检查不做一致性检查。如果还是达不到质量要求就回到资料里的建议——用领域数据做微调而不是试图用提示词弥补模型能力差距。在微调之前建议先用五十到一百条标注过的历史需求做一次基准测试确认瓶颈确实在模型能力而不在RAG管线。5.4 现象AI生成的边界参数组合物理上不可行现象边界场景生成中AI给出了一组湿滑路面、-7.0m/s²减速度、100km/h车速的组合但实际测试时车辆在这种条件下会直接打滑失控测试结果完全不可用。原因AI没有物理世界模型它只是在组合参数空间里做数学上的覆盖并不知道哪些参数组合在真实物理条件下是成立的。边界检测中这类现象非常多尤其是同时改变多个参数时AI倾向于把每个参数都推向极值来体现边界特征但真实物理系统的参数之间存在强耦合约束。解决在生成参数组合后加一道物理可行性过滤。做法有两种一是把已知的物理约束写成代码规则如湿滑路面最大减速度不能超过-6.5m/s²这是最可控的二是让AI为每个组合生成可行性置信度并附上理由由人工复核。我倾向于做法一因为物理规则是确定性的不应该让模型来判断——模型的判断不确定性反而会引入新的不可信因素。5.5 现象AI建议的测试优化方案在评审阶段被安全工程师驳回现象AI生成的测试用例优化建议合并、删减、参数化在安全评审时被认为存在合规风险理由是原本的显式用例变成参数化生成后无法证明每个实例都被执行过。原因在功能安全和网络安全受监管的行业ISO 26262、ISO/SAE 21434测试用例的结构本身是审计证据的一部分。AI把两条显式用例改成一条模板加参数实例从工程效率上是合理的但从合规角度削弱了可追溯性——为什么这个参数集是充分的这个问题AI的回答无法作为审计证据。解决在AI提出优化方案时要求它同时输出一份一致性论证说明参数化前后覆盖度的等价性以及每个参数取值的选取依据。在实际落地时参数化后的模板仍然要生成每个参数实例的具体执行记录不能只保留模板就算完成测试。这个问题的根本原则是AI负责提出优化方向和参数建议但合规性和审计证据链必须由工程师和流程来保证。从那以后我每次做用例优化都会先问一句这个改动是否影响审计追溯再决定是否采纳AI的方案。6. 验证与进阶用AI做AI测试的SOTIF闭环和输出质量控制在完成需求检查和测试用例优化之后真正决定这套方案能走多远的是验证环节。资料中的Robo-Test案例给出了一组很有说服力的数据传统的垃圾填埋场设备测试需要40天实车数据采集才能覆盖的角落用例用智能合成验证方法可以做到每天生成超过100个角落用例把SOTIF预期功能安全覆盖度评估从以月计压缩到以天计。这个案例的核心逻辑是把AI用在验证AI系统本身上——用合成场景来测试自动驾驶或自主作业系统的边界行为而不是继续依赖物理世界的实测数据。我理解的进阶路径是三层递进第一层是用AI检查需求、优化测试用例这是本文前面的内容第二层是把AI生成的合成场景作为测试输入覆盖物理实测难以触达的危险边界——比如挖掘机在陡坡上作业时翻覆、在坑道边缘运行时物体坠落这些场景人工构造既危险又耗时AI合成则可以在仿真环境中快速生成变体第三层才是真正的闭环——把测试结果反馈给需求阶段让需求工程和测试优化形成一个持续学习的循环。在这个闭环里有一个实用的验证技巧用变异测试来检验AI生成的测试用例的质量。做法是把被测系统的需求或代码做一组小的变异比如把ABS激活时间从200ms改成300ms然后看AI生成的测试用例能否捕获这个变异。如果能捕获说明测试用例对这个参数是敏感的质量可信如果捕获不到说明测试用例的预期结果写得太宽泛或者参数组合没有覆盖到该参数的边界。变异测试可以作为AI测试生成的自动化验收标准——它能用一个量化的指标告诉你AI生成的测试集到底有多强。收尾环节还有一个关键习惯值得强调无论AI的输出看起来多可信我每次都会把它的结果和标注过的基准集做一次对比。我在实际项目中维护了一个两百条标注历史需求的评估集任何新的模型版本、新的提示词模板、新的RAG参数上线之前先在这个评估集上跑一遍准确率和召回率达标才允许进入正式流程。这个习惯帮我避免过很多次看起来好用了、上线就翻车的状况特别是换了嵌入模型或者改了切块策略之后不跑基准测试根本发现不了召回率的悄然下降。从那以后我每次调整RAG管线的参数都强制走一遍基准评估也希望这个习惯对你有帮助。本文还有配套的精品资源点击获取
生成式AI赋能需求与测试：从RAG到SLM的落地
简介从汽车电子到工业自动化需求与测试团队正借助生成式AI重构研发流程。这份由Vector Consulting Services技术专家撰写的演示文稿PDF版本聚焦GenAI在需求工程与测试优化中的落地实践面向汽车电子、嵌入式系统及工业自动化领域的需求工程师、测试工程师、安全与网络安全专家以及关注AI工程化落地的技术管理者。内容涵盖基于小型语言模型SLM、语义搜索与RAG的知识增强方案讲解如何在保护知识产权的前提下提升需求一致性、可测性和完整性并自动生成高覆盖测试用例与边界条件同时结合ISO 26262功能安全与ISO/SAE 21434网络安全标准介绍了GenAI支持TARA分析、漏洞识别与安全合规分析的方法强调工程师需对AI输出保持审查控制。资源共1个PDF文件压缩包大小1.77MB以图文并茂的幻灯片形式呈现便于快速浏览关键方法与案例已有96人学习。适合有一定软件工程背景、希望将AI辅助融入现有工具链如CANoe、vTESTstudio的实践者参考。1. 生成式AI在需求与测试的落地先解决一半成本再谈效率革命软件工程的测试成本多年来稳定占据项目总成本的50%以上而缺陷又大量来自需求阶段的质量不足——这是Vector在2025年行业趋势调研里反复出现的结论。生成式AI在代码生成领域已经有超过50%的新代码由Copilot等工具辅助完成但真正的杠杆不在写代码而在需求工程和测试优化这两个长期被自动化忽略的环节。这份资料是Vector Consulting Services对GenAI应用于需求与测试的系统性实践总结包含需求质量检查的RAG架构、测试用例冗余消除、边界场景生成、以及AI测试AI系统的完整案例。适合从事汽车电子、嵌入式系统和工业自动化的需求工程师、测试工程师和安全从业者尤其是那些已经在用CANoe、vTESTstudio、PREEvision且想知道AI怎么嵌进现有工具链的团队。2. 需求质量检查的RAG架构从LLM选型到语义检索的参数拆解2.1 为什么需求检查需要RAG而不是直接让LLM读文档直接拿一份几百页的需求规格书丢给大模型让它找出不一致、不完整、不可测的地方结果通常不理想。原因在于通用模型缺乏项目上下文它不知道你的系统架构约束、不知道过往项目的坑、不知道这个领域有哪些隐含的物理规律。Vector的RequirementsCheck方案给出的答案是RAG检索增强生成核心流程是先把需求文档和RQ工具里的结构化信息切块、向量化然后针对每一条待检查的需求做相似性检索把相关的历史需求、上下文信息和领域知识一起拼进提示词再让模型做三类检查语义检查、句法检查、带上下文的一致性检查。这套流程里有两个关键参数直接决定效果一是嵌入模型的选择资料里明确提到了bge-m3和nomic-embed-text两个候选二是从RAG管道返回的相关结果数量这个数字太小会丢失上下文太大会把噪音带进提示词。我一般建议从5开始调根据需求文档的篇幅和相似度分布的集中程度上下浮动如果检索结果的相似度分数普遍低于0.7说明切块粒度或者嵌入模型需要调整而不是单纯增加返回数量。2.2 模型选型的边界LLM、SLM与私有化部署资料里提到的模型清单包括LLAMA 3.3、GPT-4o、DeepSeek R1和GPT-o1但重点不在于哪个模型更强而在于如何根据IP保护和性能需求做平衡。这里引出一个关键概念SLM小型语言模型在需求检查这种任务里真正决定输出质量的是有没有把可信的领域相关信息送进上下文而不是模型参数规模有多大。Vector给出的策略是内部或外部的可信领域信息、专家沉淀的启发式规则、以前项目的数据库三者共同构成SLM需要的浓缩内容——这和直接调用公有云大模型是两条完全不同的技术路线。从落地角度看选型要回答三个问题需求数据能不能出企业内网如果不能就得选可私有化部署的模型LLAMA 3.3这类开源权重模型配合内网推理服务是常见做法检查任务是否需要领域微调如果只是做语义检查和句法检查RAG加提示词工程通常就够不需要微调对延迟和吞吐的要求是什么实时交互式检查用SLM响应更快批量离线审查可以用更大模型。这里有个容易被忽略的点文档里强调通过微调确保隐私和IP保护意思是私有化部署不仅是为了合规更是为了让模型学习企业特有的需求表达习惯——通用模型对shall句式的要求规范理解得再透彻也不如一个读过你过去三年需求变更记录的模型。2.3 可复现的RequirementsCheck执行步骤把PPT里的流程落地成可执行的操作第一步是准备语料库。从需求管理工具DOORS、Jira等导出需求条目加上历史变更记录、缺陷报告、测试用例中涉及需求的部分统一格式化为JSON Lines每条记录至少包含id、text、source、timestamp四个字段注意不要带二进制附件。第二步是做切块和向量化常见做法是按条切而不是按页切因为需求条目本身就是最小的语义单元。切块后调用嵌入模型生成向量存储到向量数据库这一步的代码逻辑如下from sentence_transformers import SentenceTransformer import chromadb # 加载嵌入模型bge-m3对中文和英文需求文档的兼容性比nomic更好 model SentenceTransformer(BAAI/bge-m3) client chromadb.PersistentClient(path./req_vector_db) collection client.get_or_create_collection( namerequirements, metadata{hnsw:space: cosine} ) # 逐条向量化需求条目这里假设requirements是上一步导出的JSON数组 for req in requirements: embedding model.encode(req[text]).tolist() collection.add( ids[req[id]], embeddings[embedding], metadatas[{source: req[source]}], documents[req[text]] )这段代码里值得注意的参数是hnsw:space设置为cosine因为需求文本的相似度检索用余弦距离比欧氏距离更稳定尤其是向量维度较高时bge-m3的句向量对长文本和短文本都能处理单条需求一般不会超过512 token不需要额外做二次切分。第三步是构建检索和检查的提示词模板。RAG管道返回的Top-K相关需求需要和当前待检查需求一起拼进Prompt模板结构是角色设定、待检查需求原文、检索到的相关需求列表、检查指令。检查指令要拆成三个明确任务——语义检查关注需求是否含混、歧义、缺乏可验证性句法检查关注是否符合模板要求比如是否包含shall、是否有唯一的ID一致性检查关注与检索到的相关需求是否存在冲突或重复。这一步是整个流程中人工干预价值最大的地方模型输出的检查结果必须由需求工程师确认后才算数。def build_check_prompt(target_req, related_reqs, check_type): related_text \n.join( [f[相关需求 {r[id]}]: {r[text]} for r in related_reqs] ) instructions { semantic: 检查该需求是否存在歧义、矛盾、不可测试的表述并给出修改建议。, syntactic: 检查该需求是否符合组织需求编写规范列出缺失的强制字段。, consistency: 对照相关需求找出与该需求冲突或重复的条目。 } prompt f你是一名资深需求工程师。请对以下需求条目进行{check_type}检查。 待检查需求: {target_req[text]} {related_text} 检查要求: {instructions[check_type]} 以结构化列表输出问题项、严重程度和修改建议。 return promptcheck_type参数的三个取值对应前面提到的三类检查实际项目中建议分开调用而不是一次全部执行因为混合任务会让模型注意力分散输出质量明显下降——这是我在多个项目里对比过的结论一次性要求模型全面检查得到的报告通常还不如三次单任务检查结果的并集。2.4 一个完整的RAG需求检查场景以一条典型的汽车电子需求为例车辆在干燥沥青路面以100km/h行驶时踩下制动踏板至50%行程ABS应在200ms内激活。用RAG检索会发现历史项目中有类似的ABS相关需求、相关的制动系统架构说明、以及过往测试中发现的问题记录。语义检查会提示500ms内激活与这条需求200ms内激活的时间约束不一致——这就是通过上下文检索才能发现的问题单独看一条需求是完全正常的。一致性检查还可能发现这条需求与另一条关于湿滑路面ABS激活策略的需求存在逻辑冲突因为从物理规律看湿滑路面的激活时间要求应该更宽松而不是更严格。3. 测试用例优化冗余消除与边界场景生成的实现路径3.1 合并冗余测试用例从两条到一条参数化模板的完整操作资料里的ABS测试冗余消除案例非常典型。两条测试用例区别只在车速100km/h和105km/h前置条件、操作步骤、预期结果完全一致——这种冗余在真实项目中大量存在而且随着车型迭代会成倍增长。用GenAI处理这类任务的正确姿势不是让AI直接删用例而是让AI识别出用例之间的参数化关系生成一个带参数集的测试模板。案例中给出的方案是把两条用例合并成一个参数化模板车速${Speed}∈{100, 105}保留Apply/Release/No-Brake逻辑和时序检查。这个变换的收益很直接用例数量从2条变成1条模板加2个参数实例维护工作量下降50%一致性显著提升因为单条模板是唯一事实来源。关键是覆盖度没有损失——100和105作为边界车速仍在参数集中将来要扩展到新的路面条件只需增加一个参数维度而不是新增一条用例。实际操作中让AI识别可参数化的测试用例需要给模型提供足够的结构化输入。常见做法是把测试用例转成JSON格式让模型分析哪些字段在不同用例间变化、哪些字段保持不变然后生成参数化的模板代码# 转换前的冗余用例对注意这里只展示结构差异 tc_pair [ {id: TC1, speed: 100, brake: 50, surface: dry, expect: ABS_Active within 200ms}, {id: TC2, speed: 105, brake: 50, surface: dry, expect: ABS_Active within 200ms} ] # 让GenAI分析差异字段并生成参数化模板 # 关键提示聚焦于哪些字段是变量、哪些是常量以及参数间的约束关系 param_template { id: TC_param, params: {speed: [100, 105]}, preconditions: { ignition: ON, surface: dry asphalt, brake_position: 50 }, steps: [ Apply brake to BrakePedal_Pos50%, Release brake to BrakePedal_Pos0%, Keep ABS_ActiveFALSE for 200ms ], expected: ABS_ActiveTRUE within 200ms at ${speed}km/h }这段转换逻辑中AI真正起作用的是识别这个动作——它需要理解TC1和TC2之间的唯一差异是speed字段并且判断这个差异值得参数化而不是直接合并。这里有一个容易翻车的点如果两条用例的预期结果在不同速度下有不同的物理含义比如100km/h时要求ABS在200ms内激活但120km/h时要求300ms那它们就不应该被简单参数化。所以必须让AI在生成模板的同时输出参数化合理性说明人工确认之后再落地。3.2 边界场景生成如何让AI产出真正有价值的参数组合冗余消除是把重复变成参数边界场景生成则是从已知推向未知。案例中ABS激活鲁棒性测试的起点是现有测试只覆盖了干燥路面上单一减速度阈值的标称值没有系统地组合减速度、滑移率、路面、车速四个维度。GenAI给出的指导是生成10个参数组合覆盖Deceleration{-5.5, -6.0, -7.0}、Slip ratio{15%, 20%, 25%}、Surface{dry, wet}、Speed{40, 60, 100}。这个生成任务和普通的内容生成有本质区别它要求的是组合覆盖而不是随机采样。四维参数空间的总组合数是3×3×2×354从中选出10个能最大程度暴露边界问题的组合本身是一个覆盖度优化问题。GenAI在这个场景的价值不是算力而是它能把ABS激活鲁棒性这个语义目标翻译成具体的参数组合策略——比如把减速度的绝对值边界和滑移率边界组合在一起因为真实的极限工况往往是多个参数同时处于非标称值的状态。落地的输出格式需要和现有工具链对接Vector的做法是导出为vTESTstudio的迭代配置或CAPL参数集。这一步的格式转换逻辑可以抽象为AI生成参数的组合矩阵再映射成目标工具的循环执行结构。这里的一个关键提示是AI生成边界组合时必须明确物理约束——比如减速度-7.0m/s²配合湿滑路面是否可能同时成立如果物理上不成立这个组合就是无效的会浪费测试资源。因此我在实践中会让AI生成组合时附带每个参数组合的物理可行性说明用一个独立的验证步骤过滤掉不可行项。3.3 组合参数的过滤与优先级排序参数组合生成之后不能直接使用需要经过一轮过滤和排序。文件夹里如果提供有参数数据库或历史测试结果最好利用起来做回归对比——之前测过且通过的组合优先级降低没测过的边界组合优先级提高。排序规则建议按三个维度打分参数组合的物理可行性不可行直接淘汰、与既有测试的差异度差异越大优先级越高、对安全目标的影响程度涉及安全机制的参数组合优先级最高。比如ABS案例中涉及滑移率25%和湿滑路面的组合就打出了更高的安全相关分数。# 使用Python脚本对AI生成的参数组合做可行性过滤 combinations [ {decel: -5.5, slip: 15, surface: dry, speed: 40}, {decel: -7.0, slip: 25, surface: wet, speed: 40}, # ... 更多组合 ] def feasibility_check(c): # 基础物理约束湿滑路面上大减速度需要更长的制动距离 if c[surface] wet and c[decel] -6.5: return False # 高速低减速度组合更接近标称工况边界价值较低 if c[speed] 100 and abs(c[decel]) 5.5: return False return True valid [c for c in combinations if feasibility_check(c)] # 剩余组合按边界度排序优先执行偏离标称最多的组合 valid.sort(keylambda c: (abs(c[decel]) c[slip]) * (1 if c[surface]wet else 0.5))这段过滤逻辑看起来简单但实际上把AI生成和工程判断做了一个结合AI负责探索参数空间工程师负责把物理规律和测试经验编码成过滤规则。我习惯让过滤规则单独维护在一个配置文件里因为随着测试数据的积累哪些组合是有效的、哪些是无效的规则本身也会变化。4. 工具链集成与SLM落地从CANoe到私有化部署的完整链路4.1 Vector工具链中的AI功能布局与自带模型架构资料的一页PPT列出了Vector测试工具家族中的AI功能CANoe、vTESTstudio、PREEvision支持代码生成CAPL、Python、C#编写、配置生成、面板生成、符号数据库生成、聊天机器人、训练辅助、评审报告等功能。这些功能的共同特征是内嵌在工具链中而不是独立存在的AI助手——生成CAPL脚本的AI知道CANoe的环境对象模型、知道数据库格式、知道通信协议配置。这给我们的启示是AI在测试工具中的价值密度最大的地方是生成工具原生格式的内容。用通用ChatGPT生成一段Python脚本当然可以但生成一段能被CANoe直接编译执行的CAPL代码需要模型理解CAPL的事件驱动模型、系统变量、报文发送API。这也是为什么Vector会强调bring your own model——不是所有用户都想用Vector托管的模型企业有自己的数据合规要求和模型偏好工具链要做的是开放接口让用户把自有的私有化模型接进来在工具链内部完成提示词构造、上下文补充和输出校验。从实际部署角度看CANoe的AI助手生成了CAPL测试脚本之后人工审查这一步比生成本身更关键。CAPL代码有明确的语法规范和API约束AI生成的代码如果调试不通过报错信息往往不直观新手容易在环境配置上浪费大量时间。我的习惯做法是用AI生成初始版本再让AI解释代码中每个关键API的调用目的确保自己能理解之后才跑测试。4.2 私有化SLM的构建步骤从数据准备到启发式规则注入资料中强调SLM需要浓缩的内容适配领域和问题具体来说就是三样东西领域相关的可信信息、专家经验编码成的启发式规则、过往项目数据。构建一个私有化SLM的实际步骤可以拆成四步。第一步是数据收集与清洗从公司内部的需求库、缺陷库、测试用例库中提取与目标任务相关的数据。这里有一个经验值不是数据越多越好而是要保证数据的可信性——已关闭的缺陷和已验证通过的测试用例是高质量训练数据而仍在争议中的需求变更则不应该进入基础语料。第二步是规则编码。专家的领域知识不能直接丢给模型学而是要显式地写成规则。比如在汽车安全需求检查中如果需求中涉及ABS激活时间则必须给出路面条件和车速范围这条规则可以编码为提示词中的硬性约束也可以作为后处理脚本里的校验条件。第三步是模型微调或RAG管线搭建。如果团队有数据科学能力用开源模型做指令微调效果最好如果资源有限用RAG加提示词工程是更快落地的路径。RAG方案的关键是把第一、二步准备好的语料库和规则库变成可检索的上下文。第四步是在Vector工具链中做配置对接# vTESTstudio或CANoe中的AI助手配置示例指定私有化模型端点 ai_assistant_config { model_endpoint: http://internal-llm.service:8080/v1/completions, model_name: llama-3.3-8b-instruct, embedding_model: bge-m3, rag_config: { collection: req_corpus, top_k: 5, score_threshold: 0.7, include_rules: True }, tool_context: { can_db: project.dbc, protocols: [CAN, Ethernet], test_framework: vTESTstudio } }这个配置里最关键的是tool_context字段中传递的工程上下文信息,它告诉AI当前项目用的是CAN总线还是以太网、DBC数据库文件位置、测试框架类型。没有这些信息模型生成的测试代码很可能用了错误的报文类型或数据库API。score_threshold参数控制RAG检索结果的过滤力度设置过低会让模型读到大量不相关内容反而干扰生成质量设置过高可能漏掉有用的背景信息。4.3 数据安全边界什么数据能进公有模型什么必须留在内网这是整个方案里最需要工程师和管理者达成共识的地方。Vector的AI战略三支柱中AI支持的开发工作场所这一支柱强调内部聊天系统和基于私有化托管on-premise hosting的AI助手核心目的就是保护知识产权。在需求工程和测试领域需求规格书往往包含产品的核心功能定义和技术细节泄露给公有云模型的后果不是简单的数据流失而是竞争对手可能通过模型服务商的日志间接获取产品规划信息。我的建议是画一条清晰的分界线需求文档、测试用例、DBC数据库、AUTOSAR配置这类结构化工程资产原则上不允许出内网用私有化模型处理而标准规范、论文摘要、行业趋势报告这类公开信息可以交给公有云API处理。如果团队不具备自建模型的算力条件退而求其次的选择是使用提供私有化部署选项的商业模型服务并签订数据隔离协议。但无论如何完全依赖公有API处理核心需求数据在汽车、医疗这类受监管行业基本走不通。5. 避坑与常见问题需求与测试场景下GenAI落地中的五个典型教训5.1 现象RAG检索回来的相关内容不相关现象给需求检查流程配置好RAG之后模型输出的检查报告经常引用了与当前需求无关的历史需求导致提示词中上下文噪音过大正确性下降。原因切块策略不当。很多需求条目实际上是长文本中的一小段如果按固定长度切块会把多条需求的片段混在一起检索到的相关需求其实只有半句话是相关的其他全是干扰信息。另一个原因是嵌入模型与领域匹配度不够通用嵌入模型对汽车电子领域的术语表达不敏感。解决优先按需求条目的自然边界切块每条需求作为一个独立的向量单元嵌入模型换成bge-m3并测试该模型在内部需求语料上的检索准确率同时可以加一层关键词过滤用领域词表如ABS、ECU、AUTOSAR优先匹配后再用向量相似度精排。从那以后我每次搭建RAG都会先跑一个十条需求的检索准确率测试再进入正式流程。5.2 现象AI生成的参数化测试用例缺少边界条件现象让GenAI把冗余测试用例合并成参数化模板AI给出的参数集只包含了原有的几个值没有自动补全边界值或相邻值覆盖度没有提升。原因提示词中只要求了合并冗余没有明确要求补充边界参数。LLM在缺少明确指令时倾向于最小化变更它不会主动扩展参数范围因为那不是它的任务目标。解决在生成参数化模板的提示词中加入一步参数边界检查指令要求模型针对每个参数给出标称值、边界值和相邻值三个维度。比如车速参数如果原值是100和105那么模型的输出应该是{100, 105, 120, 80}加上合理的边界说明。这个边界检查需要在提示词中显式定义否则模型不会自主执行。另外需要跟进一个自动检查脚本把AI输出的参数和原有用例的参数做差集差集里如果没有新增参数说明提示词设计不合理直接打回重写。5.3 现象SLM在私有化部署后输出质量明显下降现象同样的检查任务用GPT-4o调用效果很好换成私有化的Llama 3.3之后语义检查的准确率明显下降出现大量误报。原因私有化SLM的参数规模小本身的推理能力就弱于GPT-4o而且缺少公有模型在海量通用语料上学到的知识。但根本原因往往不是模型本身而是RAG管线没有针对SLM做适配——小模型对上下文的利用效率低同样的RAG返回结果GPT-4o能从中提取有效信息SLM可能会被无关信息带偏。解决针对SLM场景把RAG的Top-K从5降到2或3减少上下文噪音提示词要写得更短更结构化避免长段落描述任务把检查任务拆得更细一次只让模型做一件事只做语义检查不做一致性检查。如果还是达不到质量要求就回到资料里的建议——用领域数据做微调而不是试图用提示词弥补模型能力差距。在微调之前建议先用五十到一百条标注过的历史需求做一次基准测试确认瓶颈确实在模型能力而不在RAG管线。5.4 现象AI生成的边界参数组合物理上不可行现象边界场景生成中AI给出了一组湿滑路面、-7.0m/s²减速度、100km/h车速的组合但实际测试时车辆在这种条件下会直接打滑失控测试结果完全不可用。原因AI没有物理世界模型它只是在组合参数空间里做数学上的覆盖并不知道哪些参数组合在真实物理条件下是成立的。边界检测中这类现象非常多尤其是同时改变多个参数时AI倾向于把每个参数都推向极值来体现边界特征但真实物理系统的参数之间存在强耦合约束。解决在生成参数组合后加一道物理可行性过滤。做法有两种一是把已知的物理约束写成代码规则如湿滑路面最大减速度不能超过-6.5m/s²这是最可控的二是让AI为每个组合生成可行性置信度并附上理由由人工复核。我倾向于做法一因为物理规则是确定性的不应该让模型来判断——模型的判断不确定性反而会引入新的不可信因素。5.5 现象AI建议的测试优化方案在评审阶段被安全工程师驳回现象AI生成的测试用例优化建议合并、删减、参数化在安全评审时被认为存在合规风险理由是原本的显式用例变成参数化生成后无法证明每个实例都被执行过。原因在功能安全和网络安全受监管的行业ISO 26262、ISO/SAE 21434测试用例的结构本身是审计证据的一部分。AI把两条显式用例改成一条模板加参数实例从工程效率上是合理的但从合规角度削弱了可追溯性——为什么这个参数集是充分的这个问题AI的回答无法作为审计证据。解决在AI提出优化方案时要求它同时输出一份一致性论证说明参数化前后覆盖度的等价性以及每个参数取值的选取依据。在实际落地时参数化后的模板仍然要生成每个参数实例的具体执行记录不能只保留模板就算完成测试。这个问题的根本原则是AI负责提出优化方向和参数建议但合规性和审计证据链必须由工程师和流程来保证。从那以后我每次做用例优化都会先问一句这个改动是否影响审计追溯再决定是否采纳AI的方案。6. 验证与进阶用AI做AI测试的SOTIF闭环和输出质量控制在完成需求检查和测试用例优化之后真正决定这套方案能走多远的是验证环节。资料中的Robo-Test案例给出了一组很有说服力的数据传统的垃圾填埋场设备测试需要40天实车数据采集才能覆盖的角落用例用智能合成验证方法可以做到每天生成超过100个角落用例把SOTIF预期功能安全覆盖度评估从以月计压缩到以天计。这个案例的核心逻辑是把AI用在验证AI系统本身上——用合成场景来测试自动驾驶或自主作业系统的边界行为而不是继续依赖物理世界的实测数据。我理解的进阶路径是三层递进第一层是用AI检查需求、优化测试用例这是本文前面的内容第二层是把AI生成的合成场景作为测试输入覆盖物理实测难以触达的危险边界——比如挖掘机在陡坡上作业时翻覆、在坑道边缘运行时物体坠落这些场景人工构造既危险又耗时AI合成则可以在仿真环境中快速生成变体第三层才是真正的闭环——把测试结果反馈给需求阶段让需求工程和测试优化形成一个持续学习的循环。在这个闭环里有一个实用的验证技巧用变异测试来检验AI生成的测试用例的质量。做法是把被测系统的需求或代码做一组小的变异比如把ABS激活时间从200ms改成300ms然后看AI生成的测试用例能否捕获这个变异。如果能捕获说明测试用例对这个参数是敏感的质量可信如果捕获不到说明测试用例的预期结果写得太宽泛或者参数组合没有覆盖到该参数的边界。变异测试可以作为AI测试生成的自动化验收标准——它能用一个量化的指标告诉你AI生成的测试集到底有多强。收尾环节还有一个关键习惯值得强调无论AI的输出看起来多可信我每次都会把它的结果和标注过的基准集做一次对比。我在实际项目中维护了一个两百条标注历史需求的评估集任何新的模型版本、新的提示词模板、新的RAG参数上线之前先在这个评估集上跑一遍准确率和召回率达标才允许进入正式流程。这个习惯帮我避免过很多次看起来好用了、上线就翻车的状况特别是换了嵌入模型或者改了切块策略之后不跑基准测试根本发现不了召回率的悄然下降。从那以后我每次调整RAG管线的参数都强制走一遍基准评估也希望这个习惯对你有帮助。本文还有配套的精品资源点击获取
