这些建议可提高LLM应用的准确率，还包含如何选择合适LLM的注意事项。
译自 4 Key Tips for Building Better LLM-Powered Apps，作者 Adrien Treuille 是 Snowflake 的产品管理总监和 Streamlit 主管，负责数据云的可视化数据产品和 Streamlit 计划。在加入 Snowflake 之前，Adrien 是 Streamlit 的联合创始人和 CEO(2022 年 3 月被 Snowflake 收购)，。。。
在 OpenAI 发布其第一个 ChatGPT 模型一年之后，对生成式 AI 的兴趣爆炸式增长。大语言模型(LLM)驱动的应用程序现在成为企业思考生产力和效率的前沿。用于构建生成式 AI 应用程序的工具和框架也得到了极大的扩展。但是人们还是担心生成式 AI 输出的准确性，开发人员需要快速学习如何处理这些问题，以构建强大且值得信赖的应用程序。
下面是一些提高 LLM 应用程序准确性的建议和技术，以及选择合适的 LLM 时需要考虑的事项。由于每个问题本身就很复杂，我们无法详尽地讨论这些问题，但是可以提供一些入门建议，供您进一步探索。
Streamlit 是一个免费的开源框架，用于快速构建和分享机器学习和数据科学 Web 应用程序。它最近发布了一份报告，分析了在 Streamlit 社区云上由超过 13，000 位不同的开发者构建的超过 21，000 个 LLM 应用程序。这为下面的部分建议提供了一些迄今开发者使用的工具和技术的见解。
例如，向量检索工具对于改进 LLM 驱动应用的上下文推荐非常有效，但是我们的调查发现，如今只有少数开发者使用向量功能，这代表着未来的巨大机会。
随着越来越多的开发者利用生成式 AI 的力量来开发应用程序，我们将开始看到各个类别和行业垂直的应用程序内置基于 AI 的搜索功能，以及会话和辅助体验。下面是我给开发者的四个提示，帮助他们构建更好的 LLM 驱动应用程序，以便他们为其组织带来真正的颠覆。
像 LangChain 和 LlamaIndex 这样的编排框架可以通过额外的工具或 Agent 来补充你的模型，增强你基于 LLM 的应用程序的功能。在这种上下文中，可以将 Agent 视为一个插件系统，允许你在应用程序中构建额外的功能，用自然语言表达。
这些 Agent 可以组合起来管理和优化 LLM 功能，例如精炼 AI 推理、解决偏见并集成外部数据源。这些 Agent 也可以为 LLM 提供一种方法来反思它是否正在犯错误以及它必须采取的步骤来成功完成一个任务。
做一个类比，想象一下开发者如何编写一个提供某种功能的 API 以及描述该 API 的文档：API 用代码表达，文档用自然语言。Agent 的工作方式类似，只不过文档是为了 LLM 的利益，而不是其他开发者。所以 LLM 会查看手头的任务，查看 Agent 的文档，并确定该 Agent 是否可以帮助它完成任务。
这些 Agent 也通过为应用程序提供一种方法来反思自己的错误并纠正错误，从而为 LLM 应用程序增加健壮性。例如，假设一个 LLM 应用程序编写一些 SQL 代码来执行一个任务，比如在数据库中检查库存水平，但它在代码中做了一个错误。对于标准的“朴素” LLM 应用程序，这个错误就是终点。
然而，如果应用程序具有执行 SQL 的 Agent，它可以查看错误并使用 Agent 确定它应该做些什么不同的事情，然后纠正错误。这可能是语法上的一个小变化，但没有 Agent，LLM 没有办法推理它的错误。
有时候你使用的 LLM 可能无法访问完成预定任务所需的所有信息。可以在提示时注入额外信息，但大多数 LLM 对这些提示的大小有限制。为了规避这些限制，LLM 可能需要使用向量查询外部数据库，这种技术称为检索增强生成(RAG)。
为了理解 RAG 能为 LLM 应用程序做什么，把 LLM 应用程序分为三个不同的级别会有所帮助。
- 级别 1: 该应用程序可以使用 LLM 内部的知识生成结果。
- 级别 2: 该应用程序需要可以在提示时注入的其他信息。只要你可以在提示限制内，这相当简单。
- 级别 3: LLM 需要访问外部信息源，比如数据库，来完成任务。
这就是 RAG 的用武之地，外部数据库通常用向量进行语义索引，这就是最近你可能经常听说向量数据库和向量搜索工具的原因。
具有向量数据库和向量搜索的应用程序可以通过对大规模非结构化数据集(包括文本、图像、视频或音频)进行分类来启用快速的上下文搜索。这对于进行更快、更准确的上下文推荐可以说是极其有效的。但向量工具的使用率仍然不高。Streamlit 的调查发现，只有 20% 的生成 AI 驱动的应用程序使用了某种形式的向量技术。
聊天机器人将生成式 AI 引入主流，但人们对它是否会成为有效的界面存在一些怀疑。有人认为聊天机器人给用户太多自由，而且没有足够的上下文来说明 LLM 应用程序的使用方式。其他人因为过去的失败而感到失望: Clippy 是一个灾难，那么为什么今天的聊天机器人会成功呢?
显然，聊天机器人是否合适，部分取决于应用程序的预期用途。但是聊天机器人至少有一个非常有用的品质不应被忽视：它们通过流畅的人机界面为用户提供了一种简单直观的方式来添加上下文和精炼答案。
要理解这为什么如此强大，想象一下搜索引擎。用户通常没有办法改进搜索引擎查询；如果结果略有偏差，那么就没有办法告诉搜索引擎“再试一次但排除关于 X 的答案”，例如，或者“给 Y 更多权重”。这会是一个方便和强大的功能，也是聊天机器人为 LLM 应用程序提供的功能。
调查发现，在 Streamlit 上构建的 28% 的生成式 AI 应用程序是聊天机器人，而 72% 的应用程序通常不允许会话式改进。另一方面，调查显示这些聊天机器人的每周使用量上升至近 40%，而非聊天机器人应用程序的使用量下降。所以聊天机器人可能是最终用户首选的界面。该报告包括具有不同文本输入模式的应用程序示例，因此您可以查看可能的功能。
GPT 的基础模型仍然是最著名的 LLM，它们非常强大，但在过去一年中出现了更多选择，其中一些可能更适合您的应用程序。需要考虑的因素包括 LLM 所需的知识范围、LLM 的大小、您的培训需求和预算，以及 LLM 是否开源或专有是否重要。与技术中的许多事物一样，存在权衡取舍。
如果您正在为内部使用构建生成式 AI 应用程序，则可能需要在内部公司数据上训练该 LLM。对于大多数企业来说，由于安全原因，与公共 LLM 共享敏感数据是不可能的，因此许多公司在其现有的云安全边界内运行 LLM。这通常会导致他们转向较小的 LLM，例如 AI21 和 Reka。
非常大的 LLM 也往往具有更高的延迟，并且由于所需的计算资源，运行成本通常更高。如果应用程序执行的任务相对简单，例如翻译文本或总结文档，则较小的 LLM 可能效果很好，使用和操作的成本也要低得多。
您也可能有推荐开源 LLM 的理由，比如 Meta 的 LLaMA，而不是来自 OpenAI、Anthropic 或 Cohere 等公司的专有 LLM，在这些公司，源代码、训练数据、权重或其他模型细节通常不会公开披露。开源 LLM 需要自我托管或通过托管提供商进行推理，但源代码和其他模型详细信息更容易获得。
生成式 AI 仍然是一个快速发展的领域，但所需的工具和技术正在迅速进步，今天就有许多选择可以开始。抓住这一机遇的开发者可以为其组织带来巨大价值，将 AI 应用程序作为日常业务操作和任务的常规功能。随着生成式 AI 继续重塑组织中的角色和责任，深入研究并成为 LLM 驱动应用程序专家的开发者将会脱颖而出，上述建议应该可以帮助您走上正轨开始。