這些建議可提高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 驅動應用程序，以便他們為其組織帶來真正的顛覆。

采用 Agent 和 Orchestration 構建更智能的應用程序

像 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 沒有辦法推理它的錯誤。

使用 Vector Magic 和 RAG 來對抗幻覺

有時候你使用的 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

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 應用程序作為日常業務操作和任務的常規功能。隨著生成式 AI 繼續重塑組織中的角色和責任，深入研究并成為 LLM 驅動應用程序專家的開發者將會脫穎而出，上述建議應該可以幫助您走上正軌開始。