通过针对性检索器微调实现乌兹别克语法律RAG的云端和本地部署

# 乌兹别克语法律检索增强生成系统的云部署与本地部署：通过定向检索器微调
来源：https://arxiv.org/html/2608.29284
Mariam Avetisyan Hrant Davtyan  
所属机构：Metric AI Lab  
联系方式：\{tatul, mariam, hrant\}@metricailab\.com

###### 摘要

部署用于法律问答的大型语言模型，面临着通用排行榜未能体现的挑战，尤其是对于低资源语言以及在严苛运行约束条件下。本文报告了为乌兹别克语构建和运营一个检索增强生成（RAG）法律助手的过程，该系统需在两种模式下运行：一种是托管云服务，旨在每个token成本上限内最大化答案质量；另一种是本地部署，适用于法律数据不得离开其基础设施的客户，这限制我们只能使用开放权重模型，并在有限的本地硬件上满足延迟约束进行运行。由于此场景缺乏现有评估标准，我们构建了两个领域基准：一个包含178个由专家标注的法律查询及其对应法规条款的检索基准，以及一个包含504个由专家策划的问答对的端到端基准，其评分由一个LLM评审完成，我们通过人工评审和独立家族的评审器对其评分进行了验证。在每种部署模式下应用这些基准，我们发现开放模型与专有模型之间的差距很小，且可通过微调低成本地弥合。因此，我们训练了UTE-1，这是目前针对乌兹别克语的开放模型中状态最先进的文本嵌入器。我们还证明，由于长上下文法律问答对硬件要求极高，且鉴于法律条文频繁变更，通过微调来弥合性能差距既不切实际也无必要。我们通过报告一个QLoRA实验的否定结果来支持这一观点。我们提炼了实用部署指南，这些指南源自一个在生产环境中为真实用户提供服务的系统。我们发布了我们的基准、评估代码和微调嵌入器（UTE-1），链接为这个 https URL (https://metric-ai-lab.github.io/Uzbek-Legal-RAG/)，以支持未来针对低资源法律自然语言处理的研究。

## 1 引言

大型语言模型（LLM）越来越多地被部署在法律和政府场景中，公民和专业人士在此提出自然语言问题，并期望得到基于适用法规的解答。此类系统通常被构建为检索增强生成（RAG）管道（Lewis 等人，2020 (https://arxiv.org/html/2608.29284#bib.bib1); Gao 等人，2023 (https://arxiv.org/html/2608.29284#bib.bib3)）：检索器选择相关法律文本，LLM则基于该文本生成答案。RAG非常适合法律领域，因为法律体系庞大、频繁修订，且要求答案必须引用特定条款。

大多数关于构建此类系统的已发表指南，其隐含读者是高资源语言和单一、无约束的部署目标。实际部署并非如此。我们描述了一个为乌兹别克语（一种被数千万人使用但NLP资源不足的突厥语系语言）构建的、基于国家法律语料库（lex\.uz）的生产级法律助手。该系统已商业部署并服务于真实用户；遵循双盲政策，我们省略了产品和组织名称。

两个事实使得该系统的模型选择并非显而易见。首先，同一助手需以*两种部署模式*进行交付，且这两种模式的约束相互冲突。*云*模式是多租户SaaS服务：允许使用任何模型，但每token成本上限排除了最昂贵的前沿API，目标是在该预算内最大化质量。*本地*模式服务于企业和公共部门客户，其法律文档*不得离开其基础设施*；数据主权约束要求我们只能使用开放权重模型，这些模型必须在客户有限的本地硬件上运行并满足延迟约束。其次，通用多语言排行榜在此场景下的质量预测能力较差：强大的综合能力并不意味着强大的乌兹别克语*法律*检索或答案质量，而现有的乌兹别克语排行榜衡量的是通用语言能力，而非基于法规的法律问答。因此，有原则的模型选择需要此前并不存在的任务和语言特定评估。

我们做出三项贡献。

(1) 一个可转移决策过程的部署案例研究。我们将云端和本地模型选择问题构建为两个带约束的优化问题，并展示如何用一套评估体系驱动两者，从而得出两个已部署的模型栈。
(2) 乌兹别克语法律问答的评估基础设施。我们发布了一个包含178个查询及黄金法规条款跨度的检索基准，一个包含504个项目的端到端问答基准，以及一个经过*人工验证*的LLM评审协议，该协议通过一个独立家族的评审器进行了交叉验证——这是任何此类研究的关键。两个基准和评估代码均已发布。
(3) 关键发现：在部署约束下，应投资于检索器。现有的法律RAG工作微调生成器（Ma 等人，2025 (https://arxiv.org/html/2608.29284#bib.bib14); Octadion (2024) (https://arxiv.org/html/2608.29284#bib.bib15)），而并行工作（Butler 和 Butler，2026 (https://arxiv.org/html/2608.29284#bib.bib16)）发现检索器占主导但未对其微调。我们微调了一个开放嵌入器，使其在乌兹别克语上达到了开放模型的最先进水平（以低成本弥合了大约一半与专有嵌入器的领域内差距），并报告了一个*否定*结果：在相同约束下微调生成器成本高昂，且鉴于法律会变更、多语言LLM持续改进，这并非必要。经验法则——*微调检索器，租用或更换生成器*——是本文核心且可复用的结论。该文本嵌入器已公开发布，以进一步促进乌兹别克语言的NLP应用。

## 2 系统与部署设置

#### 管道

该助手是一个RAG问答管道。离线阶段，我们将国家法律语料库分割为条款级别的文本块，为每个块添加其层级标题（法典/章/条），以使局部歧义文本保持可解释性，进行嵌入，并在向量数据库（Weaviate）中建立索引。查询时，我们对问题进行归一化（并在需要时进行翻译），然后使用*混合*搜索进行检索——将稠密余弦相似度（Karpukhin 等人，2020 (https://arxiv.org/html/2608.29284#bib.bib2)）与词法匹配融合——因为法律查询依赖于精确术语（条款号、法规名称），纯语义搜索会遗漏这些信息。我们向LLM提供检索到的条款和法律助手指令，以生成引用其使用的条款的答案。生产路径检索k=50个文本块，因此检索器必须确保相关法规出现在50个段落的窗口中（工程细节见附录C (https://arxiv.org/html/2608.29284#A3)）。

#### 为何需要两个模型，且其重要性为何不同

RAG管道有两个可学习组件：*嵌入器*（检索器）和*生成器*。它们的失效模式是不对称的：如果嵌入器未能检索到相关法规，任何生成器都无法补救——答案将是自信地错误或无根据的；而能力强的生成器主要需要阅读、综合和归因其获得的文本。这种不对称性促使我们将嵌入器作为首要优化对象，这一主题我们将在第5节和第6节中回归讨论。

#### 约束条件

检索到的上下文很大：在生产中，每个查询检索的k=50个条款大约跨越5.5万至9万个token。两个领域因素导致了这一点：同一法规被许多条款引用，因此较小的k值会返回交叉引用而非管辖文本，需要较高的k值才能全部捕获；以及过大的法规表格无法作为一个整体嵌入，被索引为多个文本块，但在任何一个被检索到时，需要重新完整展开。这种长上下文模式影响了成本和延迟。在云模式中，每查询成本主要由生成器的输入token决定，因此成本上限实际上排除了前沿“专业”层级API，仅允许高效的“闪速”层级或开放模型。在本地模式中，主权约束排除了所有API模型，延迟既受大型上下文的预填充影响，也受可能需要跨多个条款进行多步推理的长法律答案解码影响——因此提示词处理*和*解码时间共同决定了用户可见的等待时间。

## 3 基准与评估方法论

由于没有针对乌兹别克语法律RAG的公开基准，且本研究的核心风险是信任不可靠的评估器，我们首先投资于评估。我们构建了两个互补的基准，并验证了自动评审器与人类评审的一致性。

### 3.1 检索基准

我们构建了一个包含178个人工撰写和标注的法律问题的检索基准。对于每个问题，领域专家识别了回答问题所需的确切法规文本，并将这些段落记录为黄金目标。我们进行批次内评估并报告*前5名检索准确率*：至少有一个黄金法规出现在排名前五的文本块中。为了在外部定位我们的嵌入器，我们还在MTEB的乌兹别克语子集上进行评估（Muennighoff 等人，2023 (https://arxiv.org/html/2608.29284#bib.bib4)）（127个查询，1,263个候选，nDCG@5）。这两组在内容和评分上相互独立，共同覆盖了305个查询，分别衡量领域内法律检索和通用乌兹别克语检索。

### 3.2 端到端问答基准

我们策划了504个法律问答对，涵盖22个法律领域。每个项目通过运行*整个生产管道*进行评分：问题从实时向量索引（k=50）中检索并由生成器回答，生成的答案与参考答案进行比较。我们使用一个独立的LLM评审器对四个质量维度进行评分：*完整性*、*上下文准确性*（对检索到的条款的忠实度）、*无幻觉*和*法律理解力*，并报告一个*总体*分数。因为它评估的是部署管道而非孤立的模型，该基准直接衡量了我们关心的指标，并允许我们独立更换嵌入器和生成器（第5节 (https://arxiv.org/html/2608.29284#S5)）。

### 3.3 LLM评审器

我们的主要问答指标由一个LLM评审器产生。使用与响应LLM同系列的评审器会产生自我偏好偏差的风险：LLM评估者倾向于偏爱其同系列模型（Panickssery 等人，2024 (https://arxiv.org/html/2608.29284#bib.bib6); Zheng 等人，2023 (https://arxiv.org/html/2608.29284#bib.bib5)），可能抬高共享系列生成器的分数。因此，我们选择了一个能力强大的LLM作为评审器，它来自与被评估LLM完全不同的系列（Muse Spark 1.1）。

我们将选定的独立评审器与人工评分进行了比较。在一个由领域专家按1-10分制评分的52个问题的集合上，我们的评审器获得了斯皮尔曼相关系数ρ=0.7032，与专家评分的平均绝对误差为1.29分。

## 4 云部署：成本上限内的质量

在云模式下，原则上允许使用任何模型，因此选择简化为在成本上限约束下最大化质量。

#### 嵌入器

表1报告了14个嵌入器的检索质量。专有的gemini-embedding-001在我们的领域内基准（0.961 前5准确率）和MTEB（0.906 nDCG@5）上表现最佳，且优势明显。由于云嵌入成本只占总成本的一小部分，我们将其部署用于云服务。

#### 生成器

我们通过三个标准预先筛选LLM候选者：（i）足够强的通用乌兹别克语能力，使用公开的乌兹别克语排行榜（UzLib；完整表格见附录A (https://arxiv.org/html/2608.29284#A1)）；（ii）足够的综合能力，使用公开的综合指标（例如竞技场排名和MMLU-Pro）；（iii）价格低于我们的每token上限。这排除了最昂贵的前沿API（例如Claude、Gemini-Pro和GPT-Pro层级），尽管它们综合得分很高。在预算内的候选者中，我们随后根据我们的问答基准的端到端质量进行排名。gemini-3-flash是最强的预算内生成器（0.850 总分）；我们为提供上下文而评估的更昂贵的参考模型（例如claude-sonnet-4-6、gpt-5.4）在此任务上并未超越它。因此，我们为云服务部署gemini-embedding-001 + gemini-3-flash。

#### 成本与质量的兼顾

成本上限并非对质量的妥协。绘制每个模型的推理成本与问答质量的关系图（附录B (https://arxiv.org/html/2608.29284#A2)，图1），gemini-3-flash位于成本-质量帕累托前沿的质量最大化顶点，并*严格支配*每一个前沿API：它分别比grok-4.3、gpt-5.4和claude-sonnet-4-6便宜2.1倍、4.0倍和6.6倍，同时得分高于这三者。在此任务上，“租用闪速层级，而非前沿层级”是成本-质量最优选择，而非预算妥协。

#### 生产验证

已部署的云管道每月服务约3万个问题。在479次产品内投票中，78%为正面（375/479），这验证了选择该栈的离线问答排名。本地部署在设计上*不*提供此类遥测数据：赋予其数据主权优势的同时，也剥夺了云服务所依赖的反馈信号，这一权衡我们在第6节 (https://arxiv.org/html/2608.29284#S6) 中会再次讨论。

| 嵌入器 | 开放 | 检索 Top-5 | MTEB nDCG@5 | 平均 |
| :--- | :---: | :---: | :---: | :---: |
| gemini-embedding-001 (3072d) | — | 0.961 | 0.906 | 0.934 |
| gemini-embedding-2 (3072d) | — | 0.938 | 0.900 | 0.919 |
| <u>UTE-1 (ours)</u> | ✓ | 0.916 | 0.863 | 0.889 |
| Qwen3-Embedding-4B | ✓ | 0.893 | 0.795 | 0.844 |
| arctic-embed-l-v2.0∗ | ✓ | 0.876 | 0.850 | 0.863 |
| multilingual-e5-large | ✓ | 0.832 | 0.763 | 0.797 |
| multilingual-e5-large-inst. | ✓ | 0.815 | 0.811 | 0.813 |
| jina-embeddings-v5-small | ✓ | 0.803 | 0.777 | 0.790 |
| multilingual-e5-base | ✓ | 0.753 | 0.718 | 0.735 |
| Qwen3-Embedding-0.6B | ✓ | 0.685 | 0.743 | 0.714 |
| harrier-oss-v1-0.6b | ✓ | 0.635 | 0.758 | 0.696 |
| harrier-oss-v1-270m | ✓ | 0.612 | 0.756 | 0.684 |
| geevec-embeddings-1.0-lite | ✓ | 0.528 | 0.506 | 0.517 |
| embeddinggemma-300m | ✓ | 0.489 | 0.695 | 0.592 |

表1：嵌入器在我们的领域内法律基准（178个查询的前5准确率，§3.1 (https://arxiv.org/html/2608.29284#S3.SS1)）和乌兹别克语MTEB子集（127个查询 / 1,263个候选的nDCG@5）上的检索质量，按领域内指标排序。<b>粗体</b>= 整体最佳；<u>下划线</u>= 开放权重最佳。∗UTE-1的基础模型：微调将领域内前5准确率从0.876提升至0.916（+0.040），MTEB从0.850提升至0.863，弥合了与专有领先者大约一半的剩余差距。

| 生成器 | 开放 | 检索器 | 总分 | 完整性 | 上下文准确 | 无幻觉 | 法律理解 |
| :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| gemini-3-flash | — | proprietary | **0.850** | 0.875 | 0.900 | 0.830 | 0.800 |
| ... (表格截断) | | | | | | | |