当构建一个可以访问领域特定知识的AI应用程序时，有三种主要方法：提示工程（在上下文窗口中包含信息）、RAG（检索增强生成：在查询时检索相关信息）或微调（在领域特定数据上训练模型）。以下是每种方法适合的情况。
解释各种方法
提示工程：最简单的方法。直接在系统提示或用户消息上下文窗口中包含领域特定信息。最适合：适合上下文窗口的小型知识库、一次性任务、原型设计，以及信息频繁变化的情况。限制：上下文窗口，虽然现在很大（100K到1M+令牌），但不是无限的；成本随上下文线性增加；当上下文非常长时，模型从上下文检索的可靠性降低。RAG（检索增强生成）：检索系统（通常是嵌入上的向量搜索）从大型知识库中找到最相关的块，并在查询时将它们包含在提示中。最适合：大型知识库（文档、支持文章、法律文件）、对任何给定查询只有一部分知识库相关的问题，以及知识库频繁更新的情况。工作原理：文档被分块并嵌入（转换为向量表示）；在查询时，查询被嵌入，最相似的文档块被检索；这些块被包含在提示中。限制：RAG质量很大程度上取决于检索质量——如果检索步骤没有找到正确的文档，模型无法正确回答。微调：在领域特定数据上更新模型权重，使知识”烘焙进”模型中。最适合：改变模型的风格或语调、教授特定结构化输出格式、提高非常特定任务类型的性能，或注入不太可能改变的稳定事实知识。
决策框架
从提示工程开始：对于任何新应用程序，从精心制作的提示开始并包含相关上下文。如果有效，你就完成了——提示工程是最简单、最快的方法。升级到RAG的时机：知识库对于上下文窗口来说太大，知识库频繁更新（每日或每周），或者你需要引用特定来源。当你可以使用RAG时不要进行微调：微调是昂贵的（GPU时间、数据准备），耗时，并创建需要维护的模型。大多数应用程序不需要微调。考虑微调的时机：你需要一致的结构化输出格式（JSON模式、特定分类标签），你需要显著改变模型的默认风格，你有一个非常特定的狭窄任务和许多标记的示例，或者你需要通过使用较小的微调模型而不是较大的通用模型来改善延迟/成本。
组合各种方法
在实践中，表现最好的应用程序通常结合各种方法。常见模式：微调用于风格/格式 + RAG用于知识。示例：法律文件助手——微调以输出公司的特定引用风格并正确分类文件类型，以及用于事实检索的公司判例法数据库上的RAG。另一种模式：在系统提示中使用少量示例的RAG + 提示工程，指导模型如何使用检索到的上下文。成本现实：对有意义的训练运行进行模型微调需要数百到数千美元（截至2025年，GPT-4微调成本约为每千个训练令牌0.03美元，所以1000万令牌 = 300美元，不包括基础设施开销）。RAG成本较低，但需要向量数据库基础设施和嵌入计算。对于大多数用例——特别是知识定期变化的用例——具有良好提示工程的RAG优于微调，且维护成本更低。
