本文將介紹一種經(jīng)精心設(shè)計的開發(fā)可靠的高性能LLM應(yīng)用程序所遵循的軟件設(shè)計原則——LLM三角原則。基于這一原則開發(fā)LLM應(yīng)用，有助于縮短應(yīng)用LLM的巨大潛力和現(xiàn)實世界實施面臨的挑戰(zhàn)之間的差距。

引言

大型語言模型(LLM)存在巨大的潛力，但是想開發(fā)出高可靠性的生產(chǎn)級LLM應(yīng)用程序仍然存在相當大的挑戰(zhàn)。在經(jīng)歷過構(gòu)建了數(shù)十個LLM系統(tǒng)的實踐后，我將成功開發(fā)LLM應(yīng)用的公式提煉為任何團隊都可以遵循的3+1基本原則。

“LLM原生應(yīng)用程序有10%是訓(xùn)練復(fù)雜模型相關(guān)的工作，而另外90%則是實驗數(shù)據(jù)驅(qū)動的工程開發(fā)工作?！?/p>

構(gòu)建生產(chǎn)級實用型LLM應(yīng)用程序需要非常細致的工程實踐。當用戶無法直接與LLM交互時，必須精心編寫有關(guān)提示，以涵蓋所有細微差別，因為迭代用戶的反饋信息可能是不可用的。

LLM三角原則介紹

LLM三角原則概括了構(gòu)建有效LLM原生應(yīng)用程序的基本指導(dǎo)方針。這一原則提供了一個堅實的概念框架，指導(dǎo)開發(fā)人員構(gòu)建健壯可靠的LLM原生應(yīng)用程序，并提供指導(dǎo)和支持。

從SOP視角優(yōu)化三個突出的原則，從而實現(xiàn)最佳的LLM使用

關(guān)鍵點

總體來看，LLM三角原則引入了四種編程原則，以幫助你設(shè)計和構(gòu)建LLM原生應(yīng)用程序。

其中，第一個原則是標準操作程序(SOP：Standard Operating Procedure)。SOP提出我們?nèi)切蔚娜齻€頂點：模型、工程技術(shù)和上下文數(shù)據(jù)。

通過SOP的視角優(yōu)化上述三角形的三個頂點的原則是確保高性能LLM原生應(yīng)用程序的關(guān)鍵。

1.標準操作程序(SOP)

標準操作程序(SOP)是工業(yè)界眾所周知的術(shù)語。這是一套由大型組織編寫的分步驟說明，旨在幫助員工進行日常操作，同時每次都能保持高質(zhì)量和相似的結(jié)果。通過編寫詳細的說明，這將缺乏經(jīng)驗或低技能的工人變成了專家。

LLM三角原則借鑒了SOP范式，并鼓勵你將該模型視為缺乏經(jīng)驗/不熟練的工人。我們可以通過向模型“講授”專家應(yīng)該如何執(zhí)行這項任務(wù)，來確保更高質(zhì)量的結(jié)果。

SOP指導(dǎo)原則

“如果沒有SOP，即使是最強大的LLM也無法提供始終如一的高質(zhì)量結(jié)果。”

在思考SOP指導(dǎo)原則時，我們應(yīng)該確定哪些技術(shù)將幫助我們最有效地實施SOP。

（1）認知建模

為了創(chuàng)建SOP，我們需要選取表現(xiàn)最佳的員工(領(lǐng)域?qū)＜?，模擬他們?nèi)绾嗡伎己凸ぷ鳎詫崿F(xiàn)相同的結(jié)果，并記錄下他們所做的一切。

在經(jīng)過精心編輯和正式確定之后，我們將提供詳細的說明來幫助每一位缺乏經(jīng)驗或低技能的工人取得成功，并做出優(yōu)秀的工作業(yè)績。

與人類一樣，通過簡化或拆分任務(wù)來減少任務(wù)的認知難度至關(guān)重要。遵循簡單的循序漸進的指導(dǎo)比冗長復(fù)雜的程序更直接。

在這個過程中，我們識別出隱藏于其中的隱式認知“跳躍”——專家們采取的小而無意識的步驟，這些步驟會顯著影響結(jié)果。這些微妙的、無意識的、往往不言而喻的假設(shè)或決定會對最終結(jié)果產(chǎn)生重大影響。

“隱式認知跳躍”的一個例子

假設(shè)我們想為SQL分析師建模。我們將首先采訪他們，并問他們幾個問題，例如：

• 當要求你分析一個業(yè)務(wù)問題時，你會怎么做?
• 你如何確保你的解決方案滿足要求?
• <向受訪者反映我們所理解的過程>
• 這能準確地捕捉到你所理解的過程嗎<獲得更正>
• 等等……

一個分析師所經(jīng)歷的認知過程及對其進行建模的舉例

隱式認知過程呈現(xiàn)出多種形態(tài)和形式;一個典型的例子是“特定領(lǐng)域的定義”。例如，“暢銷書”可能是我們領(lǐng)域?qū)＜业囊粋€突出術(shù)語，而不是其他所有人都了解的術(shù)語。

在我們的SQL分析示例中擴展隱式認知過程

最終，我們將獲得一個完整的SOP“配方”，讓我們能夠模仿我們表現(xiàn)最佳的分析師。

在繪制這些復(fù)雜的過程時，將其可視化為圖形可能會有所幫助。當整個過程微妙且涉及許多步驟、條件和拆分時，這尤其有用。

圖形形式顯示的“SQL Analyst SOP”包括所有必需的技術(shù)步驟

我們的最終解決方案應(yīng)該模仿SOP中定義的步驟。在此階段，請盡量忽略最終的實現(xiàn)部分。稍后，你可以在整個解決方案中的一個或多個步驟/鏈上實現(xiàn)它。

與其他原則不同，認知建模(SOP寫作)是唯一獨立的過程。強烈建議你在編寫代碼之前先對流程進行建模。話雖如此，在實施它的同時，你可能會根據(jù)你獲得的新見解或理解來加以改變。

現(xiàn)在，我們了解了創(chuàng)建一個定義良好的SOP的重要性，該SOP指導(dǎo)我們對問題的業(yè)務(wù)理解，讓我們探索如何使用各種工程技術(shù)有效地實施它。

2.工程技術(shù)

工程技術(shù)可幫助你實際實施SOP并充分利用模型。在考慮工程技術(shù)原則時，我們應(yīng)該考慮工具箱中的哪些工具(技術(shù))可以幫助我們實施和塑造我們的SOP，并幫助模型實現(xiàn)與我們進行良好的溝通。

工程技術(shù)原理示意圖

值得注意的是，一些工程技術(shù)僅在提示層中實現(xiàn)，而許多技術(shù)需要軟件層才能有效，還有些技術(shù)需要將兩層結(jié)合在一起。

工程技術(shù)層架構(gòu)

雖然幾乎每天工程技術(shù)人員都會發(fā)現(xiàn)與發(fā)明一些細微差別和技術(shù)改進，在此我將介紹兩種主要技術(shù)：工作流/鏈和代理。

（1）LLM原生架構(gòu)(又名“流工程”或“鏈”)

LLM原生架構(gòu)描述了應(yīng)用程序為生成任務(wù)結(jié)果而經(jīng)歷的代理執(zhí)行流程。

我們流程中的每一步都是一個獨立的過程，必須發(fā)生該過程才能完成我們的任務(wù)。其中，一些步驟將會以簡單的確定性代碼方式執(zhí)行;而對于另外某些步驟，我們會使用LLM(代理)方式來執(zhí)行。

為此，我們可以進一步反思我們繪制的標準操作程序(SOP)并思考如下問題：

• 我們應(yīng)該將哪些SOP步驟分配到同一代理上?作為不同的代理，我們應(yīng)該采取哪些步驟?
• 哪些SOP步驟應(yīng)該以獨立的方式執(zhí)行(但它們可能會收到之前步驟的信息)?
• 在確定性代碼執(zhí)行方式中，我們可以執(zhí)行哪些SOP步驟?
• 等等……

一個基于給定SOP的“維基百科作者”應(yīng)用的LLM原生架構(gòu)示例

在分析我們前面所給出的架構(gòu)/圖的下一個步驟之前，我們首先定義此步驟的關(guān)鍵屬性：

輸入和輸出——這一步驟的特征是什么?在我們采取行動之前需要準備些什么?(這也可以作為代理的輸出格式)

• 質(zhì)量保證——是什么讓響應(yīng)“足夠好”?是否有需要人為干預(yù)的情況?我們可以配置哪些類型的斷言?
• 自主水平——我們需要對結(jié)果的質(zhì)量進行多少控制?這個階段可以處理哪些用例?換句話說，在這一點上，我們能在多大程度上相信模型能夠獨立工作?
• 觸發(fā)器——下一步驟是什么?下一步驟的定義是什么?
• 非功能性——所需的延遲是多少?我們需要特殊的業(yè)務(wù)監(jiān)控嗎?
• 故障轉(zhuǎn)移控制——可能發(fā)生哪些類型的故障(系統(tǒng)性和代理性)?我們的退路是什么?
• 狀態(tài)管理——我們需要一個特殊的狀態(tài)管理機制嗎?我們?nèi)绾螜z索/保存狀態(tài)(定義索引鍵)?我們需要持久性存儲嗎?這種狀態(tài)的不同用法是什么(例如緩存、日志記錄等)?
• 等等……

（2）什么是代理?

LLM代理是LLM原生架構(gòu)中的一個獨立組件，其中會涉及到LLM調(diào)用。

這里給出的僅是LLM用法的一個實例，其中的提示將包含上下文內(nèi)容。并非所有代理都是同樣的執(zhí)行方式——有些會借助現(xiàn)成的“工具”執(zhí)行，有些則不會，還有些可能在流程中“只使用一次”，而另一些則可能攜帶之前的輸入和輸出信息被遞歸調(diào)用或多次調(diào)用。

借助現(xiàn)成“工具”執(zhí)行的代理

一些LLM代理可以使用現(xiàn)成的“工具”，這些工具其實是一些用于計算或網(wǎng)絡(luò)搜索等任務(wù)的預(yù)定義函數(shù)。代理輸出指令，這些指令指定應(yīng)用程序執(zhí)行的工具和輸入數(shù)據(jù)，并將最終執(zhí)行結(jié)果返回給代理。

為了理解這個概念，讓我們來看一個簡單的工具調(diào)用的提示實現(xiàn)。這種實現(xiàn)方案甚至可以用于未經(jīng)過原生訓(xùn)練的調(diào)用工具的模型：

You are an assistant with access to these tools:
- calculate(expression: str) -> str - calculate a mathematical 
expression
- search(query: str) -> str - search for an item in the inventory
Given an input, Respond with a YAML with keys: `func`(str) and 
`arguments`(map) or `message`(str).Given input

區(qū)分具有工具的代理(因此是自主代理)和其輸出可以導(dǎo)致執(zhí)行某一動作的代理是非常重要的。

“自主代理是能夠生成完成任務(wù)的方法的代理?！?/p>

自主代理有權(quán)決定是否采取行動以及采取何種行動。相比之下，一個(非自主)代理只是“處理”我們的請求(例如分類)。基于這個過程，我們的確定性代碼執(zhí)行一個動作，而模型對此沒有控制權(quán)。

自主代理與觸發(fā)動作的代理比較

隨著我們增加代理在規(guī)劃和執(zhí)行任務(wù)方面的自主權(quán)，我們增強了其決策能力，但可能會降低對輸出質(zhì)量的控制。雖然這看起來像是一個讓它更“智能”或“先進”的神奇解決方案，但這也伴隨著會失去對質(zhì)量控制的代價。

自主代理的利弊權(quán)衡

值得注意的是，要警惕完全自主代理的誘惑。雖然它們的架構(gòu)可能看起來很吸引人，也更簡單，但將其用于一切(或作為最初的PoC)可能會對“實際生產(chǎn)”情況產(chǎn)生很大的欺騙作用。另外，自主代理難以調(diào)試且不可預(yù)測(響應(yīng)質(zhì)量不穩(wěn)定)，這使得它們無法用于生產(chǎn)。

目前，代理(沒有隱含的指導(dǎo))還不太擅長規(guī)劃復(fù)雜的流程，通常會跳過關(guān)鍵步驟。例如，在我們的“維基百科作者”應(yīng)用示例中，它們只會開始寫作，跳過系統(tǒng)化的過程。這使得代理(尤其是自主代理)僅與模型一樣好，或者更準確地說，僅與它們相對于你的任務(wù)所訓(xùn)練的數(shù)據(jù)一樣好。

與其讓代理(或一群代理)自由地以端到端方式完成所有事情，不如嘗試將它們的任務(wù)限制在需要這種敏捷性或創(chuàng)造力的流程/SOP的特定區(qū)域。這可以產(chǎn)生更高質(zhì)量的結(jié)果，因為你可以同時享受這兩個世界。

一個很好的例子是AlphaCodium(https://www.codium.ai/blog/alphacodium-state-of-the-art-code-generation-for-code-contests/)：通過將結(jié)構(gòu)化流與不同的代理(包括一個負責以迭代方式編寫和測試代碼的新型代理)相結(jié)合，它們提高了在CodeContest上GPT-4的準確性(pass@5)，其準確率從19%上升到44%。

AlphaSodium的LLM架構(gòu)

雖然工程技術(shù)為實施我們的SOP和優(yōu)化LLM原生應(yīng)用程序奠定了基礎(chǔ)，但我們還必須仔細考慮LLM三角原則的另一個關(guān)鍵組成部分：模型本身。

3.模型

我們選擇的模型是我們項目成功的關(guān)鍵組成部分。在這一方面，選擇使用大型模型(如GPT-4或Claude Opus)可能會產(chǎn)生更好的結(jié)果，但相當昂貴，而較小的模型可能不那么“聰明”，但有助于資金預(yù)算。在思考模型原則這一方面時，我們應(yīng)該著眼于確定我們的約束和目標，以及什么樣的模型可以幫助我們實現(xiàn)它們。

模型原理

“并非所有LLM都是一樣的;因此，請將選定的模型與要完成的任務(wù)相匹配即可?！?/p>

事實上，我們并不總是需要最大的模型;這取決于任務(wù)。為了找到正確的匹配，我們必須有一個實驗過程，并嘗試我們解決方案的多種不同版本。

不妨先讓我們來看一個“缺乏經(jīng)驗的工人”的類比，這將會對作出決定有所幫助。例如，一個擁有許多學(xué)歷的非?！奥斆鳌钡墓と丝赡芎苋菀自谀承┤蝿?wù)中取得成功。盡管如此，他們可能對這份工作有些資歷過高;因此，雇傭一個“更便宜”的候選工人將更具成本效益。

在考慮模型時，我們應(yīng)該根據(jù)我們愿意采取的權(quán)衡來定義和比較解決方案：

• 任務(wù)復(fù)雜性——較簡單的任務(wù)(如摘要)更容易用較小的模型完成，而推理通常需要較大的模型。
• 推理基礎(chǔ)設(shè)施——它應(yīng)該在云端還是邊緣設(shè)備上運行?模型大小可能會影響小型手機，但云服務(wù)可以容忍。
• 定價——我們能容忍什么價格?考慮到業(yè)務(wù)影響和預(yù)期使用情況，它是否具有成本效益?
• 延遲——隨著模型變大，延遲也會變大。
• 標記數(shù)據(jù)——我們是否有可以立即使用的數(shù)據(jù)，用未經(jīng)訓(xùn)練的樣本或相關(guān)信息來豐富模型?

在許多情況下，在你擁有“內(nèi)部專業(yè)知識”之前，為經(jīng)驗豐富的員工支付一點額外費用是有幫助的——LLM也是如此。

如果你沒有標定好的數(shù)據(jù)，那么建議你從一個更強大(更大)的模型開始，收集數(shù)據(jù)，然后利用它通過一些小樣本或微調(diào)來增強模型的能力。

（1）微調(diào)模型

在對模型進行微調(diào)之前，你必須考慮幾個方面：

• 隱私——你的數(shù)據(jù)可能包括必須從模型中保留的私人信息。如果你的數(shù)據(jù)包含私人信息，你必須首先匿名處理你的數(shù)據(jù)以避免法律責任。
• 法律、合規(guī)性和數(shù)據(jù)權(quán)利——在訓(xùn)練模型時可能會提出一些法律問題。例如，OpenAI使用條款政策阻止你在沒有OpenAI的情況下使用生成的響應(yīng)來訓(xùn)練模型。另一個典型的例子是遵守GDPR(即《?通用數(shù)據(jù)保護條例》，是?歐盟的一項重要法律，旨在保護歐盟境內(nèi)個人的數(shù)據(jù)隱私和安全)的法律，該法律要求“撤銷權(quán)”，用戶可以要求公司從系統(tǒng)中刪除信息。這引發(fā)了關(guān)于該模型是否應(yīng)該重新訓(xùn)練的法律問題。
• 更新延遲——在訓(xùn)練一個模型時，延遲(或數(shù)據(jù)截止)時間要比預(yù)計高得多。與通過上下文嵌入新信息不同(見下面的“上下文數(shù)據(jù)”一節(jié))——這種方式能夠提供即時延遲。訓(xùn)練模型則是一個漫長的過程，需要大量時間。因此，模型的再訓(xùn)練往往很少被采用。
• 開發(fā)和操作——在持續(xù)評估結(jié)果性能的同時，實施可重復(fù)、可擴展和可監(jiān)控的微調(diào)流程至關(guān)重要。這個復(fù)雜的過程需要持續(xù)的維護。
• 成本——再訓(xùn)練因其復(fù)雜性和每次訓(xùn)練所需的高強度資源(GPU)而被認為是昂貴的。

LLM作為上下文學(xué)習者的能力，以及新模型支持更大的上下文窗口的事實，極大地簡化了我們的實現(xiàn);因此，即使沒有微調(diào)，也能提供出色的結(jié)果。然而，由于微調(diào)的復(fù)雜性，建議將其作為最后手段或完全跳過。

相反，對特定任務(wù)(例如結(jié)構(gòu)化JSON輸出)或特定領(lǐng)域語言的模型進行微調(diào)可能是非常高效的。一個小型的、特定于任務(wù)的模型可能非常有效，并且在推理方面比大型LLM便宜得多。但無論如何，確保明智地選擇你的解決方案，并在升級到LLM訓(xùn)練之前評估所有相關(guān)考慮因素。請牢記：

“即使是最強大的模型也需要相關(guān)且結(jié)構(gòu)良好的上下文數(shù)據(jù)才能發(fā)光?！?/p>

4.上下文數(shù)據(jù)

LLM是上下文情境學(xué)習者。這意味著，通過提供特定任務(wù)的信息，LLM代理可以幫助我們在沒有特殊訓(xùn)練或微調(diào)的情況下執(zhí)行它。這使我們能夠輕松地“講授”新知識或技能。在考慮上下文數(shù)據(jù)原則時，我們應(yīng)該致力于組織和建?？捎脭?shù)據(jù)，以及如何在提示中組合數(shù)據(jù)。

上下文數(shù)據(jù)原則

為了構(gòu)建我們的上下文，我們需要在發(fā)送給LLM的提示中包含相關(guān)的(上下文)信息。歸納來看，我們可以使用兩種上下文：

• 嵌入式上下文——作為提示的一部分提供的嵌入式信息。

You are the helpful assistant of , a at

• 附件上下文——提示開始/結(jié)束時粘合的信息塊列表

Summarize the provided emails while keeping a friendly tone.
---

<email_0>
<email_1>

上下文通常使用“提示模板”來實現(xiàn)(例如jinja2或mustache，或者只是原生格式化文字字符串)。通過這種方式，我們便可以優(yōu)雅地組合它們，同時保持提示信息的精髓：

# Embedded context with an attachment context
prompt = f"""
You are the helpful assistant of {name}. {name} is a {role} at {company}.

Help me write a {tone} response to the attached email.
Always sign your email with:
{signature}

---

{email}
"""

（1）小樣本學(xué)習

小樣本學(xué)習是一種通過示例“教導(dǎo)”LLM而不需要大量微調(diào)的強大方法。在提示中提供一些代表性示例可以指導(dǎo)模型理解所需的格式、風格或任務(wù)。

例如，如果我們希望LLM生成電子郵件回復(fù)，我們可以在提示中包含一些寫得很好的回復(fù)示例。這有助于模型學(xué)習首選的結(jié)構(gòu)和音調(diào)。

我們可以使用不同的例子來幫助模型捕捉不同的極端情況或細微差別，并從中學(xué)習。因此，必須包含各種樣本示例，以涵蓋應(yīng)用程序可能遇到的一系列場景。

隨著應(yīng)用程序的增長，你可以考慮實現(xiàn)“動態(tài)小樣本(https://arxiv.org/abs/1804.09458)”，這涉及以編程方式為每個輸入選擇最相關(guān)的示例。雖然它增加了你的實現(xiàn)方案的復(fù)雜性，但它確保了模型在每種情況下都能得到最合適的指導(dǎo)，從而有助于顯著提高各種任務(wù)的性能，而無需進行昂貴的微調(diào)。

（2）檢索增強生成

檢索增強生成(RAG：https://www.promptingguide.ai/techniques/rag)是一種在生成響應(yīng)之前為其他上下文檢索相關(guān)文檔的技術(shù)。這就像讓LLM快速瀏覽特定的參考資料，以便幫助提供需要的答案一樣。這種技術(shù)可以使響應(yīng)保持最新和真實，而無需重新訓(xùn)練模型。

例如，在開發(fā)支持聊天機器人應(yīng)用程序時，RAG可以提取相關(guān)的維基頁面幫助，以告知LLM相關(guān)的答案。

這種方法通過將反應(yīng)建立在檢索到的事實基礎(chǔ)上，幫助LLM保持最新狀態(tài)并減少虛幻的信息。RAG對于需要更新的或?qū)I(yè)化的知識而無需重新訓(xùn)練整個模型的任務(wù)特別方便。

例如，假設(shè)我們正在為我們的產(chǎn)品構(gòu)建一個支持聊天。在這種情況下，我們可以使用RAG從我們的維基幫助中檢索相關(guān)文檔，然后將其提供給LLM代理，并要求其根據(jù)問題撰寫答案并提供文檔。

在實施RAG時，有三個關(guān)鍵部分需要注意：

• 檢索機制——雖然RAG的傳統(tǒng)實現(xiàn)涉及使用向量相似性搜索檢索相關(guān)文檔，但有時使用基于關(guān)鍵字的搜索(如BM-25)等更簡單的方法會更好或更便宜。
• 索引數(shù)據(jù)結(jié)構(gòu)——在沒有預(yù)處理的情況下，對整個文檔進行索引，可能會限制檢索過程的有效性。有時，我們希望添加數(shù)據(jù)準備步驟，例如根據(jù)文檔準備問題和答案列表。
• 元數(shù)據(jù)——存儲相關(guān)元數(shù)據(jù)可以更有效地引用和過濾信息(例如，將維基頁面縮小到僅與用戶特定產(chǎn)品查詢相關(guān)的頁面)。這個額外的數(shù)據(jù)層簡化了檢索過程。

（3）提供相關(guān)背景

與你的代理相關(guān)的上下文信息可能會有所不同。雖然這似乎是有益的，但為模型(就好似一位“非技術(shù)工人”)提供過多的信息可能會讓它不知所措。理論上，這會導(dǎo)致模型學(xué)習不相關(guān)的信息(或令牌連接)，這可能會導(dǎo)致混淆和幻覺(https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence))。

例如，當模型Gemini 1.5作為LLM發(fā)布并投入使用時，可以處理多達1000萬個符號，這導(dǎo)致一些從業(yè)者質(zhì)疑上下文是否仍然是一個問題。雖然這是一項了不起的成就，特別是對于某些特定場景應(yīng)用(如與PDF聊天)，但它仍然有限，尤其是在推理各種文檔時。

因此，濃縮一下提示信息并僅向LLM代理提供相關(guān)的信息至關(guān)重要。這降低了模型在無關(guān)符號上的處理能力，提高了質(zhì)量，優(yōu)化了延遲，并降低了成本。

當然，已經(jīng)有許多技巧可以提高所提供上下文的相關(guān)性，其中大多數(shù)與你如何存儲和編目數(shù)據(jù)有關(guān)。

例如，對于RAG應(yīng)用程序來說，添加一個數(shù)據(jù)準備來格式化一下你存儲的信息是很方便的(例如，基于文檔的問題和答案，然后只向LLM代理提供答案;這樣，代理就可以獲得一個總結(jié)和更短的上下文)，并在檢索到的文檔上使用重新排序算法來優(yōu)化結(jié)果。

“數(shù)據(jù)為LLM原生應(yīng)用程序的引擎提供動力。因此，上下文數(shù)據(jù)的有效性戰(zhàn)略設(shè)計會有助于更高效地釋放它們的真正潛力?！?/p>

結(jié)論

LLM三角原則提供了一種結(jié)構(gòu)化的方法來開發(fā)高質(zhì)量的LLM原生應(yīng)用程序，它有助于縮短應(yīng)用LLM的巨大潛力和現(xiàn)實世界實施面臨的挑戰(zhàn)之間的差距。開發(fā)人員可以通過專注于3+1關(guān)鍵原則(模型、工程技術(shù)和上下文數(shù)據(jù))來創(chuàng)建更可靠、更有效的LLM驅(qū)動的解決方案，所有這些原則都以明確的SOP為指導(dǎo)。

LLM三角原則

關(guān)鍵點歸納

從一個明確的SOP開始：模擬你的專家的認知過程，為你的LLM應(yīng)用程序創(chuàng)建一個循序漸進的指南。在思考其他原則時，將其作為根本指南。

• 選擇正確的模型：在能力和成本之間取得平衡，并考慮從較大的模型開始，然后再考慮轉(zhuǎn)向較小、微調(diào)的模型。
• 利用工程技術(shù)：實施LLM原生架構(gòu)，并戰(zhàn)略性地使用代理來優(yōu)化性能和保持控制。嘗試不同的提示技巧，為你的應(yīng)用場景找到最有效的提示。
• 提供相關(guān)上下文：在適當?shù)那闆r下，在上下文學(xué)習中使用，包括RAG技術(shù)，但要警惕切莫讓不相關(guān)的信息淹沒了模型。
• 迭代和實驗：找到正確的解決方案通常需要不斷地測試和改進你的工作。為此，我建議你閱讀和實施文章《構(gòu)建LLM應(yīng)用程序：清晰的步驟指南》(https://towardsdatascience.com/building-llm-apps-a-clear-step-by-step-guide-1fe1e6ef60fd)”中強調(diào)的有關(guān)技巧，以獲得詳細的LLM原生開發(fā)過程指南。

通過應(yīng)用LLM三角原則，開發(fā)公司就可以超越簡單的概念驗證，開發(fā)出強大的、可用于實戰(zhàn)型的LLM應(yīng)用程序，從而真正利用這項變革性技術(shù)的力量。

譯者介紹

朱先忠，51CTO社區(qū)編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。

原文標題：The LLM Triangle Principles to Architect Reliable AI Apps，作者：Almog Baku

鏈接：https://towardsdatascience.com/the-llm-triangle-principles-to-architect-reliable-ai-apps-d3753dd8542e。