LLM 微调实践 – 利用大语言模型微调进行翻译质量检测（上）

问题背景

大语言模型在翻译场景相对传统机翻具备很强的优势，比如更好的场景化、更自然流畅的语言（没有机翻中常见的生硬问题）、成本具备优势，同时还可以结合 RAG（Retrieve-Argument Generate）技术去引入上下文，使得翻译质量有明显的提升。但是大语言模型翻译也依然存在一些问题，除了速度不如传统机翻以外，还有以下较常见的问题：

• 拒绝翻译：对于敏感内容（情色/暴力），大语言模型没给出回答，而是道歉拒绝回答；
• 语种夹杂：翻译语种和目标语种不一致，或者出现翻译中包含了一些其他语种；
• 无关冗余词汇：LLM 在翻译的时候，有一定几率会出现额外添加的词汇，或者存在无意义的重复词汇；
• 拼写/语法/符号错误：拼写或语法出错、使用了不恰当的符号、没有遵守目标语言中的符号使用习惯；
• 数量/量词/单位错误：不同语言习惯之间，量词和单位的往往不一样，LLM 的翻译切换有时候会存在问题；
• 格式变化：翻译后，多行转成一行，或者一行被拆分多行，又或者 markdown/html 的一些格式字符没能保持；
• 词汇遗漏或不当：没有使用专业术语，或者 LLM 对于垂直领域的一些词的区分不够敏感导致误用。

下面举一些典型的例子，帮助大家更好地理解这些错误。

这些问题，一般和 FM（Foundation Model）训练时的一些特点有关，具有很强的随机性。比如拒绝翻译，一般和 LLM 的无害性目标对齐有关，又比如语种夹杂跟互联网文本中的常见语种间的借词现象有关。在特定的业务场景下，模型通用能力的提升不足以完全解决全部问题。

翻译优化思路

为了改善以上的一些问题，在目前生产实践中使用比较多的手段如下：

• 优化 Prompt，针对性地提示大语言模型注意这些问题；
• 通过翻译工作流/Agent，进行多轮的翻译-检测-优化；
• 构建一些后检查机制，来检测这些问题，检测出问题后，再提示大模型再次翻译。

第一种方式，即使在 Prompt 层面做了非常极致的优化，在实践中改善程度仍非常有限。

第二种方式，一般能带来不少改善，但导致翻译的延迟和成本很高，比较适用一些对翻译质量要求很高，但对成本和延迟不敏感的场景。对于翻译量大的场景，比如社区 UGC 内容的翻译，成本因素很重要，一般不会采用多次调用的工作流和Agent，且一般采用较小规模的大语言模型来翻译。所以这种方法并不适用所有场景，仅适用于用最好的模型叠加工作流来提高翻译质量的天花板，因为一个本身能力不足的大语言模型无论用什么工作流来提升，能达到的上限也不高。

第三种方法，比较适用于对成本和延迟有一定要求的场景，虽然不能达到最高的翻译质量，但是能大大避免一些低级错误和业务比较关注的错误。其中对于语种夹杂/拒答问题可能都可以通过代码的方式比如正则表达式来检测，这种方式的好处是比较廉价快速，额外成本很低。但是对于一些错误则很难归纳，有些人尝试通过代码进行检测和后处理往往又会带来其他的副作用。所以本文尝试通过微调模型的方式去学习归纳之前出现的这些错误特征。

业务目标分析

由于本文的工作是沿着上述第三种优化思路，在成本和延迟敏感的情况，必然不仅仅考虑单纯的机器学习指标，还要满足业务上的要求，总结为下面四个条件：

1. 足够高检出率/召回率（90% 及以上）、较低的误检率（不应超过 20%），以免带来不必要重复翻译的额外成本；
2. 成本相对固定，比如 A10 卡即可部署，并且其吞吐能力 RPM 能够高于翻译模型的水平；
3. 延迟尽可能低，最好低于 1s，对于偏实时的场景不要影响整条服务链路；
4. 检测结果除了通过与否，最好能给出出错细节，方便为下一轮翻译模型提供参考。

模型优化实践

模型的效果一般来说会从不同维度进行优化，分别是数据、训练方法、模型等。基于以往的经验，数据往往起到决定性的因素，训练方法上一般 Full Finetune 要优于 Lora，模型一般越大越好。所以作者在初始阶段的实验都是围绕着数据来进行的，在数据层面做各种优化尝试，然后再从训练方法和模型选型上进行更进一步的实验。基于以上考虑，作者首先选择在 A10 能够部署的最大尺寸的 7B 模型进行尝试，做 Full Finetune 训练，本文中选择的是 Mistral-7B-Instruct-v0.3。

第一阶段优化实践

数据基本情况

一般可供微调的数据，一般为翻译人审专家团队累计下来的翻译错误实例。一般需要包含这些字段，以下面的表 schema 为例，数量一般需要在百/千条以上。

其中 translation_by_machine 为机翻结果，translation_by_expert 为专家修订的结果，error_type 为错误类型，这个基本由业务来确定，dest_lang 为翻译的目标语言，在语种错误的案例中是有必要的。

考虑到从易到难，第一批数据仅包含一类错误（拼写/语法/符号错误），按照 dest_lang 进行均衡采样，获得 train dataset 3200+ 条，test dataset 176 条。

基础版微调实验

构建了如下 schema 的 openai 格式的训练数据 Dataset V1，把 src（原文）、机翻译文（translation_by_machine）以及 Prompt Template 作为负例，把 src（原文）、专家译文（translation_by_expert）以及 Prompt Template 作为正例，Ground Truth 作为一个简单的二分类，pass 或 fail，通过这种方式要求微调的模型输出指定的 xml 格式。

[
    {
        "messages": [
            {
                "role": "system",
                "content": "You are a expert of translation quality control."
            },
            {
                "role": "user",
                "content": """Here is the source text in <src> tag and also its translation from an translator in <translation> tag. 
                <src>
                {{ src }}
                </src>

                <translation>
                {{ translation_by_machine }}
                </translation>

                Please analyze the translation quality, and finally give the opinion, put your opinion in <opinion> xml tag.
                """
            },
            {
                "role": "assistant",
                "content": "<opinion>{{opinion}}</opinion>"
            }
        ]
    }
    ...

测试集上面的评估效果如下表， 其中类别 A（fail）的检出率（Recall）和精准率（Precision）为前文中我们最关注的指标，分别为 52.84% 和 48.69%，几乎等同于瞎猜。

COT（Chain Of Thought）版微调实验

经过数据分析，发现机器译文和专家译文在训练数据中，正例负例之间差别非常细微。比如下面例子：

在这种情况下基于 Dataset V1 无法使 LLM 注意到这些细微差别，并掌握其内在逻辑。为了强化这些细微差别，我们构建第二版数据 Dataset V2， 参考如下数据示例， 标红部分针对性地改动。

[
    {
        "messages": [
            {
                "role": "system",
                "content": "You are a expert of translation quality control."
            },
            {
                "role": "user",
                "content": """Here is the source text in <src> tag and also its translation from an translator in <translation> tag. 
                <src>
                {{ src }}
                </src>

                <translation>
                {{ translation_by_machine }}
                </translation>

                Please analyze the translation quality, and finally give the opinion, put your opinion in <opinion> xml tag.
                """
            },
            {
                "role": "assistant",
                "content": "{{ analysis }}, So my opinion is <opinion>{{opinion}}</opinion>"
            }
        ]
    }
    ...

{{ analysis }} 为翻译检测结论的论据，由于咱们即有的数据中不包含详细的分析过程，仅仅提供了error_type。为了得到这些论据信息，作者采用了数据合成的思路。为了提高论据质量，采用了性能最强的商业模型来合成。合成得到如下的 COT 分析过程：

在合成过程中，对应的 Prompt 经过了多次调整，提示 LLM 来识别原译文的错误并不是一件容易的事情，LLM 给出的分析往往和人类的意见并不一致，它可能会从其他角度来对译文来吹毛求疵。COT 分析的质量影响最后的训练效果。

下面是调整完毕后的负例和正例 Prompt 模版，两者的合成思路稍有不同，有不少细节点可以关注。

在正例的 Prompt 模版中，我仅仅置入了原文和专家翻译，并明确提示 LLM 这个翻译表现良好，让它以翻译审核学员的角色分析对照翻译准则，给出专家的翻译为什么好的依据。此外专门强调“Be Concise!”，是因为发现商业模型的分析过长，这个后续如果融入到训练数据中去的话，会导致训练出来的检测模型也输出过长，导致延迟太大，精简且切合要点的分析依据是最理想的。在检测场景中，大部分的译文是正常的，要尽可能保证正常译文的检测速度要尽可能快。

在负例的 Prompt 模版中，我不仅仅融入了原文和 LLM 翻译，还同时提供了专家翻译和错误类型，让商业模型能够注意到这些细微的差别，去生成出精准的错误原因和细节。但是在实验中，作者发现分析过程中，商业模型的分析输出中经常提到专家的翻译用作引证和对比，属于数据泄漏，这个在我们的训练数据中是不应该存在的。为了解决这个问题，专门在 Prompt 中刻意对商业模型强调这是一个闭卷考试，虽然我偷偷给了你专家的答案做参考，但是你的分析不能表露你参考了专家的答案，应该是你的独立作答。

再次评估测试集上面的评估效果如下表， 检出率和精准率为 86.36% 和 91.01%，都有非常明显的提升。

Pairwise 思路微调实验

再次分析训练数据，发现每条数据虽然结合了 COT，但是每一条构造的训练数据中，模型仅仅能见到正例或者负例，两者的对比性没有被利用起来。按照标准的做法，应该采用 PPO 或 DPO 的方式来进行训练，在训练顺序上，应该是先做 SFT 再做 DPO，考虑工作量和实验速度的因素，而是采用了一种更取巧的简单思路。

作者对训练数据做了小小的变换，把属于同一个原始数据的正例和负例，合并成多轮的训练数据，类似下面：

{
    "messages": [
        {
            "role": "system",
            "content": "You are an expert of translation quality control."
        },
        {
            "role": "user",
            "content": {{ prompt_for_neg }}
        },
        {
            "role": "assistant",
            "content": {{ answer_for_neg }}
        },
        {
            "role": "user",
            "content": {{ prompt_for_pos }}
        },
        {
            "role": "assistant",
            "content": {{ answer_for_pos }}
        }
    ]
}

顺序上让正例和负例交替，保持训练集数量不变，形成了第三版训练数据 Dataset V3 进行训练。评估结果中检出率和精准率为 90.9% 和 94.11%，提升约 3pp。指标小幅提高，说明 Pairwise 的思路确实能提高效果，后续会继续尝试 DPO。

但仍然存在 COT 输出过长，导致延迟比较大的问题。于是进行了一次消融实验，仅仅保留 Pairwise 的思路，去掉训练数据中 COT 的思考过程，如果效果不受影响的话，在仅仅需要判别结果的场景下，这个模型可以获得数倍速度和吞吐。再次测试得到如下指标：

从指标上看下滑非常严重，说明 LLM 即使做分类任务，其自回归的本质导致其前序的输出 Token 序列对后面结论对应 Token 的概率分布影响非常大。COT 是性能提升的关键因素。

从业务的真实场景考虑，一般大部分的翻译都是没有没问题的，模型检测结论为 pass，不存在需要再次调用 LLM 翻译，也就不需要检测模型输出 COT 分析过程以提示 LLM。不输出 COT 的话，大部份正常翻译检测速度都是非常快的，从业务效果上看更为理想。

为了尽可能的达到上述的业务效果，在 Dataset V3 的基础上再次调整训练数据，仅仅保留负例的 COT 过程，把训练数据正例过长的 COT 过程替换成简单结论“Looks good!\n<opinion>pass</opinion>”，形成了 Dataset V5。再次进行评估，得到如下指标，检出率和精准率为 88.06% 和 92.81%。

指标上有一定下滑，检出率和精准率还是基本可用，体感速度明显加快。在延迟敏感的场景可以作为一种 tradeoff 的手段。

基础模型选型

前面更多对训练数据准备做了较多探讨。在当前场景，基座模型本身的能力对效果一定也会存在影响。为了明确模型选型对于当前场景的影响程度，作者参考 HuggingFace 上的热度，初步筛选了四个模型，尺寸从 7B 到 1.5B。这些不同的尺寸意味着推理阶段的延迟和吞吐能力，也是重要的业务考量。

• Mistral-7B-Instruct-v0.3（https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.3）
• Yi-1.5-6B-Chat （https://huggingface.co/01-ai/Yi-1.5-6B-Chat）
• Phi-3-4B-instruct （https://huggingface.co/microsoft/Phi-3-mini-4k-instruct）
• 5-1.5B-Instruct（https://huggingface.co/Qwen/Qwen2.5-1.5B-Instruct）

基于以上的实验结果，可以看出 Qwen2.5-1.5B 具备非常高的性价比，在最小的尺寸上取得了比较接近 Mistral-7B 的效果。但这个结论仅对当前这一版训练数据的成立，随着训练数据的变化，问题难度的变化，可能还会出现不同的最优模型选择。

推理延迟吞吐测试

上一小节关于模型尺寸大小的选择，最终影响的是推理的延迟吞吐。所以作者专门在 G5.2xlarge（A10 单卡）上对比了尺寸差距最大的两个模型（Mistral-7B 和 Qwen2.5-1.5B），得到其输出延迟和吞吐能力的实际差异。

实践中采用测试工具 locust 进行评测，具体指标如下：

Qwen2.5-1.5B-Instruct 延迟和吞吐能力

Mistral-7B-Instruct-v0.3 延迟和吞吐能力

从上面的评测结果得到，Qwen2.5-1.5B 的平均延迟在 2.2s，能支持的并发吞吐为 RPS 为 4.8；Mistral-7B 的平均延迟在 8.2s，能支持的并发吞吐为 2 左右。说明目前实现方法，在追求准确率并保留长 COT 过程的情况下，仅比较适合离线或者近线的场景。

训练方式对比

训练方式上，结合当前的数据情况和业务诉求，继续 pretrain 肯定不在考虑范围内，Full Finetune 和 Lora Finetune 是唯二可选项。一般来讲 Full Finetune 效果层面上一般会优于 Lora Finetune，Lora 相对来说不容易丧失模型基础能力，但在当前场景，该微调模型没有多用途的诉求，基础能力的保持并不是关注重点。

但 Lora Finetune 的训练门槛要低一些。按照通用的经验公式， LLM 模型的 Full Finetune 训练要求，显存一般是模型尺寸的 20 倍，比如 7B 的模型一般最少需要 7*20 = 140G 显存。这对 G5 系 GPU（A10 卡）造成了很大挑战，在作者的实践中，2 台 G5.48xlarge（A10*8 卡）才能进行 Mistral 7B 模型的 Full Finetune，比较推荐的是拿 A100 进行训练。但 Lora Finetune、Mistral 7B 用 G5 系 GPU 基本上可以轻松跑起来。

所以作者也在多个模型上尝试了 Lora Finetune，并尝试做一些参数调整，比如 lora_rank 和 lora_alpha，试图确认其是否能够达到 Full Finetune 的效果，具体指标如下：

仅有 Yi-1.5-6B-Chat 该模型的在 Lora 下的表现稍好，但距离 Full Finetune 差距较大。无论是调整 Lora 的参数量和权重均无法取得稳定有效增益。所以作者初步判断，不排除 Lora 训练通过调整数据和参数可能能得到一定的提高，但从训练难度和效果上看，Full Finetune 训练方法是首选。

总结

本文首先阐述了 LLM 翻译质量提高的重要性，提出了构建翻译质检模型的思路，然后在后续的实践中，对训练数据合成进行了一些有效探索，对微调训练方法进行了一些实践对比。未完，下篇待续。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。

参考资料

1. 技术博客：基于 SageMaker 和 LLaMA-Factory 打造的一站式无代码模型微调部署平台
2. Model Hub 代码仓库 – https://github.com/aws-samples/llm_model_hub
3. Dify-AWS-Tool 代码仓库 – https://github.com/aws-samples/dify-aws-tool

系列博客

1. LLM 微调实践-微调大语言模型进行翻译质检（上）
2. LLM 微调实践-微调大语言模型进行翻译质检（下）

本篇作者