在这个AI深度介入软件开发的时代，作为一名测试工程师，如果你还停留在“自动化测试脚本怎么写”的阶段，那就已经有点落后了。如今，我们已经进入了一个“如何与大模型合作”的新纪元。
今天，我想带大家深入了解一个可能听过但不太熟悉的技术名词——RAG（Retrieval-Augmented Generation，检索增强生成），以及一个你今后绕不开的重要概念：上下文窗口（context window）。别急，这两个概念并不复杂，咱们从一个生活中的小故事说起。
一段搜索与回答的故事
假设你正在做一个旅游预订系统的测试，你对模型说：“我想测试删除预订功能的相关风险。”
如果你直接把这个问题抛给一个大语言模型，它可能会根据训练时见过的一般知识来给你一些通用建议，比如“考虑权限验证”、“检查是否有未支付订单”等等。
但你很清楚，这套系统有它自己的业务逻辑，有详细的用户故事、功能说明、甚至特定的异常流程。这些文档模型并不知道，它只是在“盲猜”。
这时候，RAG就上场了。
什么是RAG？它是如何帮你问得更聪明的？
RAG系统的核心思路其实非常直白：先查资料，再回答问题。
它的工作流程大致是这样的：
接收你的提问：比如“我想测试删除预订的相关风险点。”
去文档库检索相关内容：比如项目中的用户故事、需求文档、接口说明等。
从中选出最相关的几条：比如三条关于“删除预订”场景的用户故事。
把这些文档 + 你的问题，一起发给大模型：通过设计一个标准的提示词（prompt），告诉它：“这是用户故事，这是用户问题，请基于这些信息推荐测试风险。”
这时模型的回答就不再是“凭空想象”，而是在了解了背景文档的前提下，给出更贴切、更有上下文的回答。
就好像你在群里问“这个模块怎么测”，如果没人看文档就直接说“测下边界值”，那是套话。但如果有人先读了需求说明，再告诉你“这地方逻辑是先删子订单再删父订单，容易遗漏错误处理”，这才是有价值的回答。
那为什么不把所有文档都发给大模型？
听起来很棒是吧？那我们干脆一次性把所有文档都加进去，岂不是更保险？
——不行。我们得面对一个现实限制：上下文窗口（context window）。
什么是上下文窗口？
简单来说，大模型就像一个一次只能阅读10页书的助手。你不能指望它一口气把你500页的测试文档读完再回答问题。
以Meta的LLaMA-2为例，它的默认上下文窗口是4096个token，大约相当于10页书的内容。这个“窗口”是模型记忆的上限。超过这个数量，它要么把后面的信息截断，要么直接报错。
你可能会问：“10页不够用吗？” 对于一般搜索，够了。但在测试工作中，一个完整的需求分析文档就能有几十页；代码分析、异常用例、接口定义等也都能占不少篇幅。更别说要做链路追踪或微服务依赖分析的情况。
因此，在RAG中，我们必须挑重点的内容来加。就像你考试前做笔记，不可能把整本书抄下来，只抄最关键的章节。同理，我们用检索工具来决定哪些“资料片段”最相关，再送给模型看。
提示词结构长啥样？给你看个例子
基于前面的逻辑，一个RAG提示词大致是这样的结构：
你是一个负责测试设计的助手。你需要基于提供的用户故事，输出推荐的测试风险点。这是用户故事：{relevant_document} 用户的问题是：{user_input} 请列出推荐的测试风险点。通过这样的提示词设计，模型不仅知道你要问什么，还清楚你在问谁、问的是哪段文档、要输出哪类内容。这比模糊地问“你觉得我该测什么”靠谱得多。
测试人员需要掌握的关键知识点
如果你是测试工程师，尤其是希望使用AI辅助工作的中高级测试人员，我建议你至少掌握以下几个关键点：
理解上下文窗口的限制：你要知道一个模型一次能看多少内容，不然总是“提示词超长”。
掌握检索工具的使用：比如使用向量数据库（如FAISS、Weaviate）对文档进行索引，便于做语义搜索。
能设计结构化提示词：清晰地告诉模型你要它扮演什么角色、参考什么内容、输出什么结构。
知道怎么做“裁剪”：面对一堆文档，你要学会判断哪些是关键，哪些可以忽略。
关注未来上下文窗口的演进：一些新模型（如Claude 3、GPT-4 Turbo）已经支持几十万token，未来这项限制会逐步放宽，但不会彻底消失。
RAG结构图
RAG结构图如下：
RAG不是一个高高在上的黑科技，它更像是一种高效使用AI的思维方式。就像你面对一个助理，你不会一句话把所有问题都抛给TA，而是会先把资料准备好，再请TA给建议。
而理解上下文窗口的限制，就像知道这个助理一次只能看几页纸一样，是与模型协作的基本素养。
