1. 项目概述：为什么乌克兰语RAG是个值得深挖的“硬骨头”？
最近在折腾一个挺有意思的项目：面向乌克兰语的智能RAG系统。乍一听，可能有人觉得这不就是给RAG（检索增强生成）换个语言吗？把英文的向量模型、分词器换成乌克兰语的，不就完事了？但真正上手后才发现，这里面的水，比想象中深得多。它远不止是简单的“语言替换”，而是一个涉及多语言混杂处理、小语种资源稀缺、以及复杂代理决策逻辑的综合工程挑战。
为什么是乌克兰语？这背后有几个现实的考量。首先，乌克兰语属于西斯拉夫语系，其语法（如七格变位）、构词和字符集（西里尔字母，但包含ґ、і、ї等特有字母）与英语差异巨大，直接套用为英语优化的现成方案，效果会大打折扣。其次，互联网上高质量、结构化的乌克兰语文本数据相对稀缺，这对构建可靠的检索知识库提出了更高要求。更重要的是，在实际应用场景中，用户查询和文档内容常常是乌克兰语、俄语、甚至英语混杂的状态，系统必须具备强大的语言识别、归一化和跨语言检索能力，才能给出精准的答案。
所以，这个项目的核心目标，是构建一个不仅能“听懂”纯乌克兰语，还能妥善处理语言混合输入，并在此基础上，通过智能的代理机制来动态决策检索、重排、生成乃至调用外部工具流程的系统。它不是一个简单的问答机器人，而是一个具备一定“思考”和“调度”能力的智能体。接下来，我就把自己在搭建这个系统过程中，关于检索增强和代理机制的核心设计思路、踩过的坑以及实战心得，毫无保留地分享出来。
2. 核心架构设计：从“检索-生成”到“感知-决策-执行”的演进
传统的RAG流水线可以概括为“索引-检索-生成”三步走。但对于一个面向复杂现实场景的智能系统，尤其是处理乌克兰语这种特定语言时，我们需要一个更健壮、更灵活的架构。我将其演进为一种基于代理的感知-决策-执行循环。
2.1 整体架构蓝图
整个系统的核心不再是单一的流水线，而是一个由协调代理驱动的动态工作流。下图描绘了其核心交互逻辑：
graph TD A[用户输入<br>（混合语言问题）] --> B(语言感知与<br>查询理解代理); B --> C{决策点：<br>问题类型与需求}; C -->|简单事实查询| D[向量检索模块]; C -->|需要复杂推理/计算| E[工具调用代理<br>（计算、搜索API）]; C -->|需要多步信息整合| F[子问题分解与<br>规划代理]; D --> G[召回结果]; E --> H[工具执行结果]; F --> F1[子问题1] --> D; F --> F2[子问题2] --> E; G --> I[结果重排序与<br>融合模块]; H --> I; I --> J[生成代理]; J --> K[最终答案输出]; B --> L[乌克兰语专用<br>文本处理管道]; L --> M[知识库<br>（向量存储）]; D --> M;这个架构的关键在于，代理作为核心调度者，它根据对用户输入的理解（感知），来决定调用哪些能力（决策），并组织执行（执行）。例如，对于“请比较基辅和利沃夫的人口，并计算总和”这个问题，代理可能会：1）识别出需要事实检索（两个城市的人口）；2）识别出需要计算工具；3）规划先并行检索两个数据，再调用计算工具进行求和。
2.2 为什么选择代理机制而非固定流程？
在乌克兰语场景下，固定流程的弊端被放大。比如，用户问：“Що таке ‘державний суверенітет’？ А також знайдіть останні новини на цю тему.”（什么是“国家主权”？并请查找关于这个话题的最新新闻。）这是一个典型的混合型请求：前半部分是概念定义（可从静态知识库检索），后半部分是实时信息（需调用搜索引擎API）。固定流程要么只能处理前者，要么需要用户拆分成两个问题。
代理机制的优势立刻显现：
- 意图分解：代理能理解这是一个复合问题，自动将其拆解为“定义查询”和“实时新闻查询”两个子任务。
- 动态路由：针对“定义查询”，路由到向量检索模块；针对“实时新闻查询”，路由到网络搜索工具调用模块。
- 结果综合：代理负责将来自静态知识库的定义和来自搜索引擎的新闻摘要进行整合，组织成连贯的答案。
这种灵活性，对于处理语言本身可能就不规范、需求多样的真实用户查询至关重要。
3. 乌克兰语文本处理：检索效果的基石
检索增强，检索是第一步，也是最容易“失之毫厘，谬以千里”的一步。乌克兰语文本处理需要一套量身定制的方案。
3.1 分词与嵌入模型选型
英文RAG中，我们可能不假思索地选用sentence-transformers的all-MiniLM-L6-v2。但对于乌克兰语，这几乎是无效的。因为通用多语言模型在低资源语言上的表现通常远逊于英语。
我的选型与理由：
嵌入模型：我选择了专门针对乌克兰语优化的
intfloat/multilingual-e5-large的乌克兰语版本，或者社区训练的sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2并确保其在乌克兰语语料上微调过。更佳的选择是使用在乌克兰语维基百科、新闻语料上训练过的专用模型，例如ukr-sbert。这能确保相似语义的乌克兰语句子在向量空间中是靠近的。注意：直接使用多语言模型时，务必检查其支持的语言列表中是否明确包含乌克兰语（uk），并最好在少量乌克兰语相似性任务上做快速验证。
分词器：这是关键陷阱。许多Transformer模型使用基于
SentencePiece或BPE的分词器，对西里尔字母的处理可能将一个单词拆分成不直观的片段。例如，乌克兰语单词“державний”（国家的）可能被拆成“дер”, “жа”, “вний”这样的子词，虽然对模型理解影响不大，但对于精确匹配、关键词高亮或后续的一些处理可能带来困扰。我们需要接受这种“子词”化是当前技术的常态，但在构建知识库时，要确保文本清洗和分块策略与之适配。
3.2 文本分块策略优化
分块（Chunking）策略直接影响检索精度。乌克兰语文本有其特点：
- 长复合句常见：由于复杂的格变化和从句结构，句子可能很长。
- 形态丰富：一个词的变体很多。
我采用的混合分块策略：
- 递归字符分割：作为基础，设置一个适中的块大小（如512字符）。但单纯按字符分割容易切断一个完整的句子或意群。
- 叠加语义分割：利用乌克兰语的分句模型（如
spacy的乌克兰语支持或nltk）尝试在句末标点处进行分割。将递归分割的块与语义分割的边界进行对齐，优先保证句子的完整性。 - 重叠设置：设置较大的重叠区（如150字符）。因为乌克兰语中，关键信息可能分散在相邻的句子中，足够的重叠能减少检索时因分割不当导致的核心信息丢失。
实操心得：不要盲目追求“语义完整”而使用过大的分块。过大的块虽然包含了上下文，但也会在检索时引入更多噪声，降低答案的精确度。我的经验是，对于百科、文档类知识，块大小在300-600词（约500-1000字符）之间，重叠在15%-20%，是一个不错的起点，需要根据实际检索效果微调。
3.3 处理语言混合问题
这是现实场景中的最大挑战。用户可能输入：“Як працюєblockchainтехнологія?”（区块链技术如何工作？）其中混入了英文术语。
解决方案：
- 语言检测：在查询入口处，使用轻量级语言检测库（如
langdetect）快速识别查询中各个片段的语言。对于混合查询，可以标记出不同语言的部分。 - 查询翻译/扩展：对于嵌入模型，一种策略是将非乌克兰语的关键词（如
blockchain）翻译成乌克兰语（блокчейн），生成一个“双语”查询向量。另一种更鲁棒的策略是进行查询扩展：利用大语言模型（LLM）将原始混合查询重写为几个纯乌克兰语的、同义的查询。例如，将上述查询扩展为：“Як працює технологія блокчейн?”、“Принцип роботи блокчейну”、“Що таке блокчейн та як він функціонує?”。用这组查询去检索，能大大提高召回相关乌克兰语文档的概率。 - 知识库侧处理：在构建知识库时，对于包含大量外来词或混合语的文档，可以考虑额外添加一个“术语翻译对照表”作为元数据，或者在嵌入前对文档进行轻微的同义词替换扩展（需谨慎，避免引入错误）。
4. 智能代理机制的设计与实现
代理是系统的大脑。我设计了一个分层代理系统，核心是一个主协调代理，它可以根据任务类型调用不同的技能或子代理。
4.1 代理的核心循环
代理遵循经典的ReAct范式：Reason（思考）-Act（行动）-Observe（观察），并循环进行。
- 思考：分析当前用户问题、历史对话和可用工具，决定下一步做什么。
- 行动：执行决定，可能是调用检索工具、调用计算器、调用网络搜索，或者直接生成答案。
- 观察：获取行动的结果（检索到的文档、计算出的数字、搜索到的摘要）。
- 循环：基于观察结果，再次思考，直到问题被解决或达到步骤限制。
4.2 工具集的构建
代理的能力取决于它拥有什么工具。我为乌克兰语RAG系统装备了以下核心工具：
- 向量知识库检索工具：最核心的工具。输入是乌克兰语（或混合）查询，输出是相关的文本片段及其来源。我为其设计了丰富的元数据过滤接口，例如按文档类型、日期、语言过滤。
- 网络搜索工具：用于获取最新信息。集成如SerpAPI或自定义的新闻网站爬虫（需遵守
robots.txt）。关键点在于，搜索结果的摘要需要被翻译或处理成乌克兰语，以便与本地知识库内容融合。 - 计算器工具：处理涉及数字计算的问题。这是一个确定性工具，能保证计算结果的绝对准确。
- 子问题分解工具：严格来说这不是一个“行动”工具，而是主代理在“思考”阶段可以调用的内部能力。当遇到复杂问题时，代理可以调用一个LLM来将问题分解成一系列顺序或并行的子问题，然后逐一解决。
4.3 提示工程：让代理“理解”乌克兰语任务
代理的“思考”能力由LLM驱动，而引导LLM的关键就是系统提示词。我的系统提示词模板包含以下几个关键部分：
你是一个专业的乌克兰语信息助手，精通乌克兰语，并能处理其中可能夹杂的俄语或英语术语。 你的核心能力包括： 1. 从乌克兰语知识库中检索信息。 2. 使用网络搜索获取最新资讯。 3. 进行精确的数学计算。 4. 将复杂问题分解为简单步骤。 请严格遵循以下流程： 1. **分析问题**：判断用户问题的语言和核心意图。是事实查询、比较、计算还是需要最新信息？ 2. **制定计划**：如果需要多步，先列出步骤。例如：“第一步：检索A的定义；第二步：检索B的定义；第三步：比较异同。” 3. **选择工具**：根据计划选择工具。检索知识库用`vector_search`，找最新消息用`web_search`，计算用`calculator`。 4. **执行与整合**：使用工具获取信息，并用自己的话（乌克兰语）组织成连贯、准确的答案。所有事实陈述必须基于工具返回的证据。 特别注意： - 如果用户问题包含非乌克兰语词汇，请理解其含义，并在检索或搜索时考虑其乌克兰语对应词。 - 优先使用知识库中的信息，除非问题明确要求最新数据或知识库中找不到。 - 你的最终答案必须使用乌克兰语。这个提示词明确了代理的角色、能力、工作流程和语言要求，是代理行为符合预期的保障。
4.4 实现示例：基于LangChain的代理搭建
我使用LangChain作为代理框架的实现基础，因为它提供了良好的抽象和工具集成能力。
from langchain.agents import AgentExecutor, create_react_agent from langchain_core.prompts import ChatPromptTemplate from langchain_community.llms import OllamaLLM # 假设使用本地Ollama部署的LLaMA模型 from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.tools import Tool from langchain_community.utilities import SerpAPIWrapper # 1. 初始化组件 # LLM - 使用支持乌克兰语的模型，例如通过Ollama运行的`llama3`或专门微调过的模型 llm = OllamaLLM(model="llama3", base_url="http://localhost:11434") # 嵌入模型 - 乌克兰语专用 embeddings = HuggingFaceEmbeddings(model_name="ukr-sbert-model") # 加载已有的乌克兰语向量库 vectorstore = Chroma(persist_directory="./ukr_db", embedding_function=embeddings) retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) # 2. 定义工具 def vector_search(query: str) -> str: """在乌克兰语知识库中搜索相关信息。""" docs = retriever.get_relevant_documents(query) return "\n\n".join([f"来源 {i+1}: {doc.page_content}" for i, doc in enumerate(docs)]) search = SerpAPIWrapper(serpapi_api_key="your_key") # 实际使用时替换为你的key tools = [ Tool( name="Ukrainian_Knowledge_Base", func=vector_search, description="当需要从乌克兰语知识库中查找事实、定义、解释或历史信息时使用此工具。输入应为乌克兰语查询。" ), Tool( name="Web_Search", func=search.run, description="当问题涉及最新新闻、实时数据或知识库中找不到的非常见信息时使用此工具。输入可以是乌克兰语或英语关键词。" ), # 可以添加更多工具... ] # 3. 创建代理提示词 system_prompt = """你是一个智能乌克兰语助手...""" # 此处填入上文设计的完整提示词 prompt = ChatPromptTemplate.from_messages([ ("system", system_prompt), ("human", "{input}"), ("placeholder", "{agent_scratchpad}"), ]) # 4. 创建并运行代理 agent = create_react_agent(llm=llm, tools=tools, prompt=prompt) agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True, handle_parsing_errors=True) # 执行查询 result = agent_executor.invoke({ "input": "Хто такий Тарас Шевченко? Коли він народився та які його найвідоміші твори?" }) print(result["output"])在这个示例中，代理会根据问题“塔拉斯·舍甫琴科是谁？他何时出生？他最著名的作品是什么？”自动判断这是一个纯粹的事实查询，从而调用Ukrainian_Knowledge_Base工具，从本地向量库中检索信息并生成答案。
5. 检索增强流程的深度优化
有了强大的代理和扎实的文本处理基础，检索增强流程本身还有巨大的优化空间。
5.1 混合检索策略
单一的向量检索有时不够精确，尤其是对于包含具体名称、日期、数字的查询。我采用了混合检索：
- 密集检索：使用上述乌克兰语嵌入模型进行语义搜索，召回相关文档。
- 稀疏检索：同时使用基于关键词的检索，如BM25。对于乌克兰语，需要配置支持西里尔字母分词的分析器（如Elasticsearch中的
ukrainian分析器）。混合检索能同时保证语义相关性和关键词匹配度。 - 融合排序：将密集检索和稀疏检索的结果列表，使用倒数排序融合或更复杂的学习排序方法进行重排，得到最终的召回列表。
5.2 重排序模型的应用
从检索器召回的可能有10-20个文档块，但并非所有都与生成答案直接相关。引入一个重排序模型，对召回的文档进行精细打分，只将Top-K个最相关的文档送入生成阶段。对于乌克兰语，可以尝试多语言重排序模型，如cross-encoder/ms-marco-MiniLM-L-6-v2，并在乌克兰语数据上微调，以更好地理解查询与文档的相关性。
5.3 上下文窗口的智能管理
LLM的上下文长度有限。当代理经过多轮工具调用，积累了大量的检索结果和历史对话时，需要智能地管理上下文。
- 选择性记忆：只将与当前思考最相关的工具调用结果和历史对话保留在上下文中。
- 摘要压缩：对于较长的检索文档，可以让LLM先对其进行摘要，再将摘要送入生成上下文。
- 结构化历史：将对话历史、工具调用记录以结构化的格式（如JSON）存储，在需要时让LLM快速回顾要点，而不是塞入全部原始文本。
6. 评估与迭代：如何知道系统真的“智能”了？
构建完成后，评估至关重要。我采用多维度评估：
检索效果评估：
- 命中率：对于一组标准问题，Top-K个检索结果中包含正确答案的比例。
- 平均排序：正确答案在检索结果列表中的平均位置。
- 语言鲁棒性测试：使用混合语言查询、带错别字的乌克兰语查询进行测试，看检索效果是否稳定。
生成答案评估：
- 事实准确性：答案中的事实是否与检索到的文档一致？这是RAG的底线。
- 相关性：答案是否直接回应了问题？
- 流畅性与语言质量：生成的乌克兰语是否自然、流畅、符合语法？
- 幻觉率：答案中是否出现了知识库中没有的信息？
代理决策评估：
- 工具调用准确率：代理是否在正确的时机调用了正确的工具？
- 问题分解合理性：对于复杂问题，分解出的子问题是否逻辑清晰、可解决？
- 多轮对话连贯性：在连续对话中，代理是否能记住上下文并做出合理回应？
评估需要构建一个包含问题-标准答案-参考文档的测试集。初期可以手动评估，后期可以引入LLM作为裁判进行自动评估（例如，用GPT-4评估答案的相关性和流畅性）。
7. 生产级部署的考量与挑战
将实验系统推向生产环境，会面临新的挑战。
7.1 性能与延迟
- 嵌入模型推理：乌克兰语专用模型可能比通用小模型更大，需要GPU加速或使用量化版本。
- 向量数据库：考虑使用
Milvus、Qdrant或Weaviate等高性能向量数据库，支持大规模数据和高并发检索。 - LLM调用：代理的每一步“思考”都需要调用LLM，这是延迟的主要来源。可以考虑对常见问题类型进行缓存，或使用更小、更快的模型进行初步的意图分类和路由。
7.2 知识库的持续更新
乌克兰语世界的信息也在更新。需要建立知识库的增量更新机制。
- 流式处理：监控数据源（如特定新闻网站、官方公报），将新内容自动经过清洗、分块、嵌入，增量添加到向量数据库。
- 版本管理：对知识库进行版本快照，以便在更新引入错误时可以回滚。
- 去重与质量过滤：在入库前进行严格的内容去重和质量审核，避免垃圾信息污染知识库。
7.3 安全与可控性
- 输入过滤：对用户输入进行严格的恶意内容、敏感词过滤。
- 输出审查：在最终答案返回前，可以增加一层安全审查，确保生成的内容不包含有害信息或严重的幻觉。
- 工具权限控制：限制网络搜索工具访问的域名，计算器工具设置超时和计算复杂度限制，防止滥用。
构建一个面向乌克兰语的智能RAG系统，是一次从技术到工程的全方位挑战。它要求我们不仅深入理解RAG和代理的技术细节，更要深入理解目标语言的特性和用户的实际场景。从选择合适的嵌入模型开始，到设计能处理语言混合的文本管道，再到构建一个能动态规划、调用工具的智能代理，每一步都需要反复试验和调优。这个过程让我深刻体会到，真正的“智能”不在于模型的参数有多大，而在于系统设计能否精准地理解问题、高效地利用工具、并可靠地交付结果。目前这个系统仍在迭代中，特别是在处理高度复杂的、需要多步深度推理的乌克兰语问题上，还有很长的路要走。下一步，我计划引入更复杂的反思机制，让代理能评估自己答案的质量，并在不满意时自动调整策略，这或许能让它离真正的“智能”更近一步。
