01。

概述

在众多检索增强生成（RAG）应用中，常常遇到这样的挑战：底层数据源如技术文档，通常只提供单一语言版本。然而，用户可能希望用其他语言进行查询。这种语言不匹配的问题，对于有效检索和理解相关信息构成了不小的难题。在CONTACT公司，面对的挑战尤为明显，因为其客户主要来自德国，而公司使用的文档资料却是英文版。本文将探讨并比较两种解决此问题的方法：利用多语言嵌入技术，以及先将用户查询翻译后再进行嵌入检索。将根据它们的检索效果进行评估。

02。

方法

多语言嵌入

多语言嵌入技术专为理解并处理多种语言设计。它能够直接处理不同语言的查询，并与底层数据源内容进行匹配。此方法的主要优势在于，它避免了翻译的需要，可能更好地保留原始查询的细节和内涵。

翻译后嵌入

另一种方法是先将用户查询翻译成数据源的语言，然后再进行嵌入检索。这可以通过多种翻译模型来实现。翻译后的查询将使用与数据源相同的模型进行嵌入，以便进行直接的比较和检索。在本研究中，采用了包括GPT-3.5-turbo、GPT-4o、Claude-3.5-Sonnet在内的多种翻译模型，以及一个小型的Llama-3模型（8b-instruct-q8_0），该模型在本地运行。

数据

为了比较这两种方法，以CONTACT Elements产品的英文文档作为主要数据源。文档经过预处理，划分为750字符的块，每块之间有200字符的重叠。评估使用了一套包含196个典型用户问题的集合，这些问题以及它们在文档中的对应答案页面，均有英文和德文版本。

示例问题

德语用户可能会问：“Welche Kommandozeilenargumente sind beim PC-Client möglich？” 而英文用户可能会问：“Which command line arguments are supported by the PC client？”

嵌入

为了比较，使用了多种嵌入模型来处理文档和原始及翻译后的问题。这些模型包括OpenAI的多语言text-embedding-3-small、Cohere的embed-multilingual-v3.0，以及微软的E5模型，这些模型通过Hugging Face的SentenceTransformer库在本地运行。

工作流程

为了有效管理数据和流程，集成了数据版本控制（DVC），这是一个为机器学习项目量身定制的版本控制系统。它有助于系统地跟踪ML模型的整个生命周期，包括数据变化、依赖项和流水线。

结果

通过比较不同模型和场景下的20个召回率来评估这些方法的性能。召回得分反映了模型在前20个结果中检索相关文档的能力。

03。

分析

多语言嵌入虽然有效，但也有局限性。例如，微软的多语言e5-large模型在处理德语问题时表现出色，但使用仅限英文的E5-large-v2模型翻译的查询，其召回率更高。

翻译后嵌入通常表现良好，往往超过多语言嵌入方法，尤其是当考虑到数据隐私需要使用本地模型时。

04。

结论

处理RAG应用中不同语言问题的方法各有千秋。多语言嵌入提供了一个简单直接的解决方案，但翻译后嵌入通常能带来更好的检索效果。开发者应根据应用的具体需求和资源，选择最合适的方法，以提高RAG系统的准确性和多语言用户的可用性。