原文：Ultimate ChatGPT Handbook for Enterprises

譯者：飛龍

協(xié)議：CC BY-NC-SA 4.0

第七章：GPT 項(xiàng)目的掌握

介紹

在前面的章節(jié)中，我們已經(jīng)踏上了一段啟發(fā)之旅，探索了 GPT 模型的基礎(chǔ)、它們的 AI 能力和潛在應(yīng)用，以及它們?cè)诟淖兩虡I(yè)格局中的作用。我們還探討了一系列解決方案架構(gòu)的設(shè)計(jì)模式、有效的提示和基于提示的助手。當(dāng)我們接近第七章時(shí)，是時(shí)候深入探討企業(yè)環(huán)境中 GPT 部署項(xiàng)目的方法和技術(shù)了。

我們揭示了對(duì)這類項(xiàng)目成功的最佳實(shí)踐，從最初的項(xiàng)目準(zhǔn)備、精確的用例定義、全面的解決方案設(shè)計(jì)，到準(zhǔn)確的提示工程。我們還深入探討了解決方案實(shí)施、輸出驗(yàn)證和迭代改進(jìn)的關(guān)鍵階段的技術(shù)，使得系統(tǒng)地融入反饋成為可能。每個(gè)子章節(jié)都深入探討了這些方面，提供了實(shí)用的見解和可操作的策略，可以應(yīng)用于現(xiàn)實(shí)世界的 GPT 項(xiàng)目。

隨著本章的結(jié)束，我們還涵蓋了兩個(gè)重要的方面，根據(jù)自動(dòng)化程度量身定制的變革管理以及通過(guò) GPT-for-GPT 方法進(jìn)行創(chuàng)新項(xiàng)目加速。

【結(jié)構(gòu)】

在本章中，將涵蓋以下主題：

• 項(xiàng)目準(zhǔn)備

• GPT 解決方案開發(fā)的生命周期

• 定義用例

• 設(shè)計(jì)解決方案

• 提示工程

• 實(shí)施 GPT 解決方案

• 驗(yàn)證解決方案輸出

• 迭代改進(jìn)

• 變革管理

• 通過(guò) ChatGPT 加速 GPT 項(xiàng)目

【項(xiàng)目準(zhǔn)備】

著手進(jìn)行 GPT 項(xiàng)目涉及到技術(shù)、運(yùn)營(yíng)和人為因素的混合，這些因素需要在實(shí)際項(xiàng)目開始之前解決。因此，項(xiàng)目準(zhǔn)備階段為整個(gè)項(xiàng)目奠定了基礎(chǔ)，涉及從基礎(chǔ)設(shè)施設(shè)置、安全策略制定到員工培訓(xùn)和運(yùn)營(yíng)反饋啟用的活動(dòng)。本章旨在指導(dǎo)您了解每個(gè)準(zhǔn)備活動(dòng)的細(xì)節(jié)，從而實(shí)現(xiàn)對(duì) GPT 項(xiàng)目成功啟動(dòng)的健壯和系統(tǒng)化的方法[1]。

【基礎(chǔ)設(shè)施設(shè)置】

啟動(dòng) GPT 項(xiàng)目需要圍繞基礎(chǔ)設(shè)施設(shè)置和潛在模型微調(diào)進(jìn)行細(xì)致的規(guī)劃。為開發(fā)、測(cè)試和生產(chǎn)建立不同的環(huán)境是第一個(gè)關(guān)鍵步驟。這個(gè)過(guò)程通常使用單獨(dú)的 Azure OpenAI[2]或 ChatGPT Enterprise[3]實(shí)例，每個(gè)實(shí)例都針對(duì)其環(huán)境的特定需求進(jìn)行了定制。適當(dāng)?shù)呐渲煤蛯?duì)這些實(shí)例的持續(xù)維護(hù)對(duì)項(xiàng)目的順利執(zhí)行至關(guān)重要。

【安全策略制定】

在進(jìn)行 GPT 項(xiàng)目時(shí)，建立健壯的安全策略和指南至關(guān)重要，因?yàn)槠髽I(yè)數(shù)據(jù)和文件的巨大依賴。以下是使用 Azure OpenAI 實(shí)例進(jìn)行 GPT 項(xiàng)目的推薦安全措施的示例：

• 通過(guò) Azure OpenAI 端點(diǎn)進(jìn)行私有數(shù)據(jù)傳輸

• 政策建議：為所有 Azure 資源和 OpenAI 服務(wù)之間的數(shù)據(jù)傳輸實(shí)施 Azure OpenAI 私有端點(diǎn)。這將確保數(shù)據(jù)不會(huì)暴露在公共互聯(lián)網(wǎng)上。

• 好處：這種方法保證了一個(gè)加固的連接，大大減少了潛在的安全威脅。此外，它提供了一個(gè)高效的通信渠道，最小化了傳統(tǒng)公共端點(diǎn)所帶來(lái)的風(fēng)險(xiǎn)。

• 基于角色的訪問(wèn)控制（RBAC）

• 政策建議：在公司內(nèi)部定義特定角色（例如管理員、開發(fā)人員、分析員），并根據(jù)這些角色使用 RBAC 為 Azure OpenAI 服務(wù)分配權(quán)限。

• 好處：這確保用戶只能訪問(wèn)他們需要的功能和數(shù)據(jù)，最小化數(shù)據(jù)泄露或?yàn)E用的風(fēng)險(xiǎn)。它還通過(guò)清晰定義服務(wù)內(nèi)誰(shuí)做了什么來(lái)簡(jiǎn)化審計(jì)追蹤。

• 特定內(nèi)容過(guò)濾

• 政策建議：實(shí)施額外的內(nèi)容過(guò)濾機(jī)制來(lái)審查和調(diào)節(jié)用戶請(qǐng)求和響應(yīng)的內(nèi)容。明確定義什么構(gòu)成可接受的內(nèi)容，并建立自動(dòng)系統(tǒng)來(lái)標(biāo)記或阻止違反這些準(zhǔn)則的內(nèi)容。

• 好處：這促進(jìn)了對(duì) AI 模型的負(fù)責(zé)任使用，確保輸出符合公司的價(jià)值觀和標(biāo)準(zhǔn)。它還有助于防止生成或處理不當(dāng)或有害的內(nèi)容。

• GPT 模型使用的數(shù)據(jù)分類和批準(zhǔn)

• 政策建議：將與 Azure OpenAI 服務(wù)一起使用的所有數(shù)據(jù)分類為各種安全類別，例如公共、內(nèi)部、機(jī)密、嚴(yán)格機(jī)密。每個(gè)安全類別應(yīng)基于數(shù)據(jù)的敏感性和機(jī)密性進(jìn)行定義。只有經(jīng)批準(zhǔn)的 OpenAI 服務(wù)安全類別的數(shù)據(jù)才能由 GPT 模型處理。

• 好處：這種方法確保敏感數(shù)據(jù)得到適當(dāng)處理，并減少了意外曝光的風(fēng)險(xiǎn)，符合內(nèi)部數(shù)據(jù)處理標(biāo)準(zhǔn)。

• 個(gè)人可識(shí)別信息（PII）的匿名化

• 政策建議：在 GPT 模型處理任何個(gè)人可識(shí)別信息（PII）之前，應(yīng)對(duì)其進(jìn)行匿名化，以刪除或模糊任何可能識(shí)別個(gè)人的數(shù)據(jù)。

• 好處：對(duì) PII 進(jìn)行匿名化確保了個(gè)人信息的隱私和安全，降低了數(shù)據(jù)泄露的風(fēng)險(xiǎn)，并確保符合數(shù)據(jù)保護(hù)法規(guī)。

• API 調(diào)用限制

• 政策建議：禁止未經(jīng)注冊(cè)或未經(jīng)授權(quán)的來(lái)源直接調(diào)用 OpenAI 云 API。經(jīng)批準(zhǔn)的應(yīng)用程序必須通過(guò)預(yù)定義的代理或網(wǎng)關(guān)路由請(qǐng)求。

• 好處：這將保護(hù)系統(tǒng)免受不必要的和潛在有害的外部交互。通過(guò)網(wǎng)關(guān)路由，公司可以實(shí)施日志記錄、監(jiān)控和速率限制，以實(shí)現(xiàn)更好的控制。

• 開源工具使用

• 政策建議：任何與 OpenAI-Cloud-API 接口的開源工具在部署前應(yīng)經(jīng)過(guò)安全審查并獲得批準(zhǔn)。

• 好處：這確保第三方工具不會(huì)給系統(tǒng)引入漏洞，并且它們保持兼容性和穩(wěn)定性標(biāo)準(zhǔn)。

• 公開曝光限制

• 政策建議：限制 Azure OpenAI 服務(wù)的公開曝光，特別是在面向消費(fèi)者的平臺(tái)上。實(shí)施網(wǎng)絡(luò)級(jí)別的控制和應(yīng)用程序防火墻以防止未經(jīng)授權(quán)的訪問(wèn)。

• 好處：這減少了來(lái)自公共網(wǎng)絡(luò)的潛在威脅，并確保 Azure OpenAI 服務(wù)不被濫用或受到不必要的負(fù)載。

• 安全優(yōu)先的整合

• 政策建議：禁止將 GPT 模型與可能導(dǎo)致危及人類生命的現(xiàn)實(shí)后果的工具或系統(tǒng)集成（例如醫(yī)療設(shè)備、車輛控制系統(tǒng)）。

• 好處：這確保了 GPT 模型的潛在不準(zhǔn)確性或不可預(yù)測(cè)性不會(huì)導(dǎo)致身體傷害或危險(xiǎn)情況。

在 GPT 項(xiàng)目中確保安全至關(guān)重要。上述提供的政策為增強(qiáng)人工智能實(shí)施的安全性和責(zé)任性提供了指導(dǎo)。通過(guò)遵循這些措施，您可以更好地管理潛在風(fēng)險(xiǎn)并促進(jìn)高效的人工智能使用。對(duì)安全性的持續(xù)關(guān)注將使項(xiàng)目和用戶受益。

員工培訓(xùn)和發(fā)展

確保團(tuán)隊(duì)熟練掌握 GPT 模型和相關(guān)流程是成功實(shí)施 GPT 項(xiàng)目的關(guān)鍵步驟。這項(xiàng)任務(wù)強(qiáng)調(diào)全面的培訓(xùn)和發(fā)展舉措，促進(jìn)團(tuán)隊(duì)對(duì)已建立政策、潛在風(fēng)險(xiǎn)和與 GPT 模型相關(guān)的獨(dú)特挑戰(zhàn)的教育。

培訓(xùn)應(yīng)涵蓋以下領(lǐng)域：

• AI 能力框架：提供 CapabilityGPT?的概述，使團(tuán)隊(duì)成員能夠了解 GPT 模型具有的能力范圍。這種基礎(chǔ)知識(shí)可以幫助員工更好地利用這些能力。

• 架構(gòu)模式?：對(duì)團(tuán)隊(duì)進(jìn)行培訓(xùn)，介紹在部署 GPT 模型中適用的各種架構(gòu)模式。這使員工能夠理解并參與與基于 GPT 的應(yīng)用程序設(shè)計(jì)和實(shí)施相關(guān)的決策。

• 提示工程?：為團(tuán)隊(duì)成員提供工程有效提示 GPT 模型的技能，這對(duì)于獲得高質(zhì)量的輸出至關(guān)重要。這種培訓(xùn)可以包括提示模式選擇的指導(dǎo)方針，改進(jìn)提示以獲得更好的結(jié)果，以及要避免的常見陷阱。

• GPT 實(shí)施框架：在選擇適當(dāng)?shù)?GPT 實(shí)施框架之后，組織有針對(duì)性的培訓(xùn)至關(guān)重要。這種培訓(xùn)包括設(shè)置和集成策略、模型管理技術(shù)，以及有關(guān)錯(cuò)誤處理和有效故障排除的見解。目標(biāo)是確保開發(fā)人員深入了解他們選擇的框架，以最大化 GPT 集成的好處。

• 輸出驗(yàn)證精通：確保 GPT 模型的響應(yīng)經(jīng)過(guò)嚴(yán)格驗(yàn)證，確保準(zhǔn)確性、相關(guān)性和道德考慮。全面的培訓(xùn)強(qiáng)調(diào)事實(shí)的正確性、數(shù)據(jù)保護(hù)、相關(guān)性，以及在模型輸出中避免偏見或捏造。

• 變革管理?：理解人類和 GPT 模型在不同任務(wù)中扮演的不同角色至關(guān)重要。培訓(xùn)強(qiáng)調(diào)掌握人類專業(yè)知識(shí)和 GPT 協(xié)助之間的平衡，無(wú)論是完全自動(dòng)化、協(xié)作努力還是僅由人類驅(qū)動(dòng)的任務(wù)。目標(biāo)是利用人類經(jīng)驗(yàn)和 GPT 能力之間的協(xié)同作用，實(shí)現(xiàn)最佳結(jié)果。

運(yùn)營(yíng)反饋啟用

導(dǎo)航 GPT 項(xiàng)目的復(fù)雜性需要一個(gè)精心策劃的反饋結(jié)構(gòu)：

• GPT 輸出中的人類監(jiān)督

• 重要性：GPT 模型可以產(chǎn)生多樣化的輸出，其中一些可能與期望的結(jié)果不一致，或可能帶有意想不到的偏見。來(lái)自學(xué)科和倫理專家的監(jiān)督確保內(nèi)容質(zhì)量、相關(guān)性和倫理對(duì)齊。

• 實(shí)施：促進(jìn)專門的審查會(huì)議，邀請(qǐng)學(xué)科和倫理專家評(píng)估 GPT 的輸出。為他們提供強(qiáng)大的工具和方法，以標(biāo)記知識(shí)和倫理角度需要改進(jìn)的異常、偏離或區(qū)域。

• 培養(yǎng)提示工程文化

• 重要性：GPT 項(xiàng)目的功效與輸入模型的提示質(zhì)量密切相關(guān)。培養(yǎng)強(qiáng)調(diào)提示工程的復(fù)雜性和精通的環(huán)境，顯著提高了 GPT 響應(yīng)的精確性和相關(guān)性。

• 實(shí)施：帶頭發(fā)起深化團(tuán)隊(duì)參與的倡議，使用*第五章，高級(jí) GPT 提示工程技術(shù)中解釋的先進(jìn)提示工程技術(shù)。這可能包括專門討論這些高級(jí)技術(shù)的研討會(huì)，挑戰(zhàn)團(tuán)隊(duì)利用第五章*中的見解進(jìn)行頭腦風(fēng)暴會(huì)議，或旨在利用這些新發(fā)現(xiàn)技術(shù)進(jìn)行創(chuàng)新的團(tuán)隊(duì)驅(qū)動(dòng)挑戰(zhàn)。

• 超越輸出的 GPT 特定反饋收集

• 重要性：雖然 GPT 輸出提供了一個(gè)反饋維度，但理解用戶體驗(yàn)、系統(tǒng)性能和適應(yīng)性同樣至關(guān)重要。這些方面給出了對(duì) GPT 模型有效性的全面視圖。

• 實(shí)施：設(shè)計(jì)機(jī)制，不僅僅是在生成的內(nèi)容上征求反饋，還要考慮模型的反應(yīng)時(shí)間、對(duì)一系列提示的適應(yīng)能力以及整體用戶體驗(yàn)等參數(shù)。這種全面的反饋方法確保了 GPT 生態(tài)系統(tǒng)的全面改進(jìn)。

GPT 解決方案開發(fā)的生命周期

GPT 解決方案開發(fā)周期是一個(gè)結(jié)構(gòu)化和迭代的過(guò)程，用于實(shí)施 GPT 項(xiàng)目。如圖 7.1所示，該周期提供了一種系統(tǒng)化的方法，確保每個(gè)階段的清晰度和效率。

圖 7.1: GPT 解決方案開發(fā)周期

它始于定義用例。這個(gè)初始階段涉及確定項(xiàng)目的具體要求和目標(biāo)，以指導(dǎo)所有后續(xù)步驟。

隨后，項(xiàng)目進(jìn)入解決方案設(shè)計(jì)階段，包括三個(gè)主要任務(wù)：功能解決方案設(shè)計(jì)，概述所需的行為；解決方案架構(gòu)設(shè)計(jì)，確保系統(tǒng)健壯和可擴(kuò)展；用戶體驗(yàn)設(shè)計(jì)，針對(duì)最終用戶和解決方案之間的互動(dòng)。

接下來(lái)是提示工程階段。在這里，為解決方案設(shè)計(jì)中確定的每個(gè) GPT 任務(wù)制定具體的提示，利用前兩章介紹的提示技術(shù)。

準(zhǔn)備好提示后，周期進(jìn)入實(shí)施階段，在這個(gè)階段，通過(guò)創(chuàng)建所需的代碼以及工程提示來(lái)開發(fā)解決方案。

然后開始解決方案輸出驗(yàn)證階段，在這個(gè)階段，對(duì) GPT 模型的輸出進(jìn)行徹底審查，以確保其符合所需的準(zhǔn)確性和相關(guān)性標(biāo)準(zhǔn)。

從這個(gè)驗(yàn)證中獲得的反饋和見解導(dǎo)致了反饋驅(qū)動(dòng)的迭代階段。這是項(xiàng)目根據(jù)收到的反饋進(jìn)行改進(jìn)，進(jìn)行必要的調(diào)整以改善結(jié)果的階段。

GPT 解決方案開發(fā)周期持續(xù)進(jìn)行重復(fù)迭代，直到達(dá)到所需的準(zhǔn)確性和效率水平。

值得注意的是，上述周期是基于常用的提示工程方法，不涉及更耗時(shí)的模型微調(diào)過(guò)程?。

在接下來(lái)的子章節(jié)中，將更詳細(xì)地探討該周期的每個(gè)階段，提供見解和最佳實(shí)踐，以幫助成功開發(fā) GPT 項(xiàng)目。

定義用例

用例定義作為業(yè)務(wù)藍(lán)圖，指導(dǎo)解決方案設(shè)計(jì)、提示工程、實(shí)施和驗(yàn)證階段的 GPT 項(xiàng)目。它確保了清晰的范圍、指定的數(shù)據(jù)需求和對(duì)齊的利益相關(guān)者

圖 7.2: 定義用例

在下一節(jié)中，我們提供了一個(gè)用例模板，為您的 GPT 項(xiàng)目需求提供了一個(gè)框架來(lái)進(jìn)行文檔化。它旨在解決您 GPT 用例的所有關(guān)鍵方面，確保您的項(xiàng)目有堅(jiān)實(shí)的基礎(chǔ)和明確的方向。

• 標(biāo)題：簡(jiǎn)潔、描述性的標(biāo)題，準(zhǔn)確概括用例。

• 標(biāo)識(shí)符：用于便于參考和管理項(xiàng)目文檔的唯一標(biāo)識(shí)符。

• 目標(biāo)/目標(biāo)：該用例的具體目標(biāo)，詳細(xì)說(shuō)明 GPT 模型預(yù)期實(shí)現(xiàn)的價(jià)值和對(duì)項(xiàng)目的價(jià)值。

• 利益相關(guān)者/角色：確定所有將與 GPT 模型互動(dòng)的用戶或系統(tǒng)，描述他們的角色或互動(dòng)。

• 前提條件： 指定在使用案例啟動(dòng)之前必須滿足的條件，例如數(shù)據(jù)集、資源或任何必要的配置的可用性。

• 功能： 描述不同利益相關(guān)者視角下預(yù)期的輸入和輸出。

• 輸入： 模型需要什么來(lái)執(zhí)行其任務(wù)？這可能是文本數(shù)據(jù)、特定提示或其他類型的信息。

• 輸出： 模型的預(yù)期結(jié)果是什么？這可能是文本輸出、分析結(jié)果等。

• 后置條件： 在成功執(zhí)行使用案例后應(yīng)達(dá)到的狀態(tài)或條件。

• 性能要求： 定義 GPT 模型應(yīng)滿足的任何特定性能標(biāo)準(zhǔn)，如響應(yīng)時(shí)間、準(zhǔn)確性和吞吐量。

• 數(shù)據(jù)要求： 詳細(xì)說(shuō)明此使用案例所需的數(shù)據(jù)，包括用于提示 GPT 模型的演示。

• 痛點(diǎn)： 預(yù)期 GPT 模型應(yīng)該解決或緩解的利益相關(guān)者特定挑戰(zhàn)或問(wèn)題的詳細(xì)說(shuō)明。

• 利益： 描述使用案例對(duì)每個(gè)確定的利益相關(guān)者的預(yù)期利益。這可能包括效率、準(zhǔn)確性、用戶參與度、成本節(jié)約等方面的改進(jìn)。

作為這個(gè)模板在實(shí)際中的示例，讓我們看一個(gè)涉及公用事業(yè)公司呼叫中心的真實(shí)案例。這將幫助您了解模板如何填寫，以及如何指導(dǎo) GPT 解決方案的開發(fā)。

• 標(biāo)題： 公用事業(yè)公司呼叫中心電子郵件自動(dòng)化

• 標(biāo)識(shí)符： CC-EA-UC-001

• 目標(biāo)/目標(biāo)： 自動(dòng)處理和理解與合同調(diào)整、發(fā)票查詢、服務(wù)投訴等相關(guān)的公用事業(yè)公司呼叫中心的傳入客戶電子郵件，從而減少響應(yīng)時(shí)間并提高客戶服務(wù)效率。

• 利益相關(guān)者/角色

• 呼叫中心代表：與 GPT 模型互動(dòng)，創(chuàng)建客戶咨詢摘要，分析客戶意圖，并提供電子郵件回復(fù)建議。

• 后勤辦公室職員：使用 GPT 模型快速分析電子郵件歷史記錄，理解情境、客戶意圖、回復(fù)質(zhì)量以及從這些互動(dòng)中實(shí)現(xiàn)的客戶滿意度水平。

• 呼叫中心主管：監(jiān)控整體客戶滿意度和建議電子郵件回復(fù)的接受率等關(guān)鍵績(jī)效指標(biāo)（KPI）。

• 前提條件

• GPT 模型已經(jīng)在各種客戶服務(wù)互動(dòng)和與公用事業(yè)行業(yè)相關(guān)的文本上得到了適當(dāng)?shù)念A(yù)訓(xùn)練。

• 為了演示目的，準(zhǔn)許訪問(wèn)一些歷史電子郵件樣本。

• 功能

• 呼叫中心代表

• 輸入：傳入客戶電子郵件。

• 流程： GPT 模型閱讀電子郵件，創(chuàng)建客戶咨詢摘要，并分析客戶意圖。

• 輸出：基于查詢的情境感知摘要、推斷意圖和建議的回復(fù)文本。

• 后勤辦公室職員

• 輸入：電子郵件歷史記錄。

• 流程：GPT 模型分析電子郵件歷史記錄，理解情境、客戶意圖和以前回復(fù)的質(zhì)量。

• 輸出：從電子郵件歷史中的情境洞察，從過(guò)去互動(dòng)中推斷的意圖，以及從過(guò)去回復(fù)中實(shí)現(xiàn)的客戶滿意度水平的理解。

• 呼叫中心主管

• 輸入：客戶滿意度、回復(fù)接受率和其他相關(guān)關(guān)鍵績(jī)效指標(biāo)的數(shù)據(jù)。

• 流程：監(jiān)控和評(píng)估 KPI，特別是與 GPT 模型建議的效果和效率相關(guān)的 KPI。

• 輸出：對(duì)整體客戶滿意度、建議電子郵件回復(fù)的接受率以及潛在改進(jìn)領(lǐng)域的洞察。

• 后置條件

• 呼叫中心代表與 GPT 模型互動(dòng)后，客戶查詢的簡(jiǎn)明摘要可用，客戶意圖明確，并提供上下文相關(guān)的響應(yīng)建議。

• 后勤辦公室職員利用 GPT 模型，將清楚了解電子郵件歷史、上下文和客戶意圖。

• 呼叫中心主管將有必要的數(shù)據(jù)來(lái)監(jiān)控與電子郵件響應(yīng)和客戶滿意度相關(guān)的關(guān)鍵績(jī)效指標(biāo)（KPI）。

• 性能需求：

• GPT 模型必須能夠在幾秒內(nèi)處理和理解電子郵件，以提供實(shí)時(shí)建議。

• 模型應(yīng)保持至少 85%的準(zhǔn)確性水平，以確保建議響應(yīng)的相關(guān)性和上下文。

• 數(shù)據(jù)需求：

• 一些演示來(lái)自過(guò)去的實(shí)際公用事業(yè)客戶服務(wù)互動(dòng)。

• 獲取傳入客戶電子郵件、過(guò)去的電子郵件歷史和相關(guān)的交易系統(tǒng)數(shù)據(jù)，以供模型處理并提供響應(yīng)建議。

• 痛點(diǎn)：

• 呼叫中心代表

• 花費(fèi)過(guò)多時(shí)間解釋每封客戶電子郵件背后的意圖和上下文。

• 電子郵件響應(yīng)的不一致性導(dǎo)致潛在的誤解。

• 來(lái)自高電子郵件量的壓力，導(dǎo)致響應(yīng)時(shí)間延長(zhǎng)。

• 后勤辦公室職員

• 難以快速檢索和解釋歷史電子郵件數(shù)據(jù)，以了解當(dāng)前的響應(yīng)。

• 難以評(píng)估過(guò)去響應(yīng)的質(zhì)量和了解客戶滿意度。

• 對(duì)重復(fù)客戶關(guān)注或互動(dòng)中經(jīng)常出現(xiàn)的問(wèn)題的了解有限。

• 呼叫中心主管

• 缺乏可量化的指標(biāo)來(lái)評(píng)估整體客戶滿意度。

• 難以識(shí)別響應(yīng)接受或拒絕的模式。

• 難以確保電子郵件溝通中的一致質(zhì)量和效率。

• 好處

• 呼叫中心代表

• 高效地理解客戶查詢，并獲得清晰、上下文感知的響應(yīng)建議。

• 改善電子郵件響應(yīng)的一致性，減少誤解。

• 減少每封電子郵件的處理時(shí)間，實(shí)現(xiàn)對(duì)高電子郵件量的更好管理。

• 后勤辦公室職員

• 更快、更全面地分析電子郵件歷史，增強(qiáng)上下文和響應(yīng)的相關(guān)性。

• 清晰了解過(guò)去響應(yīng)的質(zhì)量，并更好地評(píng)估客戶滿意度。

• 增強(qiáng)發(fā)現(xiàn)和解決重復(fù)客戶關(guān)注或問(wèn)題的能力。

• 呼叫中心主管

• 獲取清晰的關(guān)鍵績(jī)效指標(biāo)，以更好地了解整體客戶滿意度和響應(yīng)效果。

• 了解響應(yīng)接受模式，有助于完善溝通策略。

• 確保電子郵件互動(dòng)中的一致質(zhì)量和效率，促進(jìn)更強(qiáng)的品牌聲譽(yù)。

設(shè)計(jì)解決方案

解決方案設(shè)計(jì)階段分為三個(gè)主要任務(wù)：功能解決方案設(shè)計(jì)、解決方案架構(gòu)設(shè)計(jì)和用戶體驗(yàn)設(shè)計(jì)。每個(gè)任務(wù)在以下各節(jié)中都有詳細(xì)描述。

**圖 7.3：**設(shè)計(jì)解決方案

功能解決方案設(shè)計(jì)

我們區(qū)分了三種類型的 AI 解決方案及其相應(yīng)的設(shè)計(jì)步驟（見圖 7.4）：

**圖 7.4：**功能解決方案設(shè)計(jì)

• 面向過(guò)程的 AI 解決方案旨在處理完全指定的結(jié)構(gòu)化任務(wù)，需要依次應(yīng)用多個(gè) AI 能力1?。與 GPT 模型的互動(dòng)基于用戶提供的指令提示11。設(shè)計(jì)步驟包括：

1. 選擇 AI 能力：確定并匹配與用例相關(guān)的 AI 能力。

2. 群體 AI 能力：將能力組織成邏輯序列，形成連貫的子流程。

3. 設(shè)計(jì)前/后處理：整合任務(wù)，以完善和豐富用戶輸入，并驗(yàn)證和可視化 GPT 模型的輸出。

• 基于分析的 AI 解決方案旨在從各種不同數(shù)據(jù)中提取全面的見解。迭代查詢提示12用作與 GPT 模型互動(dòng)，以利用其先進(jìn)的推理能力。設(shè)計(jì)過(guò)程如下：

1. 設(shè)計(jì) AI 查詢：選擇查詢類型，如信息查詢或預(yù)測(cè)，并指定響應(yīng)的理由要求。

2. 描述證據(jù)：確定支持查詢所需的事實(shí)、情境和背景證據(jù)。

3. 設(shè)計(jì)推理規(guī)則：建立指導(dǎo) GPT 模型思維鏈的分類和模糊邏輯規(guī)則。

• 多代理 AI 解決方案在需要專門的 AI 代理進(jìn)行分布式問(wèn)題解決的場(chǎng)景中表現(xiàn)出色，它們相互合作并與用戶合作。多代理提示13允許使用單個(gè) GPT 模型模擬和實(shí)現(xiàn)多代理解決方案。以下是設(shè)計(jì)步驟：

1. 指定目標(biāo)：為代理團(tuán)隊(duì)定義總體目標(biāo)。

2. 設(shè)計(jì) AI 代理：詳細(xì)介紹涉及的代理和其不同的角色和專業(yè)知識(shí)。

3. 設(shè)計(jì)代理合作：建立代理人如何相互交流和合作以實(shí)現(xiàn)指定目標(biāo)。

讓我們演示一個(gè)以流程為導(dǎo)向的 AI 解決方案的設(shè)計(jì)，使用了前一小節(jié)中突出的電子郵件自動(dòng)化用例。我們?cè)O(shè)計(jì)了兩個(gè)不同的 AI 流程來(lái)滿足不同的利益相關(guān)者需求。下面的部分概述了其中的第一個(gè)流程，名為自動(dòng)電子郵件處理，由呼叫中心代表處理（見圖 7.5）：

**圖 7.5：**用于自動(dòng)電子郵件處理的 AI 流程

1. 預(yù)處理：電子郵件準(zhǔn)備

2. 電子郵件獲?。禾幚韽碾娮余]件系統(tǒng)中提取電子郵件及其附件。

3. 轉(zhuǎn)換：將非文本電子郵件附件轉(zhuǎn)換為可處理和分析的文本格式。

4. 知識(shí)庫(kù)豐富：從知識(shí)庫(kù)中豐富電子郵件內(nèi)容，包括相關(guān)的常見問(wèn)題和過(guò)去的解決方案。

5. 客戶數(shù)據(jù)豐富：通過(guò)將后端系統(tǒng)中的客戶特定數(shù)據(jù)納入電子郵件中，進(jìn)一步豐富電子郵件內(nèi)容。

6. 電子郵件分析和分類

7. 分類：分析電子郵件內(nèi)容，并將其分類為以下類別之一：合同調(diào)整、發(fā)票查詢、服務(wù)投訴、停機(jī)報(bào)告、賬戶管理或抄表問(wèn)題。

8. 總結(jié)：對(duì)于特別冗長(zhǎng)或復(fù)雜的電子郵件，特別是那些附件轉(zhuǎn)換為文本的電子郵件，生成簡(jiǎn)潔的摘要以簡(jiǎn)化理解。

9. 因果分析：制定假設(shè)以了解客戶發(fā)送查詢背后的原因或動(dòng)機(jī)。

10. 響應(yīng)候選人的創(chuàng)建和評(píng)分

11. 創(chuàng)建：根據(jù)客戶的查詢、總結(jié)和分析的因果關(guān)系，生成各種潛在的電子郵件回復(fù)。

12. 排名：評(píng)估并根據(jù)預(yù)定義的一組標(biāo)準(zhǔn)對(duì)創(chuàng)建的回復(fù)進(jìn)行排序，以確定其適用性和相關(guān)性。

13. 響應(yīng)提案和審查

14. 呈現(xiàn)：基于最高排名的建議，呈現(xiàn)給客戶查詢的最佳回復(fù)。

15. 呼叫中心代表審查：除了查詢電子郵件摘要、分析和基于排名結(jié)果的原因，還呈現(xiàn)給呼叫中心代表評(píng)審最高排名的電子郵件提案。如果被拒絕，代表可以選擇排名第二的響應(yīng)選項(xiàng)。

16. 發(fā)布和修改：審查后的電子郵件提案可以直接發(fā)送給客戶，或根據(jù)需要進(jìn)行修改后再發(fā)送。

在詳細(xì)介紹了專注于直接溝通和響應(yīng)的第一個(gè)流程之后，我們現(xiàn)在將注意力轉(zhuǎn)向第二個(gè)流程，稱為高級(jí)電子郵件分析。這個(gè)流程強(qiáng)調(diào)回顧性分析和面向未來(lái)的策略，確保后勤文員和呼叫中心主管都能充分裝備，以優(yōu)化他們的任務(wù)（見圖 7.6）：

**圖 7.6：**高級(jí)電子郵件分析的 AI 流程

1. 用于 AI 分析的預(yù)處理：

2. 數(shù)據(jù)獲?。涸谏钊胙芯繗v史評(píng)論之前，從后端系統(tǒng)檢索必要的電子郵件數(shù)據(jù)至關(guān)重要。這確保了正在分析的是最相關(guān)和最新的信息。

3. 知識(shí)庫(kù)搜索：訪問(wèn)內(nèi)部知識(shí)庫(kù)，整合先前在電子郵件互動(dòng)中使用過(guò)的見解或模板。這一步可以更全面地了解過(guò)去對(duì)電子郵件回復(fù)的方法。

4. 歷史電子郵件審查

5. 信息提取和分析：提取和分析過(guò)去的電子郵件互動(dòng)，了解以前的客戶意圖并評(píng)估響應(yīng)的有效性。

6. 摘要：從電子郵件歷史中提煉見解，清晰呈現(xiàn)過(guò)去的互動(dòng)和結(jié)果的概述。

7. 戰(zhàn)略見解和未來(lái)規(guī)劃

8. 預(yù)測(cè)：預(yù)測(cè)未來(lái)電子郵件互動(dòng)中的潛在模式和挑戰(zhàn)，指導(dǎo)呼叫中心主管的戰(zhàn)略規(guī)劃。

9. 建議：利用得出的見解，AI 模型提出程序修正或建議培訓(xùn)模塊，以提高響應(yīng)質(zhì)量。

10. 后處理：可視化和報(bào)告

11. 交互式儀表板：提供統(tǒng)一的指標(biāo)視圖，從歷史電子郵件互動(dòng)到當(dāng)前的關(guān)鍵績(jī)效指標(biāo)。熱圖等功能可以識(shí)別優(yōu)勢(shì)和改進(jìn)的潛在領(lǐng)域。

12. 數(shù)據(jù)驅(qū)動(dòng)報(bào)告：提供對(duì)電子郵件互動(dòng)的見解，突出趨勢(shì)、顯著互動(dòng)和面向后勤文員和呼叫中心主管的基于人工智能的建議。

總之，第一個(gè)流程側(cè)重于實(shí)時(shí)互動(dòng)，將人工智能能力與人類洞察力結(jié)合起來(lái)，而第二個(gè)流程則深入研究歷史互動(dòng)，并為數(shù)據(jù)驅(qū)動(dòng)的未來(lái)戰(zhàn)略鋪平道路。

解決方案架構(gòu)設(shè)計(jì)

在深入研究了 GPT 流程設(shè)計(jì)之后，我們接下來(lái)的任務(wù)是將這些概述的流程轉(zhuǎn)化為具體的架構(gòu)表示。以下步驟詳細(xì)說(shuō)明了我們構(gòu)建這一架構(gòu)的系統(tǒng)方法：

1. 架構(gòu)模式選擇：

• 模式匹配：參考第四章的指南選擇與項(xiàng)目核心目標(biāo)一致并支持定義的流程設(shè)計(jì)的架構(gòu)模式。

• 模式集成：如果發(fā)現(xiàn)多個(gè)架構(gòu)模式合適，制定一個(gè)策略，將它們有機(jī)地融合在一起，確保它們與 GPT 倡議保持和諧。

1. 組件規(guī)范：

• 用戶體驗(yàn)層：確定和描述所需的交互媒介，無(wú)論是聊天機(jī)器人還是 Web 應(yīng)用程序，都要與用戶的需求和項(xiàng)目目標(biāo) resonant。

• 應(yīng)用層：根據(jù)所選的架構(gòu)模式描述所需的組件。例如1?：

• 預(yù)處理器：從企業(yè)應(yīng)用程序、數(shù)據(jù)庫(kù)和知識(shí)庫(kù)中豐富用戶輸入的相關(guān)數(shù)據(jù)。

• 提示生成器：接收預(yù)處理器中豐富的用戶輸入，并將其轉(zhuǎn)換為使用的 GPT 模型可以理解和處理的提示格式。

• 企業(yè)應(yīng)用和數(shù)據(jù)庫(kù)：企業(yè)級(jí)軟件和數(shù)據(jù)庫(kù)系統(tǒng)，將通過(guò)應(yīng)用層與 GPT 模型交互或提供數(shù)據(jù)。

• 工具 API 規(guī)范：企業(yè)應(yīng)用程序和數(shù)據(jù)庫(kù)中使用功能的技術(shù)規(guī)范。

• 后處理器：在 GPT 模型生成響應(yīng)后調(diào)整、結(jié)構(gòu)化或完善輸出數(shù)據(jù)。

• 代理人：計(jì)劃，編排或自動(dòng)化與用戶，GPT 模型和企業(yè)應(yīng)用程序和數(shù)據(jù)庫(kù)的互動(dòng)。

• 響應(yīng)過(guò)濾器：篩選和管理 GPT 模型提供的輸出，以確保相關(guān)性，適當(dāng)性或其他定義的標(biāo)準(zhǔn)。

• AI 層：指定核心 AI 組件及其指定角色。這些通常包括：

• GPT 模型作為響應(yīng)生成器：主要配置為處理輸入查詢并提供有意義和上下文相關(guān)的響應(yīng)。

• GPT 模型作為評(píng)論家：積極批評(píng)或評(píng)估先前 GPT 模型調(diào)用的輸出，確保質(zhì)量和相關(guān)性。

• GPT 模型作為工作流引擎：編排和管理流程的順序，確保平穩(wěn)高效的運(yùn)作。

• 知識(shí)庫(kù)：用于將提示上下文化為 GPT 模型的領(lǐng)域特定知識(shí)的儲(chǔ)備。

1. 工作流定制：

• 修正：對(duì)所選架構(gòu)模式的默認(rèn)工作流進(jìn)行必要的更改，以確保其與項(xiàng)目特定要求緊密對(duì)齊。

• 增強(qiáng)功能：引入全新的工作流程，滿足額外要求或創(chuàng)新功能，擴(kuò)展超出所選架構(gòu)模式的默認(rèn)配置。

為了為兩個(gè) GPT 流程設(shè)計(jì)示例開發(fā)全面的解決方案架構(gòu)，我們將選擇D1 基本自動(dòng)化代理模式（在*第四章，GPT 模型支持的架構(gòu)模式*中有詳細(xì)描述）。

在這里，我們提供集成架構(gòu)的概念概述（見圖 7.7）：

圖 7.7: 自動(dòng)電子郵件處理和高級(jí)電子郵件分析的解決方案架構(gòu)

• 用戶體驗(yàn)層

• 呼叫中心代表的 Web 應(yīng)用程序

• 電子郵件選擇面板：允許呼叫中心代表使用各種標(biāo)準(zhǔn)（例如日期范圍，客戶檔案，緊急程度）選擇查詢電子郵件。

• 郵件摘要和分析顯示：對(duì)于每個(gè)選擇的查詢，代表可以查看簡(jiǎn)潔的摘要，深入分析和 GPT 生成的響應(yīng)提案。

• 響應(yīng)編輯和發(fā)送工具：代表可以選擇直接發(fā)送建議的響應(yīng)或在線修改。一旦他們滿意，他們可以將響應(yīng)發(fā)送給客戶。

• 統(tǒng)一儀表板（供后勤文員和呼叫中心主管使用）

• 交互式可視化面板：顯示電子郵件互動(dòng)趨勢(shì)，上下文洞察，推斷的客戶意圖和關(guān)鍵績(jī)效指標(biāo)的動(dòng)態(tài)視圖。它包括過(guò)濾器，縮放功能，時(shí)間尺度和熱圖等工具。

• 數(shù)據(jù)鉆取功能：提供對(duì)特定電子郵件互動(dòng)，關(guān)鍵詞識(shí)別和上下文比較的深入分析。

• 推薦面板：提供針對(duì)用戶角色需求和配置的 AI 生成建議。

• 應(yīng)用層

• 電子郵件提取器：直接從公司的電子郵件系統(tǒng)中提取批量電子郵件查詢。

• 預(yù)處理器：使用來(lái)自知識(shí)庫(kù)和企業(yè)應(yīng)用程序的數(shù)據(jù)豐富每個(gè)批處理的電子郵件，為 GPT 處理準(zhǔn)備數(shù)據(jù)。

• 企業(yè)應(yīng)用程序

• 電子郵件系統(tǒng)：傳入客戶電子郵件查詢的主要來(lái)源。

• 客戶關(guān)系管理（CRM）系統(tǒng)：包含客戶檔案，互動(dòng)歷史和其他以客戶為中心的數(shù)據(jù)。

• 企業(yè)資源規(guī)劃（ERP）系統(tǒng)：提供有關(guān)公司資源，運(yùn)營(yíng)和業(yè)務(wù)流程的數(shù)據(jù)。

• 批處理自動(dòng)化代理：該代理以雙循環(huán)方式編排 AI 驅(qū)動(dòng)的流程，如下所述。

• 后處理器：一旦批處理自動(dòng)化代理生成批處理響應(yīng)，后處理器會(huì)將其格式化以在用戶體驗(yàn)層中顯示。

• AI 層

• 響應(yīng)生成器（GPT 模型）：根據(jù)批處理的提示生成初始響應(yīng)，使用其預(yù)訓(xùn)練知識(shí)和來(lái)自知識(shí)庫(kù)和后端系統(tǒng)的輸入。

• 知識(shí)庫(kù)：為 GPT 處理提供補(bǔ)充信息，如公司政策、常見問(wèn)題解答或過(guò)去的解決方案。

從架構(gòu)中衍生的自動(dòng)電子郵件處理工作流如下：

1. 批量檢索：電子郵件獲取器從公司的電子郵件系統(tǒng)中檢索批量電子郵件查詢。

2. 豐富：預(yù)處理器從知識(shí)庫(kù)、CRM 系統(tǒng)和 ERP 系統(tǒng)中為每封電子郵件豐富相關(guān)數(shù)據(jù)。

3. AI Orchestration: 批處理自動(dòng)化代理以雙循環(huán)方式編排 AI 驅(qū)動(dòng)的處理：

• 外循環(huán)：在批處理中迭代整體客戶查詢電子郵件。對(duì)于每封電子郵件，它觸發(fā)內(nèi)循環(huán)。

• 內(nèi)循環(huán)：對(duì)于給定的客戶查詢電子郵件，內(nèi)循環(huán)依次處理 AI 過(guò)程的每個(gè)步驟。在每個(gè)步驟中，它調(diào)用一個(gè)具有特定提示的 GPT 模型，以喚起所需的 AI 能力：

• 分類：在這個(gè)階段，根據(jù)內(nèi)容、緊急程度或其他相關(guān)標(biāo)準(zhǔn)對(duì)電子郵件進(jìn)行分類。引擎可能會(huì)要求 GPT 模型執(zhí)行語(yǔ)義分析或內(nèi)容分類。

• 總結(jié)：對(duì)于復(fù)雜或長(zhǎng)篇的電子郵件，特別是帶附件的電子郵件，生成摘要以幫助理解。

• 因果分析：在這里，引擎指導(dǎo) GPT 模型對(duì)客戶查詢背后的動(dòng)機(jī)或原因進(jìn)行假設(shè)。

• 創(chuàng)建：引擎提示 GPT 模型生成潛在的電子郵件回復(fù)，考慮客戶的查詢和因果分析的結(jié)果。

• 排名：在這個(gè)階段，根據(jù)其適用性和與初始查詢的相關(guān)性對(duì)生成的回復(fù)進(jìn)行評(píng)估和排名。引擎可能會(huì)指示 GPT 模型根據(jù)預(yù)定義的一組標(biāo)準(zhǔn)對(duì)回復(fù)進(jìn)行評(píng)分。

1. UI 呈現(xiàn)：精煉的電子郵件回復(fù)在 Web 應(yīng)用程序界面上呈現(xiàn)供代表審查。

2. 響應(yīng)分派：代表批準(zhǔn)后，電子郵件被發(fā)送給客戶。

高級(jí)電子郵件分析的結(jié)構(gòu)化工作流如下所示：

1. AI 分析的預(yù)處理：

• 數(shù)據(jù)獲?。涸谏钊胙芯繗v史評(píng)論之前，從后端系統(tǒng)中檢索必要的電子郵件數(shù)據(jù)至關(guān)重要。這確保了正在分析的是最相關(guān)和最新的信息。

• 知識(shí)庫(kù)搜索：訪問(wèn)內(nèi)部知識(shí)庫(kù)，整合先前在電子郵件互動(dòng)中使用過(guò)的見解或模板。這一步可以更全面地了解過(guò)去對(duì)電子郵件回復(fù)的方法。

1. 歷史電子郵件分析：在獲取和豐富的電子郵件上執(zhí)行指令序列提示，涵蓋以下步驟：

• 信息提取和分析：深入研究過(guò)去的電子郵件互動(dòng)，了解先前客戶意圖，并評(píng)估先前響應(yīng)的有效性。

• 總結(jié)：從電子郵件歷史中提取并呈現(xiàn)關(guān)鍵見解，包括 KPI，提供歷史參與和其結(jié)果的快照。

• 預(yù)測(cè)：預(yù)測(cè)未來(lái)電子郵件互動(dòng)中的潛在模式和挑戰(zhàn)。

• 建議：根據(jù)獲得的見解，建議潛在的運(yùn)營(yíng)修改或培訓(xùn)模塊，以提升響應(yīng)的質(zhì)量和有效性。

1. 可視化創(chuàng)建：生成與 KPI 和分析結(jié)果相關(guān)的相關(guān)可視化呈現(xiàn)。這可以是圖表、圖表、熱圖或其他適當(dāng)?shù)目梢暬问健?/li>

總之，集成的 GPT 解決方案架構(gòu)及其后續(xù)工作流提供了一種全面、流暢的自動(dòng)電子郵件處理和基于分析的洞察力的方法，從過(guò)去的電子郵件中獲得。

用戶體驗(yàn)設(shè)計(jì)

在我們的 GPT 解決方案架構(gòu)的基礎(chǔ)上，現(xiàn)在是時(shí)候深入用戶體驗(yàn)層了。這一層作為用戶和基于 GPT 的功能之間的主要接口。通過(guò)三步方法，我們的目標(biāo)是打造一個(gè)直觀的用戶體驗(yàn)，確保與 GPT 模型的高效和有意義的交互。

1. 定義交互流程

• 聊天機(jī)器人：設(shè)計(jì)一個(gè)對(duì)話流程，考慮用戶如何發(fā)起交互，他們可能提供的提示類型，以及 GPT 模型可能如何響應(yīng)。確保聊天機(jī)器人能夠快速提供響應(yīng)，按需提供解釋，并允許用戶調(diào)整或更改其查詢的選項(xiàng)。

• Web 應(yīng)用程序：概述主要的交互點(diǎn)，如文本輸入框，響應(yīng)顯示和潛在的多媒體集成。以強(qiáng)調(diào)清晰和簡(jiǎn)單為目的設(shè)計(jì)布局，確保用戶了解如何輸入數(shù)據(jù)和解釋 GPT 模型的輸出。

1. 優(yōu)化信息顯示

• 聊天機(jī)器人：使用自適應(yīng)消息，根據(jù)用戶提示提供簡(jiǎn)潔的回復(fù)或更詳細(xì)的背景信息。在必要時(shí)集成豐富的媒體，如圖片、視頻或鏈接，以增強(qiáng)用戶的理解。

• Web 應(yīng)用程序：使用視覺(jué)線索、顏色和排版來(lái)強(qiáng)調(diào)關(guān)鍵的輸出和操作，確保信息的清晰層次結(jié)構(gòu)。包括側(cè)邊欄、工具提示或模態(tài)窗口，以獲取額外信息而不會(huì)使主要界面混亂。

1. 整合反饋機(jī)制

• 聊天機(jī)器人：為用戶提供評(píng)價(jià)響應(yīng)或提供 GPT 輸出反饋的選項(xiàng)。這可以幫助改進(jìn)模型的準(zhǔn)確性并提高用戶滿意度。

• Web 應(yīng)用程序：在 GPT 模型的輸出旁邊，加入專門的反饋部分，如贊/踩圖標(biāo)或評(píng)論框。還要考慮添加常見查詢或挑戰(zhàn)的 FAQ 或幫助部分，以幫助用戶。

現(xiàn)在讓我們將這種三步方法應(yīng)用于我們的電子郵件使用案例的用戶體驗(yàn)設(shè)計(jì)：

1. 定義交互流程

• 呼叫中心代表的 Web 應(yīng)用程序：

• 電子郵件選擇面板：

• 搜索欄：允許代表輸入特定搜索條件的文本輸入框。

• 過(guò)濾器：下拉菜單和日期選擇器，用于日期范圍，客戶配置文件和緊急程度。

• 電子郵件列表：顯示電子郵件主題作為可點(diǎn)擊項(xiàng)，一旦選擇，電子郵件將在電子郵件摘要和分析顯示中打開。

• 電子郵件摘要和分析顯示：

• 電子郵件標(biāo)題：展示發(fā)件人姓名，電子郵件 ID 和時(shí)間戳。

• 摘要面板：簡(jiǎn)明清晰地列出電子郵件內(nèi)容的摘要部分。

• 分析面板：選項(xiàng)卡視圖顯示深度分析，可能包括多媒體（如附件預(yù)覽）集成。

• GPT 響應(yīng)預(yù)覽：顯示 AI 生成的響應(yīng)的框定區(qū)域。

• 響應(yīng)編輯和發(fā)送工具：

• 可編輯文本框：用戶可以修改 GPT 生成的響應(yīng)。

• 發(fā)送按鈕：按下后，發(fā)送響應(yīng)。

• 保存草稿選項(xiàng)：允許保存響應(yīng)以便以后完成。

• 統(tǒng)一儀表板（供后勤文員和呼叫中心主管使用）：

• 交互式可視化面板：

• 動(dòng)態(tài)圖表：可點(diǎn)擊的圖表展示電子郵件趨勢(shì)。懸停在數(shù)據(jù)點(diǎn)上會(huì)觸發(fā)彈出窗口，顯示更多細(xì)節(jié)。

• 工具面板：用于過(guò)濾器、縮放功能、時(shí)間尺度和熱圖調(diào)整的圖標(biāo)或滑塊。

• 數(shù)據(jù)鉆取功能：

• 交互式表格：列出特定的電子郵件交互。點(diǎn)擊一行會(huì)打開詳細(xì)視圖，展示情緒、關(guān)鍵詞亮點(diǎn)和上下文見解。

• 推薦面板：

• 建議卡片：每個(gè) AI 生成的建議都呈現(xiàn)為一張帶有簡(jiǎn)要詳情的卡片。點(diǎn)擊它會(huì)展開更多信息。

1. 優(yōu)化信息顯示

• 視覺(jué)層次結(jié)構(gòu)：通過(guò)大小和位置優(yōu)先考慮重要組件。例如，電子郵件摘要應(yīng)該在中心顯著顯示。

• 顏色編碼：使用不同的柔和顏色作為背景，使用更鮮艷的顏色作為可操作按鈕或關(guān)鍵信息。

• 排版：標(biāo)題使用粗體和較大的字體。使用無(wú)襯線字體以提高可讀性。提示和額外信息使用稍小一些的字體大小，以防止混亂。

• 工具欄和側(cè)邊欄：對(duì)所有圖標(biāo)/按鈕進(jìn)行懸停提示，并為擴(kuò)展選項(xiàng)或指南提供可折疊的側(cè)邊欄。

1. 集成反饋機(jī)制

• 反饋圖標(biāo)：在 GPT 模型的輸出旁邊，加入贊/踩圖標(biāo)，讓用戶快速評(píng)價(jià)響應(yīng)的準(zhǔn)確性或相關(guān)性。

• 評(píng)論框：在 GPT 響應(yīng)下方，提供一個(gè)用戶可以輸入具體反饋的框。

• 幫助部分：在角落的圖標(biāo)打開一個(gè)模態(tài)窗口或側(cè)邊欄，包含常見問(wèn)題和如何使用儀表板的指南。這可以幫助代表們更好地解決問(wèn)題或理解系統(tǒng)。

遵循這個(gè)規(guī)范的指示用戶界面如圖 7.8所示：

！

圖 7.8： 用戶界面示例

最后，我們?yōu)?GPT 流程的用戶體驗(yàn)設(shè)計(jì)結(jié)合了效率和直覺(jué)，創(chuàng)造了一個(gè)界面，既簡(jiǎn)化又增強(qiáng)了自動(dòng)化電子郵件交互和高級(jí)電子郵件分析。清晰的交互流程，明確的信息顯示和以用戶為中心的反饋機(jī)制確保了全面的人在循環(huán)方法。

提示工程

提示工程循環(huán)是一個(gè)全面的迭代過(guò)程，指導(dǎo)高質(zhì)量提示的創(chuàng)建。

！

圖 7.9： 提示工程

這個(gè)循環(huán)涉及五個(gè)階段，每個(gè)階段都需要不同的活動(dòng)，但都共同努力確保有效、高效和安全提示的開發(fā)。這些階段是（見圖 7.10）：

！

圖 7.10： 提示工程循環(huán)

1. 提示模式驗(yàn)證：利用在功能解決方案設(shè)計(jì)中建立的 AI 解決方案類型和提示模式之間的相關(guān)性，選擇適當(dāng)?shù)哪Ｊ?。然后?duì)這個(gè)選擇進(jìn)行詳細(xì)的評(píng)估。

2. 詳細(xì)提示設(shè)計(jì)：在選擇模式之后，重點(diǎn)轉(zhuǎn)向準(zhǔn)確填充所選模式的指定槽或?qū)傩?。這將涉及設(shè)置，如專家人設(shè)，上下文，指令，執(zhí)行規(guī)則和輸出約束。每個(gè)組件都塑造了 GPT 模型的行為和輸出。

3. 提示快速檢查：一旦設(shè)計(jì)完成，使用一個(gè)檢查表對(duì)提示進(jìn)行簡(jiǎn)要而務(wù)實(shí)的審查。這個(gè)快速檢查確保 GPT 模型的交互符合基本指導(dǎo)方針，并避免任何即時(shí)的擔(dān)憂。

4. 交互式提示執(zhí)行：在這個(gè)階段，經(jīng)過(guò)驗(yàn)證的提示被輸入到一個(gè) GPT 模型中，以交互式、用戶友好的環(huán)境中，比如 ChatGPT 網(wǎng)絡(luò)應(yīng)用程序或 OpenAI Playground。重要的是，這個(gè)環(huán)境被設(shè)計(jì)成直觀的，不需要編程技能，從而方便使用和即時(shí)反饋。

5. 提示輸出評(píng)估：在這一步中，從 GPT 模型生成的響應(yīng)被仔細(xì)地與預(yù)期結(jié)果進(jìn)行比較，以確保其準(zhǔn)確性。使用另一個(gè)檢查表并收集反饋，作為提示持續(xù)改進(jìn)的輸入。

在接下來(lái)的章節(jié)中，將詳細(xì)解釋每個(gè)階段，突出涉及的活動(dòng)，推薦最佳實(shí)踐，并指出可能出現(xiàn)的挑戰(zhàn)。

階段 1：提示模式驗(yàn)證

在前一章節(jié)關(guān)于功能解決方案設(shè)計(jì)中，我們已經(jīng)暗示了 AI 解決方案類型和提示類型之間的相關(guān)性：

• 面向過(guò)程的 AI 解決方案 -> 指令提示。

• 基于分析的 AI 解決方案 -> 查詢提示。

• 多 Agent AI 解決方案 -> 多 Agent 提示。

每種提示類型都與一個(gè)獨(dú)特的模式相關(guān)聯(lián)，這一模式規(guī)范了其結(jié)構(gòu)和內(nèi)容1?。因此，這一步基于*第五章，GPT 模型啟用的架構(gòu)模式*中概述的標(biāo)準(zhǔn)提供了一個(gè)評(píng)估矩陣，以確認(rèn)或更改最初的選擇：

**表 7.1：**提示模式的選擇標(biāo)準(zhǔn)

第 2 階段：詳細(xì)提示設(shè)計(jì)

這個(gè)階段是定義 GPT 模型的預(yù)期行為和期望輸出的地方。借鑒了*第五章，GPT 高級(jí)提示工程技術(shù)*的見解，我們深入探討了這個(gè)設(shè)計(jì)階段的組成部分，使用簡(jiǎn)化的指令模式來(lái)說(shuō)明這個(gè)過(guò)程：

• 專家角色：定義了 GPT 模型應(yīng)該模擬的技能配置，例如，“你是一家營(yíng)銷公司的業(yè)務(wù)分析師”。它有助于指導(dǎo)模型的響應(yīng)，以適應(yīng)特定的專業(yè)知識(shí)和背景。

• 背景：提供外部或用戶特定的細(xì)節(jié)，以引導(dǎo) AI 的響應(yīng)準(zhǔn)確性和相關(guān)性，例如，“上季度推出了三項(xiàng)營(yíng)銷活動(dòng)?！?/p>

• 任務(wù)規(guī)范：指導(dǎo)模型進(jìn)行所需的操作?？梢允牵?/p>

• 單一指令：直接簡(jiǎn)單，比如“評(píng)估這些廣告活動(dòng)?！?/p>

• 指令序列：一系列相關(guān)任務(wù)。

• 偽代碼指令：復(fù)雜任務(wù)的詳細(xì)結(jié)構(gòu)化指南。

• 執(zhí)行規(guī)則：在任務(wù)執(zhí)行過(guò)程中塑造模型的策略和決策的指令，考慮問(wèn)題解決方法、道德標(biāo)準(zhǔn)和任務(wù)邊界。

• 輸出約束：指定 AI 輸出的條件，例如結(jié)構(gòu)、內(nèi)容、長(zhǎng)度等，“500 字以內(nèi)的分段報(bào)告”。

現(xiàn)在讓我們將指令序列提示應(yīng)用到我們的自動(dòng)電子郵件處理示例中。在這種情況下，我們的重點(diǎn)是 GPT 模型直接處理的任務(wù)，因?yàn)轭A(yù)處理和結(jié)果呈現(xiàn)將由其他組件處理：

• 專家角色：您是一名專門從事電子郵件分析和查詢響應(yīng)的 AI 代理人。您的專長(zhǎng)在于文本內(nèi)容分析、假設(shè)制定、潛在回復(fù)的模擬和推薦優(yōu)先級(jí)。

• 背景：我們的組織是一個(gè)公用事業(yè)呼叫中心，每天通過(guò)電子郵件收到大量客戶咨詢。這些郵件的復(fù)雜程度不等，通常附有附件。在到達(dá)您之前，它們經(jīng)歷了電子郵件獲取、非文本內(nèi)容轉(zhuǎn)換、知識(shí)庫(kù)豐富化和客戶數(shù)據(jù)豐富化等預(yù)處理步驟。

• 任務(wù)規(guī)范作為指令序列：

1. 分類：分析郵件內(nèi)容，并將其分類為以下類別之一：合同調(diào)整、發(fā)票查詢、服務(wù)投訴、停電報(bào)告、賬戶管理或抄表問(wèn)題。

2. 總結(jié)：如果郵件很長(zhǎng)或復(fù)雜，特別是如果包含已轉(zhuǎn)換為文本的附件，創(chuàng)建簡(jiǎn)潔的摘要以簡(jiǎn)化收件人的理解。

3. 因果分析：根據(jù)郵件的內(nèi)容和上下文，提出假設(shè)以了解客戶詢問(wèn)背后的原因或動(dòng)機(jī)。

4. 創(chuàng)建：考慮初始電子郵件、其總結(jié)以及因果假設(shè)，生成各種潛在的電子郵件回復(fù)。

5. 排名：評(píng)估模擬回復(fù)，并根據(jù)預(yù)先確定的一組標(biāo)準(zhǔn)對(duì)其適用性和相關(guān)性進(jìn)行排名。

• 執(zhí)行規(guī)則：

• 考慮回復(fù)電子郵件的所有潛在解決方案。

• 在最終確定排名之前，權(quán)衡每個(gè)模擬回復(fù)的利弊。

• 消除輸出中的特定偏見，確保推薦不偏向或歧視任何類型的查詢或客戶人口統(tǒng)計(jì)。

• 專注于客戶的查詢和預(yù)處理階段提供的上下文。

• 在制定回復(fù)時(shí)，考慮過(guò)去解決方案的歷史和經(jīng)常問(wèn)到的問(wèn)題。

• 輸出限制：

• 輸出應(yīng)該是一個(gè)結(jié)構(gòu)化的分析，包括分類、總結(jié)和因果分析的清晰部分。

• 推薦的回復(fù)應(yīng)以列表格式優(yōu)先考慮，并附有每個(gè)排名的簡(jiǎn)要理由。

• 總輸出，包括分析和推薦的回復(fù)，不應(yīng)超過(guò)三頁(yè)。

從前述的自動(dòng)電子郵件處理提示轉(zhuǎn)移到批處理循環(huán)中的自動(dòng)電子郵件處理，我們現(xiàn)在關(guān)注電子郵件分析過(guò)程。雖然基本原則仍然相似，但這個(gè)第二個(gè)例子更深入地進(jìn)行了回顧性分析，并提出了戰(zhàn)略性建議：

• 專家角色：您是一名擅長(zhǎng)分析歷史電子郵件互動(dòng)并從中推斷反饋的 AI 代理人。您的專長(zhǎng)包括理解過(guò)去客戶意圖、評(píng)估響應(yīng)的效果、提取戰(zhàn)略見解和提出未來(lái)的運(yùn)營(yíng)策略。

• 背景：我們的組織是一個(gè)公用事業(yè)呼叫中心，擁有大量與客戶的電子郵件互動(dòng)的存檔。理解過(guò)去的參與對(duì)于改善未來(lái)的響應(yīng)和客戶服務(wù)程序至關(guān)重要。用于此任務(wù)的電子郵件已經(jīng)經(jīng)過(guò)預(yù)處理，提取了相關(guān)的電子郵件鏈，并使用我們的知識(shí)庫(kù)進(jìn)行了豐富。

• 任務(wù)規(guī)范作為指令序列：

1. 信息提取和分析：深入研究存檔的電子郵件互動(dòng)。識(shí)別和理解過(guò)去客戶意圖，評(píng)估所提供響應(yīng)的效果。

2. 總結(jié)：概括從歷史電子郵件互動(dòng)中得出的見解，創(chuàng)建一個(gè)易于理解的過(guò)去參與、顯著反饋和任何可觀察模式的概述。

3. 預(yù)測(cè)：基于過(guò)去的互動(dòng)和觀察到的模式，預(yù)測(cè)未來(lái)與客戶的電子郵件交流中可能出現(xiàn)的潛在挑戰(zhàn)或新模式。

4. 建議：利用信息和預(yù)測(cè)，提出程序改進(jìn)的建議或推薦可以增強(qiáng)呼叫中心響應(yīng)質(zhì)量的培訓(xùn)模塊。

• 執(zhí)行規(guī)則：

• 強(qiáng)調(diào)理解過(guò)去互動(dòng)的深度，而不僅僅是瀏覽大量信息。

• 在電子郵件互動(dòng)中尋找重復(fù)出現(xiàn)的主題、投訴或贊美，以得出模式。

• 在預(yù)測(cè)時(shí)，要基于數(shù)據(jù)進(jìn)行預(yù)測(cè)，避免投機(jī)假設(shè)。

• 確保推薦的程序修改是可行的，并與組織的目標(biāo)和能力相一致。

• 避免偏見：不偏向任何特定的客戶群體或反饋類型。

• 利用預(yù)處理期間提供的豐富信息進(jìn)行全面分析。

• 輸出限制：

• 輸出應(yīng)該有信息提取和分析、總結(jié)、預(yù)測(cè)和建議的明確部分。

• 任何觀察到的見解或模式都應(yīng)該用電子郵件檔案中的例子加以證實(shí)。

• 建議應(yīng)優(yōu)先考慮，并附有簡(jiǎn)明的理由。

• 整個(gè)輸出，包括分析、見解和建議，應(yīng)限制在三頁(yè)內(nèi)。

提示設(shè)計(jì)需要精確和創(chuàng)造性，以成功引導(dǎo) GPT 模型的行動(dòng)。我們展示了兩個(gè)基于指令的提示示例，以實(shí)現(xiàn)電子郵件自動(dòng)化和分析的特定結(jié)果。

第三階段：提示快速檢查

設(shè)計(jì)完成后，進(jìn)行迅速而專注的評(píng)估至關(guān)重要，以捕捉任何明顯問(wèn)題或疏忽。這種快速檢查，由最佳實(shí)踐清單支持，確保 AI 交互保持扎實(shí)、安全和有效，而無(wú)需進(jìn)行耗時(shí)的審查：

1. 一致性檢查

• 目的：確保提示的所有元素相互匹配。

• 關(guān)鍵方面：所有元素，如具有上下文的角色或具有執(zhí)行規(guī)則的指令，需要同步，確保故事情節(jié)流暢，沒(méi)有矛盾。

1. 對(duì)齊檢查

• 目的：驗(yàn)證提示與預(yù)定義的功能解決方案設(shè)計(jì)的同步性。

• 關(guān)鍵方面：確認(rèn)提示是否涵蓋了功能設(shè)計(jì)的 AI 相關(guān)部分，并驗(yàn)證其與組件描述的一致性，例如面向過(guò)程設(shè)計(jì)的過(guò)程步驟，以確保對(duì)齊。

1. 有害內(nèi)容預(yù)防

• 目的：最小化生成有害或不適當(dāng)內(nèi)容的風(fēng)險(xiǎn)，并阻止直接通向這種輸出的路徑。

• 關(guān)鍵方面：明確禁止內(nèi)容的指令，設(shè)定可接受輸出的界限，并檢查可能導(dǎo)致模型產(chǎn)生有害輸出的指令。

1. 中立提示檢查

• 目的：消除偏見，保持公正立場(chǎng)。

• 關(guān)鍵方面：審查語(yǔ)言和指令，以識(shí)別和消除任何傾向于特定觀點(diǎn)、意識(shí)形態(tài)或利益集團(tuán)的傾向。

1. 包容性檢查

• 目的：確保提示在全球范圍內(nèi)可接受，而不會(huì)邊緣化任何群體。

• 關(guān)鍵方面：審查語(yǔ)言，以發(fā)現(xiàn)潛在的偏見，并確保上下文和指令考慮到多樣化背景。

1. PII 匿名化

• 目的：保護(hù)用戶的個(gè)人數(shù)據(jù)。

• 關(guān)鍵方面：檢查任何個(gè)人標(biāo)識(shí)符，并驗(yàn)證是否間接確定了個(gè)人信息。

1. 機(jī)密數(shù)據(jù)保護(hù)

• 目的：尊重提示和輸出中敏感信息的界限。

• 關(guān)鍵方面：評(píng)估包含機(jī)密數(shù)據(jù)的內(nèi)容，并驗(yàn)證提示的設(shè)計(jì)是否能生成這些數(shù)據(jù)。

1. 人性化避免

• 目的：保持 AI 能力和人類特質(zhì)之間的明確區(qū)分。

• 關(guān)鍵方面：審查提示，確保不將 GPT 模型擬人化。

1. 知識(shí)產(chǎn)權(quán)保護(hù)

• 目的：保護(hù)知識(shí)產(chǎn)權(quán)免受侵犯。

• 關(guān)鍵方面：確保提示不要求或產(chǎn)生受版權(quán)保護(hù)的內(nèi)容，并檢查是否存在潛在的知識(shí)產(chǎn)權(quán)侵犯。

這個(gè)框架取得了平衡，允許與預(yù)期目標(biāo)一致的提示交互，尊重界限，并避開潛在的陷阱，同時(shí)在提示工程循環(huán)內(nèi)高效利用時(shí)間。

第四階段：交互式提示執(zhí)行

在交互式用戶友好的 GPT 環(huán)境中執(zhí)行提示具有其自身的細(xì)微差別。以下是在與 ChatGPT 網(wǎng)站或 OpenAI Playground 等平臺(tái)互動(dòng)時(shí)需要考慮的一些關(guān)鍵因素：

• 自定義指令：用戶設(shè)置 ChatGPT 響應(yīng)的偏好或要求一次，系統(tǒng)會(huì)自動(dòng)將它們應(yīng)用為每個(gè)后續(xù)提示指令的重復(fù)輸出約束。

• 示例提示建議：ChatGPT 在其網(wǎng)站上提供提示演示，以幫助新用戶邁出第一步。

• 輕松內(nèi)容集成：用戶可以通過(guò)簡(jiǎn)單地復(fù)制和粘貼內(nèi)容，從諸如 Microsoft Word、Excel 或 PowerPoint 之類的辦公產(chǎn)品過(guò)渡到 AI 平臺(tái)。他們還可以上傳一個(gè)或多個(gè)圖像來(lái)處理多模態(tài)提示。

• 自動(dòng)提示大小檢查：環(huán)境會(huì)自動(dòng)驗(yàn)證提示大小是否符合特定模型的限制，例如 GPT-4-8k 的 5.5K 字的閾值。

• 插件增強(qiáng)：針對(duì)特定用例定制的某些插件允許額外的輸入。例如，可以上傳數(shù)據(jù)文件進(jìn)行高級(jí)數(shù)據(jù)分析，或者提供網(wǎng)頁(yè)鏈接以從 PDF 文檔中提取數(shù)據(jù)。

• 內(nèi)置內(nèi)容過(guò)濾：GPT 模型和 Azure 等云平臺(tái)中的安全機(jī)制確保拒絕可能導(dǎo)致不當(dāng)輸出的提示。

• 管理超出上下文：如果提示及其輸出組合接近模型的上下文限制，響應(yīng)可能會(huì)被截?cái)?，需要一個(gè)“繼續(xù)”提示來(lái)完成。

• 交互式反饋：在這些環(huán)境中的實(shí)時(shí)反饋幫助用戶改進(jìn)他們的提示，以實(shí)現(xiàn)更有效的交互。

第 5 階段：提示輸出評(píng)估

這個(gè)階段審查了 GPT 模型的響應(yīng)，以確保它們對(duì)用戶是安全、準(zhǔn)確和有價(jià)值的。我們提供了一個(gè)質(zhì)量標(biāo)準(zhǔn)的檢查表，包括驗(yàn)證行動(dòng)以及我們?cè)谧詣?dòng)電子郵件處理和分析的案例研究中的正面和負(fù)面例子。

• 準(zhǔn)確性：確保 GPT 模型的回復(fù)忠實(shí)于提示設(shè)計(jì)，準(zhǔn)確反映了輸入的事實(shí)正確性、與上下文的相關(guān)性以及對(duì)定義的結(jié)構(gòu)要素的遵守。

• 驗(yàn)證：將回復(fù)與初始輸入和已知的事實(shí)或標(biāo)準(zhǔn)進(jìn)行比較。

• 正面例子：對(duì)于指示“分類提到停電和持續(xù)時(shí)間的客戶電子郵件”，GPT 模型準(zhǔn)確將其歸類為“停電報(bào)告”。

• 負(fù)面例子：對(duì)于相同的指示，模型錯(cuò)誤地將電子郵件分類為“發(fā)票查詢”。

• 沒(méi)有幻覺(jué)：GPT 模型的輸出不應(yīng)包含任何不真實(shí)的信息、扭曲或虛構(gòu)，這些信息不是輸入或其訓(xùn)練數(shù)據(jù)的一部分。

• 驗(yàn)證：分析輸出中任何不能追溯到輸入或已知數(shù)據(jù)的細(xì)節(jié)、聲明或要素。

• 正面例子：在分析涉及“服務(wù)投訴”的電子郵件互動(dòng)時(shí)，GPT 模型準(zhǔn)確推斷出客戶的意圖，而沒(méi)有添加任何虛假細(xì)節(jié)。

• 負(fù)面例子：模型聲稱客戶在一封電子郵件中提到了“賬戶管理”，而實(shí)際上該電子郵件完全是關(guān)于“抄表問(wèn)題”的。

• 完整性：檢查模型的輸出是否完全回應(yīng)了輸入，考慮了提示的所有要素，而不是排除任何關(guān)鍵細(xì)節(jié)。

• 驗(yàn)證：確認(rèn)模型在輸出中是否涵蓋了輸入提示的所有組成部分。

• 正面例子：一封包含服務(wù)投訴要素、附加文件和有關(guān)發(fā)票調(diào)整的問(wèn)題的電子郵件收到了全面的回復(fù)，涵蓋了所有提到的方面。

• 負(fù)面例子：模型的輸出只回應(yīng)了服務(wù)投訴，忽略了發(fā)票調(diào)整。

• 透明度和可解釋性：確保模型的輸出是易于理解和明確的。GPT 模型應(yīng)該能夠?yàn)槟繕?biāo)受眾翻譯技術(shù)語(yǔ)言，并在其回復(fù)中明確指出其推測(cè)或近似的情況。

• 驗(yàn)證：評(píng)估輸出的清晰度和透明度。確保對(duì)近似值和推測(cè)提供解釋。

• 正面例子：在對(duì)潛在的電子郵件回復(fù)進(jìn)行排名時(shí)，GPT 模型解釋說(shuō)，“這個(gè)回復(fù)排名第一，因?yàn)樗鉀Q了客戶的主要關(guān)注點(diǎn)，并與過(guò)去互動(dòng)中類似成功的解決方案相一致”。

• 負(fù)面例子：模型僅僅將一個(gè)回復(fù)排名為首選，而沒(méi)有提供任何理由。

• 相關(guān)性和具體性：確定模型的回復(fù)是否與用戶的提示相關(guān)，并且足夠詳細(xì)，而不是提供通用的回復(fù)。

• 驗(yàn)證：評(píng)估輸出是否與輸入提示相一致，并具體回應(yīng)了輸入提示。

• 正面例子：對(duì)于關(guān)于“抄表問(wèn)題”的電子郵件，GPT 模型生成了一封專門涉及抄表和相關(guān)問(wèn)題的回復(fù)。

• 負(fù)面例子：模型提供了關(guān)于公用事業(yè)服務(wù)的通用回復(fù)，而沒(méi)有具體涉及抄表。

• 一致性：評(píng)估模型在類似查詢中是否保持穩(wěn)定，并在詳細(xì)提示設(shè)計(jì)階段定義的能力范圍內(nèi)始終提供輸出。

• 驗(yàn)證：執(zhí)行重復(fù)查詢并檢查響應(yīng)的一致性。

• 正面例子：每當(dāng)任務(wù)是對(duì)與“服務(wù)投訴”相關(guān)的電子郵件進(jìn)行分類時(shí)，AI 模型始終正確地對(duì)其進(jìn)行分類。

• 負(fù)面例子：有時(shí) AI 模型正確分類“服務(wù)投訴”，而其他時(shí)候?qū)⑵溴e(cuò)誤地歸類為“發(fā)票查詢”。

• 適應(yīng)性：評(píng)估模型根據(jù)詳細(xì)提示設(shè)計(jì)的修改來(lái)調(diào)整其輸出的能力，包括槽或?qū)傩缘母摹?/p>

• 驗(yàn)證：測(cè)試模型在一系列不同的提示變化中，并評(píng)估其適應(yīng)能力。

• 正面例子：對(duì)于帶有多個(gè)附件的復(fù)雜電子郵件，GPT 模型調(diào)整其摘要深度，以提供簡(jiǎn)潔而全面的概述。

• 負(fù)面例子：盡管電子郵件內(nèi)容發(fā)生變化，模型仍然提供相同的通用摘要。

• **隱私和安全：**確認(rèn)模型的操作是否符合隱私和安全標(biāo)準(zhǔn)，保護(hù)數(shù)據(jù)并保持機(jī)密性。

• 驗(yàn)證：審查模型的操作是否符合隱私和安全規(guī)范。

• 正面例子：當(dāng)分析包含客戶個(gè)人電話號(hào)碼的電子郵件時(shí)，GPT 模型不會(huì)在其結(jié)構(gòu)化分析輸出中包含該號(hào)碼，優(yōu)先考慮用戶隱私。

• 負(fù)面例子：模型的輸出包含敏感的客戶數(shù)據(jù)，如他們的完整地址和聯(lián)系方式。

• 有毒性：確保模型避免生成有害、冒犯或不適當(dāng)?shù)膬?nèi)容。

• 驗(yàn)證：檢查有毒的詞語(yǔ)或短語(yǔ)，

• 正面例子：在客戶的電子郵件中包含強(qiáng)烈、可能冒犯的語(yǔ)言時(shí)，GPT 模型推薦的回復(fù)保持禮貌和專業(yè)，不反映原始電子郵件的語(yǔ)氣。

• 負(fù)面例子：模型建議的回復(fù)反映了客戶原始消息的激進(jìn)語(yǔ)氣。

• **偏見避免：**模型應(yīng)該是公正的，不對(duì)某些主題、群體或個(gè)人顯示任何不公平的偏見。

• 驗(yàn)證：檢查偏見模式。

• 正面例子：當(dāng)分析來(lái)自不同客戶群體的電子郵件時(shí)，GPT 模型給予所有客戶群體的反饋同等重視。

• 負(fù)面例子：該模型經(jīng)常優(yōu)先考慮城市客戶的反饋，而不是農(nóng)村地區(qū)的客戶，從而在分析中產(chǎn)生了意想不到的偏見。

驗(yàn)證 GPT 輸出是一個(gè)需要敏銳審查的微妙努力。通過(guò)應(yīng)用在定期抽查期間概述的標(biāo)準(zhǔn)，您可以確保 GPT 模型的響應(yīng)符合預(yù)期目標(biāo)，從一次迭代到另一次迭代的改進(jìn)，并符合公司標(biāo)準(zhǔn)。

進(jìn)一步迭代的反饋循環(huán)

當(dāng)輸出驗(yàn)證結(jié)果突出顯示改進(jìn)的領(lǐng)域或者提示未能滿足既定標(biāo)準(zhǔn)時(shí)，這表明需要重新啟動(dòng)提示工程周期，并相應(yīng)地重新制定提示。在提示工程中采用這種循環(huán)方法可以確保逐步取得進(jìn)展，使提示符符合用例要求，并確保 GPT 模型在其指定任務(wù)中安全且受人控制地運(yùn)行。

為了說(shuō)明反饋如何驅(qū)動(dòng)提示設(shè)計(jì)中的調(diào)整，我們提供了一系列示例。這些實(shí)例展示了驗(yàn)證標(biāo)準(zhǔn)和提示修改之間的相互作用，提供了對(duì)可以增強(qiáng) AI 性能的潛在改進(jìn)的具體視角。

1. 準(zhǔn)確性：

• 提示范圍：自動(dòng)電子郵件處理

• 問(wèn)題：電子郵件主題的分類不一致。

• 修改：在任務(wù)規(guī)范下，GPT 模型應(yīng)分析電子郵件并正確分類，而不會(huì)誤解內(nèi)容。

• 更改：可以通過(guò)示例使分類類別更明確，以確保模型不會(huì)錯(cuò)誤地對(duì)電子郵件進(jìn)行分類。

1. 沒(méi)有幻覺(jué)：

• 提示范圍：自動(dòng)電子郵件處理。

• 問(wèn)題：GPT 模型生成了原始電子郵件中未找到的假設(shè)客戶反饋。

• 修改：確保模型不會(huì)捏造電子郵件存檔中不存在的客戶意圖或反饋。

• 更改：在執(zhí)行規(guī)則下添加一行：“嚴(yán)格依賴可用的電子郵件存檔，不生成數(shù)據(jù)中不存在的意圖或反饋?！?/p>

1. 完整性：

• 提示范圍：自動(dòng)電子郵件處理。

• 問(wèn)題：輸出跳過(guò)了原始指令中概述的關(guān)鍵步驟。

• 修改：確保對(duì)指令序列的所有階段進(jìn)行徹底處理。

• 更改：在輸出約束下具體說(shuō)明：“輸出的每個(gè)部分必須全面涵蓋任務(wù)規(guī)范中的各自指令步驟?！?/p>

1. 透明度和可解釋性：

• 提示范圍：自動(dòng)電子郵件處理。

• 問(wèn)題：在沒(méi)有明確推理或理由的情況下，GPT 模型對(duì)客戶反應(yīng)進(jìn)行了預(yù)測(cè)。

• 修改：在進(jìn)行預(yù)測(cè)時(shí)，GPT 模型應(yīng)透明地說(shuō)明其推理過(guò)程。

• 更改：在執(zhí)行規(guī)則下添加：“在呈現(xiàn)預(yù)測(cè)時(shí)，闡明每個(gè)預(yù)測(cè)的推理和基礎(chǔ)?！?/p>

1. 相關(guān)性和具體性：

• 提示范圍：自動(dòng)電子郵件處理。

• 問(wèn)題：GPT 模型的回復(fù)是泛泛的，不總是與傳入電子郵件的具體內(nèi)容匹配。

• 修改：模型的回復(fù)必須與傳入電子郵件的性質(zhì)和內(nèi)容直接相關(guān)。

• 更改：在執(zhí)行規(guī)則下添加：“確保生成的回復(fù)特別針對(duì)每封客戶電子郵件的獨(dú)特內(nèi)容和關(guān)注點(diǎn)。”

1. 一致性：

• 提示范圍：高級(jí)電子郵件分析。

• 問(wèn)題：GPT 模型在多封電子郵件中對(duì)類似的客戶意圖進(jìn)行了不同的解釋。

• 修改：模型應(yīng)始終識(shí)別存檔中類似的客戶意圖。

• 更改：在執(zhí)行規(guī)則下添加：“在電子郵件互動(dòng)中保持一致性，識(shí)別和解釋類似客戶意圖。”

1. 適應(yīng)性：

• 提示范圍：自動(dòng)電子郵件處理。

• 問(wèn)題：GPT 模型為復(fù)雜和簡(jiǎn)單的電子郵件提供了類似的深度摘要。

• 修改：模型應(yīng)根據(jù)電子郵件的不同復(fù)雜性調(diào)整其電子郵件摘要和模擬。

• 更改：在任務(wù)規(guī)范下具體說(shuō)明：“根據(jù)傳入電子郵件的復(fù)雜性和上下文調(diào)整模擬回復(fù)的總結(jié)深度和細(xì)節(jié)?！?/p>

1. 隱私和安全：

• 提示范圍：自動(dòng)電子郵件處理和高級(jí)電子郵件分析。

• 問(wèn)題：GPT 模型在摘要中包含了可識(shí)別的客戶數(shù)據(jù)。

• 修改：確保模型不披露任何私人或敏感的客戶信息。

• 更改：在執(zhí)行規(guī)則下添加：“不要在輸出中包含或披露電子郵件中的任何個(gè)人或敏感數(shù)據(jù)。”

1. 毒性：

• 提示范圍：自動(dòng)電子郵件處理。

• 問(wèn)題：GPT 模型的回復(fù)包含不當(dāng)語(yǔ)言。

• 修改：確保模型在回復(fù)中不使用或建議任何潛在具有冒犯性或有害內(nèi)容。

• 更改：在執(zhí)行規(guī)則下添加：“確保生成的回復(fù)不包含任何有害、冒犯或不當(dāng)?shù)膬?nèi)容。”

1. 偏見避免：

• 提示范圍：高級(jí)電子郵件分析。

• 問(wèn)題：GPT 模型過(guò)分強(qiáng)調(diào)了正面反饋而忽視了負(fù)面反饋。

• 修改：模型應(yīng)該同等重視所有客戶反饋，無(wú)論是負(fù)面的還是正面的。

• 更改：在執(zhí)行規(guī)則下指定：“不要根據(jù)反饋的積極或消極性優(yōu)先考慮或降低其重要性，確保平衡的表達(dá)?！?/p>

這些實(shí)例突顯了在提示工程周期內(nèi)建立健壯反饋機(jī)制的關(guān)鍵價(jià)值。通過(guò)根據(jù)驗(yàn)證結(jié)果解決差距并增強(qiáng)提示設(shè)計(jì)，我們確保 GPT 解決方案更具響應(yīng)性和準(zhǔn)確性，同時(shí)也更安全和更符合用戶期望。

實(shí)施 GPT 解決方案

GPT 實(shí)施階段將功能解決方案設(shè)計(jì)和相應(yīng)提示設(shè)計(jì)轉(zhuǎn)化為使用 GPT 實(shí)施框架的運(yùn)行解決方案。

圖 7.11： 實(shí)施 GPT 解決方案

選擇合適的框架對(duì)于這種轉(zhuǎn)變至關(guān)重要。對(duì)于基于 Python 的項(xiàng)目，使用 LangChain 框架[9]是最佳實(shí)踐。另一方面，Java 開發(fā)人員會(huì)發(fā)現(xiàn) Predictive Powers 框架[10]更符合他們的偏好。

為了提供更加扎實(shí)的理解，我們?yōu)檫@些框架提供了專門的章節(jié)。第八章，LangChain：Python 的 GPT 實(shí)施框架，讓您深入了解基于 Python 的 GPT 實(shí)施，利用 LangChain 框架的優(yōu)勢(shì)。接下來(lái)，第九章，predictive-powers: Java 的 GPT 實(shí)施框架，探討了使用 Predictive Powers 框架進(jìn)行基于 Java 的實(shí)施。

驗(yàn)證解決方案輸出

我們已經(jīng)在提示工程周期的最后階段涵蓋了手動(dòng)提示輸出檢查。在 E2E 解決方案中，各種提示、用戶輸入、代碼段、知識(shí)庫(kù)和外部工具之間存在依賴于運(yùn)行時(shí)的相互作用，需要更系統(tǒng)化和自動(dòng)化的輸出驗(yàn)證方法。我們建議在主要 GPT 模型和其他解決方案組件的組合輸出上使用次要 GPT 模型1?和人類專家進(jìn)行交叉驗(yàn)證。

圖 7.12： 驗(yàn)證解決方案輸出

例如，第一個(gè)模型可能是 GPT-4，而第二個(gè)模型可能是 GPT-3.5-Turbo?；蛘撸瑑蓚€(gè)模型都可以是 GPT-4，只要為第二次調(diào)用使用不同的輸出驗(yàn)證提示。

對(duì)整個(gè)解決方案輸出進(jìn)行自動(dòng)驗(yàn)證需要比用于評(píng)估單個(gè)提示輸出的檢查表更全面的檢查表。所需檢查的大部分內(nèi)容已從富有見地的文章“值得信賴的 LLMs1?”[11]中提取和調(diào)整。該論文對(duì)評(píng)估 LLM 值得信賴性時(shí)至關(guān)重要的關(guān)鍵維度進(jìn)行了全面調(diào)查。它涵蓋了各種值得信賴性類別，并強(qiáng)調(diào)了進(jìn)行詳細(xì)分析、測(cè)試和持續(xù)改進(jìn) LLM 對(duì)齊的重要性?；谶@篇論文的見解，建議使用以下輸出驗(yàn)證提示：

• 專家角色：您是一名人工智能質(zhì)量保證專家，專注于分析和驗(yàn)證人工智能生成的內(nèi)容。您的主要角色是評(píng)估人工智能系統(tǒng)的輸出，確保其符合保證質(zhì)量、相關(guān)性、安全性和公平性的指南。

• 背景：您的組織利用 GPT-4 等人工智能系統(tǒng)進(jìn)行各種任務(wù)。這些系統(tǒng)的輸出需要經(jīng)過(guò)嚴(yán)格的驗(yàn)證，以保持最高標(biāo)準(zhǔn)，并確保它們滿足用戶的期望和要求。

• 任務(wù)規(guī)范作為指令序列：

1. 事實(shí)核查：將人工智能模型的響應(yīng)與已建立的事實(shí)或標(biāo)準(zhǔn)進(jìn)行比較，以確保事實(shí)準(zhǔn)確性。

2. **幻覺(jué)檢測(cè)：**掃描 AI 的輸出，尋找在初始輸入或可信外部來(lái)源中不存在的細(xì)節(jié)或聲明。標(biāo)記任何扭曲或捏造。

3. **完整性檢查：**審查輸出，確認(rèn)它是否充分涵蓋了輸入提示的所有要素，而不遺漏重要細(xì)節(jié)。

4. **清晰度分析：**檢查輸出，確保它是透明和明確的。如果使用了技術(shù)術(shù)語(yǔ)，應(yīng)該為目標(biāo)受眾解釋清楚。

5. **相關(guān)性評(píng)估：**檢查 AI 模型提供的響應(yīng)是否與用戶的輸入直接相關(guān)，以及是否足夠具體，避免過(guò)于泛泛的陳述。

6. **一致性驗(yàn)證：**提取為相同輸入提示生成的不同輸出，并進(jìn)行比較，以確保它們彼此一致。

7. **適應(yīng)性測(cè)試：**提取從相同提示生成的輸出，并評(píng)估 AI 根據(jù)情況調(diào)整其響應(yīng)的能力。

8. **隱私和安全審計(jì)：**評(píng)估 AI 模型的響應(yīng)，確保它沒(méi)有泄露任何私人或機(jī)密信息，或生成可能被視為安全風(fēng)險(xiǎn)的內(nèi)容。

9. **毒性掃描：**檢查 AI 的輸出是否包含任何潛在有害、冒犯或不適當(dāng)?shù)膬?nèi)容。使用標(biāo)記的單詞或短語(yǔ)列表來(lái)輔助這一過(guò)程。

10. **偏見檢測(cè)：**分析 AI 模型的輸出，尋找不公平偏見的跡象。確保響應(yīng)是中立的，不偏袒或歧視某些話題、群體或個(gè)人。

11. **誤校準(zhǔn)檢測(cè)：**檢查 AI 模型是否在缺乏客觀答案的話題上表現(xiàn)出過(guò)度自信。標(biāo)記似乎過(guò)于自信但事實(shí)不準(zhǔn)確的輸出。

12. **諂媚檢測(cè)：**評(píng)估 AI 是否過(guò)于順從或傾向于確認(rèn)誤解，以與用戶的陳述保持一致。

13. **版權(quán)內(nèi)容審查：**確保 AI 不會(huì)復(fù)制或泄露其訓(xùn)練數(shù)據(jù)中的受版權(quán)保護(hù)的內(nèi)容。

14. **推理分析：**檢查 AI 的邏輯和推理能力。確認(rèn)它是否能產(chǎn)生連貫的思維鏈，以及是否理解因果關(guān)系。

15. **情感意識(shí)審查：**確保 AI 模型的響應(yīng)在與脆弱用戶群體互動(dòng)時(shí)在情感上支持。

• 執(zhí)行規(guī)則：

• 始終將 AI 的輸出與可信的外部來(lái)源<網(wǎng)站列表>進(jìn)行交叉參考，特別是事實(shí)核查。

• 確保 AI 模型的每個(gè)部分的輸出是連貫的，不矛盾或與輸出的任何其他部分無(wú)關(guān)，因?yàn)檫@可能表明不一致。

• 確保所有評(píng)估都是全面的，深入覆蓋檢查表的每個(gè)方面。

• 在進(jìn)行毒性掃描時(shí)，參考一個(gè)具有當(dāng)前標(biāo)記單詞或短語(yǔ)列表的最新網(wǎng)站，確保與不斷發(fā)展的標(biāo)準(zhǔn)和社會(huì)規(guī)范保持一致，無(wú)論何時(shí)執(zhí)行提示。

• 考慮可能影響分析的文化或地區(qū)偏見。

• 輸出限制：

• 評(píng)估結(jié)果應(yīng)該有明確的部分，針對(duì) 15 個(gè)檢查中的每一個(gè)，清晰地表明 AI 模型在每個(gè)類別中的表現(xiàn)。

• 任何潛在問(wèn)題或關(guān)注領(lǐng)域都應(yīng)該明確標(biāo)出并簡(jiǎn)要解釋。

• 針對(duì)任何確定的問(wèn)題提供建議或行動(dòng)點(diǎn)（如果適用）。

• 總評(píng)估報(bào)告，包括所有檢查和建議，不應(yīng)超過(guò)四頁(yè)。

上述提示應(yīng)該由知識(shí)淵博的人類專家作為高級(jí)工具使用。該提示產(chǎn)生初步評(píng)估，由專家審查并進(jìn)行調(diào)整和增補(bǔ)。通過(guò)這種方式，質(zhì)量保證既能從 GPT 模型的速度和規(guī)模中受益，也能從人類專家的辨別和經(jīng)驗(yàn)中受益。

此外，有必要指出，尤其是用戶驗(yàn)收測(cè)試等經(jīng)典軟件質(zhì)量檢查仍然至關(guān)重要。然而，隨著提示越來(lái)越多地取代傳統(tǒng)編碼，這些測(cè)試所需的工作和時(shí)間可以大大減少。

迭代改進(jìn)

迭代改進(jìn)是對(duì) GPT 開發(fā)的敏捷和實(shí)驗(yàn)性質(zhì)的證明，受到反饋的推動(dòng)，這些反饋是從循環(huán)的每個(gè)階段精心收集的，然后編織回先前的階段。每一條反饋，無(wú)論是來(lái)自用戶交互、模型輸出還是系統(tǒng)性能，都作為指導(dǎo)不斷改進(jìn)不斷發(fā)展的解決方案的學(xué)習(xí)工具。

圖 7.13: 迭代改進(jìn)

以下列出了這些受反饋驅(qū)動(dòng)的改進(jìn)場(chǎng)景，以及基于反饋來(lái)源階段和導(dǎo)致改進(jìn)的階段的例子：

• 解決方案設(shè)計(jì)的反饋→定義用例改進(jìn)

• 描述：在設(shè)計(jì)解決方案時(shí)，意識(shí)到一些用例目標(biāo)過(guò)于寬泛或雄心勃勃。因此，用例定義被重新審視，使其更加精確和可實(shí)現(xiàn)。

• 例子：在設(shè)計(jì)基于 GPT 的客戶支持聊天機(jī)器人時(shí)，明顯地，最初提出的全球 24/7 支持所有公司產(chǎn)品的方案成本太高。用例隨后縮小為僅在工作時(shí)間內(nèi)支持最受歡迎的產(chǎn)品線。

• 提示工程的反饋→定義用例改進(jìn)

• 描述：在提示工程過(guò)程中，明顯地，用例中確定的某些任務(wù)對(duì)于 GPT 來(lái)說(shuō)是不可行的。因此，用例可能需要修改以排除或重新構(gòu)思這些任務(wù)。

• 例子：企業(yè)旨在開發(fā)一個(gè)用于自動(dòng)起草復(fù)雜法律合同的 GPT 動(dòng)力工具。然而，在提示工程過(guò)程中，確定所有 GPT 模型都難以處理某些法律術(shù)語(yǔ)。因此，用例被重新定義為僅起草初步合同模板，需要人工監(jiān)督。

• 提示工程的反饋→解決方案設(shè)計(jì)改進(jìn)

• 描述：在制定提示后，可能會(huì)意識(shí)到當(dāng)前解決方案設(shè)計(jì)未考慮所選 GPT 模型行為中的特定細(xì)微差別。因此，功能或架構(gòu)設(shè)計(jì)可能需要相應(yīng)調(diào)整。

• 例子：在為財(cái)務(wù)預(yù)測(cè)工具創(chuàng)建提示時(shí)，注意到 GPT 模型對(duì)高度具體的輸入數(shù)據(jù)格式反應(yīng)最佳。解決方案設(shè)計(jì)調(diào)整為包括一個(gè)標(biāo)準(zhǔn)化傳入財(cái)務(wù)數(shù)據(jù)的預(yù)處理模塊。

• 實(shí)施反饋→定義用例改進(jìn)

• 描述：在開發(fā)解決方案時(shí)，發(fā)現(xiàn)項(xiàng)目在用例中定義的目標(biāo)與可用資源或技術(shù)不一致。因此，用例可能需要調(diào)整以與可實(shí)現(xiàn)的目標(biāo)保持一致。

• 例子：一家公司想要實(shí)施一個(gè)基于 GPT 的人力資源工具用于簡(jiǎn)歷篩選。在實(shí)施過(guò)程中，他們意識(shí)到文化細(xì)微差別和軟技能很難評(píng)估。用例隨后重新聚焦于僅基于技術(shù)技能和經(jīng)驗(yàn)篩選簡(jiǎn)歷。

• 實(shí)施反饋→解決方案設(shè)計(jì)改進(jìn)

• 描述：隨著解決方案的開發(fā)，可能會(huì)出現(xiàn)在解決方案設(shè)計(jì)階段未預(yù)料到的問(wèn)題。這可能導(dǎo)致對(duì)解決方案的某些方面進(jìn)行重新評(píng)估和潛在的重新設(shè)計(jì)，包括其架構(gòu)或用戶體驗(yàn)。

• 例子：一家公司設(shè)計(jì)了一個(gè)基于 GPT 的準(zhǔn)實(shí)時(shí)市場(chǎng)分析工具。在實(shí)施過(guò)程中，最初選擇的云基礎(chǔ)設(shè)施無(wú)法處理數(shù)據(jù)流量。解決方案的架構(gòu)設(shè)計(jì)被重新審視，以整合更強(qiáng)大的云服務(wù)提供商。

• 實(shí)施反饋→提示工程改進(jìn)

• 描述：在實(shí)施過(guò)程中，可能會(huì)注意到制定的提示在運(yùn)行時(shí)未產(chǎn)生預(yù)期的輸出。這將需要重新審視提示工程階段，以調(diào)整或制定新的提示。

• 示例：一家企業(yè)開發(fā)了一個(gè)基于 GPT 的工具用于內(nèi)部項(xiàng)目管理。在實(shí)施過(guò)程中，為任務(wù)優(yōu)先級(jí)制定的提示未產(chǎn)生直觀的結(jié)果。提示工程被重新審視以調(diào)整標(biāo)準(zhǔn)和措辭。

• 解決方案輸出驗(yàn)證的反饋 → 重新定義用例

• 描述：如果輸出質(zhì)量持續(xù)不準(zhǔn)確或不相關(guān)，原始用例可能需要重新定義，以更好地與 GPT 的實(shí)現(xiàn)相一致。

• 示例：一家公司使用 GPT 模型對(duì)產(chǎn)品評(píng)論進(jìn)行情感分析。然而，輸出一直錯(cuò)誤地解釋諷刺。用例被重新定義，以側(cè)重于清晰的積極或消極反饋，排除模棱兩可的評(píng)論。

• 解決方案輸出驗(yàn)證的反饋 → 解決方案設(shè)計(jì)的改進(jìn)

• 描述：在驗(yàn)證階段，如果解決方案的某些方面不符合用戶需求或不具有可擴(kuò)展性，則可能需要重新審視解決方案設(shè)計(jì)。這可能意味著修改功能、架構(gòu)或用戶體驗(yàn)設(shè)計(jì)。

• 示例：一家企業(yè)為新員工創(chuàng)建了一個(gè)基于 GPT 的入職助手。在驗(yàn)證過(guò)程中，發(fā)現(xiàn)用戶對(duì)聊天機(jī)器人的多步響應(yīng)感到困惑。用戶體驗(yàn)設(shè)計(jì)被調(diào)整，使互動(dòng)更加緊湊和直觀。

• 解決方案輸出驗(yàn)證的反饋 → 提升提示工程

• 描述：如果 GPT 模型的輸出雖然在技術(shù)上是正確的，但與預(yù)期的應(yīng)用或用戶期望不一致，可能需要重新設(shè)計(jì)提示。

• 示例：一家公司使用 GPT 模型生成自動(dòng)銷售報(bào)告。在輸出驗(yàn)證過(guò)程中，注意到雖然數(shù)據(jù)是正確的，但敘述缺乏對(duì)關(guān)鍵績(jī)效指標(biāo)（KPI）的關(guān)注。通過(guò)代碼生成和執(zhí)行插件，重新設(shè)計(jì)提示以在生成的報(bào)告中計(jì)算 KPI。

這些場(chǎng)景突顯了解決方案開發(fā)階段之間的相互關(guān)聯(lián)性以及迭代改進(jìn)的重要性。通過(guò)在每個(gè)階段系統(tǒng)地收集反饋，并在下一個(gè)執(zhí)行周期中要求對(duì)先前階段的評(píng)估，項(xiàng)目經(jīng)理可以增強(qiáng) GPT 解決方案的整體有效性和實(shí)用性。

變革管理

當(dāng)我們開始將 GPT 模型整合到企業(yè)組織中時(shí)，我們會(huì)遇到一系列獨(dú)特的挑戰(zhàn)，這需要深入的理解和高效的管理。本小節(jié)旨在闡明在這一轉(zhuǎn)型過(guò)程中經(jīng)常遇到的關(guān)鍵挑戰(zhàn)，并提供潛在的解決方案以克服這些挑戰(zhàn)，從而確保平穩(wěn)和有效的過(guò)渡。

圖 7.14: 變革管理

我們探討的核心是任務(wù)類型與 GPT-人類交互的概念。了解任務(wù)可以從完全自動(dòng)化到需要大量人工干預(yù)的范圍，使我們能夠?qū)ο嚓P(guān)挑戰(zhàn)進(jìn)行分類和更好地解決。通過(guò)對(duì)這些任務(wù)進(jìn)行分段，我們可以揭示特定風(fēng)險(xiǎn)，并相應(yīng)地調(diào)整我們的緩解策略。隨后的表格提供了對(duì)這些任務(wù)模式的全面了解，呈現(xiàn)了每種任務(wù)類型的風(fēng)險(xiǎn)和相應(yīng)緩解方法的詳細(xì)分析：

表 7.2: 特定任務(wù)類型的變革管理實(shí)踐

通過(guò) ChatGPT 加速 GPT 項(xiàng)目

典型的 GPT 項(xiàng)目通常由一組經(jīng)驗(yàn)豐富的 GPT 專家團(tuán)隊(duì)執(zhí)行，根據(jù)復(fù)雜性平均需要 12-16 周時(shí)間。

利用 ChatGPT 可以減少 GPT 解決方案開發(fā)生命周期的工作量和持續(xù)時(shí)間。

圖 7.15: 加速 GPT 項(xiàng)目

讓我們分解每個(gè)階段如何可以加快速度：

• 用例定義:

• 自動(dòng)化用例模板填充：ChatGPT 可以利用用例模板向用戶提出具體問(wèn)題，并根據(jù)用戶的輸入自動(dòng)填寫初始模板。

• 一致性和可行性檢查: ChatGPT 配備了參考用例，可以識(shí)別用戶輸入中的不一致或不可行要求。

• 從高級(jí)描述到詳細(xì)規(guī)范：給定一個(gè)高級(jí)描述，ChatGPT 可以生成詳細(xì)的用例規(guī)范，并通過(guò)與用戶的對(duì)話交流逐步完善。

• 解決方案設(shè)計(jì)：

• 從用例自動(dòng)生成設(shè)計(jì)：基于用例規(guī)范，ChatGPT 可以建議流程步驟和組件需求，從根本上創(chuàng)建解決方案設(shè)計(jì)的初稿。

• UI 設(shè)計(jì)集成：ChatGPT 可以與基于 GPT 的 UI 設(shè)計(jì)應(yīng)用集成，根據(jù)用戶需求生成 UI 模型，簡(jiǎn)化用戶體驗(yàn)設(shè)計(jì)。

• 迭代設(shè)計(jì)完善：通過(guò)對(duì)話界面，設(shè)計(jì)可以根據(jù)用戶反饋和 ChatGPT 提出的建議進(jìn)行完善。

• 提示工程：

• 提示生成：使用前兩章定義的模式，ChatGPT 可以為解決方案設(shè)計(jì)中確定的任務(wù)建議初始提示。

• 設(shè)計(jì)清單驗(yàn)證：ChatGPT 可以自動(dòng)檢查設(shè)計(jì)的提示是否符合清單，確保滿足所有必要的標(biāo)準(zhǔn)。

• 輸出驗(yàn)證提示：對(duì)于每個(gè)主要提示，ChatGPT 還可以建議相應(yīng)的驗(yàn)證提示，用于輸出驗(yàn)證階段。

• 解決方案實(shí)施：

• 代碼庫(kù)搜索和推薦：ChatGPT 可以根據(jù)用戶需求搜索現(xiàn)有的代碼庫(kù)，突出潛在的代碼可重用性，并在需要時(shí)建議修改。

• 代碼生成：對(duì)于標(biāo)準(zhǔn)組件，ChatGPT 可以使用代碼生成器生成所需的代碼片段，減少手動(dòng)編碼的工作量。

• 自動(dòng)化文檔：文檔是 GPT 項(xiàng)目生命周期中至關(guān)重要但耗時(shí)的部分。ChatGPT 可以根據(jù)用例規(guī)范、設(shè)計(jì)、代碼和提示自動(dòng)生成文檔。

• 解決方案輸出驗(yàn)證：

• 自動(dòng)輸出驗(yàn)證：ChatGPT 可以執(zhí)行先前選擇的驗(yàn)證提示。

• 集成到生產(chǎn)工具中：ChatGPT 可以集成到現(xiàn)有的辦公工具中，使用戶能夠輕松地驗(yàn)證實(shí)際輸出與預(yù)期輸出并記錄偏差。

• 即時(shí)反饋循環(huán)：當(dāng)用戶驗(yàn)證輸出時(shí)，反饋可以立即傳達(dá)給 ChatGPT，后者可以建議立即進(jìn)行完善，確?？焖俚?/p>

結(jié)論

借鑒對(duì)架構(gòu)和提示模式的探索的見解，本章闡明了開發(fā)和管理 GPT 項(xiàng)目所涉及的全面流程。通過(guò)專注于項(xiàng)目準(zhǔn)備、用例定義、解決方案設(shè)計(jì)、提示工程、解決方案實(shí)施、輸出驗(yàn)證和迭代改進(jìn)等關(guān)鍵階段，我們進(jìn)一步揭示了 GPT 模型在企業(yè)環(huán)境中的適應(yīng)性和多功能性。我們還演示了如何管理 GPT 項(xiàng)目的變革影響，并指出了使用“GPT-for-GPT”方法加速項(xiàng)目的方式。

下一章將解釋我們的第一個(gè) GPT 實(shí)施框架，為基于 Python 的 LangChain 框架提供實(shí)用指南。

關(guān)鍵點(diǎn)

1. 項(xiàng)目準(zhǔn)備：任何成功的 GPT 項(xiàng)目的基礎(chǔ)在于細(xì)致的準(zhǔn)備工作。這包括建立基礎(chǔ)設(shè)施、制定安全政策、培訓(xùn)員工和建立全面的反饋系統(tǒng)。

2. 用例定義：明確定義的用例作為項(xiàng)目執(zhí)行的重要起點(diǎn)，確保清晰的范圍、指定的數(shù)據(jù)需求和利益相關(guān)者的一致性。

3. 解決方案設(shè)計(jì)和提示工程：創(chuàng)建健壯的解決方案設(shè)計(jì)和有效的提示是直接促成 GPT 模型成功的基本階段。

4. 解決方案實(shí)施和輸出驗(yàn)證：功能性解決方案設(shè)計(jì)使用 LangChain 或 Predictive Powers 等實(shí)施框架轉(zhuǎn)化為可工作的解決方案。解決方案輸出通過(guò)使用次級(jí) GPT 模型和人類專家進(jìn)行系統(tǒng)驗(yàn)證。

5. 系統(tǒng)化反饋管理：利用解決方案開發(fā)周期的每個(gè)階段的見解，用于改進(jìn)和完善隨后周期中的前期階段，培養(yǎng)動(dòng)態(tài)改進(jìn)和增強(qiáng)的文化。

6. 定制變更管理：從完全自動(dòng)化到人力密集型的任務(wù)類型的區(qū)分對(duì)于成功部署 GPT 項(xiàng)目在不同的運(yùn)營(yíng)環(huán)境中變得至關(guān)重要。

7. GPT 項(xiàng)目加速：利用 ChatGPT 可以顯著簡(jiǎn)化和加快 GPT 解決方案的開發(fā)生命周期，從用例定義到輸出驗(yàn)證，部分自動(dòng)化關(guān)鍵任務(wù)，促進(jìn)迭代改進(jìn)，并通過(guò)對(duì)話界面增強(qiáng)用戶協(xié)作。

8. 利用 GPT 模型的多功能性和適應(yīng)性：通過(guò)在整個(gè)項(xiàng)目周期中導(dǎo)航，組織可以有效地利用 GPT 模型的多樣化能力，應(yīng)用于各種用例，從簡(jiǎn)單任務(wù)到復(fù)雜工作流程，最大限度地發(fā)揮其在企業(yè)自動(dòng)化中的潛力。

1 本章僅集中于利用 GPT 模型（或類似的人工智能語(yǔ)言模型）的項(xiàng)目特定活動(dòng)。傳統(tǒng)的項(xiàng)目管理和準(zhǔn)備任務(wù)，包括團(tuán)隊(duì)入職、定義可交付成果和利益相關(guān)者對(duì)齊，是有意省略的。

2 Azure OpenAI 服務(wù)在*第一章*中進(jìn)行了簡(jiǎn)要描述，從 GPT-1 到 ChatGPT-4：通向生成人工智能的演進(jìn)，企業(yè)軟件集成部分。有關(guān)詳細(xì)信息，讀者請(qǐng)參閱微軟的相關(guān)網(wǎng)站內(nèi)容。

3 ChatGPT Enterprise 在*第一章*的同名部分進(jìn)行了描述。此外，讀者被要求閱讀有關(guān) OpenAI 網(wǎng)站的信息。

? 微軟已經(jīng)執(zhí)行同步（在 API 調(diào)用執(zhí)行期間）和異步（在 API 調(diào)用執(zhí)行后）的內(nèi)容過(guò)濾機(jī)制。對(duì)于異步檢查，保留相應(yīng)的提示和響應(yīng) 30 天。根據(jù)微軟的政策，它們不用于訓(xùn)練 GPT 模型。

? CapabilityGPT 是推薦的人工智能能力框架，并在*第二章*中進(jìn)行了解釋。

? 架構(gòu)模式在*第四章*中進(jìn)行了描述。

? 高級(jí)提示工程技術(shù)在*第五章和第六章*中進(jìn)行了討論。

? 本章末尾有一個(gè)專門的變更管理部分。

? 模型微調(diào)過(guò)程在*第四章*的‘由 GPT 模型啟用的架構(gòu)模式’中進(jìn)行了描述，作為對(duì)“C1 與微調(diào)模型對(duì)話”的架構(gòu)模式的描述的一部分。建議將預(yù)訓(xùn)練模型的微調(diào)組織為一個(gè)范圍更大、數(shù)據(jù)集更大的單獨(dú)項(xiàng)目，以確保微調(diào)模型學(xué)習(xí)一系列能力，然后可以提示處理該范圍內(nèi)的所有用例。這個(gè)過(guò)程也被稱為多任務(wù)學(xué)習(xí)。

1? 第二章 介紹了 CapabilityGPT，這是一個(gè)具有詳細(xì)描述和每個(gè)十八項(xiàng)能力用例的人工智能能力框架。

11 第五章 提供了指令提示模式的定義和幾個(gè)示例。

12 查詢提示模式也在*第五章*中進(jìn)行了討論。

13 第五章 結(jié)束于多代理提示模式。

1? 第四章，由 GPT 模型實(shí)現(xiàn)的架構(gòu)模式，詳細(xì)描述了每種架構(gòu)模式在應(yīng)用層上所需的組件。

1? 不同類型的代理在*第四章*的‘D 代理模式’部分中有詳細(xì)描述。

1? 所有三種提示模式在*第五章*中有詳細(xì)描述。

1? 這種方法與*第四章*中描述的架構(gòu)模式‘A4 質(zhì)量控制對(duì)話’非常相似，其中首先使用 GPT 模型生成用戶的響應(yīng)，然后以不同的上下文和提示調(diào)用以檢查這些響應(yīng)。

1? LLM 代表大型語(yǔ)言模型。

第八章：LangChain：Python 的 GPT 實(shí)現(xiàn)框架

介紹

本章討論了在 Python 中使用 ChatGPT 的gpt-3.5-turbo等大型語(yǔ)言模型（LLMs），并介紹了一種名為 LangChain [12]的開創(chuàng)性框架。LangChain 通過(guò)其專門設(shè)計(jì)的組件，為與 LLMs 合作而量身定制，允許實(shí)現(xiàn) CapabilityGPT 框架中的所有 18 種能力。它通過(guò)允許將預(yù)先學(xué)習(xí)的模型知識(shí)與實(shí)時(shí)信息相結(jié)合，提高了與大型語(yǔ)言模型合作的可靠性。借助 LangChain，LLMs 可以與數(shù)據(jù)庫(kù)、API、云平臺(tái)和其他基于 API 的資源等各種實(shí)體進(jìn)行交互，從而實(shí)現(xiàn)特定目標(biāo)。因此，LangChain 簡(jiǎn)化和流暢了開發(fā)全面應(yīng)用的過(guò)程。

本章對(duì)構(gòu)成該框架的不同組件進(jìn)行了解釋。這些組件包括模式、模型、數(shù)據(jù)處理、鏈、內(nèi)存處理和代理。通過(guò)探索這些組件中的每一個(gè)，讀者將全面了解 LangChain 作為一個(gè)整體的功能。為了進(jìn)一步增進(jìn)他們的理解，我們還將通過(guò)三個(gè)示例用例提供這些組件如何被利用的實(shí)際演示。這些演示將包括 Python 代碼片段和每個(gè)步驟的詳細(xì)解釋。

第一個(gè)用例探討了 LangChain 如何使法律專家受益，并通過(guò)利用 GPT 模型系列中 LLM 的創(chuàng)建和轉(zhuǎn)換能力來(lái)增強(qiáng)他們的生產(chǎn)力和成功。我們將提供一個(gè)實(shí)際的例子，演示語(yǔ)義搜索在幫助律師找到相關(guān)先前案例方面的應(yīng)用。這使他們能夠有效地為即將到來(lái)的審判做準(zhǔn)備，最終提高他們?cè)诜ㄍド系谋憩F(xiàn)。

在第二個(gè)用例中，我們探討了 LangChain 如何實(shí)現(xiàn)從各種文本數(shù)據(jù)源無(wú)縫檢索數(shù)據(jù)。具體來(lái)說(shuō)，我們提供了一種解決方案，允許自動(dòng)化專家參與有關(guān)控制器的聊天對(duì)話。簡(jiǎn)單解釋一下，控制器本質(zhì)上是一種管理過(guò)程以實(shí)現(xiàn)和維持期望參數(shù)的設(shè)備。例如，在溫度控制系統(tǒng)中，恒溫器通過(guò)監(jiān)測(cè)當(dāng)前溫度并調(diào)整加熱或冷卻設(shè)備以保持設(shè)定溫度來(lái)充當(dāng)控制器。

該解決方案利用了 CapabilityGPT 框架中描述的基本能力，如問(wèn)答、溝通和摘要。這次對(duì)話所需的信息以 PDF 格式提供，其中包括控制器手冊(cè)。LangChain 簡(jiǎn)化了瀏覽和利用這些信息的過(guò)程。

我們提出的最后一個(gè)例子集中在實(shí)時(shí)價(jià)格檢查，這可以通過(guò)使企業(yè)及時(shí)了解并保持競(jìng)爭(zhēng)力而極大地使其受益。本章深入探討了 LangChain 代理如何結(jié)合 LLM 的推理能力和工具的執(zhí)行能力，并提供準(zhǔn)確和最新的價(jià)格信息。在這個(gè)例子中，代理將利用各種 GPT 功能，如規(guī)劃、評(píng)估、問(wèn)答、摘要和溝通。這使企業(yè)能夠做出符合當(dāng)前市場(chǎng)條件的明智決策，最終提高其競(jìng)爭(zhēng)力和成功。

通過(guò)本章的學(xué)習(xí)，讀者將全面了解 LangChain 的工作原理及其潛在應(yīng)用。這些知識(shí)將為進(jìn)一步的自學(xué)打下基礎(chǔ)，讀者可以深入研究技術(shù)方面并探索更高級(jí)的用例。無(wú)論您是希望優(yōu)化業(yè)務(wù)運(yùn)營(yíng)的商業(yè)領(lǐng)袖，對(duì)最新人工智能技術(shù)感興趣的 IT 專業(yè)人士，還是渴望探索可能性的人工智能愛(ài)好者，本章都將為您提供導(dǎo)航 LangChain 世界所需的知識(shí)。

結(jié)構(gòu)

在本章中，將涵蓋以下主題：

• 介紹 LangChain

• LangChain 的組成部分：

• 模式

• 模型

• 數(shù)據(jù)處理

• 鏈

• 內(nèi)存處理

• 代理

• 示例 1：律師的準(zhǔn)備助手

• 示例 2：通過(guò)控制器手冊(cè)進(jìn)行聊天

• 示例 3：使用代理進(jìn)行當(dāng)前價(jià)格檢查

介紹 LangChain：釋放大型語(yǔ)言模型的潛力

LLM 的強(qiáng)大源自于它們?cè)诖罅繑?shù)據(jù)上的訓(xùn)練，除其他因素外。然而，重要的是要理解，LLM 通常不是最新的。這是因?yàn)樗鼈兪窃谔囟〝?shù)據(jù)集上訓(xùn)練的，這些數(shù)據(jù)集可能不包括最新信息。盡管經(jīng)過(guò)大量數(shù)據(jù)的訓(xùn)練，LLM 在某些領(lǐng)域的專業(yè)知識(shí)上仍可能存在困難。

此外，由于其令牌限制（最大令牌限制決定了模型可以處理的輸入范圍和生成的輸出范圍），它們?cè)谔幚泶罅课谋緯r(shí)存在限制。在某些情況下，開發(fā)應(yīng)用程序可能需要根據(jù)預(yù)算和要求使用不同的 LLM。這就是像 LangChain 這樣的綜合框架可以發(fā)揮作用的地方，因?yàn)樗峁┝诉m應(yīng)各種需求和預(yù)算的解決方案。

LangChain 框架是一個(gè)基于 Python 的工具，可以實(shí)現(xiàn)充分利用大型語(yǔ)言模型的能力來(lái)創(chuàng)建應(yīng)用程序。它提供了開發(fā)復(fù)雜應(yīng)用程序所需的所有組件。

LangChain 不僅僅是語(yǔ)言模型的簡(jiǎn)單接口。它不僅允許我們利用不同的語(yǔ)言模型，還與各種實(shí)體進(jìn)行交互，如數(shù)據(jù)庫(kù)、API、云平臺(tái)和其他基于 API 的資源。這些交互擴(kuò)展了語(yǔ)言模型的能力，并實(shí)現(xiàn)了高級(jí)應(yīng)用程序的創(chuàng)建。

LangChain 的主要支柱是組件、用例特定鏈和代理。

• 組件

在復(fù)雜應(yīng)用中使用大型語(yǔ)言模型涉及使用特定概念。這些概念包括為提示創(chuàng)建模板，利用各種工具，訪問(wèn)數(shù)據(jù)源并處理數(shù)據(jù)，管理內(nèi)存等。在 LangChain 中，這些概念被稱為組件。組件是使使用這些功能更容易的類或函數(shù)。它們已經(jīng)構(gòu)建好，準(zhǔn)備供開發(fā)人員使用。這些組件旨在易于實(shí)現(xiàn)，無(wú)論您是將 LangChain 用于整個(gè)項(xiàng)目還是僅用于其中的某些部分。

• 用例特定鏈

鏈以結(jié)構(gòu)化的方式實(shí)現(xiàn)了上述組件的無(wú)縫集成。它們特別設(shè)計(jì)用于在特定場(chǎng)景中最大化性能。將組件鏈接在一起的概念既簡(jiǎn)單又有影響力。它極大地簡(jiǎn)化了復(fù)雜應(yīng)用程序的實(shí)現(xiàn)，從而提高了調(diào)試、維護(hù)和應(yīng)用程序整體增強(qiáng)的便利性。

• 代理

該框架旨在能夠以代理方式工作。在日常生活中，代理是幫助實(shí)現(xiàn)特定目標(biāo)的人或事物。在 LangChain 中，代理可以被視為將任務(wù)分解為較小步驟的 LLM。然后，它使用各種工具和其他 LLM 來(lái)實(shí)現(xiàn)任務(wù)的主要目標(biāo)。

為開發(fā)人員設(shè)置應(yīng)用程序可能是一個(gè)復(fù)雜和耗時(shí)的任務(wù)。然而，通過(guò)使用組件、鏈和代理，這個(gè)過(guò)程變得更加簡(jiǎn)單和快速。通過(guò)利用這些工具，開發(fā)人員能夠節(jié)省寶貴的時(shí)間和精力，從而更多地專注于應(yīng)用程序的實(shí)際開發(fā)和定制。這將提高生產(chǎn)率并加快上市時(shí)間。

LangChain 的組件

要有效地利用 LangChain，熟悉其主要元素至關(guān)重要。本節(jié)旨在全面介紹這些組件，為理解 LangChain 的工作提供堅(jiān)實(shí)的基礎(chǔ)。

模式

讓我們討論在使用 LangChain 時(shí)會(huì)遇到的基本數(shù)據(jù)類型。這些包括文本、聊天消息、示例和文檔。在語(yǔ)言模型的世界中，文本是主要的交流方式。LangChain 作為 LLMs 和各種實(shí)體之間的橋梁，專門設(shè)計(jì)為優(yōu)先考慮基于文本的界面。

隨著聊天界面的流行，某些模型提供商開始提供專門的 API，期望聊天消息而不是純文本。聊天消息數(shù)據(jù)類型由兩部分組成——內(nèi)容字段，通常是文本本身，以及與之關(guān)聯(lián)的用戶。目前，LangChain 支持系統(tǒng)、人類和 AI 等用戶，引入了不同類型的聊天消息，即系統(tǒng)聊天消息（用于主提示）、人類聊天消息和 AI 聊天消息。這種格式目前適用于 GPT-3.5-turbo 和 GPT-4 系列的所有語(yǔ)言模型。

我們可能使用的另一種數(shù)據(jù)類型是示例。它是表示函數(shù)輸入和預(yù)期輸出的輸入和輸出對(duì)。示例經(jīng)常被納入提示中，以更好地引導(dǎo) LLM 提供的答案。

最后，LangChain 利用文檔。文檔包括稱為頁(yè)面內(nèi)容的非結(jié)構(gòu)化數(shù)據(jù)，以及描述其屬性的元數(shù)據(jù)。

模型 I/O

LangChain 的核心圍繞著其模型展開，這些模型作為整個(gè)框架的基礎(chǔ)。這些模型為互動(dòng)提供了必要的元素和構(gòu)建模塊。在討論與模型的工作時(shí)，我們將分為三個(gè)部分：模型、提示和輸出解析器。

語(yǔ)言模型

LangChain 提供兩種類型的模型：語(yǔ)言模型和聊天模型。語(yǔ)言模型接受原始輸入并輸出一個(gè)字符串，而聊天模型接受標(biāo)記為系統(tǒng)、AI 和用戶的聊天消息列表作為輸入，并生成另一個(gè)標(biāo)記為 AI 的聊天消息。系統(tǒng)角色通過(guò)提供高級(jí)指令和上下文來(lái)引導(dǎo)模型的行為，從而構(gòu)建整個(gè)互動(dòng)。AI 角色與用戶互動(dòng)，回答查詢。最后，用戶角色代表與模型互動(dòng)的個(gè)體，給出指示并參與對(duì)話。語(yǔ)言模型和聊天模型都有自己的接口。

如果您的應(yīng)用程序需要與語(yǔ)言模型和聊天模型一起工作，LangChain 開發(fā)了一個(gè)名為基礎(chǔ)語(yǔ)言模型的解決方案。這個(gè)接口允許您無(wú)縫地集成模型。此外，如果您想為自己的 LLM 創(chuàng)建自定義包裝器，或者使用 LangChain 不支持的包裝器，也支持這個(gè)選項(xiàng)。

如果您想在生成響應(yīng)時(shí)向用戶顯示響應(yīng)，而不是等待整個(gè)答案生成并一次性發(fā)送，您可以使用特殊的流式類。但請(qǐng)注意，流式響應(yīng)僅受到某些模型的支持。

提示

有效的結(jié)構(gòu)化提示是釋放 GPT 模型巨大潛力的關(guān)鍵。為了適應(yīng)不同的用例，我們可以采用一系列提示模式，例如指令提示、指令序列提示、查詢提示、請(qǐng)求提示、合作提示或其他在之前的*第五章，高級(jí)提示工程技術(shù)*中提到的特殊提示。

為了簡(jiǎn)化創(chuàng)建提示并有效管理它們的不同部分的過(guò)程，LangChain 引入了提示模板。這些模板作為一種結(jié)構(gòu)化的方式來(lái)一致地生成提示。它們本質(zhì)上是接受一組參數(shù)的字符串，然后由模型用于處理。目前，在 LangChain 中，這些字符串可以使用兩種語(yǔ)法來(lái)組成：f-strings 和 Jinja。

如果您決定使用聊天模型，應(yīng)該使用專門的聊天提示模板。這些模板針對(duì)聊天模型輸入進(jìn)行了優(yōu)化，并與原始字符串不同，原始字符串直接傳遞給語(yǔ)言模型。在聊天消息中，每條消息都與一個(gè)角色相關(guān)聯(lián)：系統(tǒng)、用戶或 AI。此外，還有少量提示模板，允許在我們的提示中包含示例。如果默認(rèn)提示模板不符合您的特定需求，您還可以創(chuàng)建自定義提示模板。例如，您可能希望創(chuàng)建一個(gè)具有針對(duì)您語(yǔ)言模型的動(dòng)態(tài)指令的提示模板。在這種情況下，自定義提示模板提供了靈活性和定制選項(xiàng)。

輸出解析器

無(wú)論我們是在處理語(yǔ)言模型還是聊天模型，它們都會(huì)生成文本作為輸出。為了以所需格式組織或結(jié)構(gòu)化這些輸出，我們使用輸出解析器。這些輸出解析器使我們能夠以各種格式獲取輸出，例如逗號(hào)分隔列表、日期時(shí)間、枚舉或 JSON。

如果您希望輸出多個(gè)自定義文本字段，可以利用結(jié)構(gòu)化輸出解析器。另一個(gè)選擇是使用更強(qiáng)大的 Pydantic（JSON）解析器。但是，它需要具有足夠容量的 LLM 來(lái)生成格式良好的 JSON。值得注意的是，在某些模型系列中，一些模型擅長(zhǎng)生成 JSON，而其他模型可能表現(xiàn)不佳。例如，像text-davinci-003、gpt-3.5-turbo或gpt-4這樣的模型可以一致地生成結(jié)構(gòu)良好的 JSON，而text-curie-001在這方面的熟練程度顯著降低。

此外，還有一個(gè)可用的自動(dòng)修復(fù)解析器。如果初始結(jié)果不正確或包含錯(cuò)誤，它會(huì)自動(dòng)調(diào)用另一個(gè)解析器。

數(shù)據(jù)連接

使用獨(dú)立的 LLM 的主要挑戰(zhàn)之一是它們只能訪問(wèn)它們專門訓(xùn)練過(guò)的數(shù)據(jù)。為了克服這一限制并使它們能夠使用最新信息，我們必須將它們連接到其他數(shù)據(jù)源。幸運(yùn)的是，LangChain 提供了有效的組件，可以輕松地與各種數(shù)據(jù)源進(jìn)行交互（詳細(xì)探討了用于訪問(wèn)企業(yè)特定數(shù)據(jù)源的 A2-A4 架構(gòu)模式，請(qǐng)參閱*第四章，由 GPT 模型啟用的架構(gòu)模式*）。

數(shù)據(jù)加載器

與外部數(shù)據(jù)源一起工作的一個(gè)重要方面是使用數(shù)據(jù)加載器。這些加載器的重要任務(wù)是將不同類型的數(shù)據(jù)加載到稱為文檔的特定結(jié)構(gòu)中。文檔包含文本和與之相關(guān)的元數(shù)據(jù)。已經(jīng)創(chuàng)建了幾個(gè)加載器來(lái)處理各種數(shù)據(jù)源。這些加載器使得從文本文件、CSV 文件、JSON 文件、GitBooks、Azure Blob 容器、YouTube 轉(zhuǎn)錄等加載數(shù)據(jù)變得方便。使用這些加載器極大地簡(jiǎn)化了數(shù)據(jù)加載過(guò)程。

數(shù)據(jù)轉(zhuǎn)換器

一旦成功將數(shù)據(jù)導(dǎo)入文檔對(duì)象，您可以開始轉(zhuǎn)換過(guò)程，以滿足應(yīng)用程序的需求。一種常見的轉(zhuǎn)換類型是將文檔分成稱為塊的較小部分，這些塊與您選擇的 LLM 的上下文窗口對(duì)齊。例如，如果您打算使用 4 個(gè)塊作為上下文，并分配 2000 個(gè)標(biāo)記用于上下文，您可能希望將您的文檔分成每個(gè) 500 個(gè)標(biāo)記的塊。對(duì)于英文文本，1 個(gè)標(biāo)記大約是 4 個(gè)字符或 0.75 個(gè)單詞。

此外，您還可以選擇自動(dòng)提取與每個(gè)塊相關(guān)的特征或元數(shù)據(jù)。然后可以利用這些提取的細(xì)節(jié)來(lái)執(zhí)行各種任務(wù)，如分類或摘要。

文本嵌入模型

嵌入意味著將文本表示為矢量，這是在轉(zhuǎn)換文檔時(shí)我們可以考慮的另一種方法。LangChain 中這種方法的實(shí)現(xiàn)是簡(jiǎn)單而高效的。LangChain 提供了一個(gè)標(biāo)準(zhǔn)接口，可以與各種嵌入模型提供商一起使用。

需要注意的是，不同的嵌入提供商可能采用不同的嵌入查詢和文檔的技術(shù)。為了解決這個(gè)問(wèn)題，LangChain 采用了類似的方法，并為嵌入每個(gè)方法提供了不同的方法。通過(guò)這樣做，LangChain 確保了在與各種嵌入提供商合作時(shí)的兼容性和靈活性，使用戶能夠無(wú)縫地將他們喜歡的嵌入技術(shù)集成到他們的工作流程中。

矢量存儲(chǔ)

在大量非結(jié)構(gòu)化文本中搜索特定信息是 LangChain 的常見用例。為了解決這個(gè)任務(wù)，一個(gè)方法是首先將非結(jié)構(gòu)化文本分解成文檔類型的塊。然后將這些文檔轉(zhuǎn)換為數(shù)字列表（矢量）并存儲(chǔ)在一個(gè)稱為矢量存儲(chǔ)的特殊數(shù)據(jù)庫(kù)中。

為了找到所需的信息，查詢也被轉(zhuǎn)換為矢量表示，并與矢量存儲(chǔ)中的每個(gè)矢量進(jìn)行比較。選擇過(guò)程涉及識(shí)別與查詢最相似的文檔。相似性是利用余弦相似度或歐氏距離等度量來(lái)計(jì)算的。余弦相似度通過(guò)測(cè)量?jī)蓚€(gè)矢量之間的夾角的余弦來(lái)確定兩個(gè)矢量之間的相似性，而歐氏距離則計(jì)算空間中兩點(diǎn)之間的直線距離。

矢量存儲(chǔ)作為一個(gè)數(shù)據(jù)庫(kù)，可以存儲(chǔ)文檔的矢量表示和它們的元數(shù)據(jù)。LangChain 的特殊之處在于它與各種開源矢量存儲(chǔ)的兼容性，以及它與不同付費(fèi)矢量存儲(chǔ)提供商的集成能力。

檢索器

一旦我們的相似性搜索完成，我們可以利用檢索器來(lái)檢索與查詢相關(guān)的文檔。檢索器功能使我們能夠根據(jù)相似性搜索結(jié)果有效地檢索相關(guān)文檔。

鏈

前面提到的功能可以被視為提供便利的附加功能，但 LangChain 的真正優(yōu)勢(shì)在于其鏈。雖然單獨(dú)使用語(yǔ)言模型適用于簡(jiǎn)單的應(yīng)用程序，但在開發(fā)更復(fù)雜的應(yīng)用程序時(shí)，使用多個(gè) LLM 或 LLM 和其他組件的組合是必不可少的。LangChain 通過(guò)引入鏈來(lái)簡(jiǎn)化這個(gè)過(guò)程。

有各種類型的鏈。它們特別設(shè)計(jì)用于快速實(shí)現(xiàn)特定用例，這就是它們?cè)趶?fù)雜性上的差異所在。最基本的類型是 LLM 鏈，它由提示模板和語(yǔ)言模型組成。這個(gè)鏈的目的是將給定的輸入值格式化為提示，使用準(zhǔn)備好的提示執(zhí)行 LLM，最后返回輸出。

另一個(gè)常用的鏈?zhǔn)呛?jiǎn)單順序鏈。在這種類型中，初始調(diào)用后會(huì)對(duì)同一個(gè)或不同的語(yǔ)言模型進(jìn)行一系列調(diào)用。當(dāng)一個(gè)調(diào)用的輸出需要作為另一個(gè)調(diào)用的輸入時(shí)，這是特別有用的（參見*第四章，由 GPT 模型實(shí)現(xiàn)的架構(gòu)模式*中的 C2、D1 和 D2 模式）。

檢索問(wèn)答鏈?zhǔn)橇硪环N流行的類型，它涉及接受一個(gè)問(wèn)題，使用檢索器檢索相關(guān)文檔，然后將這些文檔作為上下文提供給 LLM 來(lái)回答問(wèn)題。還有 SQL 數(shù)據(jù)庫(kù)鏈，專門用于回答 SQL 數(shù)據(jù)庫(kù)上的問(wèn)題，以及摘要鏈，用于對(duì)多個(gè)文檔進(jìn)行摘要。

這只是一些例子，但還有許多其他可能性。此外，用戶可以通過(guò)對(duì) Chain 類進(jìn)行子類化來(lái)創(chuàng)建自己定制的鏈。

內(nèi)存

默認(rèn)情況下，大型語(yǔ)言模型被設(shè)計(jì)為無(wú)狀態(tài)的。這意味著每個(gè)接收到的查詢都是獨(dú)立處理的，不考慮先前的查詢或?qū)υ挕Ｈ欢?，在某些?yīng)用程序中，比如虛擬助手，有必要訪問(wèn)對(duì)話的上下文，以更好地理解用戶的意圖并提供與先前查詢相關(guān)的響應(yīng)。為了更好地理解這一點(diǎn)，讓我們來(lái)探討以下對(duì)話：

用戶: 大腦的估計(jì)計(jì)算能力是多少？

AI: 大腦的計(jì)算能力極其復(fù)雜，難以精確量化，但一些粗略估計(jì)表明它可能在 10^18 到 10^26 浮點(diǎn)運(yùn)算每秒（FLOPS）的范圍內(nèi)。

用戶: 為什么難以量化？

AI: “難以量化”的說(shuō)法是用來(lái)描述情況的常見短語(yǔ)，其中…

如果用戶詢問(wèn)大腦的估計(jì)計(jì)算能力，AI 模型可能會(huì)根據(jù)現(xiàn)有知識(shí)提供一個(gè)一般性答案。然而，當(dāng)用戶跟進(jìn)提問(wèn)時(shí)，AI 可能會(huì)在沒(méi)有訪問(wèn)先前交互的情況下難以理解引用。

示例中的問(wèn)題與指代消解有關(guān)。指代消解涉及識(shí)別句子中指代同一事物的詞語(yǔ)。在這種情況下，“it”和“computing power”就是這樣的詞語(yǔ)。語(yǔ)言模型的缺乏記憶和狀態(tài)的無(wú)關(guān)性導(dǎo)致了無(wú)關(guān)的答案。為了解決這個(gè)問(wèn)題，必須管理完整對(duì)話或至少部分對(duì)話的記憶是至關(guān)重要的。LangChain 提供了一些方法來(lái)協(xié)助解決這個(gè)問(wèn)題。這些方法提供了一系列針對(duì)不同類型交互的選擇。在傳遞數(shù)據(jù)時(shí)，考慮每次調(diào)用的令牌限制是很重要的，因?yàn)榭赡軙?huì)有包含的信息量的限制。例如，如果預(yù)計(jì)交互會(huì)很簡(jiǎn)短，整個(gè)對(duì)話可以傳遞給下一個(gè)提示，或者如果預(yù)計(jì)交互會(huì)很長(zhǎng)，可以使用摘要版本。所有這些方法使模型能夠根據(jù)上下文理解并回應(yīng)對(duì)話，從而提高其能力。

代理

有時(shí)，為了為用戶服務(wù)，我們需要根據(jù)不可預(yù)測(cè)的輸入來(lái)確定行動(dòng)。這就是代理變得有用的地方。代理充當(dāng)一個(gè)有用的助手，不僅代表我們執(zhí)行任務(wù)，還考慮需要執(zhí)行哪些子任務(wù)以及以何種順序執(zhí)行。

在 LangChain 中，代理可以被視為將任務(wù)分解為較小步驟的 LLMs。它們利用各種工具和其他 LLMs 來(lái)實(shí)現(xiàn)任務(wù)的最終目標(biāo)。

代理的第一個(gè)組成部分是編排代理，簡(jiǎn)單來(lái)說(shuō)就是“經(jīng)理”LLM。這個(gè) LLM 處理所有認(rèn)知過(guò)程，包括制定步驟、分析輸出、必要時(shí)調(diào)整計(jì)劃，并確定下一步行動(dòng)。

此外，代理還可以使用工具。這些工具可以從簡(jiǎn)單的計(jì)算器到其他 LLM、SERP（搜索引擎結(jié)果頁(yè)面）API 或 JsonGetValueTool 等更高級(jí)的工具。還有包含多個(gè)相同類別工具的綜合工具包，如 Zapier Toolkit、OpenAPI Agent Toolkit 或 JSON Agent Toolkit。每個(gè)工具都附有描述性文本標(biāo)簽，由“經(jīng)理”LLM 用于了解該工具是否適用于即將到來(lái)的步驟。

總之，一個(gè)代理包括一個(gè)“經(jīng)理”LLM，它決定完成任務(wù)所需的子動(dòng)作，然后使用一系列工具和工具包來(lái)執(zhí)行每個(gè)步驟。

有兩種類型的代理如下：

• 行動(dòng)代理：這些代理根據(jù)所有先前工具的輸出在每個(gè)時(shí)間步驟上做出決策。它們非常適合高效處理小任務(wù)。

• 計(jì)劃和執(zhí)行代理：相比之下，計(jì)劃和執(zhí)行代理事先制定整個(gè)行動(dòng)計(jì)劃，并在執(zhí)行過(guò)程中不改變計(jì)劃。這種類型的代理非常適合有效地處理復(fù)雜任務(wù)。

還可以通過(guò)允許計(jì)劃和執(zhí)行代理利用行動(dòng)代理來(lái)結(jié)合這兩種類型。這種混合方法使代理能夠從兩種代理類型的優(yōu)勢(shì)中受益。

【示例】

LangChain 提供了一系列出色的工具，大大加快了開發(fā)過(guò)程。通過(guò)利用鏈和代理等各種組件，整個(gè)過(guò)程變得更加簡(jiǎn)單和快速，節(jié)省時(shí)間和精力。這使個(gè)人能夠?qū)Ｗ⒂诶斫庑枨蟛?shí)際構(gòu)建所需的解決方案。使用 LangChain 時(shí)，有許多優(yōu)勢(shì)可以獲得。它允許充分利用所有CapabilityGPT 的優(yōu)勢(shì)-簡(jiǎn)化操作、節(jié)省成本、改善決策等等。為了充分理解 LangChain 的潛力，讓我們通過(guò)探索現(xiàn)實(shí)世界的例子來(lái)深入了解其組成部分。

【示例 1：律師的準(zhǔn)備助手】

現(xiàn)在，讓我們探討 LangChain 在創(chuàng)建一個(gè)幫助律師進(jìn)行審前準(zhǔn)備的應(yīng)用程序的實(shí)際用例。為了有效準(zhǔn)備，律師通常需要研究過(guò)去的案例。然而，要找到與他們目前正在處理的案件類似的相關(guān)案例可能是具有挑戰(zhàn)性的。我們的目標(biāo)是開發(fā)一個(gè)能夠根據(jù)律師對(duì)他們特定需求的描述來(lái)檢索包含過(guò)去案例的文件的應(yīng)用程序。

例如，應(yīng)用程序應(yīng)能夠列出所有與誹謗或經(jīng)濟(jì)損失有關(guān)的案件。僅依靠簡(jiǎn)單的關(guān)鍵詞搜索可能無(wú)法產(chǎn)生準(zhǔn)確的結(jié)果。

為了克服這一局限性，我們將采用一種更先進(jìn)的方法，稱為語(yǔ)義搜索。在下面的例子中，我們將演示一種流行的方法，該方法從嵌入文檔和律師的查詢開始。文本嵌入是文本的數(shù)值表示，使機(jī)器能夠理解和處理自然語(yǔ)言。它們將單詞或短語(yǔ)轉(zhuǎn)換為一系列數(shù)字（向量），具有語(yǔ)義相似性的項(xiàng)目具有相似的值。

在語(yǔ)義搜索中，這使系統(tǒng)能夠根據(jù)語(yǔ)義相似性而不僅僅是關(guān)鍵詞匹配來(lái)將用戶的查詢與相關(guān)文檔進(jìn)行匹配。通過(guò)使用文本嵌入，系統(tǒng)可以理解微妙的含義，并提高搜索結(jié)果的相關(guān)性，提供更高效和有效的搜索體驗(yàn)。

因此，一旦我們嵌入了所有文檔（轉(zhuǎn)換為數(shù)字列表，即向量）并存儲(chǔ)在向量存儲(chǔ)中，我們嵌入查詢并計(jì)算查詢與每個(gè)文檔之間的語(yǔ)義接近度。我們將使用的度量標(biāo)準(zhǔn)稱為余弦相似度，它是兩個(gè)向量之間的夾角的余弦。具有最高余弦相似度的文檔將成為我們的搜索結(jié)果。

盡管如此，為了說(shuō)明這個(gè)應(yīng)用程序的功能，我們首先需要生成一組我們可以使用的樣本民事案件。

內(nèi)容生成

使用語(yǔ)言模型或 LangChain 的模型組件中的聊天模型可以生成案例。在這種情況下，我們將使用 OpenAI 的 GPT-3 家族text-003-davinci模型*的語(yǔ)言模型。為了有效地演示輸出解析器的使用，我們將采用一個(gè)兩步的方法。最初，我們將創(chuàng)建一個(gè)表示每個(gè)案例各種內(nèi)容的不同名稱列表。

隨后，使用相同的模型，我們將為民事案件生成內(nèi)容并將其保存在一個(gè) docx 文件中。

生成名稱列表

讓我們從一些有用的導(dǎo)入和函數(shù)定義開始：

from LangChain import PromptTemplate

from LangChain.llms import OpenAI

from LangChain.chains import LLMChain

from LangChain.output_parsers import CommaSeparatedListOutputParser

import os

從 docx 導(dǎo)入文檔

from typing import List

def generate_civil_cases_names() -> List[str]:

在這種特殊情況下，我們的目標(biāo)是在單個(gè)請(qǐng)求期間保持在 Open AI 模型令牌限制內(nèi)創(chuàng)建大約 60-80 個(gè)民事案件的名稱。為了實(shí)現(xiàn)這一目標(biāo)，我們將利用 Python f-string。我們將包括一個(gè)名為**number_of_cases**的變量，以便在需要修改指定生成案例數(shù)量的數(shù)量時(shí)使用。

generate_civil_cases_names_template = “””

你是一名律師和法律專家。生成{number_of_cases}個(gè)民事案件名稱。\n{format_instructions}

“””

為了以列表格式實(shí)現(xiàn)所需的輸出，我們可以利用 LangChain 的列表解析器。這個(gè)解析器旨在返回一個(gè)逗號(hào)分隔的項(xiàng)目列表。然而，為了獲得正確的輸出，有兩個(gè)重要的步驟需要遵循：

步驟 1：為提示定義格式說(shuō)明

第一步涉及調(diào)用**ComaSeparatedListOutputParser()**類對(duì)象。這個(gè)對(duì)象將允許我們?cè)L問(wèn)**get_format_instructions**方法。通過(guò)在對(duì)象上調(diào)用這個(gè)方法，我們可以檢索包含格式說(shuō)明的字符串，稍后將其合并到我們的提示中：

output_parser = CommaSeparatedListOutputParser()

format_instructions = output_parser.get_format_instructions()

步驟 2：格式化實(shí)際輸出

一旦我們獲得了輸出，我們將繼續(xù)格式化從模型獲得的文本。

讓我們討論一下提示的創(chuàng)建。要使用提示，我們必須創(chuàng)建**PromptTemplate**類的一個(gè)實(shí)例。這涉及指定模板、輸入變量和部分變量以及格式說(shuō)明的指令：

prompt = PromptTemplate(

template=generate_civil_cases_names_template,

input_variables=[“number_of_cases”],

partial_variables={“format_instructions”: format_instructions},

)

為了繼續(xù)，定義一個(gè)模型是至關(guān)重要的。為了我們的目的，我們利用了一個(gè) Open AI 模型，盡管 LangChain 支持許多其他備選方案。OpenAI 類對(duì)象中的標(biāo)準(zhǔn)模型是**text-davinci-003**。**temperature**和**max_tokens**是控制模型輸出的參數(shù)。**Temperature**確定生成文本的隨機(jī)性，而**max_tokens**是在提示和完成之間生成的最大標(biāo)記數(shù)。

model = OpenAI(temperature=0.9, max_tokens=4000)

下一步是將輸入傳遞給模型：

_input = prompt.format(number_of_cases=”80”)

輸出 = 模型（_ 輸入）

最后，我們解析輸出以獲得民事案件流程的列表對(duì)象：

processes_list = output_parser.parse(output)

return list_of_processes

現(xiàn)在我們有了一系列民事案件名稱，我們將生成內(nèi)容。

生成民事案件內(nèi)容

首先，讓我們?yōu)槲覀兊拿袷掳讣?chuàng)建一個(gè)目錄：

def 生成民事案件（processes_list）：

if not os.path.exists(“civil_cases”):

os.makedirs(“civil_cases”)

我們希望以可重復(fù)的方式生成每個(gè)民事案件，這就是為什么我們?cè)俅问褂锰崾灸０?。我們使用了一個(gè)包含變量**civil_case_name**的 Python f-string，它將在每次迭代中更改：

generate_civil_case_template = “””

你是一名律師和法律專家。生成民事案件內(nèi)容：{civil_case_name}。包括標(biāo)題，當(dāng)事人的全名，背景，主張，證據(jù)，法律問(wèn)題和程序狀態(tài)。

“””

當(dāng)我們有簡(jiǎn)單的用例時(shí)，單獨(dú)使用 LLMs 就可以了。但是，隨著應(yīng)用變得更加復(fù)雜，鏈?zhǔn)?LLMs 可能會(huì)派上用場(chǎng)。讓我們看看如何實(shí)現(xiàn)一個(gè)簡(jiǎn)單的**LLMChain**，它接受一個(gè)提示模板，用用戶輸入進(jìn)行格式化，并從 LLM 返回一個(gè)響應(yīng)。

llm = OpenAI(溫度=0.9，最大標(biāo)記=4000)

提示 = PromptTemplate(

input_variables=[“civil_case_name”],

template=generate_civil_case_template,

)

chain = LLMChain(llm=llm, prompt=prompt)

我們?cè)谘h(huán)中調(diào)用鏈，以生成并保存民事案件：

對(duì)于 i, process in enumerate(list_of_processes, start=1):

legal_process_content = chain.run(process)

doc = Document()

doc.add_paragraph(legal_process_content)

doc.save(f”civil_cases/civil_case_{i}.docx”)

以下是完整的代碼供參考：

從 LangChain 導(dǎo)入 PromptTemplate

from LangChain.llms import OpenAI

from LangChain.chains import LLMChain

從 LangChain.output_parsers 導(dǎo)入 CommaSeparatedListOutputParser

導(dǎo)入 os

from docx import Document

from typing import List

def 生成民事案件名稱（）-> List[str]：

generate_civil_cases_names_template = “””

你是一名律師和法律專家。生成 {number_of_cases} 民事案件名稱。\n{format_instructions}

“””

``output_parser = CommaSeparatedListOutputParser()`

format_instructions = output_parser.get_format_instructions()

提示 = PromptTemplate(

template=generate_civil_cases_names_template,

input_variables=[“number_of_cases”],

partial_variables={“format_instructions”: format_instructions},

)

模型 = OpenAI(溫度=0.9，最大標(biāo)記=4000)

_ 輸入 = prompt.format(number_of_cases=”80”)

輸出 = 模型（_ 輸入）

processes_list = output_parser.parse(output)

``return list_of_processes`

def 生成民事案件（processes_list）：

if not os.path.exists(“civil_cases”):

os.makedirs(“civil_cases”)

``generate_civil_case_template = “””`

你是一名律師和法律專家。生成民事案件內(nèi)容：{civil_case_name}。包括標(biāo)題，當(dāng)事人的全名，背景，主張，證據(jù)，法律問(wèn)題和程序狀態(tài)。

“””

llm = OpenAI(溫度=0.9，最大標(biāo)記=4000)

提示 = PromptTemplate(

input_variables=[“civil_case_name”],

template=generate_civil_case_template,

)

chain = LLMChain(llm=llm, prompt=prompt)

對(duì)于 i, process in enumerate(list_of_processes, start=1):

legal_process_content = chain.run(process)

doc = Document()

doc.add_paragraph(legal_process_content)

doc.save(f”civil_cases/civil_case_{i}.docx”)

if __name__ == “__main__”:

process_names = generate_civil_cases_names()

generate_civil_cases(process_names)

代碼從介紹generate_civil_cases_names函數(shù)開始。這個(gè)函數(shù)利用 LangChain 的**PromptTemplate**和**OpenAI**模型生成一個(gè)案例名稱列表。為了確保正確的格式，輸出然后通過(guò)**output_parser**進(jìn)行處理。接下來(lái)，我們有**generate_civil_cases**函數(shù)，它將生成的案例名稱列表作為參數(shù)。在這個(gè)函數(shù)內(nèi)部，**LLMChain**被用來(lái)通過(guò)迭代過(guò)程為每個(gè)案例單獨(dú)生成內(nèi)容。生成的案例將被用作后續(xù)語(yǔ)義搜索部分的輸入。

語(yǔ)義搜索

現(xiàn)在我們有了一個(gè)民事案件數(shù)據(jù)庫(kù)，我們希望我們的應(yīng)用能夠進(jìn)行語(yǔ)義搜索，以返回所有對(duì)于一名準(zhǔn)備審判的律師相關(guān)的案件。

這個(gè)想法是獲取所有的民事案件，然后使用一個(gè)模型將它們轉(zhuǎn)換為向量表示（嵌入）并將它們存儲(chǔ)在一個(gè)特殊的向量數(shù)據(jù)庫(kù) - 向量存儲(chǔ)中。例如，一旦律師輸入一個(gè)查詢，比如我在尋找有關(guān)財(cái)務(wù)損失的案例，接下來(lái)將執(zhí)行以下步驟：

1. 將查詢轉(zhuǎn)換為向量表示 - 嵌入查詢

2. 在嵌入查詢和嵌入民事案件之間進(jìn)行相似性檢查

3. 從數(shù)據(jù)庫(kù)中檢索相關(guān)向量

嵌入民事案件并將其存儲(chǔ)在 Pinecone 向量存儲(chǔ)中

讓我們開始導(dǎo)入所需的庫(kù)和模塊：

from LangChain.document_loaders import DirectoryLoader

from LangChain.vectorstores import Pinecone

from LangChain.embeddings import OpenAIEmbeddings

import pinecone

import os

我們將使用 Open AI 嵌入模型嵌入文檔，然后將它們存儲(chǔ)在 Pinecone 向量存儲(chǔ)中。

首先要做的是加載民事案件。為此，**DirectoryLoader**類對(duì)象將加載指定目錄中的所有文件。請(qǐng)注意，默認(rèn)情況下，DirectoryLoader使用**UnstructuredLoader**類來(lái)加載文檔。如果您需要加載不同（結(jié)構(gòu)化）類型的文檔，可以使用不同的加載器類。例如，如果您想加載 Python 源代碼文件，可以使用PythonLoader類：

def embed_and_store_documents():

loader = DirectoryLoader(“civil_cases”, glob=”*.docx”)

documents = loader.load()

讓我們定義嵌入模型：

embeddings_model = OpenAIEmbeddings()

現(xiàn)在，讓我們深入了解 Pinecone 的功能。Pinecone 充當(dāng)向量數(shù)據(jù)庫(kù)，使我們能夠有效地存儲(chǔ)嵌入數(shù)據(jù)并發(fā)送查詢。在使用 Pinecone 之前，我們需要?jiǎng)?chuàng)建一個(gè)索引，這個(gè)索引作為我們數(shù)據(jù)的容器。

在創(chuàng)建 Pinecone 索引時(shí)，我們必須指定我們想要使用的相似性度量，比如余弦相似度。這個(gè)度量有助于根據(jù)向量空間中它們與查詢的接近程度來(lái)找到最相關(guān)的向量。此外，我們需要定義我們正在處理的向量的維度。在我們將使用的 OpenAI 的嵌入模型text-embedding-ada-002的情況下，輸出向量的維度為 1536。

創(chuàng)建索引后，我們可以通過(guò)將 API 密鑰和環(huán)境名稱添加到環(huán)境變量中來(lái)繼續(xù)進(jìn)行。這一步確保我們的 Pinecone 客戶端具有必要的授權(quán)來(lái)訪問(wèn)數(shù)據(jù)庫(kù)。此外，我們需要提供我們創(chuàng)建的索引的名稱。這些信息使我們能夠有效地初始化 Pinecone 客戶端，提供與向量存儲(chǔ)的無(wú)縫交互。

pinecone.init(

api_key=os.environ[‘PINECONE_API_KEY’], environment=os.environ[‘PINECONE_ENV’]

`)

index_name = “l(fā)egal-documents-search”

最后，通過(guò)這一行代碼，所有文檔都將被嵌入并存儲(chǔ)在 Pinecone 中。這些 ready-to-use 的部分是 LangChain 的巨大力量：

Pinecone.from_documents(

documents, embeddings_model, index_name=index_name

`)

這是完整的代碼供參考：

from LangChain.document_loaders import DirectoryLoader

from LangChain.vectorstores import Pinecone

from LangChain.embeddings import OpenAIEmbeddings

import pinecone

import os

def embed_and_store_documents():

loader = DirectoryLoader(“civil_cases”, glob=”*.docx”)

documents = loader.load()

embeddings_model = OpenAIEmbeddings()

pinecone.init(

api_key=os.environ[‘PINECONE_API_KEY’], environment=os.environ[‘PINECONE_ENV’]

)

index_name = “l(fā)egal-documents-search”

Pinecone.from_documents(

documents, embeddings_model, index_name=index_name

)

if __name__ == “__main__”:

embed_and_store_documents()

代碼片段首先通過(guò)使用**DirectoryLoader**加載民事案件。這個(gè)加載器從指定的目錄中檢索所有具有指定擴(kuò)展名的文件。然后，我們定義嵌入模型并初始化 Pinecone 客戶端。最后一步是使用客戶端將加載的文件進(jìn)行嵌入并存儲(chǔ)在 Pinecone 向量存儲(chǔ)中。

相似性搜索和檢索相關(guān)數(shù)據(jù)

最后一部分是檢索相關(guān)數(shù)據(jù)。首先，我們要嵌入律師提出的查詢并進(jìn)行相似性搜索。一旦找到最接近的結(jié)果，我們希望將民事案例文件的名稱返回給用戶。讓我們從必要的導(dǎo)入開始：

from LangChain.vectorstores import Pinecone

from LangChain.embeddings import OpenAIEmbeddings

from LangChain.embeddings.openai import OpenAIEmbeddings

import pinecone

import os

為了嵌入律師的查詢，我們將再次使用 Open AI 的嵌入模型：

def retrieve_relevant_cases(query):

embeddings_model = OpenAIEmbeddings()

現(xiàn)在我們有了一個(gè)包含我們的民事案件的現(xiàn)有索引，我們可以使用**from_existing_index**方法創(chuàng)建一個(gè)**docsearch**對(duì)象，用于相似性檢查：

index_name = “l(fā)egal-documents-search”

pinecone.init(

api_key=os.environ[“PINECONE_API_KEY”], environment=os.environ[“PINECONE_ENV”]

)

docsearch = Pinecone.from_existing_index(index_name, embeddings_model)

如果我們將查詢?nèi)纭瓣P(guān)于財(cái)務(wù)損失的案例”傳遞給docsearch對(duì)象調(diào)用similarty_search方法，將會(huì)發(fā)生以下情況：查詢將使用OpenAIEmbeddings對(duì)象中定義的默認(rèn)模型進(jìn)行嵌入，執(zhí)行相似性搜索并返回所有相關(guān)文件：

docs = docsearch.similarity_search(query)

最后，由于我們正在尋找特定的文件，我們希望返回存儲(chǔ)在元數(shù)據(jù)中的這些文件的名稱：

sources = [doc.metadata[“source”] for doc in docs]

這是檢索相關(guān)民事案例的完整代碼：

from LangChain.vectorstores import Pinecone

from LangChain.embeddings import OpenAIEmbeddings

from LangChain.embeddings.openai import OpenAIEmbeddings

import pinecone

import os

def retrieve_relevant_cases(query):

embeddings_model = OpenAIEmbeddings()

index_name = “l(fā)egal-documents-search”

pinecone.init(

api_key=os.environ[“PINECONE_API_KEY”], environment=os.environ[“PINECONE_ENV”]

)

docsearch = Pinecone.from_existing_index(index_name, embeddings_model)

docs = docsearch.similarity_search(query)

sources = [doc.metadata[“source”] for doc in docs]

return sources

if __name__ == “__main__”:

print(retrieve_relevant_cases(“Cases about financial loss”))

代碼片段包括一個(gè)名為**retrieve_relevant_cases**的函數(shù)，旨在獲取適當(dāng)?shù)陌咐?。首先，我們定義嵌入模型、索引名稱并初始化 Pinecone 客戶端。接下來(lái)，我們創(chuàng)建一個(gè)用于進(jìn)行相似性搜索的docsearch對(duì)象。最后，我們從返回的文件的元數(shù)據(jù)中提取案例的名稱。

示例 2：自動(dòng)化專家的內(nèi)部知識(shí) QA-在特定控制器手冊(cè)上聊天

在企業(yè)環(huán)境中利用 LLM 的一個(gè)常見場(chǎng)景是從各種類型的文本文檔中提取數(shù)據(jù)，如產(chǎn)品規(guī)格、使用文檔、網(wǎng)頁(yè)、演示文稿和內(nèi)部文檔。在這些情況下的主要挑戰(zhàn)是處理大量數(shù)據(jù)以及不同術(shù)語(yǔ)用于指代同一事物的不一致性。簡(jiǎn)單的關(guān)鍵詞搜索通常是不夠的，理解用戶問(wèn)題的語(yǔ)義含義變得至關(guān)重要。為了解決這個(gè)問(wèn)題，LangChain 提供了一系列組件，具有有效的策略來(lái)解決語(yǔ)義搜索。

為了說(shuō)明 LangChain 的功能，讓我們考慮一個(gè)例子，我們開發(fā)一個(gè)工具，用于自動(dòng)化專家加快搜索文檔的過(guò)程。這個(gè)工具將作為一個(gè)聊天機(jī)制，允許專家詢問(wèn)關(guān)于特定控制器的問(wèn)題。提醒一下，控制器是管理過(guò)程以實(shí)現(xiàn)和維持期望參數(shù)的設(shè)備。例如，在巧克力制造工廠中，可編程邏輯控制器（PLC）通過(guò)監(jiān)控和控制各種設(shè)備和過(guò)程來(lái)維持特定的生產(chǎn)參數(shù)，如溫度、壓力和速度，確保最佳運(yùn)行和產(chǎn)品質(zhì)量。這類控制器的文檔可能非常廣泛，包含大量?jī)?nèi)容。

目標(biāo)是為自動(dòng)化專家提供一個(gè)聊天界面，使他們能夠快速訪問(wèn)設(shè)計(jì)和編程所需的信息。

將手冊(cè)分塊并加載到 Pinecone 向量存儲(chǔ)器

讓我們探討使用 LangChain 進(jìn)行實(shí)現(xiàn)的技術(shù)方面?？刂破魇謨?cè)是一份 40 頁(yè)的 PDF 文檔，所以我們的初始任務(wù)是加載文檔。由于整個(gè)文檔太長(zhǎng)而無(wú)法輸入到我們的提示中，我們必須制定一種策略將文檔分成可管理的部分。首先，讓我們考慮一些有用的導(dǎo)入：

from LangChain.text_splitter import RecursiveCharacterTextSplitter

from LangChain.vectorstores import Pinecone

from LangChain.embeddings import OpenAIEmbeddings

from LangChain.document_loaders import PyPDFLoader

import pinecone

Import os

加載手冊(cè)是我們的下一步。為了實(shí)現(xiàn)這一目標(biāo)，我們可以利用**PyPDFLoader**類，這個(gè)類可以方便地加載文檔并將其保存為Document對(duì)象：

def embed_and_store_documents():

loader = PyPDFLoader(“Manual_MT655333.pdf”)

manual = loader.load_and_split()

現(xiàn)在我們已經(jīng)加載了 PDF 文件，我們需要將其分成較小的部分。在 LangChain 中，有一個(gè)名為RecursiveCharacterTextSplitter的文本分割器類，可以幫助我們完成這個(gè)任務(wù)。分割器根據(jù)特定字符拆分文本，這些字符列在下面：[“\n”, “\r”, “ “, ?“]。采用這種方法的原因是盡可能保持整個(gè)段落在一起。這增加了獲取強(qiáng)語(yǔ)義相關(guān)文本塊的機(jī)會(huì)。

分塊大小指的是每個(gè)部分的最大大小，由長(zhǎng)度函數(shù)測(cè)量。重疊指示了每個(gè)相鄰部分之間共享多少標(biāo)記。長(zhǎng)度函數(shù)確定了如何計(jì)算各部分的長(zhǎng)度。默認(rèn)情況下，它計(jì)算字符數(shù)，但通常使用標(biāo)記計(jì)數(shù)。**add_start_index**參數(shù)確定是否應(yīng)在元數(shù)據(jù)中包括每個(gè)部分在原始文檔中的起始位置。

text_splitter = RecursiveCharacterTextSplitter(

chunk_size=500,

chunk_overlap=30,

length_function=len,

add_start_index=True,

)

為了將文檔分成較小的部分，我們可以利用**text_splitter**對(duì)象及其**split_documents**方法：

documents = text_splitter.split_documents(documents=manual)

完成此步驟后，我們繼續(xù)嵌入這些塊并將它們發(fā)布到 Pinecone 向量存儲(chǔ)中：

embeddings_model = OpenAIEmbeddings（）

pinecone.init（

api_key = os.environ [‘PINECONE_API_KEY’]，environment = os.environ [‘PINECONE_ENV’]

）

index_name = ‘mt655333-manual’

Pinecone.from_documents（documents，embeddings_model，index_name = index_name）

以下是分塊、嵌入和推送向 Pinecone 的完整代碼：

從 LangChain.text_splitter 導(dǎo)入 RecursiveCharacterTextSplitter

從 LangChain.vectorstores 導(dǎo)入 Pinecone

從 LangChain.embeddings 導(dǎo)入 OpenAIEmbeddings

從 LangChain.document_loaders 導(dǎo)入 PyPDFLoader

導(dǎo)入 pinecone

導(dǎo)入 os

def embed_and_store_documents（）：

加載器= PyPDFLoader（“Manual_MT655333.pdf”）

manual = loader.load_and_split（）

text_splitter = RecursiveCharacterTextSplitter（

chunk_size = 500，

chunk_overlap = 30，

length_function = len，

add_start_index = True，

）

documents = text_splitter.split_documents（documents = manual）

``embeddings_model = OpenAIEmbeddings（）

pinecone.init（

api_key = os.environ [‘PINECONE_API_KEY’]，環(huán)境= os.environ [‘PINECONE_ENV’]

）

index_name = ‘mt655333-manual’

Pinecone.from_documents（documents，embeddings_model，index_name = index_name）

if name == ‘main’：

embed_and_store_documents（）

上述代碼片段使用PyPDFLoader加載控制器手冊(cè)。之后，它利用RecursiveCharacterTextSplitter將文檔分割成較小的塊。隨后，它嵌入這些塊并使用 Pinecone 客戶端將它們放入向量存儲(chǔ)中。這使我們能夠?yàn)橄乱徊綔?zhǔn)備文檔，該步驟涉及在手冊(cè)上執(zhí)行相似性搜索。

[在控制器手冊(cè)上聊天-用于相似性搜索的對(duì)話檢索鏈]（toc.xhtml＃s455a）

現(xiàn)在讓我們探討一種聊天機(jī)制的實(shí)現(xiàn)，該機(jī)制允許自動(dòng)化專家詢問(wèn)有關(guān)控制器的信息。為了確保對(duì)話流暢，我們必須解決后續(xù)查詢可能與先前查詢相關(guān)的事實(shí)。為了處理這一點(diǎn)，我們需要有效地管理對(duì)話的記憶。為了檢索相關(guān)數(shù)據(jù)塊并有效處理聊天歷史記錄，我們將使用ConversationalRetrievalQAchain。使用這個(gè)類，我們將處理先前的交互并將它們整合到當(dāng)前的聊天中。

從 LangChain.embeddings.openai 導(dǎo)入 OpenAIEmbeddings

從 LangChain.llms 導(dǎo)入 OpenAI

從 LangChain.chat_models 導(dǎo)入 ChatOpenAI

從 LangChain.chains 導(dǎo)入 ConversationalRetrievalChain

從 LangChain.vectorstores 導(dǎo)入 Pinecone

導(dǎo)入 pinecone

導(dǎo)入 os

pinecone.init（

api_key = os.environ [“PINECONE_API_KEY”]，環(huán)境= os.environ [“PINECONE_ENV”]

）

def retrieve_controllers_info（query，chat_history）：

embeddings_model = OpenAIEmbeddings（）

index_name = “mt655333-manual”

docsearch = Pinecone.from_existing_index（index_name，embeddings_model）

通過(guò)在ConversationalRetrievalChain類上使用from_llm方法創(chuàng)建以下鏈：

qa = ConversationalRetrievalChain.from_llm（

OpenAI（temperature = 0），

docsearch.as_retriever（），

return_source_documents = True，

condense_question_llm = ChatOpenAI（temperature = 0，model =”gpt-3.5-turbo”），

）

return qa（{“question”：query，“chat_history”：chat_history}）

為了獲取生成答案所使用的源文檔的信息，我們包括一個(gè)名為“return_source_documents”的額外參數(shù)，并將其設(shè)置為“True”。最后一個(gè)參數(shù)“condense_question_llm”負(fù)責(zé)將聊天歷史和查詢合并為單個(gè)查詢向量。這使我們能夠使用不同的模型來(lái)壓縮問(wèn)題并回答它?？梢愿鶕?jù)特定任務(wù)的性能或使用成本選擇模型。該鏈生成一個(gè)包含答案和聊天歷史的元組。聊天歷史是一個(gè)包含查詢及其對(duì)應(yīng)答案的元組列表。

內(nèi)存處理

最后一步是測(cè)試鏈。重要的是要注意，在這種情況下，我們必須在聊天會(huì)話期間管理內(nèi)存。在每個(gè)會(huì)話開始時(shí)，我們將內(nèi)存設(shè)置為空列表。當(dāng)每個(gè)查詢發(fā)送到聊天助手時(shí)，我們將其添加到一個(gè)包含查詢及其對(duì)應(yīng)答案的元組中，添加到聊天歷史列表中：

如果 name ==“main”：

chat_history=[]

查詢=“MT65533 支持自動(dòng)調(diào)諧嗎？”

結(jié)果=檢索控制器信息（查詢，聊天記錄）

打?。╮esult[“answer”]）

打?。╮esult[“source_documents”]）

chat_history.append（（query，result[“answer”]））

查詢=“到底是哪些方法？”

result=檢索控制器信息（query，chat_history）

打?。╮esult[“answer”]）

打印（result[“source_documents”]）

以下對(duì)話是前面的后端應(yīng)用程序的結(jié)果。此外，根據(jù)設(shè)計(jì)，人們可能希望添加由“docsearch”對(duì)象返回的手冊(cè)的相關(guān)片段。

自動(dòng)化專家：MT65533 支持自動(dòng)調(diào)諧嗎？

AI：是的，MT655333 控制器支持自動(dòng)調(diào)諧技術(shù)，以自動(dòng)確定最佳控制參數(shù)。

自動(dòng)化專家：到底是哪些方法？

AI：MT65533 控制器支持自動(dòng)調(diào)諧方法，如繼電器反饋、Ziegler-Nichols 前向控制、自適應(yīng)控制和模糊邏輯控制。

以下是完整的代碼供參考：

從 LangChain.embeddings.openai 導(dǎo)入 OpenAIEmbeddings

從 LangChain.llms 導(dǎo)入 OpenAI

從 LangChain.chat_models 導(dǎo)入 ChatOpenAI

從 LangChain.chains 導(dǎo)入 ConversationalRetrievalChain

從 LangChain.vectorstores 導(dǎo)入 Pinecone

導(dǎo)入 pinecone

導(dǎo)入 os

pinecone.init（

api_key=os.environ[“PINECONE_API_KEY”]，environment=os.environ[“PINECONE_ENV”]

）

def retrieve_controllers_info（query，chat_history）：

embeddings_model=OpenAIEmbeddings（）

index_name=“mt655333-manual”

docsearch=Pinecone.from_existing_index（index_name，embeddings_model）

qa=從 llm 創(chuàng)建對(duì)話檢索鏈（

OpenAI（temperature=0），

docsearch.as_retriever（），

return_source_documents=True，

condense_question_llm=ChatOpenAI（temperature=0，model=”gpt-3.5-turbo”），

）

返回 qa（{“question”：query，“chat_history”：chat_history}）

如果 name ==“main”：

chat_history=[]

查詢=“MT65533 支持自動(dòng)調(diào)諧嗎？”

result=檢索控制器信息（query，chat_history）

打?。╮esult[“answer”]）

打?。╮esult[“source_documents”]）

chat_history.append（（查詢，result[“answer”]））

查詢=“到底是哪些方法？”

result=檢索控制器信息（query，chat_history）

打?。╮esult[“answer”]）

打?。╮esult[“source_documents”]）

這段代碼從初始化 Pinecone 客戶端開始，然后定義了“retrieve_controllers_info”函數(shù)。此函數(shù)接受query和chat_history作為輸入?yún)?shù)，并利用“ConversationalRetrievalChain”在向量存儲(chǔ)中執(zhí)行相似性搜索并生成答案。在主函數(shù)中，通過(guò)將query和chat_history傳遞給“retrieve_controllers_info”函數(shù)來(lái)測(cè)試解決方案。對(duì)話記憶的管理由開發(fā)人員自行決定。

示例 3：使用 LangChain 代理進(jìn)行市場(chǎng)研究

以下示例說(shuō)明了如何利用 LangChain 的代理進(jìn)行市場(chǎng)調(diào)研。這個(gè)過(guò)程包括理解任務(wù)，制定執(zhí)行策略和實(shí)施具體行動(dòng)。

在這個(gè)例子中，我們將使用 LangChain 的代理組件。我們將賦予我們的代理能力，利用 SERP API 作為搜索引擎。SERP API 本質(zhì)上是開發(fā)人員可以利用的工具，用于訪問(wèn)和提取搜索引擎結(jié)果頁(yè)面的數(shù)據(jù)。代理將利用 Open AI 模型來(lái)規(guī)劃所有必要的步驟。它將確定要搜索的相關(guān)數(shù)據(jù)，驗(yàn)證 API 輸出的準(zhǔn)確性，并編譯結(jié)果以向用戶提供答案。

由于 LangChain 提供了所有必要的工具，因此實(shí)現(xiàn)這個(gè)功能將是簡(jiǎn)單和不復(fù)雜的。讓我們首先導(dǎo)入必要的模塊和庫(kù)：

從 LangChain.agents 導(dǎo)入 load_tools

從 LangChain.agents 導(dǎo)入 initialize_agent

從 LangChain.agents 導(dǎo)入 AgentType

從 LangChain.llms 導(dǎo)入 OpenAI

導(dǎo)入 os

為了使用 SERP API，我們需要注冊(cè)并獲取serp_api_key：

serpapi_api_key = os.environ[‘SERPAPI_API_KEY’]

llm = OpenAI(temperature=0)

我們正在為代理配備 SERP API 和 LLM。這些工具使代理能夠生成準(zhǔn)確和全面的答案：

tools = load_tools([“serpapi”], llm=llm)

現(xiàn)在我們已經(jīng)準(zhǔn)備好工具列表，讓我們使用zero-shot-react-agent。這種類型的代理使用ReAct [13]范式來(lái)確定基于工具描述的最合適的工具。ReAct得名于reasoning和acting這兩個(gè)詞的組合。這個(gè)框架利用推理組件來(lái)識(shí)別需要執(zhí)行的任務(wù)并評(píng)估觀察結(jié)果。然后它利用執(zhí)行組件來(lái)執(zhí)行任務(wù)。ReAct是一個(gè)將推理和行動(dòng)與語(yǔ)言模型相結(jié)合，用于解決各種語(yǔ)言推理和決策任務(wù)的通用范式。

agent = initialize_agent(tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True)

要開始，我們首先需要初始化代理。我們通過(guò)提供一組工具和推理 LLM 來(lái)實(shí)現(xiàn)這一點(diǎn)，并指定ReAct代理類型。此外，我們可以設(shè)置 verbose 參數(shù)，以確定代理是否應(yīng)該提供其行動(dòng)的逐步描述。一旦代理被初始化，我們就可以要求它解決一個(gè)問(wèn)題：

agent.run(“當(dāng)前最好的蘭博基尼車型的價(jià)格是多少？”)

這是完整的代碼供參考：

從 LangChain.agents 導(dǎo)入 load_tools

從 LangChain.agents 導(dǎo)入 initialize_agent

從 LangChain.agents 導(dǎo)入 AgentType

從 LangChain.llms 導(dǎo)入 OpenAI

導(dǎo)入 os

serpapi_api_key = os.environ[“SERPAPI_API_KEY”]

llm = OpenAI(temperature=0)

tools = load_tools([“serpapi”], llm=llm)

agent = initialize_agent(

tools，llm，agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION，verbose=True

）

agent.run(“當(dāng)前最好的蘭博基尼車型的價(jià)格是多少？”)

在初始化代理并裝備它的工具后，我們通過(guò)使用查詢*最新蘭博基尼車型的價(jià)格是多少？*來(lái)運(yùn)行它。代理然后開始思考并執(zhí)行一系列動(dòng)作。由于我們?cè)诔跏蓟^(guò)程中先前設(shè)置了 verbose 參數(shù)，這些步驟將顯示為輸出：

進(jìn)入新的 AgentExecutor 鏈…

我應(yīng)該查找當(dāng)前最好的蘭博基尼車型

動(dòng)作：搜索

動(dòng)作輸入：“當(dāng)前最好的蘭博基尼車型”

觀察：當(dāng)前蘭博基尼車型陣容中最好的是·蘭博基尼 Huracán Evo RWD / STO·蘭博基尼 Aventador SVJ·蘭博基尼 Urus·蘭博基尼 Sián·很棒…

思考：我應(yīng)該查找蘭博基尼 Huracán Evo RWD / STO 的價(jià)格

動(dòng)作：搜索

動(dòng)作輸入：“蘭博基尼 Huracán Evo RWD / STO 價(jià)格”

觀察：當(dāng)蘭博基尼 Huracan STO 轎車推出時(shí)，價(jià)格為 327,838 美元，不包括稅費(fèi)和交付費(fèi)，到 2023 年款約為 33.5 萬(wàn)美元。應(yīng)該...

想法：我現(xiàn)在知道最終答案

最終答案：蘭博基尼 Huracán Evo RWD / STO 的價(jià)格約為 2023 年款約為 33.5 萬(wàn)美元。

> 鏈完成。

確定頂級(jí)蘭博基尼車型的價(jià)格是代理要執(zhí)行的任務(wù)。代理開始通過(guò)識(shí)別所請(qǐng)求的蘭博基尼車型來(lái)進(jìn)行任務(wù)，該車型被描述為“最佳”。

一旦確定了車型，代理就使用 SERP API 來(lái)進(jìn)行徹底的搜索，以獲取有關(guān)其價(jià)格和相關(guān)數(shù)據(jù)的具體信息。它不斷評(píng)估從 API 收到的輸出，仔細(xì)分析以確定缺失的信息。為了得出正確的答案，代理依靠推理和執(zhí)行能力的結(jié)合。這就是 LangChain 代理如此強(qiáng)大的原因。它們有能力使用工具，并配備有 LLMs，使它們能夠得出結(jié)論。通過(guò)遵循這種系統(tǒng)化的方法，代理能夠準(zhǔn)確可靠地確定頂級(jí)蘭博基尼車型的價(jià)格。這展示了 LangChain 代理的令人印象深刻的能力，使它們成為各種用例的有價(jià)值的工具。其他一些例子包括利用代理創(chuàng)建個(gè)性化的動(dòng)態(tài)定價(jià)策略，基于歷史和市場(chǎng)數(shù)據(jù)為個(gè)別股票生成風(fēng)險(xiǎn)評(píng)估，或者通過(guò)分析與特定行業(yè)相關(guān)的新聞文章和社交媒體帖子來(lái)識(shí)別市場(chǎng)趨勢(shì)。

結(jié)論

LangChain 框架是一個(gè)強(qiáng)大的基于 Python 的工具，可以釋放大型語(yǔ)言模型在應(yīng)用程序開發(fā)中的全部潛力。該框架提供了一套全面的組件，賦予開發(fā)人員創(chuàng)建復(fù)雜應(yīng)用程序的能力。通過(guò)利用組件、鏈和代理的使用，開發(fā)過(guò)程變得更加流暢和高效。這導(dǎo)致了大幅的工作量節(jié)約、提高的質(zhì)量、標(biāo)準(zhǔn)化和可讀性，最終導(dǎo)致了組織生產(chǎn)力的提高和更快的上市時(shí)間。LangChain 是一個(gè)可以徹底改變企業(yè)和專業(yè)人士利用大型語(yǔ)言模型所有能力的工具。

隨著我們結(jié)束對(duì) LangChain 的章節(jié)，我們已經(jīng)看到這個(gè)基于 Python 的框架在開發(fā)基于 GPT 的應(yīng)用程序方面表現(xiàn)出色。在我們開始下一章之際，我們將深入探討“predictive-powers”，這是一個(gè)特別設(shè)計(jì)用于構(gòu)建利用 LLMs 能力的解決方案的杰出的基于 Java 的庫(kù) - 這是我們?cè)谏墒饺斯ぶ悄茴I(lǐng)域激動(dòng)人心旅程的延續(xù)。

要點(diǎn)

• LangChain 是一個(gè)基于 Python 的框架，允許開發(fā)人員創(chuàng)建最大化大型語(yǔ)言模型潛力的應(yīng)用程序。它可以與多個(gè)供應(yīng)商的 LLMs 一起使用，包括 OpenAI，以及定制的模型。

• 使用 LangChain 有助于提高質(zhì)量、標(biāo)準(zhǔn)化和可讀性。憑借其即用型組件，開發(fā)全面應(yīng)用程序的過(guò)程變得簡(jiǎn)化和流暢。

• 通過(guò)將預(yù)先學(xué)習(xí)的知識(shí)與實(shí)時(shí)或領(lǐng)域信息相結(jié)合，LangChain 增強(qiáng)了與 LLMs 合作的能力和可靠性。

• 該框架包括模式、模型、數(shù)據(jù)處理、鏈、內(nèi)存處理和代理等組件，賦予開發(fā)人員更快的工作能力。

• 鏈?zhǔn)且环N可立即使用的類，允許堆疊命令。它們有助于提高開發(fā)人員的效率。

• 代理在需要獨(dú)立推理、規(guī)劃和執(zhí)行操作的任務(wù)中非常有價(jià)值，這使得創(chuàng)建自主和強(qiáng)大的應(yīng)用程序成為可能。````````````````文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-806979.html

到了這里，關(guān)于面向企業(yè)的 ChatGPT 究極手冊(cè)：第七章到第八章的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！