基于BGE-M3与Qwen2.5构建乌克兰语Agentic RAG系统实战-开发者社区

1. 项目概述：当RAG走向“能动性”，为乌克兰语内容赋能

最近在折腾大语言模型应用落地的朋友，对RAG（检索增强生成）这个概念肯定不陌生。简单说，就是让模型在回答问题时，不是凭空“编造”，而是先去一个庞大的知识库（比如你的文档、数据库）里检索相关信息，再基于这些“证据”来生成答案。这极大地缓解了模型“一本正经胡说八道”的幻觉问题。但传统的RAG流程，往往是“一次性”的：用户提问 -> 检索 -> 生成答案，然后就结束了。整个过程模型是被动的，缺乏对复杂、多轮问题的深度思考和规划能力。

这就引出了“Agentic RAG”（能动性RAG）这个概念。它不是一个具体的工具，而是一种设计范式。你可以把它理解为给RAG系统装上了一个“大脑”和“双手”。这个系统不再只是被动响应，而是能像一个智能代理（Agent）一样，主动规划任务、拆解复杂问题、进行多轮甚至多工具的交互。比如，面对一个需要综合多份文档、进行对比分析才能回答的问题，Agentic RAG会自己制定计划：先检索A文档的关键部分，再根据初步结果去检索B文档的相关段落，发现信息矛盾时，可能还会去检索第三份权威资料进行验证，最后综合所有信息，生成一个逻辑严谨、证据链完整的回答。

而我这次动手实践的目标，是将这套先进的Agentic RAG范式，应用到一个相对小众但极具价值的领域：乌克兰语内容处理。选择乌克兰语，一方面是出于对多语言AI应用公平性的关注，另一方面也是因为其作为一门拥有复杂语法和丰富形态变化的语言，对检索和生成都是不小的挑战。市面上成熟的RAG方案大多围绕英语、中文优化，直接套用到乌克兰语上，效果往往大打折扣。

这个项目的核心，就是构建一个能理解、检索并智能处理乌克兰语文档的“能动”系统。我选用了两个在各自领域表现出色的开源模型作为基石：BGE-M3作为多语言嵌入模型负责文档的向量化与检索，Qwen2.5-3B-Instruct作为轻量级但能力不俗的生成模型，扮演“智能体大脑”的角色。接下来，我会详细拆解从设计思路到代码实现的每一个环节，分享如何让这两个模型协同工作，打造一个真正能为乌克兰语内容服务的Agentic RAG系统。

2. 核心架构与组件选型解析

构建一个Agentic RAG系统，远不是把检索和生成模型简单拼在一起。它需要一套清晰的架构，让各个组件各司其职又能高效协同。我的设计核心是“分工明确，循环迭代”。整个系统可以看作一个由“规划器”、“执行器”（检索工具）和“生成器”组成的智能工作流。

2.1 为什么是Agentic？与传统RAG的本质区别

传统RAG可以看作一个“查询-响应”系统。它的流程是线性的、静态的。用户输入问题，系统将其转化为向量，去向量数据库做一次相似性搜索，返回Top-K个相关片段，然后一股脑塞给大模型，说：“给，这是相关资料，请生成答案。” 这种方式存在几个明显短板：

检索僵化：一次检索定终身。如果第一次检索没找到关键信息，或者检索到的信息相互矛盾，系统没有自我修正的机会。
缺乏推理：模型只是信息的“总结者”，而非“思考者”。它无法判断是否需要进一步搜索，也无法将复杂问题拆分成多个子问题逐步解决。
上下文局限：当问题涉及多个方面或需要多步骤推理时，一次性提供的杂乱上下文很容易让模型迷失重点。

Agentic RAG则引入了“智能体”的思维模式。它将整个问答过程视为一个可规划、可执行、可评估的任务。系统会先对用户问题进行意图理解和任务规划（例如：“这是一个需要对比分析的问题，我需要先找到A产品的特性，再找到B产品的特性，最后进行比较”）。然后，它会自主调用检索工具，可能进行多轮、带有反馈的检索。每次检索后，它都会评估当前收集到的信息是否足够、是否准确，如果不够，就生成新的、更精准的查询词再次检索。这个过程可以循环多次，直到它认为信息完备，再启动最终答案的生成。

简单类比：传统RAG像是一个记忆力好但不会思考的图书管理员，你问什么，他就在固定区域找几本书给你。而Agentic RAG像是一个资深的研究助理，他会先理解你研究课题的深度，然后制定查阅计划，去档案室、数据库、期刊库等多处查找、对比、验证资料，最后给你整理出一份详实的报告。

2.2 核心组件深度选型：BGE-M3与Qwen2.5-3B-Instruct

选型直接决定了系统的能力上限和落地成本。我经过大量测试和对比，为本次乌克兰语项目锁定了以下两个核心模型。

嵌入模型：BGE-M3检索的基石在于如何将文本（无论是问题还是文档）转化为数学向量（嵌入）。这个向量的质量直接决定了检索的准确性。对于多语言场景，尤其是乌克兰语，模型必须在多种语言上都有均衡且强大的表现。

为何选择BGE-M3？BGE-M3是北京智源研究院开源的“重磅炸弹”，它最突出的特点是“全能”。它支持超过100种语言，并且在 Massive Text Embedding Benchmark (MTEB) 排行榜上综合表现非常靠前。它不仅支持最常用的稠密向量检索（dense retrieval），还同时支持稀疏向量检索（lexical retrieval，类似传统关键词匹配）和多向量检索（ColBERT-like），这意味着它可以通过多种方式理解文本相似性。对于乌克兰语，我测试了其与LaBSE、multilingual-e5等模型的对比，BGE-M3在语义相似度任务上表现更稳定，对语言形态变化（如词尾变化）的理解更好。
实操注意点：BGE-M3模型较大（约2.2B参数），需要一定的GPU内存（例如，FP16精度下需要约4.5GB）。在部署时，可以使用FlagEmbedding库轻松加载。一个关键技巧是，对于非英语查询，官方建议在查询文本前添加指令“Represent this sentence for searching relevant passages: ”，这能显著提升跨语言检索效果。对于乌克兰语文档，我们则不需要添加此指令。

生成模型/智能体大脑：Qwen2.5-3B-Instruct在Agentic RAG中，生成模型扮演着“大脑”的角色：它要理解用户意图、规划任务、决定何时检索、如何提炼检索结果、并生成最终答案。因此，我们需要一个既足够“聪明”能进行复杂规划，又足够“轻量”便于快速响应和部署的模型。

为何选择Qwen2.5-3B-Instruct？通义千问开源的Qwen2.5系列在轻量级模型中表现堪称惊艳。Qwen2.5-3B-Instruct虽然只有30亿参数，但其指令跟随、逻辑推理和工具调用能力在同类模型中脱颖而出。它完全支持Agent所需的复杂指令理解和多轮对话规划。相比于更大的7B、14B模型，3B版本在消费级显卡（甚至高端CPU）上就能流畅运行，推理速度极快，非常适合作为实时交互的智能体核心。它的多语言能力也足够覆盖乌克兰语的理解与生成。
实操注意点：使用该模型作为Agent，关键在于系统提示词（System Prompt）的设计。我们需要在提示词中明确赋予它“规划者”和“执行者”的角色，定义好它可以使用的工具（这里主要是检索工具），并规定它输出格式（例如，以特定JSON格式表示下一步动作）。我们可以使用transformers库或vLLM进行部署和推理。对于3B模型，在RTX 3060（12GB）上即可进行FP16精度的流畅推理。

2.3 系统工作流设计

整个系统的工作流程是一个动态循环，如下图所示（概念描述）：

初始化：用户输入一个乌克兰语问题。
规划阶段：Qwen2.5-3B-Instruct（作为Agent）接收问题，结合系统指令，分析问题复杂度。如果问题简单直接，它可能决定直接跳转到最终生成；如果问题复杂，它会生成一个任务规划，例如：“首先，需要检索关于‘乌克兰能源政策’的概述性文档；其次，需要检索最近一年关于‘可再生能源投资’的具体新闻或报告。”
执行与检索阶段：Agent根据规划，生成一个或多个精准的检索查询词（可能是乌克兰语，也可能是模型内部翻译成的英语，但BGE-M3能处理）。系统调用BGE-M3模型，将这些查询词转化为向量，在预先构建好的乌克兰语文档向量库中进行相似性搜索，返回最相关的文本片段。
评估与迭代阶段：Agent收到检索结果后，对其进行评估。它会判断：信息是否足够？是否回答了当前子问题？是否存在矛盾？如果不够，它会基于已有信息，生成一个更聚焦、更具体的后续查询词（例如：“在刚才找到的能源政策文档中，没有提到太阳能的具体补贴金额，请专门检索‘乌克兰太阳能补贴 2024’。”），然后回到第3步。这个过程可能循环2-4次。
生成阶段：当Agent判定信息已收集充分，或达到最大迭代次数时，它将所有相关的检索片段作为上下文，综合生成一个连贯、准确、基于证据的乌克兰语最终答案，返回给用户。

这个循环的核心是“思考-行动-观察”的智能体范式，使得系统具备了处理复杂、开放式问题的能力。

3. 乌克兰语知识库构建与检索优化实战

Agentic RAG的“智能”发挥，建立在高质量、易检索的知识库之上。对于乌克兰语，这一步的挑战更大，需要针对语言特点做专门处理。

3.1 文档预处理与分块策略

原始文档（PDF、网页、DOCX等）不能直接用于检索。我们需要将其转化为纯文本，并切割成大小合适的“块”。

文本提取：使用pypdf（PDF）、beautifulsoup4（HTML）、python-docx（DOCX）等库进行文本提取。对于乌克兰语网页，特别注意编码问题，通常使用UTF-8。
分块（Chunking）：这是关键步骤。分块太大，会包含无关信息，稀释检索精度；分块太小，会割裂语义，让模型难以理解。
- 策略选择：对于一般性文档，我采用“递归字符分割”结合“句子重叠”的策略。使用langchain的RecursiveCharacterTextSplitter是一个不错的选择。分隔符可以设置为["\n\n", "\n", "。", "！", "？", " ", ""]，优先按段落分割。
- 乌克兰语特调：乌克兰语句子结束符与英语类似，但要注意其特有的标点。块大小（chunk_size）设置为512-1024个字符（约150-250个单词），重叠（chunk_overlap）设置为100-150个字符。重叠部分能确保关键信息不会因为恰好被切在块边缘而丢失。
- 元数据附加：为每个文本块附加元数据非常重要，例如来源文件名、原始页码、章节标题等。这在最终生成答案时，可以为模型提供引用来源信息，也便于人工核查。

3.2 使用BGE-M3生成高质量向量

分块后的文本需要转化为向量存入数据库。

加载模型：

from FlagEmbedding import BGEM3FlagModel model = BGEM3FlagModel('BAAI/bge-m3', use_fp16=True) # 使用FP16加速，节省显存

批量编码：一次性对大量文本进行编码效率更高。注意，BGE-M3的encode方法会返回稠密向量、稀疏向量等多重表示。我们主要使用稠密向量（dense_vecs）进行检索。
```
# 假设 `chunks` 是文本块列表 embeddings = model.encode(chunks, batch_size=32, # 根据GPU内存调整 max_length=8192, # 模型最大长度 return_dense=True, return_sparse=False, return_colbert_vecs=False) dense_embeddings = embeddings['dense_vecs']
```
注意：BGE-M3模型本身支持长文本，但通常我们会将输入限制在512或1024个token以内，这与我们分块的大小相匹配。对于超过模型长度的文本，它内部会进行截断或池化操作。

3.3 向量数据库的选择与部署

我们需要一个数据库来存储这些向量，并支持高效的相似性搜索。

选型：Chroma DB。我选择Chroma是因为它轻量、易用、完全开源，并且与Python生态集成极好。它支持内存和持久化模式，对于中小规模知识库（百万级向量以下）完全够用。

部署与插入：

import chromadb from chromadb.config import Settings # 创建或连接持久化数据库 client = chromadb.PersistentClient(path="./ukrainian_rag_db") collection = client.get_or_create_collection(name="ukrainian_docs") # 准备数据：ID、文本、向量、元数据 ids = [f"chunk_{i}" for i in range(len(chunks))] documents = chunks metadatas = [...] # 对应的元数据列表 # 批量插入 collection.add( ids=ids, documents=documents, metadatas=metadatas, embeddings=dense_embeddings.tolist() # 注意转为list )

检索查询：在Agentic循环中，当需要检索时：

# 假设 `query` 是Agent生成的搜索词 # 对查询词进行编码，添加检索指令以优化效果 query_for_retrieval = f"Represent this sentence for searching relevant passages: {query}" query_embedding = model.encode([query_for_retrieval], return_dense=True)['dense_vecs'][0] # 在Chroma中搜索 results = collection.query( query_embeddings=[query_embedding.tolist()], n_results=5 # 每次检索返回5个最相关片段 ) retrieved_docs = results['documents'][0] retrieved_metadatas = results['metadatas'][0]

4. 智能体（Agent）的构建与提示工程

这是Agentic RAG的灵魂所在。我们需要让Qwen2.5-3B-Instruct模型学会规划、使用工具（检索）、评估和生成。

4.1 系统提示词设计

系统提示词定义了Agent的角色、能力和行为规范。一个强大的提示词是成功的关键。

你是一个专业的乌克兰语信息分析助手。你的核心能力是使用检索工具来查找乌克兰语文档库中的信息，以回答用户的问题。 ## 能力 1. **规划**：分析用户问题的复杂性。如果问题简单，可以直接回答；如果复杂，将其分解为多个子问题。 2. **检索**：你可以使用`search_documents`工具。根据你的规划，生成最精准、关键的搜索查询词来查找相关信息。你可以进行多轮检索。 3. **评估**：每次收到检索结果后，评估信息是否足够、相关、准确。思考：是否已回答了当前子问题？是否需要从不同角度或更具体地搜索？ 4. **综合与生成**：当你认为信息足够时，综合所有检索到的相关信息，生成一个清晰、准确、完整的乌克兰语答案。答案必须基于检索到的证据，可以引用来源（如提到“根据XX文档”）。 ## 行动格式 你必须严格按照以下JSON格式输出你的“思考过程”和“下一步行动”： { "thought": "你的详细思考过程，分析问题，规划步骤，评估当前信息。用乌克兰语或英语思考均可。", "action": "next_step", // 可以是 "search", "final_answer" "action_input": { // 只有当 action 为 "search" 时才需要 "query": "你的搜索查询词，使用最可能找到答案的关键词" } } ## 流程控制 - 从分析用户问题开始。 - 如果决定搜索，输出上述JSON，工具会被自动调用，并将结果返回给你。 - 你收到搜索结果后，继续输出JSON格式的思考和新行动。 - 当你决定给出最终答案时，将 `action` 设为 `"final_answer"`，并在 `"thought"` 字段后直接开始用乌克兰语书写完整答案。 现在，开始处理用户的问题。

这个提示词明确了角色、步骤、输出格式和循环逻辑，将大模型“框定”在我们希望的工作流中。

4.2 工具调用与循环控制实现

我们需要编写代码来解析模型的输出，调用工具，并将结果反馈给模型，形成循环。

import json from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 加载Qwen2.5-3B-Instruct模型 model_name = "Qwen/Qwen2.5-3B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype=torch.float16, device_map="auto") def chat_with_agent(user_query, system_prompt, max_turns=5): """ 与Agent进行多轮交互 """ messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_query} ] for turn in range(max_turns): # 1. 获取模型响应 inputs = tokenizer.apply_chat_template(messages, tokenize=True, add_generation_prompt=True, return_tensors="pt").to(model.device) with torch.no_grad(): outputs = model.generate(inputs, max_new_tokens=512, do_sample=True, temperature=0.7) response_text = tokenizer.decode(outputs[0][len(inputs[0]):], skip_special_tokens=True) # 2. 尝试解析JSON格式的“行动指令” try: # 找到可能的JSON块 lines = response_text.strip().split('\n') json_str = None for line in lines: if line.strip().startswith('{'): json_str = line.strip() break if json_str: action_data = json.loads(json_str) else: # 如果没有检测到JSON，可能模型直接给出了最终答案 print(f"Turn {turn+1}: 模型可能直接生成了最终答案或格式错误。") print("响应:", response_text[:200]) return response_text except json.JSONDecodeError: print(f"Turn {turn+1}: 解析JSON失败，响应内容：", response_text[:200]) return "Agent响应格式错误。" # 3. 根据行动类型处理 if action_data.get("action") == "final_answer": # 提取最终答案（通常在thought字段之后） final_answer = response_text.split('"thought":')[1].split('"final_answer":')[-1] if '"final_answer":' in response_text else action_data.get("thought", "") print(f"Turn {turn+1}: 生成最终答案。") return final_answer elif action_data.get("action") == "search": search_query = action_data.get("action_input", {}).get("query") if not search_query: print("搜索查询词为空。") break print(f"Turn {turn+1}: 执行搜索，查询词: {search_query}") # 4. 调用检索工具（这里接入上一节的检索函数） search_results = retrieve_documents(search_query, top_k=5) # 假设retrieve_documents是封装好的检索函数 # 将检索结果格式化为文本，准备喂给模型 retrieved_context = "\n---\n".join([f"[片段{i+1}]: {doc}" for i, doc in enumerate(search_results)]) # 5. 将检索结果作为“助手”的观察，添加到对话历史 messages.append({"role": "assistant", "content": response_text}) # 记录模型刚才的“行动”输出 messages.append({"role": "user", "content": f"这是检索到的信息：\n{retrieved_context}\n\n请根据这些信息继续分析。"}) else: print(f"未知行动: {action_data.get('action')}") break return "达到最大交互轮数，未生成最终答案。" # 使用示例 system_prompt = ... # 填入上面的系统提示词 user_question = "乌克兰在可再生能源领域，特别是风能和太阳能方面，最新的国家战略和激励政策是什么？" final_answer = chat_with_agent(user_question, system_prompt) print("\n=== 最终答案 ===\n") print(final_answer)

这段代码实现了核心的Agent循环。模型输出JSON指令，代码解析并执行检索，再将结果反馈，直到模型决定给出最终答案。

4.3 多轮检索与自我修正策略

在循环中，Agent的“智能”体现在它如何利用前一轮的检索结果来优化下一轮的查询。这通常通过系统提示词和模型自身的推理能力来实现。在我们的提示词中，要求模型进行“评估”。在实践中，模型可能会：

细化查询：第一轮搜索“乌克兰可再生能源政策”，返回的是概述。模型发现缺少具体数据，第二轮搜索“乌克兰 2024 太阳能装机容量目标”。
纠正方向：第一轮搜索“乌克兰风能补贴”，返回信息过时。模型在思考中判断“可能需要查找2023年或2024年的最新法案”，从而发起新的搜索。
综合验证：从不同文档中检索到看似矛盾的信息（如两个不同的补贴比例），模型可能会发起第三次搜索，查询“乌克兰可再生能源补贴官方最新文件”来寻找权威来源进行核实。

这种自我修正能力，是Agentic RAG超越传统单次检索的核心价值。

5. 系统集成、评估与性能调优

将各个模块组装成一个稳定、高效的服务，并科学评估其效果，是项目落地的最后一步。

5.1 端到端服务搭建

我们可以使用FastAPI搭建一个简单的Web服务，提供API接口。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import uvicorn app = FastAPI(title="Ukrainian Agentic RAG API") class QueryRequest(BaseModel): question: str max_turns: int = 5 class QueryResponse(BaseModel): answer: str sources: list[str] # 可以返回引用的文档来源ID或片段 turn_count: int @app.post("/ask", response_model=QueryResponse) async def ask_question(request: QueryRequest): """ 接收用户问题，启动Agentic RAG流程，返回答案。 """ try: # 这里调用前面实现的 chat_with_agent 函数 final_answer = chat_with_agent( user_query=request.question, system_prompt=SYSTEM_PROMPT, # 全局定义的系统提示词 max_turns=request.max_turns ) # 在实际应用中，需要在检索和生成过程中记录来源 # 这里简化处理，假设从全局变量或函数返回值中获取 retrieved_source_ids = get_last_retrieval_sources() # 伪函数，获取本次对话检索到的源ID return QueryResponse( answer=final_answer, sources=retrieved_source_ids, turn_count=... # 记录实际交互轮数 ) except Exception as e: raise HTTPException(status_code=500, detail=str(e)) if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0", port=8000)

这样，前端或其它服务就可以通过发送POST请求到/ask端点来获取智能答案。

5.2 效果评估方法论

如何判断这个系统比传统RAG好？需要定量和定性结合。

检索相关性评估：人工标注一批乌克兰语问题，并标注标准答案及相关文档片段。计算系统的检索召回率（Recall@K），即在前K个检索结果中，有多少比例包含了正确答案所需的片段。对比单次检索和Agentic多轮检索的召回率。
答案准确性评估：
- 基于事实的准确性：将生成的答案与标注的标准答案对比，检查关键事实（如日期、数字、名称、政策要点）是否一致。可以使用LLM-as-a-judge（让一个更强的模型，如GPT-4，来评判）辅助进行。
- 幻觉率：统计答案中无法从提供上下文中找到依据的陈述比例。
复杂问题处理能力：设计需要多步推理、综合多来源信息的复杂问题。定性评估Agentic RAG是否能通过多轮检索成功拆解问题并找到所有必要信息，而传统RAG是否只能回答问题的某个片面或直接失败。
人工评估：邀请懂乌克兰语的专家或用户，从答案的有用性、完整性、连贯性、基于证据的程度等多个维度进行打分（例如1-5分）。

5.3 性能瓶颈分析与调优

在实际运行中，可能会遇到性能问题。

检索延迟：BGE-M3编码和向量数据库查询是主要耗时点。
- 优化：对知识库向量进行索引优化（如Chroma的HNSW索引）。对于查询，可以启用缓存，对相同或相似的查询直接返回缓存结果。考虑使用更快的向量数据库，如Weaviate或Pinecone（云服务），但它们会引入复杂性和成本。
生成延迟：Qwen2.5-3B-Instruct的生成速度。
- 优化：使用vLLM或TGI(Text Generation Inference) 部署模型，它们具有高效的连续批处理和PagedAttention技术，能极大提升吞吐量。对于3B模型，在合适硬件上达到每秒生成数十个token是可行的。
循环轮次控制：防止Agent陷入无限循环或进行不必要的检索。
- 优化：在系统提示词中强调效率。在代码中设置最大轮次（如5轮）。可以引入一个简单的“信心分数”评估，当连续两轮检索结果高度相似或新增信息很少时，自动触发最终生成。
上下文长度管理：多轮检索的上下文会越来越长。
- 优化：不是将所有历史检索片段都堆给模型。可以采用“滑动窗口”或“摘要”策略。例如，只保留最近2-3轮的检索片段，或者让模型在每一轮后对已收集的信息做一个简要总结，然后将总结作为下一轮的历史上下文，而不是原始文本。

构建一个面向乌克兰语的Agentic RAG系统，是一次将前沿AI范式与具体语言需求结合的深度实践。从选择BGE-M3和Qwen2.5-3B-Instruct这对“多语言检索尖兵”和“轻量智能体大脑”组合，到设计能自我规划、检索、评估的智能循环，再到针对乌克兰语进行细致的预处理和调优，每一步都需要权衡技术选型、资源开销和最终效果。这个过程让我深刻体会到，Agentic RAG不是简单的功能叠加，而是通过赋予系统“主动性”和“思考能力”，从根本上提升了复杂信息获取任务的可靠性和深度。对于资源相对稀缺的非英语语言，这种能够主动、精准挖掘知识的智能系统，其价值尤为显著。未来，可以考虑引入更多工具（如计算器、网页搜索API），让这个乌克兰语智能助理的能力边界进一步扩展。