电竞比分网-中国电竞赛事及体育赛事平台

分享

軟件工程十大技術(shù)之一:AI輔助編碼技術(shù)

 漢無為 2024-02-04 發(fā)布于廣東
大綱
  1. LLM、Transformer、LangChain基本概念
  2. AIGC業(yè)界現(xiàn)狀
  3. AI輔助編碼實現(xiàn)架構(gòu)
  4. Prompt Engineering提示工程
  5. RAG檢索增強生成
  6. Toolformer:讓模型自己使用工具


一、LLM、Transformer、LangChain基本概念
1. 什么是LLM?
通常認為參數(shù)量超過10B的模型為大語言模型。這些是通過大量文本數(shù)據(jù)訓練的復雜人工智能模型。它們能理解和生成自然語言,可以用于回答問題、撰寫文本、翻譯語言等。GPT(生成式預訓練變換器)就是一個著名的LLM例子。
2. LLM的結(jié)構(gòu)
LLM本身基于transformer架構(gòu)。
大型語言模型(LLM)的結(jié)構(gòu)是相當復雜的,但我我們嘗試以簡化的方式來解釋其核心組成部分。這些模型通?;谝环N被稱為“Transformer”的神經(jīng)網(wǎng)絡(luò)架構(gòu)。以下是LLM的關(guān)鍵結(jié)構(gòu)要素:
  • 輸入層:這是模型接收文本數(shù)據(jù)的部分。文本首先被分割成更小的單元,通常是詞或子詞(subwords),這些單元被轉(zhuǎn)換成數(shù)字形式(通常稱為“詞嵌入”或“token embeddings”),以便模型可以處理它們。
  • Transformer架構(gòu):LLM的核心是基于Transformer模型,這是一種專為處理序列數(shù)據(jù)(例如文本)設(shè)計的神經(jīng)網(wǎng)絡(luò)。Transformer架構(gòu)的關(guān)鍵特性包括:
    • 自注意力機制(Self-Attention Mechanism):這使得模型能夠在處理一個詞時,同時考慮到句子中的其他詞。這是理解上下文和語言流的關(guān)鍵。
    • 多頭注意力(Multi-Head Attention):模型在不同的“注意力頭”上同時處理信息,每個頭關(guān)注不同的信息部分。這增強了模型處理復雜語言結(jié)構(gòu)的能力。
    • 前饋神經(jīng)網(wǎng)絡(luò):這些網(wǎng)絡(luò)負責在每個Transformer層中處理數(shù)據(jù),提供非線性處理能力,使模型能夠?qū)W習復雜的語言模式。
  • 層堆疊:在Transformer模型中,多個這樣的層被堆疊在一起。每一層都包含自注意力和前饋網(wǎng)絡(luò),層數(shù)越多,模型越能處理復雜的語言結(jié)構(gòu)和含義。
  • 輸出層:在處理完輸入數(shù)據(jù)之后,模型通過輸出層生成文本。在生成任務(wù)中,模型通常使用稱為“softmax”層的東西,這可以生成下一個最可能的詞或詞組。
  • 參數(shù)和訓練:LLM擁有極其龐大的參數(shù)數(shù)量(例如,GPT-3擁有1750億個參數(shù))。這些參數(shù)在訓練期間通過大量的文本數(shù)據(jù)進行調(diào)整,以學習語言的結(jié)構(gòu)和用法。
總的來說,LLM的結(jié)構(gòu)允許它學習和理解復雜的語言模式,并在各種任務(wù)(如文本生成、翻譯、摘要等)中生成高質(zhì)量的語言輸出。
3. LLM與Transformers之間的關(guān)系
現(xiàn)在,用一個通俗的例子來解釋LLM和Transformers之間的聯(lián)系:
想象你正在制作一部電影。在這個比喻中,Transformers就像是電影的基本劇本。它規(guī)定了故事的基本結(jié)構(gòu)、角色和情節(jié)發(fā)展,但還沒有詳細到具體的對話或場景。
而LLM(如GPT)就像是根據(jù)這個基本劇本制作出來的完整電影。這部電影不僅有了詳細的對話、背景音樂、特效和演員的演繹,還融入了導演的獨特視角和創(chuàng)意,使得基本的劇本變成了觀眾可以觀看和欣賞的完整作品。
在這個比喻中,Transformers提供了處理和理解語言的基礎(chǔ)框架,就像電影的劇本;而LLM則是在這個框架上增加細節(jié)和深度,最終創(chuàng)造出能夠與人類自然交流的AI,就像將劇本轉(zhuǎn)化為一部精彩的電影。
4. GPT與LLM之間的關(guān)系
LLM是一個廣泛的分類,涵蓋了所有使用大量數(shù)據(jù)進行訓練的、能夠處理和生成自然語言的復雜AI模型。而GPT是這一類模型中的一個特定例子,它使用Transformer架構(gòu),并通過大規(guī)模的預訓練學習語言的模式和結(jié)構(gòu)。
為了更好地理解LLM(大型語言模型)、GPT(Generative Pre-trained Transformer)和Transformer之間的關(guān)系,我們可以將它們比作建筑的不同部分。
Transformer架構(gòu):基礎(chǔ)結(jié)構(gòu)
想象Transformer架構(gòu)像是建筑的基礎(chǔ)結(jié)構(gòu),比如一座大樓的框架。它提供了基本的支撐和形狀,決定了建筑的整體設(shè)計和功能。在技術(shù)上,Transformer是一種神經(jīng)網(wǎng)絡(luò)架構(gòu),專為處理序列化數(shù)據(jù)(如文本)而設(shè)計,特別擅長捕捉數(shù)據(jù)中的長距離依賴關(guān)系。
LLM:整體建筑
LLM則可以看作是建立在這個框架上的整座建筑。這些建筑不僅有堅固的框架(即Transformer架構(gòu)),還包括了房間、電梯、裝飾等,使得建筑完整、功能豐富。類似地,LLM是使用Transformer架構(gòu)構(gòu)建的,通過大量的數(shù)據(jù)訓練,這使得它們能夠處理復雜的語言任務(wù),比如文本生成、理解、翻譯等。
GPT:特定類型的建筑
GPT可以被視為這些大型建筑中的一種特定類型,如一座特別的摩天大樓。它不僅使用了Transformer架構(gòu)(即基礎(chǔ)框架),而且通過特定的方式進行了設(shè)計和優(yōu)化(即大規(guī)模的預訓練),以實現(xiàn)特定的功能,如高效的文本生成和語言理解。
總結(jié)起來,Transformer是基礎(chǔ)架構(gòu),LLM是建立在這種架構(gòu)上的一類復雜系統(tǒng),而GPT是LLM中的一種特定實現(xiàn),使用了Transformer架構(gòu),并通過大量的預訓練獲得了強大的語言處理能力。這種關(guān)系像是建筑基礎(chǔ)、整體建筑和特定類型建筑之間的關(guān)系。
5. LLM與LangChain之間的關(guān)系
LangChain是一個開源庫,用于構(gòu)建和運行基于語言模型的應(yīng)用程序。它是由語言模型(如GPT)的用戶和開發(fā)者設(shè)計的,旨在簡化大型語言模型(LLM)的使用和集成過程。LangChain的目標是讓開發(fā)者能夠更容易地將語言模型的能力集成到各種應(yīng)用中,無論是聊天機器人、自動內(nèi)容生成工具還是其他類型的NLP應(yīng)用。
LangChain與GPT和其他LLM之間的關(guān)系可以用以下方式來理解:
工具和應(yīng)用程序構(gòu)建:LangChain不是一個獨立的語言模型,而是一個工具集,使得開發(fā)者可以更容易地構(gòu)建和部署基于LLM的應(yīng)用程序。它提供了一系列的功能,如對話管理、信息檢索、內(nèi)容生成等,以利用LLM的能力。
中間層:可以將LangChain看作是LLM(如GPT)和最終應(yīng)用之間的中間層。它幫助處理用戶輸入,調(diào)用合適的語言模型,處理模型輸出,使其適用于特定的應(yīng)用場景。
簡化集成:LangChain的存在簡化了將語言模型如GPT集成到各種應(yīng)用中的過程。它為開發(fā)者提供了一種高效、靈活的方式來利用LLM的強大功能,而無需深入了解其底層的復雜性。
綜上所述,LangChain是一個工具和框架,用于促進和簡化GPT和其他大型語言模型在各種應(yīng)用中的使用和集成。它作為一個中間層,允許開發(fā)者更容易地利用LLM的強大能力,創(chuàng)建多樣化和復雜的NLP應(yīng)用。

二、AIGC業(yè)界現(xiàn)狀
AIGC,也就是人工智能生成代碼,是自動或半自動生成可執(zhí)行程序的過程。隨著AI的普及,AIGC的應(yīng)用也越來越廣泛,它不僅可以提高編程效率,降低開發(fā)成本,而且還能讓非編程專業(yè)的人員也可以實現(xiàn)代碼的編寫。
1、編程語言模型:定義與發(fā)展
代碼編程輔助技術(shù)已經(jīng)擁有超過40年的歷史了,它的發(fā)展經(jīng)歷了從語法高亮、IDE中的自動完成,到代碼分析和規(guī)范性檢測等各個階段。其中,集成開發(fā)環(huán)境(IDE)這類工具成為過去二十年的標志性產(chǎn)物,它們通過自動代碼補全、代碼高亮、語法錯誤提示、代碼片段等特性,顯著提升了開發(fā)效率與質(zhì)量,同時為開發(fā)人員帶來了更優(yōu)質(zhì)的編程體驗。
去年可謂是生成式AI的元年,大型語言模型(Large Language Models,簡稱LLMs)取得了令人矚目的突破和成功。這些通用大模型在自然語言處理任務(wù)中表現(xiàn)出色,也往往具備一定的”編程“能力,但由于它們的訓練數(shù)據(jù)更多地是屬于通用的自然語言文本,而編程語言更加結(jié)構(gòu)化,有明確的語法規(guī)則,而且語義更加直接和明確,所以對于代碼理解和生成這一特定領(lǐng)域來說,它們的表現(xiàn)可能會受到一定限制。
為了更好地滿足開發(fā)者在代碼相關(guān)任務(wù)中的需求,編程語言模型(Code Large Language Models,簡稱Code LLMs)應(yīng)運而生。與通用的大型語言模型相比,Code LLMs通過在大規(guī)模代碼庫上進行訓練,學習代碼片段、編程模式和編碼規(guī)范。這使得它們能夠更好地理解代碼結(jié)構(gòu)和邏輯,并生成符合語法和語義要求的代碼。
2、市場上的編程語言模型
近幾年,編程語言模型(Code LLMs)的市場也在不斷發(fā)展和壯大,許多主要的科技公司和開源組織都在開發(fā)和推出自己的模型。這些模型都在解決代碼理解和生成的挑戰(zhàn)上取得了顯著的進步。下面從閉源與開源的劃分角度列舉一些具有影響力的編程語言模型:

圖片

閉源模型:
  • OpenAI的GPT3.5&4、Code-Davinci-002、Code-Cushman-001和Codex;
  • Google的Bard、PaLM2、PaLM和LaMDA;
  • Google DeepMind的AlphaCode;
  • Anthropic的Claude。
開源模型:
  • Salesforce的CodeGen,CodeT5和CodeT5+;
  • 清華大學的CodeGeeX;
  • BigCode項目的StarCoder;
  • WizardCoder:目前HumanEval排行榜上最優(yōu)秀的開源模型。
3、編程語言模型在實踐中的應(yīng)用:讓編程變得更加快樂與高效
你在Visual Studio Code或者Jetbrains的插件市場可以看到數(shù)百個AI生成技術(shù)相關(guān)的代碼編程輔助工具,功能也越來越豐富,接下來讓我們更詳細地探討其常見的功能。
圖片
3.1 代碼生成與補全
這應(yīng)該是編程語言模型最直接、最顯眼的應(yīng)用。當開發(fā)者開始編寫代碼時,模型會根據(jù)輸入的注釋或代碼開始部分自動生成建議,幫助完成行或函數(shù)的編寫。用戶可以接受、忽略或探索它的建議。只需鍵入指令并在出現(xiàn)建議后按Tab鍵,就能實現(xiàn)代碼補全。這種工具不僅提升了編碼效率,也能幫助開發(fā)者避免一些常見的錯誤。
3.2 代碼解釋
程序員往往需要花費大量時間理解一段代碼的含義,尤其是當它涉及到他們不熟悉的庫或上下文時。在這種情況下,編程語言模型能夠解釋代碼的功能,讓人們更容易理解它。這對于添加代碼注釋和理解舊代碼都非常有幫助。
3.3 代碼轉(zhuǎn)換
開發(fā)者經(jīng)常需要將一種語言的代碼轉(zhuǎn)換為另一種語言,比如將Java代碼轉(zhuǎn)為Python,或者反過來。雖然傳統(tǒng)上這是一項費時且容易出錯的任務(wù),但編程語言模型可以大大簡化這個過程。模型通過學習理解不同語言的語義,從而在不同語言間進行有效的轉(zhuǎn)換。
3.4 代碼調(diào)試
編程語言模型還可以用于調(diào)試。如果你的代碼出現(xiàn)問題或錯誤信息,你可以將它們提供給模型,模型會指出可能的問題并提供解決方案。這樣,你可以更輕松地找到并修復代碼中的錯誤。
3.5 代碼重構(gòu)
編程語言模型還可以用于代碼重構(gòu)。如果你需要對代碼進行優(yōu)化或調(diào)整,例如為簡單的文件讀取代碼添加異常處理邏輯,你可以向模型提供現(xiàn)有的代碼和你想要實現(xiàn)的目標,模型會生成滿足你需求的新代碼。
3.6 測試生成
編程語言模型還可以用于生成代碼的單元測試,這包括覆蓋主要的用例、邊界情況和錯誤情況。模型可以根據(jù)你的代碼和需求自動生成相應(yīng)的測試用例,從而幫助你確保代碼的質(zhì)量和穩(wěn)定性。
3.7 代碼審查
編程語言模型還可以集成到代碼審查過程中。在你提交拉取請求時,模型可以幫助你填寫模板、生成針對你的代碼的測試,甚至在你鍵入時給出建議。這使得代碼審查變得更加簡單和高效。
總的來說,編程語言模型可以提供代碼生成、代碼解釋、代碼轉(zhuǎn)換、代碼調(diào)試、代碼重構(gòu)、測試生成和代碼審查等方面的能力。表面上看,它們似乎十分完美,不僅能提升開發(fā)者的生產(chǎn)力,還有助于提高代碼的質(zhì)量和穩(wěn)定性。但是開發(fā)者對AI編程輔助工具的態(tài)度是參差不齊的。一些開發(fā)者非常歡迎諸如Copilot工具的出現(xiàn),認為它可以顯著提高他們的開發(fā)效率,并減少重復性的工作。他們對Copilot的代碼生成能力和智能提示功能感到滿意,并認為它可以幫助他們更快速地編寫高質(zhì)量的代碼。然而,也有一些開發(fā)者對Copilot持保留意見,他們擔心Copilot生成的代碼可能不夠準確或符合最佳實踐,還需要經(jīng)過開發(fā)者的仔細審查和測試。此外,一些開發(fā)者擔心可能侵犯他人的知識產(chǎn)權(quán),或者產(chǎn)生法律和倫理上的問題。
開發(fā)者對編程語言模型的態(tài)度是復雜的,取決于個人的經(jīng)驗和觀點。然而,無論態(tài)度如何,編程語言模型的出現(xiàn)無疑為開發(fā)者提供了一個強大的工具,可以在我們的編碼過程中提供有價值的幫助。

圖片

三、AI輔助編碼實現(xiàn)架構(gòu)

1. 研發(fā)大模型構(gòu)建探索總體思路

為了提高研發(fā)迭代的反饋效率,華為云PaaS大模型團隊制定了5項數(shù)據(jù)標注與清洗規(guī)范、以及5個腳本工程項目。圖片
圖1 研發(fā)大模型探索的總體思路
在整個流程中,從原始訓練語料的準備與清洗、SFT語料的提取,到訓練、評估和部署的全自動化操作,華為云PaaS團隊已經(jīng)制定了5個數(shù)據(jù)標注和清洗規(guī)范。在訓練流水線過程中,涉及到的5個腳本工具(包括清洗工具、SFT提取工具、訓練腳本工程、部署腳本工程和IDE插件)也已經(jīng)得到了產(chǎn)品線業(yè)務(wù)專家的認可和落實。這些措施顯著提高了大模型研發(fā)的效率。

2. 那些數(shù)據(jù)應(yīng)該參與研發(fā)大模型的訓練?

數(shù)據(jù)是大模型研發(fā)的基石,其質(zhì)量直接影響到模型的最高性能。若大模型未經(jīng)過專業(yè)領(lǐng)域數(shù)據(jù)的訓練,就如同“文科生學理科”。針對產(chǎn)業(yè)特有的數(shù)據(jù)特征和挑戰(zhàn),我們首先對產(chǎn)業(yè)數(shù)據(jù)的訓練配方表進行了梳理。明確了訓練語料的范圍、目標、場景、數(shù)據(jù)標準、處理規(guī)則、處理工具、試點產(chǎn)業(yè)以及質(zhì)量評價等相關(guān)信息。
圖片
圖2:研發(fā)大模型語料層次表
L0 開源階段:對 GitHub、Stack Overflow 等高質(zhì)量數(shù)據(jù)進行清洗。
L1 RawCode 階段:清洗華為語料庫中的 30 億 tokens,涉及公司 10 余個產(chǎn)品線,以增強華為業(yè)務(wù)代碼的基礎(chǔ)能力。
L2 領(lǐng)域數(shù)據(jù)-SFT 階段:包括代碼地圖、項目級的跨文件信息以及工程規(guī)范。通過 SFT 指令微調(diào),利用跨文件上下文信息和領(lǐng)域?qū)I(yè)知識,解決生成代碼中的幻覺問題。
RAG(Retrieval Augmented Generation)階段:在 IDE 項目文件中檢索跨文件信息;在向量數(shù)據(jù)庫中檢索 API 接口說明、工程規(guī)范信息。根據(jù) prompt 模板,將用戶的需求描述與上述檢索信息拼接成完整的 prompt,輸入給大模型。
由于 L1/L2 模型訓練需要一定周期,業(yè)務(wù)實踐中項目組先使用 RAG 語料驗證效果,逐步探索 L2 SFT/L1 Raw Code 匹配任務(wù),以提升模型的理解能力和研發(fā)效率。
單一的 Prompt 工程/RAG 在一定程度上可以讓模型接觸到專業(yè)領(lǐng)域知識,增強專業(yè)表達。然而,更為關(guān)鍵的是讓專業(yè)領(lǐng)域知識參與到模型訓練過程中。

3. 研發(fā)大模型整體演進策略與方案設(shè)計

為了提高大模型研發(fā)的效率,將整個研發(fā)過程分為兩個階段進行迭代和優(yōu)化:
1、數(shù)據(jù)準備階段。首先,需要對各產(chǎn)品線的代碼倉庫進行評估,挑選出高質(zhì)量的代碼倉庫。接著,根據(jù)華為云PaaS研發(fā)項目組制定的五項數(shù)據(jù)標注和清洗規(guī)范對代碼進行清洗。在《訓練&推理語料層次表》的基礎(chǔ)上,構(gòu)建代碼地圖,并通過人工抽查與腳本校驗自動化執(zhí)行。最后,對訓練數(shù)據(jù)進行格式統(tǒng)一,生成訓練集、客觀評測集和主觀評測集。
2、在訓練和評估階段,針對第一階段所準備的訓練數(shù)據(jù),在ModelArts平臺上啟動訓練任務(wù)。通過每隔x個epoch生成的檢查點(checkpoint)來進行訓練迭代。在此基礎(chǔ)上,我們進行批量模型評估,并將模型部署在Alpha環(huán)境中,以便用戶進行評估和使用。
在Alpha環(huán)境中,IDE插件的上下文提取和RAG檢索兩個過程被巧妙地隱藏起來。IDE需要在項目層面跨文件進行上下文分析,從而提取當前編輯區(qū)域用戶關(guān)注的跨文件上下文信息,并在prompt工程中進行組裝。同時,RAG會根據(jù)用戶的輸入和意圖,檢索業(yè)務(wù)知識向量庫。在prompt工程中,上下文信息和業(yè)務(wù)知識將按照重要性進行排序,然后送入代碼大模型進行推理。生成的代碼經(jīng)過后處理后,最終呈現(xiàn)在IDE用戶界面上。
在研發(fā)過程中,數(shù)據(jù)準備以及模型的訓練和評估并非一蹴而就,而是需要經(jīng)過多次迭代和驗證。訓練和評估過程中出現(xiàn)的現(xiàn)象和問題可以為數(shù)據(jù)迭代過程提供反饋。兩個階段緊密銜接,共同推進以實現(xiàn)最終的優(yōu)化目標。
圖片
圖3:研發(fā)大模型整體演進策略與方案設(shè)計

4. RAG:研發(fā)大模型的最后“一公里”

模型訓練在一定程度上緩解了領(lǐng)域知識匱乏的問題(例如,避免使用不存在的數(shù)據(jù)對象和API,從而減少編譯錯誤和運行錯誤)。然而,由于模型更新迭代周期較長且領(lǐng)域范圍廣泛,在實際產(chǎn)業(yè)應(yīng)用中,仍需結(jié)合領(lǐng)域相關(guān)的《xx使用手冊》、《xx白皮書》和《xx使用指南》等資料,以進一步減輕代碼生成中的幻覺問題,提高知識的可追溯性和解釋性。
圖片
RAG的設(shè)計方案和實現(xiàn)形式多樣,我們的RAG方案主要關(guān)注自動化信息抽取和項目級上下文感知能力。
業(yè)務(wù)知識廣泛分布于HTML、PDF、DOC、Word等多種形式,且范圍廣泛且接口不統(tǒng)一。為解決這一問題,項目組結(jié)合知識圖譜和大模型技術(shù),實現(xiàn)結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化信息的抽取,無需人工干預,即可生成低成本且高質(zhì)量的知識。
以某產(chǎn)品線開發(fā)場景為例,我們整理了開發(fā)手冊、線下文檔、社區(qū)平臺以及開發(fā)者經(jīng)驗等數(shù)據(jù),匯總成開發(fā)的領(lǐng)域知識,并將這些知識向量化,存儲到向量數(shù)據(jù)庫中。當用戶輸入需求任務(wù)后,通過RAG能力,我們可以獲取與該任務(wù)相關(guān)的開發(fā)經(jīng)驗信息。將這些信息通過“領(lǐng)域經(jīng)驗”提示模板輸入給大模型,從而顯著提高大模型輸出代碼的正確性。
圖片
圖5 RAG方案中使用的Prompt版本示例

四、Prompt Engineering提示工程
Prompt 是一個輸入的文本段落或短語,用于引導 AI 生成模型執(zhí)行特定的任務(wù)或生成特定類型的輸出。不同的 Prompt 會導致不同的搜索結(jié)果,因為它們會影響模型對信息的處理方式。而通過巧妙構(gòu)建Prompt,我們可以讓模型在廣泛的任務(wù)中執(zhí)行特定的操作,從而提高搜索效率和用戶滿意度。

復雜AIGC應(yīng)用的三個核心特征

Copilot 依靠結(jié)合用戶行為,以及當前代碼上下文,光標位置(行內(nèi)、塊間、塊外)來生成三種不同類型的代碼。其基本特質(zhì)便是圍繞用戶的潛在意圖來設(shè)計對應(yīng)的生成內(nèi)容。并結(jié)合當前的代碼文件,來調(diào)整生成的內(nèi)容,以符合對應(yīng)語言的基本語法。
而 Bloop 則是圍繞于檢索增強生成(RAG)來推測用戶的潛在意圖,諸如通過查詢擴展的方式,來更好地匹配潛在的代碼。并通過輸出更多的上下文交互過程,以讓用戶來調(diào)整自己的問題,獲得更準確的答案。
再結(jié)合 JetBrains AI Assistant 的語言上下文模塊化架構(gòu),我們簡單將復雜 AIGC 應(yīng)用總結(jié)了三個核心特征:
1、感知用戶意圖,以構(gòu)建清晰的指令: 這一特征涉及捕獲和分析用戶的操作,以全面理解用戶的目標和偏好。應(yīng)用程序需要能夠識別用戶的需求,提供相應(yīng)的內(nèi)容生成方案,從而建立清晰的指令。這可以包括收集和解釋用戶輸入,行為分析,以及利用歷史數(shù)據(jù)來更好地了解用戶需求。通過這個特征,AIGC 應(yīng)用可以更好地滿足用戶的期望。
2、圍繞用戶意圖地交互設(shè)計,以讓用戶輸出更多上下文: 這個特征旨在創(chuàng)建友好和靈活的用戶界面,鼓勵用戶提供更多上下文信息。用戶通常通過輸入和修改內(nèi)容生成的參數(shù)和條件來表達他們的需求。此外,AIGC 應(yīng)用還可以隱式地獲取用戶的上下文信息,例如 v0.dev、數(shù)據(jù)智能和流式交互。這些信息可以包括用戶的操作歷史、上下文語言信息、位置信息等,以提供更個性化和智能化的內(nèi)容生成服務(wù),從而增強用戶體驗。
3、基于數(shù)據(jù)的反饋改進與模型優(yōu)化: 這一特征通過不斷收集和分析用戶對生成內(nèi)容的反饋,如評分、評論、分享等,以實現(xiàn)內(nèi)容生成模型和算法的不斷調(diào)整和優(yōu)化。通過利用這些反饋數(shù)據(jù),AIGC 應(yīng)用可以提高生成內(nèi)容的質(zhì)量和多樣性,確保用戶滿意度不斷提高。
而對于這些應(yīng)用來說,并不是需要復雜的 prompt 技巧。技巧性、復雜的 Prompt 在工程化面前都是災(zāi)難性的

復雜 AIGC 應(yīng)用的基本 Prompt 策略

對于復雜 AIGC 應(yīng)用來說,難點是在于 Prompt 的策略,也就是如何構(gòu)建自動的上下文收集?通常來說,其設(shè)計過程要考慮:
  • 魯棒性:Prompt 的設(shè)計應(yīng)該能夠處理各種輸入情況,并在不同任務(wù)和領(lǐng)域中表現(xiàn)良好。它們應(yīng)該是通用的,而不僅僅適用于特定任務(wù)。
  • 評估和反饋循環(huán):Prompt 設(shè)計的成功與否通常需要不斷的迭代和反饋。開發(fā)者可能需要花時間來調(diào)整Prompt以提高模型的性能,這也可能影響軟件架構(gòu)。
魯棒性也意味著,復雜的 Prompt 會變成一種災(zāi)難,因為作為一個生成模型,它無法考慮到你的每個 MUST/HAVE TO/必須,以及你交給他的,你不應(yīng)該 xxx。太長的 prompt,不僅顯得 LLM 很愚蠢,也間接地讓你覺得自己很愚蠢。你應(yīng)該將長 prompt 分為多個 stage(人及 GPT 會在閱讀很長的文本之后,忽略這句要求),即復雜問題應(yīng)該先進行拆解 —— 參考領(lǐng)域驅(qū)動設(shè)計的方式。
在 AIGC 工具里,我們可以將 Prompt 分為多種類型,強指令型,強結(jié)果型。

Prompt 策略 1:精短地指令,精準上下文

圖片


在非聊天的場景下,諸如于編寫文檔、編寫報告等等,工具中的指令往往都非常簡潔:Write documentation ,而為了讓 LLM 生成更精準的結(jié)果,我們還需要進行更多的上下文補充,諸如于:
Write documentation for given method ,它結(jié)合著不同的語言的語法形式(類聲明、方法聲明等)。
隨后,還需要考慮不同的文檔工具,諸如于 write PHPDoc 。而使用 Python 語言時,則又需要使用 ''' 來作為文檔的起始標志。而為了編寫更規(guī)范的文檔,還需要結(jié)合 use @param tag 來進行示例,告訴 LLM 應(yīng)該寫什么樣的文檔。
那么,問題就來了,要讓 AIGC 構(gòu)建出這個上下文,我們需要:
  • 獲取語言相關(guān)的信息,諸如版本信息等
  • 配置或者獲取該語言的文檔工具
  • 獲取待寫文檔的代碼信息
  • 如果是方法的話,需要提醒 method has return type 。
  • 根據(jù)不同的語言配置基本的規(guī)范。如 Python 到底是用 Tab 還是用空格。
指令本身很簡單,但是要構(gòu)建精準的上下文,則是要回到工程化問題上來。

Prompt 策略 2:圍繞結(jié)果設(shè)計交互,獲取用戶的上下文

圖片

在非編碼場景的其他 RAG 場景之下,通常我們會圍繞于:感知-分析-執(zhí)行 來分析用戶的意圖,進而根據(jù)用戶的意圖來生成更多的上下文。先看個數(shù)據(jù)問答的示例:
意圖:xx (子公司)去年營收?
觀察:...
思考:請選擇查詢的數(shù)據(jù)子項?
操作:選擇 xx 領(lǐng)域。
.
最終輸出:圖表(柱狀圖等)
這里就存在一個問題,用戶最終要的是圖表,還是文字信息?我們要不要幫用戶做這個決定?如果要做這個決定,那么我們是不是需要根據(jù)用戶以往的歷史經(jīng)驗?
所以,在這個場景里,在進入解決方案之前,我們一直在圍繞用戶的問題進行澄清

五、RAG檢索增強生成
檢索增強生成(Retrieval Augmented Generation),也稱為RAG,是一種在私有或自定義數(shù)據(jù)集上構(gòu)建生成式AI應(yīng)用程序的方法和流程。
無可否認,大型語言模型(LLM)擅長從大量數(shù)據(jù)中存儲和學習事實信息,從而推動了NLP特定任務(wù)架構(gòu)的發(fā)展。然而,由于固有的局限性,他們在面對知識密集型任務(wù)時表現(xiàn)不佳。LLM很難有效地獲取和運用知識,因為他們無法輕易擴展或更新他們的記憶。此外,他們可能會產(chǎn)生被稱為“幻覺”的錯誤輸出,并且常常無法提供對其預測的清晰見解。為了解決LLM的局限性,檢索增強生成(RAG)通過結(jié)合檢索和生成的優(yōu)勢,受到了廣泛關(guān)注,并正在重新定義我們處理文本生成任務(wù)的方式。
在生成式應(yīng)用程序爆發(fā)式增長的時代,從聊天機器人和內(nèi)容生成到問答系統(tǒng)和語言翻譯,檢索增強生成技術(shù)提供了強大的解決方案來提高這些應(yīng)用程序的質(zhì)量和可靠性。RAG應(yīng)用已經(jīng)成為企業(yè)內(nèi)部GenAI的最佳框架,用于各種用例,例如聊天機器人、問答、以及研究和分析。
RAG應(yīng)用開發(fā)框架

圖片

其中,藍色箭頭演示了數(shù)據(jù)處理流程,綠色箭頭演示了查詢-響應(yīng)流程,紅色箭頭描繪了最后一個可選步驟:通過企業(yè)自動化和集成根據(jù)響應(yīng)采取行動。
RAG框架的基本概念和流程:
(1)提示(Prompt):一開始,用戶會提供一個提示,概述他們對響應(yīng)的期望。
(2)上下文搜索(Retrieval):這一關(guān)鍵步驟涉及使用外部上下文信息來增強原始提示。負責從各種來源搜索和檢索數(shù)據(jù)的外部程序開始發(fā)揮作用。此過程可能包括查詢關(guān)系數(shù)據(jù)庫、在索引文檔中進行基于關(guān)鍵字的搜索,甚至調(diào)用API從遠程或外部源獲取數(shù)據(jù)。
(3)提示增強(Prompt Augmented):在上下文搜索之后,檢索到的附加信息將無縫集成到原始用戶提示中。這種增強通過事實數(shù)據(jù)豐富了用戶的查詢,增強了其深度和相關(guān)性。
(4)生成響應(yīng)(Generation):有了這種增強且上下文豐富的提示,語言模型(LLM)就開始發(fā)揮作用。LLM現(xiàn)在配備了原始用戶查詢和補充上下文,顯著提高了其準確性。它可以利用事實數(shù)據(jù)源來提供更精確且與上下文相關(guān)的響應(yīng)。
RAG開發(fā)模塊
簡單來說,RAG框架中包括3個基本模塊:
  1. 數(shù)據(jù)處理模塊
  2. 檢索模塊
  3. 生成模塊
(1)數(shù)據(jù)處理
數(shù)據(jù)處理模塊,包括2部分:一是數(shù)據(jù)接入和加工,二是嵌入。
數(shù)據(jù)接入和加工,處理用于檢索增強生成的數(shù)據(jù)并準備用于查詢。這些數(shù)據(jù)可能來自各種來源,例如數(shù)據(jù)庫或云存儲、S3、Google Drive、本地文件夾或企業(yè)應(yīng)用程序(例如 Notion、JIRA)或其他內(nèi)部應(yīng)用程序。
對基于文本的GenAI應(yīng)用程序,我們需要將任何輸入數(shù)據(jù)轉(zhuǎn)換為適當?shù)奈谋疚臋n格式。例如PDF、PPT或DOCX,那么我們首先從這些文檔中提取實際文本。如果數(shù)據(jù)位于數(shù)據(jù)庫中,則文本源自數(shù)據(jù)庫中的一個或多個列或文檔。這種文檔處理通常是特定于應(yīng)用程序的,并且取決于源數(shù)據(jù)的格式。
文本準備好后,就會被分成適合檢索的“塊”(或段)。使用嵌入模型(如Huggingface的SentenceTransform模型),為每個文本塊計算“向量嵌入”。通常,文本嵌入的結(jié)果,都保存到向量數(shù)據(jù)庫中,以便稍后用于高效的語義檢索。
(2)檢索模塊
檢索模塊,主要使用向量數(shù)據(jù)庫進行語義檢索。用戶發(fā)出查詢,對向量數(shù)據(jù)庫中的數(shù)據(jù)進行語義檢索,獲取到用戶查詢的最相關(guān)信息。
首先,我們使用(相同的)嵌入模型對查詢本身進行編碼,并使用近似最近鄰(ANN)搜索算法來檢索向量存儲中可用的最相關(guān)文本塊的排名列表。
(3)生成模塊
生成模塊,主要利用大模型LLM生成響應(yīng)內(nèi)容。
在這個環(huán)節(jié),我們?yōu)長LM構(gòu)建了全面的提示,包括用戶問題和檢索得到的所有相關(guān)信息。完整的提示將發(fā)送到LLM來生成響應(yīng)。有了用戶問題和相關(guān)事實,LLM現(xiàn)在可以根據(jù)所提供的事實對問題做出回答,從而避免產(chǎn)生幻覺。
生成響應(yīng)后,可以選擇將其發(fā)送到“驗證”服務(wù)(例如Nvidia的Nemo Guardrails),最后返回給用戶。
RAG的應(yīng)用
RAG在各個領(lǐng)域和行業(yè)都有應(yīng)用,利用其結(jié)合基于檢索和生成技術(shù)的能力來增強文本生成和信息檢索。以下是RAG的一些值得注意的應(yīng)用:
(1)問答系統(tǒng):RAG在問答應(yīng)用中特別有價值。它可以檢索并生成用戶查詢的精確且上下文相關(guān)的答案,使其適用于虛擬助理、常見問題解答和專家系統(tǒng)。
(2)聊天機器人和虛擬助理:RAG支持的聊天機器人可以對用戶詢問提供更準確、信息更豐富的響應(yīng)。它們擅長自然語言交互,非常適合客戶支持、信息檢索和對話式人工智能。
(3)內(nèi)容摘要:RAG可用于通過選擇最顯著的信息并生成簡潔的摘要來總結(jié)冗長的文檔、文章或報告。這對于內(nèi)容管理和信息消化很有用。
(4)內(nèi)容生成:RAG用于生成用于各種目的的內(nèi)容,包括新聞文章、報告、產(chǎn)品描述等。它確保生成的內(nèi)容事實上準確且與上下文相關(guān)。
(5)內(nèi)容審核:RAG可以通過識別違反準則或政策的用戶生成內(nèi)容并生成響應(yīng)來協(xié)助在線平臺上的內(nèi)容審核。
(6)知識庫和專家系統(tǒng)——RAG可用于實時更新和擴展知識庫,確保專家系統(tǒng)能夠訪問最新信息。
這些應(yīng)用突出了RAG在各個領(lǐng)域的多功能性和實用性,其中檢索和生成功能的組合顯著增強了基于文本的任務(wù)和信息檢索過程。
RAG的優(yōu)勢
(1)它幾乎消除了幻覺:它消除了由于LLM無法訪問您的數(shù)據(jù)而產(chǎn)生的幻覺。通過準確地從數(shù)據(jù)中檢索最相關(guān)的事實,并在運行時將其提供給LLM,RAG管道可確保LLM擁有最有用的數(shù)據(jù)來回答問題。這在實踐中非常有效。
(2)成本低:RAG不需要任何培訓或微調(diào),這意味著它沒有很高的成本,并且不需要專門的機器學習專業(yè)知識。
(3)可解釋性:使用RAG生成的LLM回復具有高度可解釋性,通過RAG,可以提供引用和回復,以便讀者可以了解哪些事實用于支撐LLM的回復,甚至可以前往這些來源之一進行進一步調(diào)查。
(4)企業(yè)就緒:借助RAG,您可以對檢索到的事實實施細粒度的許可,并設(shè)計控制以確保機密材料不會進入生成GenAI響應(yīng)的事實。

六、Toolformer:讓模型自己使用工具

Toolformer 是一個大型語言模型,通過使用 In-Context Learning 來提高模型理解和生成適合給定上下文或情況的語言能力。它使用 API 調(diào)用來注釋大量數(shù)據(jù),然后使用這些 API 調(diào)用對模型進行微調(diào),以進行有用的 API 調(diào)用。
大語言模型(LLM)在利用有限的文本數(shù)據(jù)解決新任務(wù)方面表現(xiàn)出令人難以置信的優(yōu)勢。然而,盡管如此,它們在其他方面也有局限性,例如:
  • 無法訪問最新信息
  • 幻想事實的傾向
  • 低資源語言的困難
  • 缺乏精確計算的數(shù)學技能
  • 對時間進程的不了解
如何使用大模型解決更多的問題呢?在《解讀TaskMatrix.AI》一文中,TaskMatrix.AI是 Toolformer 和 chatGPT 的結(jié)合,將基礎(chǔ)模型與數(shù)百萬個 API 連接起來以完成任務(wù)。那么,什么是 Toolformer 呢?
Toolformer 是 Meta 開源的新模型,能夠解決需要利用 API 的問題,如計算器、維基百科搜索、字典查找等。Toolformer 能夠認識到它必須使用一個工具,能夠確定使用哪個工具,以及如何使用該工具。Toolformers 的用例可能是無窮無盡的,從提供任何問題的即時搜索結(jié)果,到情景信息,比如城里最好的餐館。

1. 什么是Toolformer?

什么是 Toolformer 呢?簡而言之,Toolformer 是一個可以自學使用工具的語言模型。
Toolformer 基于一個預先訓練的 GPT-J 模型,包含 67 億個參數(shù),使用自監(jiān)督學習方法進行訓練。這種方法包括采樣和過濾 API 調(diào)用,以增加現(xiàn)有的文本數(shù)據(jù)集。
Toolformer 希望通過以下兩個要求來完成 LLM 自學如何使用工具的任務(wù):
  • 工具的使用應(yīng)該通過自我監(jiān)督的方式來學習,而不需要大量的人工注釋。
  • LM 不應(yīng)喪失其一般性,應(yīng)該能夠自行決定何時以及如何使用哪種工具。
下圖顯示了 Toolformer 的預測(例如,在數(shù)據(jù)樣本中嵌入的 API 調(diào)用):
圖片
2. Toolformer 的架構(gòu)和實現(xiàn)方法
ChatGPT 中的一個核心特性是基于上下文的學習(In-Context Learning),指的是一種機器學習方法,其中模型從特定上下文或環(huán)境中呈現(xiàn)的示例中學習。上下文學習的目標是提高模型理解和生成適合給定上下文或情況的語言的能力。在自然語言處理(NLP)任務(wù)中,可以訓練語言模型來生成對特定提示或問題的響應(yīng)。那么,Toolformer 如何利用 In-Context Learning 呢?
Toolformer 是一個大型語言模型,它能夠通過 API 調(diào)用使用不同的工具。每個 API 調(diào)用的輸入和輸出需要格式化為文本/對話序列,以便在會話中自然流動。

圖片
從上面的圖片中可以看到的,Toolformer 首先利用模型的上下文學習能力來對大量潛在的 API 調(diào)用進行采樣。
執(zhí)行這些 API 調(diào)用,并檢查獲得的響應(yīng)是否有助于將來預測 token,并被用作篩選條件。經(jīng)過過濾之后,對不同工具的 API 調(diào)用被嵌入到原始數(shù)據(jù)樣本中,從而產(chǎn)生增強的數(shù)據(jù)集,而模型就是在這個數(shù)據(jù)集上進行微調(diào)的。
具體地,上圖顯示了使用問答工具完成此任務(wù)的模型:
  1. LM 數(shù)據(jù)集包含示例文本: 為“Pittsburgh is also known as”輸入提示“Pittsburgh is also known as The Steel City”。
  2. 為了找到正確的答案,模型需要進行一個 API 調(diào)用并正確地進行調(diào)用。
  3. 對一些 API 調(diào)用進行了抽樣,特別是“ What other name is Pittsburgh known by?”和“ Which country is Pittsburgh in?”。
  4. 相應(yīng)的答案是“Steel City”和“United States”。因為第一個答案更好,所以它被包含到一個新的 LM 數(shù)據(jù)集中,并帶有 API 調(diào)用: “Pittsburgh is also known as [QA(”What other name is Pittsburgh known by?”) -> Steel City] the Steel City”。
  5. 這包含預期的 API 調(diào)用和應(yīng)答。重復此步驟以使用各種工具(即 API 調(diào)用)生成新的 LM 數(shù)據(jù)集。
因此,LM 使用嵌入在文本中的 API 調(diào)用來注釋大量數(shù)據(jù),然后使用這些 API 調(diào)用對 LM 進行微調(diào),以進行有用的 API 調(diào)用。這就是自監(jiān)督訓練的方式,這種方法的好處包括:
  • 更少需要人工注釋。
  • 將 API 調(diào)用嵌入到文本中允許 LM 使用多個外部工具來添加更多內(nèi)容。
Toolformer 然后學會預測每個任務(wù)將使用哪個工具。

2.1 API 調(diào)用的采樣

下圖顯示了給定用戶輸入的情況下,Toolformer使用和來表示API調(diào)用的開始和結(jié)束。為每個API編寫一個提示符,鼓勵Toolformer使用相關(guān)的API調(diào)用對示例進行注釋。
圖片
Toolformer為每個token分配一個概率,作為給定序列的一個可能的延續(xù)。該方法通過計算ToolFormer分配給在序列中每個位置啟動API調(diào)用的概率,對API調(diào)用的最多k個候選位置進行采樣。保持概率大于給定閾值的位置,對于每個位置,通過使用以API調(diào)用為前綴、以序列結(jié)束標記為后綴的序列從Toolformer采樣,最多可獲得m個API調(diào)用。

2.2 API調(diào)用的執(zhí)行

API調(diào)用的執(zhí)行完全取決于正在執(zhí)行調(diào)用的客戶端。客戶端可以是不同類型的應(yīng)用程序,從另一個神經(jīng)網(wǎng)絡(luò)、Python腳本,到在大型語料庫中搜索的檢索系統(tǒng)。需要注意的是,當客戶端發(fā)出調(diào)用時,API會返回一個單一的文本序列響應(yīng)。此響應(yīng)包含有關(guān)調(diào)用的詳細信息,包括調(diào)用的成功或失敗狀態(tài)、執(zhí)行時間等。
因此,為了獲得準確的結(jié)果,客戶端應(yīng)該確保提供正確的輸入?yún)?shù)。如果輸入?yún)?shù)不正確,API可能會返回錯誤的結(jié)果,這對于用戶來說可能是不可接受的。另外,客戶端還應(yīng)該確保與API的連接是穩(wěn)定的,以避免在調(diào)用期間發(fā)生連接中斷或其他網(wǎng)絡(luò)問題。

2.3 過濾API調(diào)用

在過濾過程中,Toolformer通過API調(diào)用后的token計算Toolformer的加權(quán)交叉熵損失。
然后,比較兩種不同的損失計算:
(i)一種是API調(diào)用,其結(jié)果作為輸入給Toolformer
(ii)一種是沒有API調(diào)用或者API調(diào)用但沒有返回結(jié)果。
如果為API調(diào)用提供輸入和輸出,使得Toolformer更容易預測未來的token,那么API調(diào)用就被認為是有用的。應(yīng)用過濾閾值僅保留兩個損失之間的差值大于或等于閾值的API調(diào)用。

2.4 模型微調(diào)

最后,Toolformer將剩余的API調(diào)用與原始輸入合并,并創(chuàng)建一個新的API調(diào)用來增強的數(shù)據(jù)集。換句話說,增強的數(shù)據(jù)集包含與原始數(shù)據(jù)集相同的文本,只插入了API調(diào)用。
然后,使用新的數(shù)據(jù)集使用標準語言建模目標對ToolFormer進行微調(diào)。這樣可以確保在增強的數(shù)據(jù)集上微調(diào)模型會暴露給與在原始數(shù)據(jù)集上微調(diào)相同的內(nèi)容。通過在準確的位置插入API調(diào)用,并使用幫助模型預測未來token的輸入,對增強數(shù)據(jù)的微調(diào)使語言模型能夠了解何時以及如何根據(jù)自己的反饋使用API調(diào)用。

2.5 推理

在推理過程中,當語言模型產(chǎn)生“→”token時,解碼過程被中斷,這表明 API 調(diào)用的下一個預期響應(yīng)。然后,調(diào)用適當?shù)?API 來獲取響應(yīng),并在插入響應(yīng)和token之后繼續(xù)解碼。
此時,我們需要確保獲取的響應(yīng)與上一個token所期望的響應(yīng)相匹配。如果不匹配,我們需要調(diào)整 API 調(diào)用以獲得正確的響應(yīng)。在繼續(xù)解碼之前,我們還需要執(zhí)行一些數(shù)據(jù)處理來準備下一步的推理過程。這些數(shù)據(jù)處理包括對響應(yīng)的分析、對上下文的理解以及對推理路徑的選擇。因此,在推理過程中,不僅需要調(diào)用 API 來獲取響應(yīng),還需要進行一系列的數(shù)據(jù)處理和分析,以確保推理過程的正確性和連貫性。

2.6 API工具

Toolformer 中每個可以使用的API工具都要滿足以下兩個條件:
  • 輸入/輸出都需要表示為文本序列。
  • 有可用的演示表達如何使用這些工具。
Toolformer 的初始實現(xiàn)中支持了五個API工具:
  1. 問答回答:這是另一個LM,可以回答簡單的事實問題。
  2. 計算器:目前只支持4個基本的算術(shù)運算,并四舍五入到小數(shù)點后兩位。
  3. Wiki搜索:返回從維基百科剪切下來的短文本的搜索引擎。
  4. 機器翻譯系統(tǒng):一個可以將任何語言的短語翻譯成英語的LM。
  5. 日歷:對日歷的API調(diào)用,該調(diào)用返回當前日期而不接受任何輸入。
下圖顯示了使用的所有API的輸入和輸出示例:
圖片
局限
對于通過在自監(jiān)督的方法實現(xiàn)語言模型使用各種工具的方法(Toolformer)是存在著一些局限的:
  1. Toolformer是不能鏈式使用工具
  2. 現(xiàn)有的Toolformer不能使語言模型以交互的方式使用工具
  3. Toolformer對于是否調(diào)用API是總是對輸入的某些詞更加敏感
  4. 對于一些工具,這個方法的樣本效率是非常低下的
  5. 目前Toolformer在決定是否調(diào)用API時還沒有將涉及使用工具的算力成本考慮進去
大概解釋一下,第一點就是這個模型還不能將一個工具的使用結(jié)果作為另一個工具使用的輸入,這個原因是出在訓練設(shè)計上的,我們對于每一個工具的訓練是分開獨立的,最后在直接用增廣數(shù)據(jù)集合到一起的。第二點,比如在讓語言模型使用搜索引擎的時候,它只能返回搜索引擎的結(jié)果,而不能幫我們進行一次篩選。第三點,這也是預料以內(nèi)的吧,這個對于語言模型的敏感詞問題是one-shot、few-shot比較難避免的。第四點,這個設(shè)計到一些工具的使用文檔并不適合于機器去學習使用,有一種解決思路是在相關(guān)引導下迭代的是使用這個工具。最后一個就是單純沒考慮。

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導購買等信息,謹防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多