大语言模型工程化：挑战与解决方案

题图由 Bedrock SDXL 模型生成

引言

大型语言模型（LLM）的迅速发展和广泛应用正在推动一种新型的生产和工作方式。在这种方式下，我们只需通过自然语言向大模型提供”提示”（prompt），就能让它完成相应的任务。

当前，大模型成了个人生产力，企业创新和运营效率提升的工具。个人使用的常见的场景有信息提取和报告总结等。企业级的应用包括智能客服，销售助手，有智能问答功能的新一代知识库，智能报表生成等。

随着 LLM 的不断深入的应用，在很多场景中提示词的编写愈发变得复杂，结构化，系统化，同时需要结合工程化的技术才能使 LLM 完成指定任务，因此有必要区分“提示优化（Prompt Optimization）”和“提示工程（Prompt Engineering）”，提示优化是针对提示词本身，而提示工程是围绕提示词进行的工程化构建，两者的良好结合成为 LLM 应用落地的一个重要因素。

本文基于大量的大语言模型工程实践积累，通过一个 POC 项目的构建全过程，从场景到部署，一步一步来梳理并呈现大语言模型工程化的全貌，以供企业在构建大模型应用前参考。

基于大语言模型的智能翻译案例解析

这个案例总体遵循了定义业务目标，发现技术挑战，应用解决方案的过程。

图一：POC 项目的主要过程

业务场景共创

基于多个企业项目经验，我们发现找到具有业务价值并具备技术可行性的创新场景并不容易，需要客户的业务人员和技术人员将业务需求和最新的技术对齐，共同讨论定义出业务场景。

比如，某游戏公司需要翻译游戏的多语言版本，因为存在较多游戏中特有的地名和人名，机器翻译的效果不好，主要是人工翻译为主，翻译的时间根据工作量的不同从数天到数周不等。

通过联合创新机制，针对这个场景，业务负责人和技术负责人共同组成项目组，确定该场景的业务价值，并且分工合作，定义了翻译效果和可上线的翻译标准。

业务目标

翻译项目组共同认可的翻译场景的业务目标为：

• 在翻译的准确性和流畅度上达到或接近之前的人工翻译水平，翻译仅需对结果进行校验即可
• 具备准确的专有名词的多语种翻译能力
• 大幅节省翻译的时间和翻译成本，将长文档的翻译所需的人工工作量缩短 60% 以上

快速发现挑战

首先，项目组使用简单的提示词初步测试了翻译效果，发现在使用明确的提示词后，大语言模型可以避免中式英语，并且翻译较为流畅。但也快速识别和发现了下述挑战。

• 专有名词的翻译：游戏中的人名，地名，道具和武器等名称是自创的专有名词，大语言模型不可能翻译的准确。翻译时要将不同游戏的不同术语表给到大语言模型，这些术语表随着游戏版本的升级会有所变化。
• 长文翻译：相比较短的脚本翻译效果来说，过长的脚本一次给大模型翻译的效果会下降。因此要对长脚本先分片，后翻译。测试中发现简单的分片会使得分片前后的上下文丢失，影响翻译效果。
• 翻译风格：不同风格的游戏对翻译的风格有不同要求，有的翻译要求恢弘大气，有的要求翻译的轻松调皮，最好可以通过自动检测文本类型来确定翻译风格。
• 翻译准确度提升：简单的提示词，不足以让大语言模型生成质量极高的翻译结果。可能会出现标点符号的使用错误，翻译生硬等问题。
• 合规：翻译中不应出现违反 DEI（多元化、公平性和包容性）的情况，比如“主人”这样的词汇在英文中最好译成“Mentor”而不是“Master”，否则可能会引发严重的合规问题。
• 大语言模型的部署和应用方式：是使用云上托管的大语言模型还是要自行部署模型，会极大的影响投资回报率，如何保证应用的高可用性的同时提供弹性伸缩能力。

我们可以看到在这样一个相对简单的大语言模型的应用场景中，就需要面对如此众多的问题。在下面的篇幅中，我们将从架构设计和工程化两个视角来阐述如何系统的解决上述问题。

解决方案

针对上述挑战，我们归纳总结后有针对性的解决方案如下。

提升译效果 – 让大语言模型自省（Self-Reflection）

吴恩达提出了 Translation Agent Framework，其中使用了自省机制，将翻译分成了三个步骤，第一步是先调用大模型进行一遍预翻译。第二步是让大语言模型根据检查条件对翻译结果进行检查，并对发现的问题逐条给出建议，在这一步中可以要求大语言模型注意使用正确的标点符号，不同语言的语序的区别，流畅度，准确度等，但是并不直接要求改正。第三步是将预翻译和建议一同给到大模型进行最终的翻译，我们发现在引入大语言模型自省后的翻译效果有了极大的提升。

专有名词的翻译

构建专有词表，针对不同的游戏，提供源语言和目标语言的词汇表。在前述 Translation Agent 进行翻译前，对照词汇表提取输入中的专有词汇，并将对应的翻译一同给到大模型，获取准确的专有名词的翻译。如下样例是一个多语言字典的样例。

{
			"mapping" : {			
				"CHS" : "奇怪的渔人吐司",
				"CHT" : "奇怪的漁人吐司",
				"DE" : "Misslungene Fischerschnitte",
				"EN": "Suspicious Fisherman’s Toast",
				"ES" : "Tostada del pescador extraña",
				"FR": "Toast du pêcheur (suspect)",
				"ID" : "Suspicious Fisherman’s Toast",
				"IT" : "Toast del pescatore sospetto",
				"JP" : "微妙な漁師トースト",
				"KR" : "이상한 어부 토스트",
				"PT" : "Torrada do Pescador Estranha",
				"RU" : "Странный рыбацкий бутерброд",
				"TH" : "Fisherman’s Toast รสประหลาด",
				"TR" : "Balıkçı Tostu (Tuhaf)",
				"VI" : "Bánh Người Cá Kỳ Lạ"
			},
			"entity_type": "Character"
		}

长文本拆解

为了让大语言模型更好的理解上下文，我们采用 langchain_text_splitters 中的 RecursiveCharacterTextSplitter 来进行长文本的拆解，它可以照段落或者句子来进行，同时包含前后段落，仅让大语言模型对中间部分进行翻译。拆分后的效果举例如下：

<pre-context>…一个小伙伴的名字叫</pre-context>
<translate-content>
奇怪的渔人吐司
</translate-content>
<post-context>他很乐于助人…</post-context>

完整的 Translation Agent 的翻译流程如下图二所示。

图二： 基于提示工程的翻译流程

提示词工程是一个庞大的话题，您在遇到效果提升瓶颈的时候可以参考 Prompt Engineering Guide 网站中的内容，这里提供了几十种提示工程的方法和技巧，也提供了数百篇提示工程相关的论文链接。

在提示工程之外，如果具备足够多的翻译数据，我们还可以采用模型微调的形式来进一步提升翻译效果。

安全与合规

大语言模型的合规问题表现在如下方面：

1. 数据隐私和保护
2. 不符合道德标准，偏见和歧视
3. 内容有害或者不合法
4. 模型被恶意使用或者越狱

出于不触碰合规红线的考虑，仅仅通过提示词来约束是不够的。我们建议可以从输入和输出的审核这两个方面来防范。

因为大语言模型本身已经在尽最大努力来回答问题，让大语言模型自己对自己的结果进行检查并不能取得很好的结果，有必要使用单独的合规模型来对输入和输出进行约束。合规模型应该针对上述的合规问题来构建，一般需要使用对应的不合规的数据集来微调模型，并将微调后得到模型应用在输入和输出的审核上。比如对于带有恶意或者越狱指令的输入，合规模型应该发现并主动拒绝对该输入的进一步处理；对于包含个人信息（PII）数据的输入，模型应该对个人信息进行检测和替换。对于冒犯性的输出，我们同样可以使用合规模型来进行过滤。

合规模型围绕着大模型形成的模型集成方案如下图所示。

图三：多模型集成

部署

大模型因为对 GPU 内存的要求较高，而部署在 GPU 机型上的费用是按小时计算的，比如 ml.m5d.12xlarge 在俄勒冈（ohio）区域 2024 年 9 月的按需机型价格是每小时 3.254 美元，Bedrock Claude 3.5 Sonnet 在俄亥俄区域的价格是每 1 百万 token 3 美元。对于调用频率不高的应用，因为云服务商已经对推理效率进行的专业和极致的优化，建议优先使用亚马逊云科技 Bedrock 上已经部署好的大语言模型。

对于调用频率较高或者使用行业模型的应用，自行部署可能更有性价比，为此亚马逊云科技的 SageMaker 服务也提供了弹性伸缩，高可用性的私有模型部署能力。在最终决定使用哪种部署方式的时候，我们需要综合多种因素来决定。

进一步产品化的考虑事项

大语言模型在进一步产品化的时候会遇到下述问题。

定制领域大模型

托管的大语言模型提供的主要是通用能力，在一些行业场景里未必能达到客户期待的最佳效果。遇到特定的场景或者业务领域，应该考虑模型微调，以便得到更好的效果。

应用评估

完成应用的构建之后，我们如何知道应用的表现达到了预期？一般来说我们需要构建一个测试集，根据应用在测试集的表现来预估应用上线后可以期待的效果，测试集合的构建并不简单，它的分布需要尽可能的接近真实的使用场景，以确保测试集的指导作用。

反馈

对于多数大语言模型的应用来说，上线并投入使用只是持续迭代和改进的起点。如何知道大语言模型项目在生产环境中运行良好？如何知道客户是否对他们获得的结果满意？在应用中引入反馈机制是必要的，通过反馈机制，我们可以发现错误情况，这样就可以跟踪结果并继续改进应用。

从数据处理到模型训练—构建机器学习流水线（ML Pipeline）

在需要模型微调的场景，基于前面的模型评估和反馈，我们经常要调整模型微调的数据，并定期微调模型，自动的将评估通过的新模型上线。注意在数据预处理时应该去除 PII，PHI 等数据，以防止隐私数据被大模型学到，产生泄漏隐患。

数据科学家和工程师团队应该将该流程固化为从数据处理到模型训练的流水线。从长远来看，这将为应用效果不断增强提供有力的技术支持。

图四展示了一个机器学习流水线的主要部分。

图四：机器学习流水线

亚马逊云科技的 Bedrock 服务和 SageMaker 服务提供了上述所需的数据处理，流程编排，大模型微调，推理节点部署等能力，可以极大的加速项目上线的过程。

法律

在选用大语言模型的时候需要获得客户使用人工智能/生成式人工智能的同意、避免使用客户数据训练大型语言模型，确保大语言模型托管平台不保留任何关于对话的信息。针对如何满足合规性（例如 GDPR 等），我们也应该咨询法务部门的专业意见。

通用的大语言模型应用的解决方案

我们用一张通用大语言模型应用的架构图来作为总结，它包含了本文描述的大多数内容。

图五：完整解决方案全景图

• 应用层主要负责：流程配置，用户权限，用户界面，合规审查
• 模型层主要负责：模型的托管，高可靠，自动伸缩
• 机器学习流线负责：应用的效果评估，数据的标记，清洗，新模型的微调

回顾和总结

本文通过一个企业翻译应用的案例，全面阐述了大语言模型应用从构思到上线的完整过程。我们讨论了以下关键点：

1. 业务场景发现与目标设定的重要性
2. 提示优化和提示工程的区别
3. 一个示例大语言模型翻译应用面临的主要挑战，包括专有名词翻译、长文本处理、翻译风格、准确度提升、合规性和部署问题
4. 针对这些挑战的解决方案，如使用定制模型，自省机制、专有词表、长文本拆解等技术
5. 安全与合规的考虑，通过多模型集成对输入输出进行多方面的审核
6. 部署策略的选择，权衡云托管大模型和单独部署的适用性
7. 其他重要考虑因素，如模型评估、用户反馈机制、机器学习流水线的建立等
8. 法律和合规性的注意事项

通过这些讨论，我们勾勒出了一个通用的大语言模型应用架构，包括应用层、模型层和机器学习流水线。这个架构为企业在构建和部署大语言模型应用时提供了全面的参考框架。

在大语言模型快速发展的今天，企业要充分利用这一技术带来的机遇，同时也要审慎应对其中的挑战。希望本文能为企业在这一领域的探索和实践提供有益的指导。

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

参考链接

[translation-agent] https://github.com/andrewyng/translation-agent

[An LLM Journey: From POC to Production] https://medium.com/cyberark-engineering/an-llm-journey-from-poc-to-production-6c5ec6a172fb

本篇作者