从0到1搭建RAG Agent？这4步实操指南，帮你避开90%的踩坑误区！

AI Agent应用从0到1搭建：全流程落地指南

想要从0到1搭建一套成熟的AI Agent应用，需遵循清晰的推进逻辑，从需求梳理到技术落地，再到工程优化，每一步都有明确的核心动作与关键策略。以下是系统化的搭建路径，帮你高效推进项目落地：

一、锚定核心：以业务需求为起点，分阶段实现迭代闭环

搭建AI Agent的首要前提，是精准锚定业务需求，通过Vibe Coding快速落地核心功能，再聚焦细节持续调优，实现从快速交付到精细化打磨的进阶：

1. 需求梳理与快速实现：先全面梳理业务逻辑，将核心诉求拆解为可落地的功能模块。借助Vibe Coding，可快速达成约80%的核心功能搭建，大幅缩短初期交付周期。
2. 剩余功能迭代优化：针对剩余20%的精细化需求，开展多轮迭代优化。核心动作包括：追踪任务卡点，通过prompt修复指令引导AI精准解决问题；核查测试数据的覆盖度，补齐场景短板，通过多轮打磨，让应用能力逐步完善。

二、技术选型：分步验证，兼顾效率与灵活性

技术框架的选择需兼顾试错成本与扩展性，采用先轻量验证、后稳健迭代的策略，逐步搭建稳固的技术底座：

1. 轻量POC验证：优先选用qwen-Agent开展核心功能验证，依托其效率高、试错成本低的优势，快速跑通业务逻辑，完成一轮POC验证，确保核心方向可行。
2. 框架迭代升级：验证通过后，借助Trae、lingma、Qoder、codeBuddy、Cursor、Claude code、Codex等高代码工具，将框架替换为Nanobot框架，同时结合langchain/langgraph，搭建完整的Agent工作流。过程中，同步规划核心模块的落地，明确是否引入MCP、Skill模块，以及RAG的部署方式，保障技术架构适配业务需求。

若想深入了解Nanobot框架的实战细节，可参考文章：Agent实战首秀！ChatBI股票分析助手：从0到1的智能分析搭建全记录

三、工程约束：沉淀代码规范，破解LLM随机性难题

为规避LLM写代码时的随机性与幻觉问题，需建立完善的工程约束体系，通过规范沉淀提升代码稳定性：

1. 代码规范沉淀：搭建专属代码沉淀体系，借助**@xxx**的约束形式，明确LLM的代码生成规则，从源头规避代码随机性问题。
2. 引入Harness工程思维：融入Harness思维，构建工程约束机制，以标准化的工程管控逻辑，规范代码开发流程，确保代码质量稳定可控。

若想系统掌握Harness思维与工程约束方法，可参考文章：Harness Engineering：从入门到精通

四、质量保障：落地“红-绿-重构”流程，夯实应用稳定性

代码完成后，需依托完善的测试体系与迭代流程，保障应用质量：

1. 测试用例体系搭建：提前梳理并整理完备的测试用例，覆盖核心业务场景与边缘场景，为代码质量验证提供全面依据。
2. 执行“红-绿-重构”流程：代码完成后，严格跑通红-绿-重构流程，先验证测试用例的通过情况，再针对问题持续重构优化，通过反复打磨，筑牢应用的稳定性与可靠性。

这套从0到1的搭建路径，既兼顾了业务需求的快速落地，又保障了技术架构的稳健性与代码质量的可控性，助力高效打造贴合业务诉求的AI Agent应用。

解锁RAG Agent搭建全流程

下面将带大家系统梳理Agent的搭建逻辑，以“基于公司年度报告构建问答系统”为核心案例，拆解从需求落地到流程设计的完整路径，为Agent搭建提供清晰指引。

业务需求，基于公司年度报告构建一个问答系统：

• 随机收集100家公司的年度报告，解析这些报告并构建一个数据库。这些报告是 PDF 格式，每份最长可达 1000 页。
• 然后，系统会生成 100 个随机问题（基于预设模板），RAG系统必须尽快回答这些问题。

所有问题都有确定的答案，例如：

• 是/否；
• 公司名称（某些情况下是多个公司名称）；
• 领导职位头衔、推出的产品名称；
• 数值指标：营收、商店数量等。

每个答案都必须注明引用的页码，确保系统是从原文中得出答案，而不是输出虚假信息。

业务流程图，在native RAG的基础上，加入了两个路由器（router）和 LLM 重排序模块（LLM reranking）：

1.数据预处理：精细化切片，筑牢检索根基
针对PDF文件，先开展数据清洗与标准化处理，统一文件格式、精准提取核心文字，彻底消除格式杂乱、信息冗余等问题；随后按照300字符的小颗粒度进行切片——因目标问答的颗粒度极细，小切片能精准锚定细节信息，避免大切片带来的语义模糊。最终将处理好的切片存入向量数据库，为后续高效检索搭建底层数据底座。

2.路由分流：精准分类，缩小检索范围
面对海量数据带来的检索压力，引入Router路由机制破解难题。其核心逻辑是意图识别与数据分类：预先搭建多类别专属数据库，当用户发起提问时，Router快速识别问题类型，精准匹配对应的数据库，实现靶向筛选。这一过程能大幅缩小检索范围，让待检索的数据量显著缩减，从源头提升检索的精准度与效率。

3.检索与排序：双重优化，锁定核心信息
在精准定位目标数据库后，先开展向量相似度检索，完成基础的信息召回；再通过Rerank Score打分对召回结果进行精细化排序，剔除低关联度内容，让高匹配、高价值的信息脱颖而出，为后续答案生成锁定核心上下文。

4.智能推理：COT赋能，迭代生成优质答案
针对用户问题，依托COT（思维链）拆解背后的隐含逻辑，将复杂问题转化为清晰的处理路径，生成多套针对性答案。结合LLM Rerank对答案进行二次优化，输出融合精准上下文与逻辑框架的全新Prompt，最终交付LLM开展深度推理，迭代生成逻辑严谨、贴合需求的答案。

5.RAG核心链路：闭环驱动，高效输出
整个RAG系统的核心逻辑可概括为：用户Query + 精准检索的上下文 + COT Prompt模板，三者协同输入LLM，形成从需求输入到智能推理的闭环链路，保障答案的精准性与逻辑完整性。

若想深入掌握COT（思维链）的核心原理与应用方法，可查阅文章：初识Agent

===========================================

PDF解析与RAG构建全链路：从格式攻坚到精准检索的落地方案

PDF解析：突破格式壁垒，夯实文本基础

PDF解析是复杂且精细的系统性工程，需攻克格式不统一、结构多样化的核心难题，既要保障内容完整提取，又要兼顾语义连贯性与结构化呈现，具体攻坚策略如下：

1. 解析核心难点与应对

PDF文档格式灵活多变，排版涵盖上下、左右、右左等多方向，还包含图片、表格、公式、页眉页脚等多元元素，解析需精准破解以下痛点：

• 完整保留表格结构、标题、项目符号列表、多栏文本等关键格式；
• 妥善处理图表、公式、页眉页脚等复杂元素；
• 应对排版方向不统一、格式混杂的问题。

落地工具：直接依托Python工具，或选用专业第三方工具，如docling、mineru，高效完成解析工作。

2. 表格处理：破解语义断裂，保障理解精准

大型表格存在度量名称与纵向表头距离过远、合并单元格结构复杂的问题，既会削弱语义连贯性，干扰LLM推理，又会导致向量检索相关性降低，还可能出现表格无法完整装入单个chunk的情况。

核心解决方案：采用表格序列化策略，将表格改写为符合人类表达逻辑的自然语言语句，例如将表格内容转化为“2023年4月5日毛利是98345元”的表述。同时参考Row-wise Serialization（行式序列化）、Attribute-Value Pairing（属性-值对匹配）思路。

3. 格式选择：优先HTML，规避理解偏差

• Markdown格式缺乏结构化标识，LLM易出现理解偏差，一旦理解失误，将引发数据连锁错误；
• HTML凭借tr/td格式可精准描述合并单元格、子标题等复杂结构，且LLM对HTML数据格式熟悉度高，理解准确率显著优于Markdown；
• HTML本质是XML语言，结构化程度高，便于后续操作管理，经大量实验验证，HTML的解析效果更优。

解析成果：最终将报告从PDF转换为包含HTML的Markdown文本，为后续数据库搭建奠定基础。

文档切分：锚定语义连贯，确定合理粒度

文档切分需兼顾操作便捷性与语义相关性，核心目标是让查询与文本块形成强语义关联，提升检索精准度，具体方案如下：

1. 切分方案对比

• 整页切分：操作最简单，因单页token数通常不超几千，但目标语句若分散在整页中，会被大量无关文本稀释，导致相似度得分偏低，语义连贯性不足。
• 小段落切分：通常情况下，能回答问题的信息片段不超过十个句子，小段落能聚焦核心信息，让目标语句获得更高的相似度得分，语义关联性更强。

2. 最终切分策略

采用每页文本分割为300个token（约15个句子）的块的方案，同时为每个块存储专属ID，并在元数据中记录父页面编号，既保障信息聚焦，又便于后续溯源。

数据库搭建：以公司为单位，实现精准管理

针对100家公司的文档，数据库搭建的核心原则是结构清晰、检索精准，避免信息混淆，具体方案如下：

数据库数量选择

搭建100个Faiss数据库，每个数据库对应1家公司的文档，而非将所有公司信息混合存储。

• 优势：无需后续拆分不同公司的信息，想看某家公司的情况，直接检索对应公司的Faiss库即可，结构清晰、检索高效，从源头规避跨公司信息混淆的问题。

Faiss索引选型

采用IndexFlatIP方法创建Faiss数据库，核心特性如下：

• 优点：向量以原始状态存储，无压缩、无量化，采用暴力搜索，检索精度极高；
• 缺点：搜索计算量与内存消耗相对较高，但能充分保障检索的精准度，契合对答案准确性要求高的场景需求。

NativeRAG详解

NativeRAG系统的开发流程：

• 解析 (Parsing)：为知识库准备数据，包括收集文档、将其转换为文本格式，并清理无关的噪点信息。
• 内容提取 (Ingestion)：创建并载入知识库。
• 检索 (Retrieval)：构建一个工具，根据用户查询查找并返回相关数据，通常在向量数据库中进行语义搜索。
• 回答 (Answering)：将检索到的数据 + 用户的提示词（prompt）， 发送给 LLM，返回最终答案。

这里需要你去看下 我上一篇文章 RAG进化论：多模态融合×动态检索优化实战手册，在解析阶段，进行更好的数据清洗，query改写，在检索时，使用混合检索。

检索（Retrieval）

RAG 系统中的R（检索）是一个通用的搜索系统，它接收查询作为输入，返回回答所需的 相关文本。

在基础实现中，它只是对向量数据库发起查询，提取 Top N 个结果。

Retrieval是 RAG 系统中的关键部分，是否需要采用混合搜索？
如果 LLM 在查询上下文中没有接收到必要信息，它就无法提供正确答案（无论我们如何精心设置提示词）垃圾进 → 垃圾出（Garbage in → Garbage out）。

常用的策略是：采用混合搜索
=> vDB + BM25混合搜索（Hybrid search），结合了基于向量语义和传统关键词的搜索（ BM25 算法）。

理论上，它通过不仅考虑文本语义，还考虑精确关键词匹配来提高检索准确性。
=> 将两种方法的搜索结果合并，再进行重排序。

想了解混合搜索，可以去看下我之前写的文章 RAG进化论：多模态融合×动态检索优化实战手册。

重排序（Reranking）

Jina Reranker是一款专为提升信息检索性能设计的神经网络重排序模型，
尤其适用于RAG：

• 细粒度语义分析：采用交叉编码器架构，对查询和文档进行联合编码，捕捉令牌级别的交互细节，弥补传统向量检索（如余弦相似度）在语义理解上的不足。
• 多阶段检索优化：在向量检索初步召回候选文档后，对结果进行二次重排，提升Top-K结果的准确性。例如，在LlamaIndex测试中，命中率提升7.9%，均值倒排率（MRR）提升33.7%。
• 多语言支持：支持100多种语言，在MKQA基准测试中表现优于同类模型（如bge-reranker-v2-m3）24。
• Agentic RAG增强：集成函数调用和Text-to-SQL能力，可识别结构化数据查询意图（如MySQL/MongoDB），并为API调用生成相关性评分，扩展了RAG的应用场景。
• 超快推理速度：通过Flash Attention 2技术优化，v2版本比前代快6倍，比竞品bge-reranker-v2-m3快15倍，参数量仅278M，兼顾效率与性能

想详细了解，可以看下我之前写的文章 Embedding不是魔法：把文字变成数字的底层逻辑。

Jina Reranker和bge-m3都是常用的Reranking模型，但在比赛中作者使用功了LLM重排序

LLM重排序

system_prompt_rerank_single_block=""" 你是一个RAG检索重排专家。 你将收到一个查询和一个检索到的文本块，请根据其与查询的相关性进行评分。 评分说明： 1. 推理：分析文本块与查询的关系，简要说明理由。 2. 相关性分数（0-1，步长0.1）： 0 = 完全无关 0.1 = 极弱相关 0.2 = 很弱相关 0.3 = 略有相关 0.4 = 部分相关 0.5 = 一般相关 0.6 = 较为相关 0.7 = 相关 0.8 = 很相关 0.9 = 高度相关 1 = 完全匹配 3. 只基于内容客观评价，不做假设。 """

LLM 查询结果进行格式化输出，包含两个字段：

• reasoning（让模型解释其判断）和
• relevance_score，可以直接从 JSON 中提取。

修正后的相关性得分，使用加权平均计算：
vector_weight = 0.3，llm_weight = 0.7
理论上，我们可以直接跳过向量搜索，将每一页都直接传递给 LLM。然而，使用embedding进行更便宜、更快速的过滤仍然是必要的。

对于一份 1000 页的文档，仅仅回答一个问题就可能花费约 25 美分——太昂贵了。

父页面检索 (Parent Page Retrieval)

虽然回答问题的核心信息通常集中在某个小块中（这也是分块能提升检索效果的原因），但同一页面的其他部分可能仍包含次要却重要的细节。

因此，在实际应用中，我们会先检索出 Top N 个最相关的文本块
=> 这些块仅作为“指针”来定位对应的完整页面。
=> 随后，我们会将整个页面的内容纳入上下文（context）中进行分析。

这就是为什么我们在每个块的元数据中记录其所属的页面编号——以便快速回溯原始内容。

整合后的检索器 (Assembled Retriever)

最终检索器的步骤：

1. 对查询进行向量化。
2. 根据查询向量找到 Top 30 个相关块。
3. 通过块的元数据提取对应的页面（记得去重）。
4. 通过 LLM 重排序器处理这些页面。
5. 调整页面的相关性得分。
6. 返回得分最高的 Top 10 页，在每一页前面加上页码，并将它们合并成一个字符串。

增强 (Augmentation)

目前为止，向量数据库已建立，RAG 系统中的“R”（检索）已完成，我们现在进入“A”（增强）部分。这部分相当直接，主要是 f-string 字符串拼接操作。

如何更有效的管理提示词存储的方式？
在项目中，尝试了不同方法后，最终确定：将提示词存储在一个专门的prompts.py文件中，并将提示词分割成逻辑块：

• 核心系统指令；
• 定义 LLM 返回响应格式的 Pydantic schema；
• 用于创建单次示例（one-shot）/少次示例（few-shot）提示词的问答对示例；
• 用于插入上下文和查询的模板。

1. 核心系统指令，告诉大模型“你是谁、你要做什么、你要遵循哪些规则”的主提示词。

classAnswerWithRAGContextSharedPrompt:instruction=""" 你是一个RAG（检索增强生成）问答系统。 你的任务是仅基于公司年报中RAG检索到的相关页面内容，回答给定问题。 ... """

2. 定义 LLM 返回响应格式的 Pydantic schema，用 Pydantic 的 BaseModel 定义 LLM 输出的 JSON 格式，强制 LLM 输出结构化内容，便于后续解析和校验。

classComparativeAnswerPrompt:classAnswerSchema(BaseModel):step_by_step_analysis:str=Field(description="详细分步推理过程，至少5步，150字以上。")reasoning_summary:str=Field(description="简要总结推理过程，约50字。")relevant_pages:List[int]=Field(description="保持为空列表。")final_answer:Union[str,Literal["N/A"]]=Field(description="公司名称需与问题中完全一致。答案只能是单个公司名或'N/A'。")

3. 用于创建单次示例（one-shot）/少次示例（few-shot）提示词的问答对示例
   给 LLM 一个或几个“问题-答案”示例，帮助它学会输出你想要的格式和风格。

example=r"""示例： 问题： "下列公司中，哪家2022年总资产最低："A公司", "B公司", "C公司"？若无数据则排除。" 答案： { "step_by_step_analysis": "...", "reasoning_summary": "...", "relevant_pages": [], "final_answer": "C公司" } """

4. 用于插入上下文和查询的模板，让 LLM 能够“看到”相关内容和问题，基于这些内容作答。

user_prompt=""" 以下是上下文: \"\"\" {context} \"\"\" --- 以下是问题： "{question}" """

prompts.py 文件就是把所有和 LLM 交互相关的提示词、格式、示例、模板都集中管理，并且分成了四个逻辑块：

• 系统指令：告诉 LLM 你是谁、你要干什么。
• Pydantic schema：告诉 LLM 输出什么格式。
• 示例：给 LLM 看标准答案，学会怎么答。
• 模板：动态插入上下文和问题，驱动实际问答。

这样做的好处是结构清晰、易于维护、可复用、易于扩展，也是当前主流 LLM/RAG 项目的最佳实践。

生成 (Generation)

RAG 中的 “G”（生成）是最耗费精力的。要在这一阶段实现高质量，需要巧妙地使用几种技术。

业务场景：

• 每家公司都设置了独立的向量数据库。
• 问题中明确包含公司名，直接匹配即可定位数据库。

实际应用：可能需要 LLM 提取实体或打标签来匹配数据库。
核心逻辑：1.提取公司名 → 2. 匹配对应数据库 → 3. 仅搜索该库。
这样可将搜索范围缩小 100 倍，提升效率。

将查询路由到数据库（RAG 系统中最简单却最有用的部分）：

答案必须简洁且严格匹配指定数据类型（如int/float/bool/str/list[str]），类似数据库存储格式：

• 每种类型有 3-6 个细节需处理（如去除货币符号、单位换算等）。
• 直接让 LLM 遵守所有规则不可靠：规则越多，出错概率越高。

解决方案：
将复杂查询拆解为多个简单步骤，减少单次请求的规则数量。
例如：

• 先提取原始数值；
• 再单独处理货币单位转换。
  分步操作能显著提升准确性。

核心思路：简化任务 → 降低 LLM 认知负荷 → 确保格式零错误。

查询路由到提示词：

由于每个问题的预期响应类型（如int/float/bool/str/list[str]）都是明确给定的，我们可以采用更直接的解决方案：
为每种数据类型预先设计了专门的提示词模板，然后通过简单的if-else逻辑来自动选择对应的提示词版本。

这种方法既保证了回答格式的精确性，又实现了高效的自动化处理。

复合查询路由：

处理涉及多家公司比较的复杂问题时，采用分步拆解。

比如：苹果和微软谁的营收更高？

1. 问题拆解阶段

   • 首先由LLM将原始比较问题自动拆解为多个独立子问题
   • 示例生成："苹果的营收是多少？“和"微软的营收是多少？”

2. 并行查询阶段

   • 对每个子问题使用标准查询流程独立处理
   • 分别获取各家公司的精确指标数据

3. 综合判断阶段

   • 将收集到的各公司数据作为上下文
   • 由LLM进行最终比较并生成答案

复合查询路由：

这种模块化处理模式具有高度可扩展性，能够灵活应对各类复杂比较查询

调优

思维链 (Chain of Thoughts, CoT)

思维链（CoT）通过让模型在给出最终答案之前“出声思考”，显著提高了答案质量。

早期提示词工程中，“一步步思考”（Think step by step）这类通用指令能提升答案质量，但对复杂任务仍不足。
尤其较弱模型（如GPT-4o-mini、Llama 8b）常出现“虚假推理”——先给答案再倒推理由，甚至捏造事实。

COT有2种方式：
1）基于业务经验，老法师做一遍给出few shot
2）thinking模型

为了确保CoT 的作用，我们必须清晰地引导模型如何进行推理。解释推理步骤、目标、并提供示例。

带有模糊上下文的推理示例：

Ritter Pharmaceuticals Inc. 的研发设备（按成本计）是多少？

模型的推理步骤：

1. 问题询问 Ritter Pharmaceuticals Inc. 的“研发设备，按成本计”。这表明需要从资产负债表中提取一个特定数值，代表专门用于研发的设备的原始购置成本，不包含任何累计折旧。

2. 上下文（第 35 页）显示“不动产和设备，净额”为 12,500 美元。这是一个净值（已扣除折旧），而且是一个更广泛的类别，包含所有不动产和设备，而不仅仅是研发设备。

3. 上下文（第 37 页）还提到“机械和设备”的“累计折旧”为 110,000 美元。这代表了总的折旧，而不是原始成本，更重要的是，它没有说明这些设备专门用于研发。

4. 这两个指标都不完全符合请求的指标。“不动产和设备，净额”范围太广，且是折旧后的价值。“累计折旧”仅显示折旧，而非成本，并且缺乏研发的针对性。

5. 由于上下文没有提供仅用于研发设备的原始成本，且我们无法进行假设、计算，因此答案是“N/A”。

大家也可以去看下我之前的文章，了解下COT到底是什么？ 初识Agent。

结构化输出 (Structured outputs)

结构化输出（Structured Output，SO）是一种强制模型返回标准化格式（如JSON/Pydantic schema）的方法。

通过API传递schema，确保输出始终符合预定结构。

比如，这里是用于 LLM 重排序的 Pydantic schema

classRetrievalRankingSingleBlock(BaseModel):"""Rank retrieved text block relevance to a query."""reasoning:str=Field(description=("Analysis of the block, identifying key information and how it""relates to the query"))relevance_score:float=Field(description=("Relevance score from 0 to 1, where 0 is Completely Irrelevant ""and 1 is Perfectly Relevant"))

有了这个 schema，LLM 总是会返回一个包含两个字段的JSON——第一个是字符串，第二个是数字。

CoT+SO （思维链+结构化输出）

思维链 + 结构化输出 可以理想地结合使用：
在生成阶段，LLM模型有一个专门用于推理的字段，还有一个单独的字段用于最终答案 => 这样我们可以直接提取答案，而无需从冗长的推理步骤中进行解析。

在用于回答比赛问题的主要schema 中，设置了四个字段：
•step_by_step_analysis：初步推理（思维链本身）。
•reasoning_summary：前一个字段的精简摘要（用于更轻松地跟踪模型的逻辑）。
•relevant_pages：答案引用的报告页码。
•final_answer：根据业务要求格式化后的简洁答案

指令细化 (Instruction Refinement)

当AI回答用户问题时，需要判断"答案的灵活范围"——比如问"CEO是谁"，实际要包括哪些类似职位？（如总裁、董事总经理等）

这种问题，在现实中经常遇到，而且现实数据不完美，即不同公司用不同头衔称呼老大（美国叫CEO，英国可能叫MD）

用户真正想知道的可能比字面意思更广 => 所以需要对 instruction 进行细化

指令细化的挑战：

1. 解释自由度：该把哪些边缘情况算作答案？

   • 硬标准：只认"CEO"字眼；
   • 软标准：包括相似职位（如总裁/MD），但要划定界限；

2. 如果没有找到答案，该如何处理：
   比如：问"股息政策有变吗？“，若报告未提及，该回答"无变更"还是"无信息”？

解决方案：

• 提前与客户确定规则（如"接受MD作为CEO的答案吗？"）；
• 收集大量边缘案例测试系统；

真实案例对比：

• 灵活回答（适合开放问答）：“Ethan Caldwell是董事总经理（最接近CEO的角色），但目前因调查暂停职务…”；
• 严格回答（适合简答问答）：需预先定义是否允许"MD≈CEO"，否则可能输出错误简答

指令细化，这一部分的工作量与整个数据准备阶段不相上下，因为需要进行无止境的迭代调试、校对答案以及手动分析模型的推理过程。

提示词创建 (Prompt Creation)

通过LLM，利用公开的问题生成器快速创建了100个问题的验证集，并通过手动回答这些问题获得了两个重要收益：

• 量化改进：验证集成为客观衡量系统性能的标准，通过统计正确率和错误模式，能精准优化提示词和流程。
• 发现隐性规则：手动分析暴露了问题中隐藏的细节和歧义，促使团队与专家（Rinat）确认回答规范，并将这些规则明确写入提示词指令中。

最终，这些洞察被系统化地整合到提示词设计中，形成更严谨的指令框架。

RAG系统调参

拥有一个验证集不仅帮助改进了提示词，也使整个系统受益。

我们将所有关键功能配置化，以便衡量它们的实际效果并微调超参数。以下是一些示例配置字段：

classRunConfig:# 运行流程参数配置use_serialized_tables:bool=Falseparent_document_retrieval:bool=Falseuse_vector_dbs:bool=Trueuse_bm25_db:bool=Falsellm_reranking:bool=Falsellm_reranking_sample_size:int=30top_n_retrieval:int=10parallel_requests:int=1# 并行的数量，需要限制，否则qwen-turbo会超出阈值pipeline_details:str=""submission_file:bool=Truefull_context:bool=Falseapi_provider:str="dashscope"#openaianswering_model:str="qwen-turbo-latest"config_suffix:str=""

通过配置不同的RAG超参数，惊讶地发现：原来被寄予厚望的表格序列化，不仅没有改进系统，反而降低了有效性。

系统化方法胜于“神奇方案”：成功并非依赖单一突破性技术，而是通过系统化的流程优化，结合并精细调整多种技术。
这些关键因素包括：

• 高质量解析：确保数据预处理精准、结构化。
• 高效检索：优化检索效率与准确性。
• 智能路由：动态分配查询到最合适的处理模块。
• LLM重排序：利用大语言模型对检索结果重新排序，显著提升相关性。
• 提示词设计：精心设计的提示词（prompt engineering）使紧凑模型也能发挥出色性能。

RAG的优化是一个精细化工程问题，RAG问答结果高度依赖对任务细节的深入理解，通过精准微调每个环节（解析、检索、路由、排序等），即使简单技术也能实现显著效果。

高效梳理测试灰色地带问题

面对测试中边界模糊、覆盖不足的灰色地带，可依托人机协同的三步闭环流程，实现高效、全面的梳理，既发挥人类的专业判断力，又借助AI的发散能力拓展边界，具体落地路径如下：

一、核心流程：三步联动，精准锁定灰色地带

这套流程以“人类锚定核心+AI拓展边界+人工校验确认”为核心逻辑，层层递进，确保不遗漏关键灰色场景，同时避免无效冗余：

1. 锚定种子：人类输出核心灰色问题
   由测试人员基于业务经验与场景认知，主动撰写1个典型的灰色测试问题。这类问题需聚焦边界模糊、规则不清晰、易被忽视的核心地带，作为整个梳理流程的起点，为后续拓展划定核心方向。

2. AI拓展：LLM发散挖掘潜在场景
   将第一步确定的种子问题输入LLM，借助其强大的发散联想与场景推演能力，全面拓展出更多可能的灰色测试问题。AI可快速覆盖人类思维易遗漏的边缘场景、隐性关联场景，大幅拓宽灰色地带的覆盖范围，弥补人工梳理的局限性。

3. 人工校验：筛选确认有效边界
   对LLM输出的拓展问题进行人工过滤与确认，剔除重复、无关、不符合业务实际的无效内容，保留真正属于灰色地带的核心问题，最终形成完整、精准的灰色测试问题清单。这一步依托人类的专业判断，把控最终质量，确保梳理结果贴合业务需求。

二、配套技术支撑：全链路工具协同，夯实落地基础

梳理灰色地带问题的同时，需依托完善的技术工具体系，为测试全流程提供底层支撑，核心工具覆盖数据处理、AI应用、交互搭建等关键环节：

• 数据处理层：以数据清洗规范原始数据格式、剔除杂质，保障输入质量；借助mineru高效完成文档解析与信息提取，为测试提供精准数据源。
• AI核心层：依托LLM完成问题拓展、逻辑推演；通过embedding将文本转化为向量，支撑语义检索与匹配，提升测试场景的覆盖效率。
• 交互与服务层：采用streamlit、gradio这类轻量Python Web框架快速搭建可视化交互界面，降低测试操作门槛；以flask作为Python后端框架，提供稳定的接口服务，保障测试流程的顺畅运行；同时预设回答问题模板，统一输出格式，提升测试反馈的规范性与效率。

这套“人机协同的三步闭环法”，既解决了人工梳理灰色地带效率低、覆盖不全的痛点，又通过成熟的技术工具链保障了落地可行性，助力测试工作精准覆盖边界场景，全面提升测试质量。