为了解决这个问题，一般有如下的方法可以考虑：
提示工程
检索增强生成 (RAG)
任务微调
从头开始训练自己的基础模型（FM）
那么，在接手一个具体的业务场景后，我们会面临的一些常见问题：
如何选型？选择什么参数规模的大模型？
选定参数规模的模型后，模型的基础能力如何？是否能够满足当前场景任务？
如果能满足当前场景，和预期目标有多大差距？
和预期存在差距，那么这个差距是否可以通过一些方法解决？
在逐步考虑上述问题的过程中，我们需要对不同的方法，提示工程、RAG、Fine-Turning或训练基础模型，做出自己的判断，到底选择何种方法，以及何种方法能够高效、快速、准确的解决自己的业务场景问题。那么我们应该从哪些角度考虑上述方法呢？
如何比较上述方法？
针对上述四种方法，我们可以从下面几个维度进行分析比较：
准确性（响应的准确性如何？）
实现复杂性（实现有多复杂？）
成本（需要付出多少成本来实施？）
更新迭代（架构的松散耦合程度如何？更换/升级组件有多容易？）
上述的评估维度不是统一的，只是从个人工程经验角度来谈的。例如提示工程能够快速出结果，但如何写提示工程是一个比较依赖经验性的过程。
准确性
让我们首先讨论最有影响的一点：哪种方法提供最准确的响应？
下面结果是指大量实验后，平均表现情况，在具体场景下，存在特例，例如简单场景问答，可能RAG是表现效果最佳。
提示工程就是通过提供少量示例（少量学习）来提供尽可能多的上下文，以使LLM更好地了解用例。虽然结果可能不错，但与此处讨论的其他方法相比，它产生的结果最不准确，这个不准确指的是在大量实验中，出现准确性结果的概率低于其他的方法，在特定场景下，该方法可能有出其不意的效果哦。
RAG方法由于增加了来自向量化检索的上下文信息，RAG一般能产生高质量的结果。与提示工程相比，它产生的结果大大改善，并且产生幻觉的可能性大大降低。
微调可提供相当高精度的结果，其输出质量与 RAG 相当。与 RAG 相比，质量具体取决于用例。因此，评估是否真的值得花时间在两者之间进行权衡分析非常重要。一般来说，选择微调可能有多种原因，而不仅仅是准确性。原因包括数据更新的频率、出于监管、合规性和可重复性目的而在自己的环境中控制模型工件等。
从头开始的训练可以产生最高质量的结果。由于该模型是从头开始对用例特定数据进行训练，因此产生幻觉的可能性几乎为零，并且输出的准确性也是比较中最高的。
实施复杂度
让我们看看实施这些方法有多容易或多困难。
提示工程的实现复杂性相当低，因为它几乎不需要编程。需要良好的语言技能和领域专业知识，就能通过上下文学习方法和少量学习方法得到还不错的结果。
RAG比提示工程具有更高的复杂性，因为需要具备编程能力来实施此方案。根据 RAG 架构中选择的工具，复杂性可能会更高，例如向量召回框架、相似度计算方法等。
微调的复杂性甚至比提示工程和 RAG 还要高，因为模型的权重/参数是通过模型训练进行变更的，这需要具备一定的编程能力、深度学习能力以及大模型领域微调能力。
从头开始的训练具有最高的实施复杂性，因为不仅仅是对工程师能力的依赖，对算力、数据、时间的消耗也是非常巨大的。
成本
让我们了解每种解决方案需要付出多少成本。请注意，实现复杂性和工作量并不总是成正比。
提示工程需要大量的迭代探索才能得到正确的结果。LLM对提示的非常敏感，改变一个词甚至标点有时会给出完全不同的反应。因此，需要进行多次迭代才能使其适合各自的大模型。
由于涉及文本向量化、向量存储和检索的任务，RAG对成本的需求要高于提示工程。
与提示工程和 RAG 相比，微调是一项更费力的工作。虽然可以用很少的数据来完成微调，但进行微调以及获得比较良好微调结果是一项重复费事的工作。
从头开始训练是所有方法中最有效的方法，但也是最耗时的，这个过程可能会很长（几周到几个月）。
更新迭代
上述方法在可扩展性以及泛化性上的表现。
提示工程具有非常高的灵活性，因为只需要根据LLM和用例的变化来更改提示模板。
当架构发生变化时，RAG具有最高程度的灵活性。可以独立更改嵌入模型、向量存储和 LLM，对其他组件的影响最小到中等。它还可以灵活地在流程中添加更多组件，例如复杂的授权，而不会影响其他组件。
微调对变化的灵活性相当低，因为数据和输入的任何变化都需要另一个微调周期，这可能非常复杂且耗时。此外，使相同的微调模型适应不同的用例需要付出很大的努力，因为相同的模型权重/参数可能在其他领域表现不佳，而不是在其所调整的领域。
从头开始的培训对变化的灵活性最差。由于在这种情况下模型是从头开始构建的，因此对模型执行更新会触发另一个重新训练周期。可以说，我们也可以微调模型，而不是从头开始重新训练，但准确性会有所不同。
从上述所有比较中可以明显看出，没有明显的赢家。这取决于在考虑解决方案时候，哪个指标更加看重。
一般来说：
当希望更改LLM和提示模板方面具有更高的灵活性并且用例不包含大量上下文时，可以考虑提示工程。
当希望在更改不同组件（数据源、嵌入、FM、矢量引擎）方面获得最高程度的灵活性，同时保持高质量的输出时，可以使用RAG 。
当想要更好地控制模型输出及其版本管理时，使用微调。当领域特定术语对于数据非常具体时（例如法律、生物学等），也很有用。
当以上都不适合时，可以从头开始训练。
总而言之，选择正确的生成人工智能方法需要深入思考并评估可协商和不可协商的指标。没有单一的正确或错误的答案。
原文作者：芝士AI吃鱼；如有侵权，请联系管理员删除。
