文章性质
本文是技术文章《LLMs应用构建一年之心得（第一篇）》的中文译文，原文由 Eugene Yan、Bryan Bischof、Charles Frye、Hamel Husain、Jason Liu 与 Shreya Shankar 合著，原作发布日期为2024年5月28日，由译者“ian”翻译并发布在个人博客上。文章分为战术、运作和战略三个篇章，本译文为第一篇“战术篇”，聚焦使用LLM构建应用时的具体实践细节。
译者说明，第一稿由 Deepseek V2 翻译，但大量专业术语有误；此后经过多次校译，对部分术语和词汇做了统一处理。译者已向原作者发送邮件请求翻译授权，并获得多位原作者同意。译者计划继续翻译此系列文章的续篇，但截至资料提供时后续译文暂未提供。
背景与定位
文章指出，过去一年里LLM已经“足够好”，可用于实际应用。LLM的广泛可用性使不限于机器学习专家的人都能将智能融入产品。尽管构建AI产品的门槛降低，创建超越演示的有效产品仍然困难。作者们来自不同背景，包括独立顾问、研究ML/AI团队工作方式的研究员、应用AI团队领导者以及深度学习教学者。他们汇总了过去一年在LLM基础上构建实际应用的经验教训，希望将本文打造成围绕LLM构建成功产品的实用手册。
战术篇主要内容
文章围绕新兴LLM技术栈的核心组件展开，具体包括以下方面。
提示（Prompting）
文章建议从提示技巧入手，认为这既容易被低估也容易被高估。被低估是因为恰当运用提示技巧可以事半功倍；被高估是因为即便基于提示的应用也需要围绕提示进行大量工程工作。文中提到的几种技巧包括：多轮对话中的上下文学习、思维链推理以及提供相关资源。对于多轮示例，文章建议目标 n ≥ 5，示例应代表预期输入分布，不必一定提供完整“输入-输出”对，若使用支持工具调用的LLM，示例中也应包含希望Agent使用的工具。对于思维链，文章鼓励模型在给出最终答案前阐述思考过程，并指出让思维链越具体则越有效，添加一两句详细说明通常能大幅降低幻觉率。文章也提到有研究质疑该技术的实际效果，学界对其具体作用仍存争议。提供相关资源方面，文章指出这通常通过检索增强生成（RAG）实现，但仅包含资源不够，还需指示模型优先使用、直接引用并在资源不足时予以说明。
结构化输入和输出
文章认为结构化输入和输出能帮助模型更准确地理解输入内容，并生成可靠地集成到下游系统的输出。针对结构化输出，文章提到 Instructor 和 Outlines 是理想选择：使用LLM API SDK时选择Instructor，自托管模型时选用Outlines。文章还提醒不同LLM家族对格式存在偏好差异，例如Claude倾向XML，而GPT青睐Markdown和JSON。
保持提示简洁
文章借用软件中的“上帝对象（God Object）”反模式，说明提示工程中同样存在问题：提示从简单指令和少量示例起步，在应对边缘情况过程中逐渐膨胀，最终可能演变成有2000个Token的“怪物”，反而在处理常见和直接输入时表现更差。文章建议将包罗万象的提示拆分为多个简单、专注且易于理解的提示，以便单独迭代和评估每个提示。此外，文章建议重新审视发送给Agent的上下文量，将最终提示放在空白页上仔细阅读，以发现冗余内容、自相矛盾的表述和不恰当的格式，并琢磨如何构建上下文、突出各部分之间的联系。
信息检索/RAG
文章指出RAG的效果很大程度上取决于检索文档的相关性、信息密度和细节程度。相关性通常通过平均倒数排名（MRR）或归一化折损累积增益（NDCG）等排名指标量化。信息密度方面，应在同样相关的文档中优先选择更简洁、冗余信息较少的文档。详细程度方面，文章以从自然语言生成SQL查询为例，说明包含列描述和代表性值等额外细节可帮助LLM更好理解表语义。
文章还强调不要忘记关键词搜索，建议将其作为基线和混合搜索使用，并引用了 Perplexity.ai CEO 和 Sourcegraph CTO 的观点，说明单纯使用Embedding的最近邻搜索可能产生嘈杂结果，混合方法在多数情况下效果最佳。
关于RAG与微调的选择，文章引用研究表明RAG可能更具优势，无论对训练期间遇到的知识还是全新知识，RAG都始终优于微调；同时RAG在保持检索索引更新、删除问题文档、对检索索引分区控制等方面具有实际优势。文章还讨论长上下文模型是否会使RAG过时，认为RAG消亡之说过于夸大，原因包括仍需选择信息输入模型、缺乏令人信服的数据表明模型能有效推理超大上下文、以及Transformer推理成本随上下文长度增长带来的成本问题。
调整和优化工作流
文章指出提示LLM只是开始，为榨取最大价值需要超越单个提示、拥抱工作流。文章以 AlphaCodium 为例，说明从单一提示转换为多步骤工作流，可将GPT-4在CodeContests上的准确率（pass@5）从19%提高到44%。工作流包含迭代解决方案、明确的规划步骤、将用户提示重写为Agent提示、将Agent行为设计为线性链/DAG/状态机、规划验证、固定上游状态的提示工程等。文章还讨论AI Agent的非确定性本质使部署成为挑战，建议让Agent系统生成确定性计划，然后以结构化、可重复的方式执行这些计划，并指出最成功的Agent构建者可能是那些在管理初级工程师方面拥有丰富经验的人。
通过温度以外的其他方式获得更多样化的输出
文章讨论提高温度参数可能带来的失效模式，例如某些商品可能永远不会被输出，或温度过高导致引用不存在商品。文章建议通过调整提示中的元素来增加输出多样性，例如每次插入提示时打乱项目列表顺序、保留最近输出的简短列表以防止重复、改变提示中使用的措辞等。
缓存（Caching）
文章指出缓存通过消除对相同输入重新计算响应的需求，节省成本并消除生成延迟；如果响应之前已经过审核，还可提供这些经过审查的响应，减少提供有害或不当内容的风险。一种直接方法是使用正在处理的条目的唯一ID，对于开放查询可以借鉴搜索领域的技术，自动完成和拼写纠正等功能也有助于规范化用户输入、提高缓存命中率。
何时进行微调
文章指出，如果即使经过大量提示工程仍无法获得可靠、高质量的输出，可能有必要针对特定任务对模型进行微调。文中举了两个例子：Honeycomb 的自然语言查询助手通过微调模型在领域特定语言的语法和规则方面产生了更好输出；ReChat's Lucy 需要以结合结构化和非结构化数据的规范格式生成响应，微调对其始终如一地工作至关重要。文章同时提醒微调伴随巨大成本，包括标注微调数据、微调和评估模型、自行托管等，并提到可通过生成并在合成数据集上微调或在开源数据集上进行引导式训练来降低成本。
评估与监控
文章认为严格和周到的评估至关重要，并提出以下经验：从实际输入/输出样本创建基于断言的单元测试；LLM-as-Judge 有作用但不是银弹；针对评估生成的“实习生测试”；过度强调某些评估可能会损害整体性能；简化标注为二元任务或成对比较；（无参考）评估和护栏可以互换使用；LLM会在不应该的时候返回输出；幻觉是一个顽固的问题。
文章具体说明了基于断言的单元测试、基于执行的评估（ODEX）、LLM-as-Judge 的注意事项（使用成对比较、控制位置偏差、允许平局、使用思维链、控制响应长度）等。文章还提到传统分类器和奖励模型能够比LLM-as-Judge达到更高准确率且成本和延迟更低。“实习生测试”是指把语言模型的确切输入包括上下文交给相关专业的普通大学生，看他们能否成功、需要多长时间，以此判断任务难度和上下文是否充分。
文章以“大海捞针”（Needle-in-a-Haystack，NIAH）评估为例，说明当衡量标准成为目标时，就不再是一个好的衡量标准。过度强调NIAH评估可能导致在提取和总结任务上的性能下降。文章还建议将标注简化为二元分类和成对比较，以减轻标注者的认知负担、提高评分者之间的一致性。
适用场景与限制
文章面向使用LLM构建产品的实践者以及“周末项目开发”的爱好者，尤其适合有一定经验的开发者浏览标题快速定位感兴趣段落阅读。文章多次提醒，由于内容较长，仔细阅读需要花费较长时间。文中也指出，部分译句因英语习惯与中文习惯不同而略显生涩，可能存在排版错误。文章为系列第一篇，后续“运作篇”和“战略篇”在本次资料中暂未提供。关于文章中提到的外部工具（如Instructor、Outlines、AlphaCodium、BM25等）的具体功能、收费、价格、平台或使用步骤，本资料未提供详细信息。
