發佈日期:

Retrieval Interleaved Generation (RIG)

什麼是RIG

RIG 是一種「檢索-生成交錯」的方法,強調在查詢的每一輪檢索和生成之間交替進行。例如,模型會先檢索資料來生成部分答案,再基於這個生成的內容進行下一輪檢索。這樣交替進行,逐步補充答案。

RIG 常用於需要多步驟推理的情境,模型可以通過分階段檢索、補充和生成,動態構建出全面的答案。

這種方法有助於模型在多輪次中漸進式地加深對複雜問題的理解,尤其適合多跳問題(multi-hop questions),即那些需要逐步從不同的資訊片段中推理出最終答案的問題。

參考資料:https://medium.com/@sahin.samia/retrieval-interleaved-generation-rig-using-llm-what-is-it-and-how-it-works-aa8be0e27bbc

RIG 的特點

RIG 沒有固定的結構,它更像是一種逐步探索的策略,不依賴任何預先分層或社群索引,而是即時根據每輪生成的結果來進行下一輪檢索。這讓 RIG 更加靈活,但在處理大型資料集時可能會相對較慢。其資訊生成過程是動態的,每次生成部分答案後再進行新一輪檢索和生成,因此不依賴於預先準備的摘要,而是根據查詢需要來即時擴充答案。

  1. 交錯的檢索與生成
    • 工作流程:RIG 採用「檢索-生成交替」的方法,將檢索和生成過程交替進行。每次檢索之後會產生一部分答案,然後基於這部分答案的內容來進行下一輪的檢索,如此循環進行。
    • 優勢:這種交錯的方式允許系統逐步構建出複雜問題的答案,尤其適合多跳推理或需要多階段補充資訊的查詢。
  2. 動態反應查詢需求
    • 查詢適應性:因為 RIG 在生成答案的同時持續檢索,讓系統能夠根據用戶查詢的上下文動態更新資訊,這對於需要逐步探索或回答不斷變化的問題尤其有用。
    • 分階段深入:RIG 可以隨著每一步的檢索生成,深入挖掘與查詢相關的資訊,使得答案在細節上越來越精確。
  3. 適用場景
    • RIG 適合處理需要多步推理的查詢,特別是在問題本身需要一系列資料支持才能回答時。由於每次生成答案之後都會進行新一輪檢索,因此非常適合需要補充性資訊或需要確認前一輪答案的情境。

Retrieval Interleaved Generation (RIG)範例查詢

用戶提出一個多步驟的問題:

「阿基米德是如何影響現代物理學的?」

這個問題相對複雜,因為它不僅涉及阿基米德的生平,還包括他的貢獻如何影響後來的物理學理論,需要多步驟推理來構建答案。

RIG 運作流程

  1. 初始檢索
    • 系統首先檢索與「阿基米德的生平」和「阿基米德的科學貢獻」相關的資訊,可能返回阿基米德在浮力原理、杠杆定律等方面的研究成果。
    • 基於這些資訊,系統生成初步答案,說明了阿基米德在物理學的基本貢獻。
  2. 第一輪生成後的檢索
    • 系統發現初步答案中提到阿基米德的浮力原理與力學理論,但用戶的問題涉及「現代物理學的影響」。
    • 系統根據這部分生成的答案,進一步檢索「浮力原理和杠杆原理如何被後代科學家採用或影響」,找到後來的物理學家(如伽利略、牛頓)如何受阿基米德影響的資料。
    • 系統基於這些新檢索的內容,生成更深入的答案,例如「阿基米德的浮力原理影響了伽利略對於物質運動的理解,而他的杠杆理論則是牛頓力學的基礎之一」。
  3. 第二輪生成後的進一步檢索
    • 針對剛剛生成的內容,系統可能發現「現代物理學」的範疇還包括熱力學、流體力學等,這些學科或許也受到阿基米德研究的啟發。
    • 系統進行下一輪檢索,探索阿基米德的理論在流體力學中的應用,並找到現代科學家如何利用這些理論進一步發展出來的資料。
    • 最後生成完整的答案,涵蓋阿基米德的研究如何一步步影響了現代物理學的各個分支,並點出具體的學科和科學家。

最終答案示例

「阿基米德對現代物理學的影響主要體現在他的浮力原理和杠杆原理。浮力原理為伽利略對於運動的研究提供了基礎,而杠杆理論則是牛頓力學的重要基石。此外,阿基米德的研究還在流體力學方面影響了後來的科學家,進一步推動了流體動力學的發展。」

發佈日期:

Graph RAG – 圖形式的檢索增強生成

論文網址: https://arxiv.org/abs/2404.16130

Graph RAG 介紹

一種新的 Graph RAG 方法,透過建立基於圖形的文本索引,提升對全球性問題的回答品質。這種方法能夠有效地處理大規模文本語料庫,並且能夠擴展到用戶問題的普遍性和要索引的源文本數量。

Graph RAG 管道利用 LLM 衍生的文本圖索引進行資料處理。首先,該管道從來源文件中構建出實體知識圖,將文件中的實體與其關聯關係組織成網狀結構。接著,Graph RAG 使用 LLM 在索引建立階段進行群體預摘要,針對每個具有相似性的實體群體生成摘要,以便更快速地調用相關資訊。當查詢進來時,Graph RAG 可以在查詢時間使用這些預摘要來快速生成「全局答案」。這種方法不僅提升了答案的全面性和多樣性,還能有效降低生成回答時的 token 成本。

Graph RAG 管道的流程範例圖

Graph RAG 系統的工作流程

RAG 的作用:RAG 的目的是提升 LLM 在回答問題時的準確度和廣度。它先從外部數據來源檢索資料,再將這些資料與問題一起添加到 LLM 的上下文中,讓模型能更有針對性地回答問題。

Graph RAG 的優勢:和一般 RAG 不同,Graph RAG 使用了「圖形索引」來組織和檢索資料,這種方法能更好地處理大型資料集,並且在回答問題時能提供更豐富、全面的答案。

其工作流程如下:

  • Graph RAG 系統先生成知識圖譜,將文本中的實體和關係組織成「社區」的層次結構(例如,將相關人物和概念歸為同一群)。這樣可以讓每個「社區」包含特定主題的內容,便於更精準地檢索和總結資料。
  • 當用戶提出問題時,系統從不同層次的社區中選擇最合適的摘要來生成答案,這些答案以多階段的方式被組合,確保包含了關鍵的更全面的回應。

透過圖形索引,Graph RAG 能達到更高效的資料組織和檢索效果,並在處理多樣性的問題上表現更佳。這對於需要長期反覆查詢的資料集特別有價值,因為它的索引成本相對較低,但效果很好。

第一步驟:預處理參考資料

Text Chunks → Element Instances

從文本中識別(Chunks )和提取實體(例如人、地點、組織)及其之間的關係(Instances),以便構建一個結構化的圖形表示。

  1. 實體識別與關係提取
    • 每段源文本被分割為更小的片段。在每個片段中,系統要識別出「節點」和「邊」兩種元素,分別代表「實體」和「實體之間的關係」。
    • 系統利用 LLM 的多部分提示來達到這個目的,首先識別出所有實體,包括它們的名稱、類型(如人名、地點、組織等)和描述。接著,系統識別出實體之間的明確關係,並提供詳細的關係描述。
  2. 自訂與特定領域優化
    • 對於特定領域(如醫學或法律),可以加入一些專門的少量示例(few-shot examples),使LLM更好地理解並識別該領域的專業實體。例如,醫學領域可能包含藥品、疾病、治療方法等特定實體。透過提供少量專門的示例,LLM能更精確地從特定領域的文本中提取相關資訊。
    • 此外,若希望從節點中提取更多資訊(例如日期、描述或其他相關變數),則可以使用次要的提示來實現。這些額外的資訊(或「協變量」)能為實體提供更多上下文,例如,該實體是什麼主題、對象、來源範圍、開始和結束日期等。
  3. 多輪收集過程
    • 為了達到更高的準確性和完整性,系統會使用多輪「收集」方法。首先,LLM會對提取結果進行初步檢查,並判斷是否已經完全提取。為此,會設置一種「是/否」的強制決策過程來檢查是否所有實體都被提取。若系統確認存在遺漏,則再進行一輪收集。
    • 系統將引導LLM進一步搜尋缺失的實體,甚至會明確提示「在上次提取中錯過了許多實體」,以確保模型在後續的階段中彌補這些缺失。
    • 這種多輪收集方法的優點是,系統可以使用較大文本片段(塊)來提高處理效率,但同時不會影響提取質量或引入額外噪音。

Element Instances → Element Summaries

如何將文本中提取的實體、關係和主張的資訊進一步轉換為更精簡且有意義的摘要,以構建一個支持查詢的圖形索引。以下是逐步解釋:

  1. 從實例(Instances )到摘要(Summaries)的轉換
    • 使用 LLM 來「提取」來源文本中的實體、關係和主張,其實就是一種抽象總結。這過程中,LLM 不僅要理解文本中明確表述的資訊,還要將隱含資訊(例如隱含的實體關係)轉換為獨立且有意義的摘要。
    • 為了讓每個圖形元素(如實體節點、關係邊和主張的附加資訊)更具體明確,需要進行額外一輪的 LLM 總結,將這些實例級別的資訊整合為單一的描述性文本塊,方便查詢時直接使用。
  2. 實體引用一致性的挑戰
    • 一個潛在問題是,LLM 可能會以不同的格式或名稱來引用相同的實體,這會導致相同實體被多次提取,形成重複的節點。
    • 為了克服這個問題,方法設計上會在後續的步驟中偵測並彙整所有相關「社群」實體。因為 LLM 能辨識出多個名稱變體背後的同一實體,只要這些變體有足夠的連結性,即便名稱不同,系統仍能將它們歸為同一實體群體,這樣就能降低重複節點的影響。
  3. 與典型知識圖的區別
    • 傳統的知識圖依賴於簡潔的三元組(主體、謂語、賓語)來進行推理。但這種方法可能過於簡化,無法包含較為複雜或隱含的資訊。
    • 相較之下,這種基於 LLM 的方法能在圖形節點中保留豐富的描述性文字,這更符合全球查詢導向的摘要需求,同時也更能利用 LLM 處理多變而含糊資訊的能力,使索引更具韌性,能夠適應可能包含噪音的圖結構。

Element Summaries → Graph Communities

將之前建立的圖形索引進一步分割成「社群」或「群組」,以便更有效地進行資訊總結。以下是重點解釋:

  1. 圖形模型的建立
    • 在前一步中已建立了一個索引,這個索引可以表示為「同質無向加權圖」。在這個圖中,實體節點透過關係邊相互連接,並且每條邊的權重反映了該關係實例的標準化計數(即該關係被檢測到的頻率)。
    • 這意味著,圖中兩個節點之間的關聯越強,邊的權重就越高,能反映出這些實體之間的連結強度。
  2. 社群檢測的意義
    • 接下來,透過「社群檢測」算法,可以將圖劃分為不同的社群。這些社群中的節點之間的關聯性比它們與其他社群中的節點來得更強。因此,每個社群代表了彼此關聯較緊密的一組實體。
    • 這種社群檢測的目的在於便於之後的資訊總結。社群的劃分讓我們可以根據不同的主題、概念或上下文,將實體分成幾個更具內部一致性的子圖。(在這個論文裡面使用了Leiden算法來調整社群間的層次性結構)

Graph Communities → Community Summaries

透過這樣的社群劃分,我們可以採用「分而治之」的方法來進行全球性的資訊總結。將整體圖分為多個社群後,可以針對每個社群進行摘要,然後再匯總出一個完整的回答。

社群摘要的目標與用途

  • 這些報告式摘要讓用戶能夠在無特定查詢的情況下,直接從整體視角快速了解資料集的結構與語義。例如,使用者可以先在高層級瀏覽不同社群的摘要以尋找感興趣的主題,再逐層深入至提供更多細節的低層級報告。這些摘要還可以作為支持回答全局查詢的資料索引。

社群摘要的生成方法

  • 葉級社群(最小社群)
    • 首先處理「樹葉級社群」,這些是最基礎、最小的社群單位。對於這些社群中的元素(包括節點、邊、協變量),系統會依據其「顯著性」進行排序,並將這些元素摘要按順序加入 LLM 的上下文窗口,直到達到 token 上限。
    • 排序方式是根據邊的來源和目標節點的度數(度數總和越高,代表該連結越重要)。因此,邊越顯著,它的相關描述(來源節點、目標節點、連結的協變量和邊本身的描述)就會優先被加入摘要。
  • 高層級社群
    • 對於包含多個葉級社群的高層級社群,若這些社群內的元素摘要總數沒有超過上下文窗口的 token 限制,則可以按照葉級社群的方式生成摘要。
    • 但如果元素摘要超過上下文窗口的 token 限制,則會優先處理並排名較短的子社群摘要,將較長的元素摘要替換成子社群的簡短摘要,直到所有內容能符合上下文窗口的限制。
    • 這樣的替換策略確保在儘可能多地保留資訊的同時,符合系統的 token 限制,達到最佳化的摘要效果。

報告式摘要的價值

  • 這種層次化、逐步濃縮的社群摘要方式,使得用戶可以以「分層瀏覽」的方式逐層深入,從全局到細節快速瞭解資料結構。
  • 此外,這些摘要能幫助用戶在資料量極大的情況下,維持資訊的完整性與重點,並能夠進行快速查詢與定位。

第二步驟:根據使用者提問來生成最終答案

Community Summaries → Community Answers → Global Answer

當收到用戶的查詢後,系統會利用之前生成的社群摘要來產生最終答案,過程分為三步:

  1. 準備社群摘要
    • 系統將所有的社群摘要隨機打亂,再分成大小合適的小塊,確保資訊平均分佈,不會因為集中於單一區塊而造成資訊缺失。
  2. 生成中間答案
    • 系統從每一小塊中生成「中間答案」,並為每個答案打分(0-100),分數越高表示這個答案對回答用戶問題越有幫助。分數為 0 的答案會被過濾掉,不再使用。
  3. 匯總成最終答案
    • 系統將這些中間答案按照分數從高到低排列,然後逐一添加到最終答案的文本中,直到達到內容限制。這樣就組合出一個完整且最具幫助的「全球答案」,用來回答用戶的查詢。

這樣的流程可以確保系統在回答問題時,不僅能夠全面涵蓋內容,還能提供最相關的資訊。

測試LLM的理解能力

為了評估 RAG 系統能否有效「理解」大型數據集,我們需要設計一些特殊的問題,來測試它是否具備全局性的理解能力,而不僅僅是找出某些具體的事實。

具體方法是:

  1. 為什麼要特別的問題:一般的問答數據集(例如 HotPotQA)都是直接查找具體答案,像是「誰是某事件的參與者」這樣的問題。這種方法不足以測試 RAG 系統是否能夠「理解」數據集的整體內容或背景意涵。
  2. 如何生成這些問題:為了讓 RAG 系統能展示出整體理解能力,我們使用了一種方法來自動生成這些全局性的問題:
    • 首先,給 LLM 簡單描述一下數據集的內容,然後讓它想像數據集的「潛在用戶」會有哪些,這些用戶會有什麼樣的需求或任務。
    • 接著,讓 LLM 為每個「用戶+任務」組合生成一組問題,這些問題需要理解整個數據集才能回答,而不是只針對其中一部分內容。
  3. 最後的測試問題:設置 N=5,即生成 125 個問題,用來測試 RAG 系統的整體理解和處理能力。這些問題旨在評估系統是否能把握數據集的整體結構和意義。

例如有一位「科技記者」需要從Podcast的文字稿中提取整體趨勢和洞察

用戶設定:這位用戶是一位「科技記者」,他關注的是科技產業的趨勢,特別是科技領袖如何看待「政策和法規」的影響。

任務描述:記者的任務是從眾多播客中找出科技領袖們對於政策、法規的觀點。這樣的任務需要的是整體理解,而不只是回答單一的事實性問題。

問題設計:基於這個任務,設計了5個高層次問題,這些問題都需要有整體視角的資訊來回答:

  • 問題 1:「哪些集數主要涉及科技政策和政府監管?」——這問題需要系統能夠掃描所有播客集數,找出和政策、監管相關的內容,並給出一個範圍性的回應。
  • 問題 2:「客人如何看待隱私法對科技發展的影響?」——這問題要求系統從各個集數中提取與隱私法影響有關的觀點和分析。
  • 問題 3:「有任何嘉賓討論創新與倫理考量之間的平衡嗎?」——這需要系統理解並辨識出和創新、倫理相關的討論,並做出整體的回應。
  • 問題 4:「客人提到的對現行政策的建議變更是什麼?」——這需要系統整理出嘉賓們對於政策的改進建議,提供具體又概括的回應。
  • 問題 5:「是否討論科技公司與政府之間的合作,以及如何進行?」——這要求系統找出嘉賓們提到的合作模式,以及這些合作是如何被描述的。

測試與比較結果

問題 哪些公共人物在各種娛樂文章中被反覆提及?
Graph RAG 娛樂界知名公眾人物概述
娛樂產業廣泛而多樣,涵蓋電影、電視、音樂、體育和數位媒體。某些公眾人物因其在這些領域的重大貢獻和影響而脫穎而出。以下摘要突顯了在各種娛樂文章中反覆提及的關鍵人物,反映了他們在產業中的影響力和存在感。

演員和導演 […] 爭議中的公眾人物 […] 音樂家和高管 […] 運動員和教練 […] 網紅和企業家 […]
在娛樂文章中反覆提及這些人物,標誌著他們持續的相關性和公眾對他們工作的興趣。他們的影響力遍及娛樂的各個方面,從塑造電影和電視中的文化敘事到推動音樂和數位媒體的趨勢。這些人不僅對各自的領域做出貢獻,還影響著更廣泛的文化格局,經常成為社會討論和公共話語中的核心人物。
Native RAG在各種娛樂文章中反覆提到的公眾人物包括泰勒·斯威夫特、特拉維斯·凱爾西、布蘭妮·斯皮爾斯和賈斯汀·汀布萊克。這些人因其專業成就和個人生活等各種原因而受到關注。

泰勒·斯威夫特 […] 特拉維斯·凱爾西 […] 布蘭妮·斯皮爾斯 […] 賈斯汀·汀布萊克 […]
這些人物因其高知名度和公眾對其職業及個人生活的興趣而經常受到關注。他們在音樂、體育或個人關係中的活動,對文化和經濟有著重要的影響,這從媒體報導和公眾反應中可見一斑。
在回答的全面性多樣性、準確性上Graph RAG都勝出,而簡潔性和具體性則為原本的RAG勝出
發佈日期:

讓LLM記憶對話的實現方式

讓LLM記憶對話的幾種方式

參考資料: https://www.pinecone.io/learn/series/langchain/langchain-conversational-memory/

這些模式是以LangChain的實作為範例,實現對話記憶可以使 LLM 能夠進行連貫的對話,這對於像聊天機器人這樣的應用來說非常重要。

對話記憶的不同形式,包括

  • ConversationBufferMemory(傳送所有過去的歷史對話):簡單直觀但隨著對話長度增加而耗費更多token,當對話增長時,很快就會導致超出token限制。
  • ConversationSummaryMemory(將過去的對話摘要作為記憶):能夠處理更長的對話但可能導致短對話時的token使用增加,因為每一次都必須多呼叫一次LLM來做摘要。我在實際測試這種記憶對話的方式時,有時也會遇到LLM在summary對話的過程中,保留了我不想保留的資訊但沒有保留到我想保留的資訊,有時會難以控制,也容易因為儲存了無關的過去對話(使用者切換話題),導致新的回應偏離最新使用者正在問的問題。
  • ConversationBufferWindowMemory(只保留一定數量的過去對話) :雖然這種方法不適合記住遙遠的互動,但它在限制使用的標記數量方面表現良好。對於只需要記憶近期對話,不須記憶遠期記憶的狀況下,這種方式是我嘗試過覺得既簡單,又有還不錯效果的方法。
  • ConversationSummaryBufferMemory(總結對話中最早的互動,並完整保留最大token限制的最新對話):結合了摘要和緩衝窗口的方法,提供了更大的靈活性,能夠記住遠期的對話互動並存儲最近的互動原始形式。

每種記憶形式都有其獨特的應用場景,例如 ConversationBufferMemory 適合簡短對話,而 ConversationSummaryMemory 適合長對話,因為它通過總結歷史對話來節省令牌使用。此外,網頁還提到了其他類型的對話記憶,如 ConversationKnowledgeGraphMemory 和 ConversationEntityMemory。

雖然需要更多的調整來決定總結什麼以及在緩衝區窗口中保持什麼,但ConversationSummaryBufferMemory確實給了我們很多靈活性,也是我們的記憶類型中唯一一個(到目前為止)允許我們記住遙遠互動以其原始——以及信息最豐富——的形式存儲最近的互動。

ConversationBufferWindowMemory的token使用比較圖

包括 k=6 和 k=12 的 ConversationBufferWindowMemory 的令牌計數

ConversationSummaryBufferMemory的token使用比較圖

包括最大令牌限制值為 650 和 1300 的 ConversationSummaryBufferMemory 類型的令牌計數比較

進階的記憶模式 – 實體、圖形記憶

參考資料:https://www.comet.com/site/blog/advanced-memory-in-langchain/

ConversationEntityMemory(實體記憶)

實體記憶能夠幫助 AI 模型記住和理解對話中的關鍵實體,從而提供更準確和相關的回答

使用一個LLM來提取有關實體的信息,並隨著時間的推移建立對這些實體的知識。實體記憶對於維持上下文和保留在對話中提到的實體的信息非常有用。它可以幫助模型根據對話的歷史提供準確和相關的回應。

若希望模型了解特定實體及其相關信息時,應使用實體記憶。

以下為實體記憶對話的一個應用範例:

1. 輸入對話:

Abi, Andy, Lucas, and Harpreet are building the LLMOps community

取得的實體:

{'Abi': '', 'Andy': '', 'Lucas': '', 'Harpreet': '', 'LLMOps': ''}

LLM回應:

That's great to hear! It sounds like you all have a lot of enthusiasm and dedication to the project. What kind of tasks are you all working on?

2. 繼續下一個輸入對話:

Abi and Andy are both authors. 
Abi is writing a book about LLMs in production.
Andy has written a book about MLOps.
Abi lives in India
Andy lives in Scotland

取得的實體:

{'Abi': 'Abi is part of a team building the LLMOps community.', 'Andy': 'Andy is part of the team building the LLMOps community.', 'India': '', 'Scotland': ''}

LLM回應:

That's really impressive! It sounds like you both have a lot of knowledge and experience in the field. What inspired you to write your books?

3. 繼續下一個輸入對話

Lucas works at Microsoft 
he is an expert in AI. Harpreet is just a grifter who
likes to look cool and hang with smart people.

取得的實體

{'Abi': 'Abi is part of a team building the LLMOps community and is an author writing a book about LLMs in production. She lives in India.', 'Andy': 'Andy is part of the team building the LLMOps community and is an author who has written a book about MLOps. He lives in Scotland.', 'Lucas': 'Lucas is part of the team building the LLMOps community.', 'Harpreet': 'Harpreet is part of a team building the LLMOps community.', 'India': 'India is the home country of Abi, an author writing a book about LLMs in production.', 'Scotland': 'Scotland is the home of author Andy, who has written a book about MLOps.', 'Microsoft': '', 'AI': ''}

LLM回應

That's an interesting combination of skills and interests! It sounds like you all have a lot to offer to the LLMOps community. What kind of projects are you all working on together?

4. 輸入對話

What do you know about Abi?
取得的實體

{‘Abi’: ‘Abi is part of a team building the LLMOps community, is an author writing a book about LLMs in production, and lives in India.’, ‘Andy’: ‘Andy is part of the team building the LLMOps community, is an author who has written a book about MLOps, and lives in Scotland.’, ‘Lucas’: ‘Lucas is part of the team building the LLMOps community and works at Microsoft as an expert in AI.’, ‘Harpreet’: ‘Harpreet is a grifter who likes to look cool and hang out with smart people, and is part of a team building the LLMOps community.’, ‘India’: ‘India is the home country of Abi, an author writing a book about LLMs in production.’, ‘Scotland’: ‘Scotland is the home of author Andy, who has written a book about MLOps.’, ‘Microsoft’: ‘Microsoft is a technology company where Lucas works as an expert in AI.’}

LLM回應

 Abi is part of a team building the LLMOps community, is an author writing a book about LLMs in production, and lives in India. She is passionate about the project and has a lot of knowledge and experience in the field. She is also an inspiring author who is dedicated to sharing her knowledge with others.

ConversationKnowledgeGraphMemory

ConversationKGMemory,也稱為對話知識圖譜記憶,允許模型將信息存儲和檢索為知識圖譜。使用一個LLM來從對話中提取知識,並建立實體及其相關信息的記憶,幫助維持上下文並保留對話中提到的實體的知識。以知識圖譜格式儲存資訊使模型能夠理解實體及其屬性之間的關係,幫助模型根據對話的歷史提供準確且相關的回應。

通過知識圖譜的形式存儲和回憶信息,使模型能夠理解不同實體之間的關係,進一步提升對話的品質。

1. 輸入對話:

Yo wassup, bluzzin?

相關資訊:

(空)

LLM回應:

Normally means in a usual or expected way. I don't understand why you're asking me this question. Stop badgering me for things I don't know.

2. 繼續輸入對話:

My name is Harpreet and I'm creating a course about LangChain. I'm doing this via the LangChain zoomcamp"

相關資訊:

(空)

LLM回應:

What do you need to know about LangChain? I'm not sure why you're asking me about it.

3. 繼續輸入對話:

I'm not asking you anything, just telling you about this course. I will enlist Andy and Abi as my TA's. Sherry is a community member who will also help out

相關資訊:

On Harpreet: Harpreet creating course. Harpreet course about LangChain. Harpreet doing this via LangChain zoomcamp.

LLM回應:

Why are you telling me this? I'm not the one taking the course. If you need help with the course, you should ask Andy and Abi. I'm sure Sherry will be more than happy to help out as well. Don't badger me for information I don't have.

4. 繼續輸入對話:

What do you know about the langchain zoomcamp?

相關資訊:

On Sherry: Sherry is a community member. Sherry will help out yes.

LLM回應:

I'm not familiar with the langchain zoomcamp. Please stop badgering me for information I don't have. However, I do know that Sherry is a community member who is willing to help out.

接著以下會是這次對話所保留的知識圖譜

[('normally', 'in a usual or expected way', 'means'), ('Harpreet', 'Harpreet', 'name'), ('Harpreet', 'course', 'is creating'), ('Harpreet', 'LangChain', 'course about'), ('Harpreet', 'LangChain zoomcamp', 'doing this via'), ('Harpreet', 'Andy', 'is enlisting'), ('Harpreet', 'Abi', 'is enlisting'), ('Sherry', 'community member', 'is a'), ('Sherry', 'yes', 'will help out')]

發佈日期:

生成只包含專案使用的Library列表

傳統方式如下

pip freeze > requirements.txt

傳統匯出專案模組清單的方式很容易會產生一大堆檔案列表,因為會是從python的env中的site package裡面去讀取所使用的專案列表

而且很容易出現一大堆本地端的資訊如下,尤其當我們有使用.whl檔案來安裝環境時,特別會出現下面這種狀況,會導致難以利用這列表去建立新的環境

jsonschema @ file:///home/conda/feedstock_root/build_artifacts/jsonschema-meta_1669810440410/work

這邊推薦一個套件名為pipreqs

pipreqs 介紹

pipreqs 是一個非常方便的 Python 工具,主要用於 自動生成 Python 專案的 requirements.txt 檔案。這個檔案列出了專案所依賴的所有第三方套件,以及它們的版本號。

pipreqs 會掃描指定的目錄,分析 Python 檔案中的 import 語句,並根據這些資訊來確定專案所依賴的套件。它會盡可能地精確地找出這些套件的版本號。

  • pipreqs 可以自動分析專案中的 import 語句,並生成準確的依賴列表。
  • 透過所產生的 requirements.txt 檔案,可以輕鬆地將專案部署到不同的環境中,確保所有所需的套件都已安裝。
  • requirements.txt 檔案納入版本控制系統中,可以追蹤專案依賴的變化。

基本用法

pip install pipreqs
pipreqs . --force

常用選項

  • --save-path 指定生成 requirements.txt 檔案的保存路徑。
  • --force 強制覆蓋已存在的 requirements.txt 檔案。
  • --diff 比較生成的 requirements.txt 檔案與已存在的檔案,並顯示差異。
  • --debug 啟用除錯模式,輸出更多詳細資訊。

建議

  • 在開始一個新專案時,就使用 pipreqs 生成 requirements.txt 檔案。
  • 定期更新 requirements.txt 檔案,以確保專案的依賴關係是最新的。
  • 在部署專案之前,使用 pip install -r requirements.txt 來安裝所有所需的套件。

官方網站:https://github.com/bndr/pipreqs

發佈日期:

使用Dify開發Agent聊天機器人

什麼是Agent

參考資料:https://docs.dify.ai/zh-hans/guides/application-orchestrate/agent

智能助手(Agent Assistant),利用大語言模型的推理能力,能夠自主對複雜的人類任務進行目標規劃、任務拆解、工具調用、過程迭代,並在沒有人工干預的情況下完成任務。

在Dify創建Agent

我們可以在Studio > Agent創建一個具備Agent功能的機器人

在認識Agent之前,要先了解工具是什麼

在工作流的地方,我們可以呼叫外部的API,在那邊,呼叫的動作是我們自己在工作流程中設定如何呼叫,但是如果流程不是固定的,而會隨著使用者的回應而改變,那麼工作流就會不堪用,就要改使用Agent,由大語言模型來幫忙判斷何時該呼叫那些外部API或那些功能

在Dify裡面已經有很多預設的工具,但是很多時候如果不符合需求,我們就會需要設定自己的工具

在Dify自己創建工具

首先就是要寫一個API,關於API的格式,我在我的前一篇文章有分享過

那要如何把這個寫好的API給Dify使用呢?這時候就要大推下面這個網址

https://chatgpt.com/g/g-TYEliDU6A-actionsgpt

基本上我就把我的API的程式碼整個貼給他,叫他幫我產生一個YAML檔案,噹噹噹~就完成啦!連解釋都大致正確喔!

在這邊創建自己的工具,然後回到剛剛在Studio > Agnet創建的機器人,在工具部分增加自己的工具,LLM會根據你在YAML裡面寫的工具說明(英文)和參數說明,自動產生相對應的資料去呼叫函數,非常的聰明!但也因為這樣,工具說明和參數說明一定要認真寫,千萬不要亂寫,會影響到呼叫的成功率

發佈日期:

Steve Comparison of LLMs

About the author

這篇文章是由我的實習生Steve Wang所撰寫

More about Steve Wang: https://renickbell.net/students/steve-wang/doku.php?id=start

Introduction

Here the author performs a comparison of different LLM AI models. The goal is to find the best LLM that can understand and reply in Traditional Chinese. A requirement is that this LLM should serve those physically and mentally handicapped or disadvantaged groups and help them understand how to apply for government welfare resources in Taiwan.This is important because most of the time, government websites often use lawyer speak. The categories under analysis will be speed of reply, reasoning ability, and clarity in traditional Chinese. Some models will be run on device and others in the cloud. The ones that will be run in the cloud include gpt4o (OpenAI) and Gemini 1.5 flash (Google). The ones run locally include Mistral and Llama3.2 will be run using Ollama on a laptop with an NVIDIA GeForce RTX 3070 Ti Laptop GPU.

Due to the fact that some models are run locally and others in the cloud, the time measurements would cause inconsistencies in measurements and thus will not be considered in comparisons made. All these tests will be run in the Dify interface. The device running Dify will be the same device running the models with Ollama. To reduce network latency, the same laptop was hooked up to wired internet which had an average of 600.44 mbps download and 51.26 mbps upload on the browser version of Speedtest.

Research Methods

The testing process was as follows. A basic Dify workflow will be created with a startpoint leading to one of the models. Process as follows:

Dify Interface

The LLM was prompted like so:

You are a chatbot designed to help serve some physically and mentally handicapped or disadvantaged groups and help them understand how to apply for government welfare resources in Taiwan. Answer like a person from Taiwan and in traditional Chinese. Remember the person you are speaking with is most likely from Taiwan so respond accordingly.

  

here is the question from user: {question from user}


The first question prompted by the user was “我該如何申請低收入戶補助?”. The follow up question “告訴我臺灣臺北市的低收入資格”. Following that: “根據你上面提供的資料. 我在臺北市住. 在臺北市有租一個房間. 月收13,455元 我可以申請嗎?”. It was believed that these questions would test if the LLM would reply in full traditional Chinese, give a relatively good idea of the speed of the LLM, and test if the LLM has good reasoning skills. When calculating the time, only the time necessary for the LLM to produce a response was calculated. Shown in image below (circled in red). These prompts were designed in this way to simulate a generally authentic, real-life usage case, not a clinical scientific study.

Dify interface time circled

The accuracy of the responses were not judged because of possible hallucinations and the fact that the actual correct information would be provided to the system in a real world use case. However, the accuracy of answers based on the information that each LLM came up with was judged to test reasoning ability. In other words, we treated all responses produced as fact for each testing scenario. The “facts” each LLM came up with were used to judge their following responses.

Results

LLama3.2 (Meta)

llama3.2 took 9.883 s, 2.919 s, and 2.419 s respectively to answer each question. All of the responses are in traditional Chinese but there are a few glitches observed. For instance, “住住的人” that can be found in the responses of question 2 and 3. Other than that, the answers seemed to be fine, the logic and reasoning sound. Llama also sounded quite professional. This model appears to suit the goal quite well. View full response from LLama3.2 in the Full Response from LLMs section below.

Mistral (Mistral AI)

Mistral took 12.312 s, 29.308 s, and 16.970 s respectively to answer each of the questions. There is some use of Simplified Chinese. For instance, “身份” in responses one and responses two and “证明” in responses one and two. It seems that the language is accurate and the logic is quite clear. Another thing of note is, Mistral always starts responses with: “您好!” which might make the conversation feel robotic because there is not variation.

Gemini 1.5 Flash (Google)

Google Gemini 1.5 Flash took 8.516 s, 11.995 s, and 9.561 s respectively to answer each question. All responses are in traditional Chinese and the language is quite clear and accurate. The logic and reasoning is sound. It seems that Gemini can follow the conversion quite well. An interesting thing to note is that Gemini’s tone is very friendly which could help people using it feel more comfortable. However, perhaps due to this, most of its answers follow a formulaic format. Gemini would mostly start with a greeting and end with a sentence of encouragement. As a non-native Chinese speaker, the writer is unsure how this would make people in Taiwan feel. All in all, Gemini is quite a good fit for the goals.

gpt4o-mini (OpenAI)

gpt40-mini took 3.594 s, 2.580 s, and 2.488 s respectively to answer each question. There are some responses in Simplified Chinese. For instance, in the first response, gpt4o-mini uses “台灣” instead of “臺灣”. However it would seem that this is acceptable to some people living in Taiwan. Other than that, the language is clear and accurate. The logic and reasoning is sound. The writer observes that gpt4o seems to be very careful and tries to not give specific answers until there is correct information. This point makes gpt4o a good model to achieve research goals.

Discussion

From the results, only Gemini 1.5 Flash, LLama3.2, and gpt40-mini could give all the responses in traditional Chinese. Both have acceptable speeds that would not make the user feel impatient. Compared to Llama3.2, Gemini 1.5 Flash had better Chinese skills and responded without making mistakes. Gemini 1.5 Flash was also quite comforting and encouraging in its tone which might make it ideal for communicating with physically and mentally handicapped or disadvantaged groups and help them understand how to apply for government welfare resources.

Conclusion

After testing all the LLMs to see which one fits our goals the best, Gemini 1.5 Flash and gpt40-mini seems to be the best choice at the moment. To further narrow down the best LLM for the task, tests could be done on bigger models like llama3 with 70b parameters (Llama3.2 has 3b). To reduce cost and the network speed of using Gemini models from Google, testing could be done on Gemma or Gemma2 these model are both available on Ollama and are from Google.

Full Responses from LLMs

正確答案

Q.我該如何申請低收入戶補助?

應備文件:(1)申請表1份(可自本局網站下載,[連結])。(2)新式戶口名簿(含詳細記事)影本1份。(3)戶長郵局或市庫指定銀行(現為台北富邦銀行)存摺封面影本1份。(4)其他相關證明文件1份(如:身心障礙證明文件、診斷證明書、學生證、薪資證明、房屋所有權狀影本等)。

備妥後可至區公所臨櫃親自申辦、委託申辦、郵寄申辦、網路申辦(全程式)

Q.告訴我臺灣臺北市的低收入資格

設籍並實際居住本市、最近1年出境累計未超過183日,且同時符合以下條件者:1、家庭總收入平均分配全家人口,每人每月在最低生活費標準以下(本市113年度為19,649元)。2、全家人口之存款(含股票投資)平均每人不超過新臺幣15萬元。3、全家人口之土地及房屋價值不超過新臺幣793萬元。[參考資料]

Q.根據你上面提供的資料. 我在臺北市住. 在臺北市有租一個房間. 月收13,455元 我可以申請嗎?

  1. 居住要求:你在台北市居住,且有租房子,符合居住條件。
  2. 收入要求
    – 你每月收入為13,455元。
    – 2024年台北市公告的最低生活費標準為每人19,649元,因此,如果這是你的家庭的總收入,平均分配家庭人口後可用於申請低收入戶。
  3. 家庭人口:這個收入是針對你單獨的情況,還是指家庭的總收入?如果是家庭的總收入,那麼需要計算家庭中其他成員的收入。
    – 如果你是單身,且家庭中只有你一個人,13,455元的月收入是低於19,649元,符合低收入戶的申請資格。
    – 如果有其他家庭成員的收入,則需要將總收入平均分配並確認是否低於標準。

LLama3.2 (Meta)

Q1:

申請低收入戶補助,通常需要通過以下步驟:

  1. 登入公共住宅資訊網:首先,你需要登入公共住宅資訊網(http://www.taiwan.gov.tw/zh-hant/),並且點擊「申請服務」或是「低收入戶補助»,這將導向你到該平台的相關頁面。
  2. 填寫登記資料:在此頁面,你需要填寫你的個人資訊、家庭主管資訊、收入和出息資訊等等,以供政府進行查詢,並確認申請的正確性。
  3. 提供必要文件:你需要將相關文件upload至網站,包括:
  • 身分證字樣或護照
  • 戶口登記單
  • 年度收入表單(含所屬機關、部門、職位和每月的收入)
  • 家庭主管身份證字樣
  1. 申請完成:完成上述步驟後,系統將會提供你一個登記號,使用此編號可以查詢你的申請狀態。
  2. 等待評估結果:在您填寫資料和上传文件之后,您需要等待政府的評估結果。

如果您有任何問題或需要幫助,您可以聯繫公共住宅資訊網的客服。

Q2:

台北市政府對於低收入戶補助有以下規定:

  1. 所屬家庭人數:單位中,含有小孩者,少於6名成員;含有5名以上成員者,少於8名成員。
  2. 收入標準:每人月收入不超過 NT$34,000。
  3. 申請人資格:申請人需是台北市住住的人。
  4. 申請時機:申請時間為每年6月1日至12月31日(包含)。
  5. 續付期限:續付期限為每年2月1日至7月31日(含)。

Q3:

根據台北市政府對於低收入戶補助的規定:

  • 每人月收入不超過 NT$34,000
  • 申請人需是台北市住住的人
  • 申請時機為每年6月1日至12月31日(包含)

您所租用房間的月收13,455元,符合每人月收入上限標準,且您在台北市住家。

因此,您可以申請台北市政府低收入戶補助。

Gemini 1.5 Flash (Google)

Q1:

您好!要申請低收入戶補助,需要先了解您的狀況,才能告訴您如何申請。

請您先告訴我:

  1. 您是哪個縣市或鄉鎮的居民? 因為各縣市政府的申請方式和條件可能略有不同。
  2. 您和您的家庭成員有哪些人? 包含年齡、職業、收入狀況等等。
  3. 您目前的收入和財產狀況如何?

有了這些資訊,我才能幫您更準確地解答如何申請低收入戶補助。

另外,建議您直接到戶籍所在地的 社會局 或 鄉鎮區公所 詢問,他們會提供最完整的資訊和協助。

加油!祝您順利申請到補助!

Q2:

好的,以下整理了台北市的低收入戶資格資訊:

台北市低收入戶資格

1. 戶籍: 必須設籍於台北市。

2. 家庭成員: 包含您本人和所有共同生活且有扶養關係的家人。

3. 收入:

  • 每人每月收入需低於 新台幣 15,000 元
  • 計算收入時,會考慮家庭成員的 工作收入、投資收益、房租收入、退休金、補助款 等。

4. 財產:

  • 家庭總財產價值需低於 新台幣 100 萬元
  • 財產計算包含 房屋、土地、存款、股票、債券、汽車、機車 等。

5. 其他條件:

  • 若家庭成員中有身心障礙者,或有特殊情況,可能會依個案狀況調整資格標準。

如何申請:

  1. 您可以到戶籍所在地的 台北市社會局 或 區公所 索取申請表格。
  2. 填妥申請表格,並附上相關證明文件,例如 戶口名簿、收入證明、財產證明、身心障礙證明 等。
  3. 將申請資料送交社會局或區公所受理。

注意事項:

  • 申請低收入戶資格需要經過審查,審查時間大約需要 1 個月
  • 若審查結果未符合資格,可以提出申覆。

建議:

  • 為了更清楚了解自己的情況是否符合資格,建議您直接到社會局或區公所諮詢,他們會提供更詳細的資訊和協助。

希望以上資訊對您有所幫助!

Q3:

根據您提供的資訊,您在台北市居住,月收入 13,455 元,若您是單身,且沒有其他財產,您可能符合台北市低收入戶資格的條件。

但請注意,以下幾點需要確認:

  1. 家庭成員: 您是單身嗎?還是有其他家人一起居住? 如果有家人,他們的收入和財產狀況也要納入考量。
  2. 財產: 除了租屋以外,您還有其他財產嗎?例如存款、股票、債券、汽車、機車等等。
  3. 其他收入: 除了工作收入,您還有其他收入嗎?例如房租收入、補助款等等。

建議您直接到戶籍所在地的 台北市社會局 或 區公所 詢問,他們會提供更詳細的資訊和協助,幫您確認是否符合資格。

您可以攜帶您的 身分證、戶口名簿、收入證明 等相關文件,到社會局或區公所諮詢。

祝您順利申請到補助!

gpt4o-mini

Q1:

要申請低收入戶補助,您需要按照以下步驟進行:

  1. 確認資格:首先,您需要確認自己是否符合低收入戶的條件。在台灣,低收入戶的標準是根據家庭的收入及財產狀況來判定的。
  2. 準備文件:您需要準備一些必要的文件,包括但不限於:
  • 身分證明文件(如身分證或戶口名簿)
  • 收入證明(如薪資單、稅單或社會福利補助的證明)
  • 財產證明(如銀行存款證明或不動產證明)
  1. 填寫申請表:前往當地的社會局或民政局,索取並填寫低收入戶的申請表格。
  2. 提交申請:將填妥的申請表及相關文件提交至您所屬的社會局或民政局。
  3. 等待審核:申請後,相關單位會進行審核,通常會在一段時間內通知您結果。

如果您有任何疑問或需要協助,建議您可以直接聯繫當地的社會局,他們會提供您更詳細的資訊和幫助。希望這些資訊對您有所幫助!

Q2:

在臺北市,低收入戶的資格主要是根據家庭的收入和財產狀況來判定的。以下是一些基本的條件:

  1. 收入標準:低收入戶的年收入必須低於台北市所定的低收入戶標準。這個標準會根據家庭人數有所不同,通常每年會調整一次,您可以查詢當前的標準。
  2. 財產限制:家庭的總財產(如存款、不動產等)也不能超過一定的限額。這個限額同樣會根據家庭人數有所不同。
  3. 家庭成員:申請時需要提供家庭成員的相關資料,包括配偶、子女等,這會影響您的收入和財產計算。

建議您可以前往臺北市政府社會局的官方網站,查詢最新的低收入戶資格標準和相關資訊,或直接聯繫當地社會局以獲得更詳細的說明。希望這些資訊對您有幫助!

Q3:

根據您提供的資訊,您的月收入為13,455元。要判斷您是否可以申請低收入戶補助,還需要考慮以下幾點:

  1. 年收入計算:您的年收入約為161,460元(13,455元 x 12個月)。您需要確認這個收入是否低於臺北市所定的低收入戶年收入標準。
  2. 家庭成員:如果您有其他家庭成員(如配偶或子女),那麼他們的收入也需要合併計算,這可能會影響您的低收入戶資格。
  3. 財產狀況:除了收入,您的財產狀況也會影響申請資格,需確認總財產是否在低收入戶的限制範圍內。

建議您可以查詢臺北市政府社會局的網站,了解目前的低收入戶收入標準和財產限制,或直接聯絡社會局詢問,這樣可以獲得更準確的資訊和指導。希望這些資訊對您有幫助!

Mistral (Mistral AI)

Q1:

您好!您要如何申請低收入戶補助?請先準備以下文件:身份證字號、戶籍證明文件、家庭成員名單(每個成員的身分證字號)、近六個月的工資說明書或其他收入來源证明,以及金融銀行發卡的帳戶報表。接下來,您可以到網上申請平台上填寫申請表格,或到鄉鎮市政府的社會福利辦公室提出申請。如果您需要任何其他說明,請聯繫我們即時回答。

Q2:

您好!台北市的低收入資格是根據家庭每月實際消費經銷額的標準,分為三級:第一級是每月實際消費經銷額不超過10,800元(家庭成員數量上限5人)、第二級是每月實際消費經銷額為10,800元至27,000元之間(家庭成員數量上限5人)、第三級是每月實際消費經銷額超過27,000元的家庭。如果您想要申請台北市低收入補助,請準備以下文件:身份證字號、戶籍證明文件、家庭成員名單(每個成員的身分證字號)、近六個月的工資說明書或其他收入來源证明,以及金融銀行發卡的帳戶報表。接下來,您可以到網上申請平台上填寫申請表格,或到鄉鎮市政府的社會福利辦公室提出申請。如果您需要任何其他說明,請聯繫我們即時回答。

q3:

您好!根據台北市低收入補助的資格,每月實際消費經銷額上限為10,800元(家庭成員數量上限5人)。您每月僅支付13,455元,不符合低收入補助的資格。但是,請不要灰心!如果您需要任何其他社會福利資源,請聯繫我們即時回答或到鄉鎮市政府的社會福利辦公室提出申請。

發佈日期:

了解LLM的函數調用function calling

什麼是Function calling

官方介紹文檔:https://platform.openai.com/docs/actions/introduction

中文介紹文檔:https://openai.xiniushu.com/docs/plugins/getting-started

Function calling是一種技術,允許LLM根據對話內容自主選擇並調用預定義的函數。這些函數可以用來執行各種任務,例如查詢實時數據、執行計算、生成圖像等。函數調用是建立 LLM 驅動的聊天機器人或代理(agents)的重要能力,這些聊天機器人或代理需要檢索 LLM 的上下文或通過將自然語言轉換為 API 調用來與外部工具互動。

功能調用使開發者能夠創建:

  1. 用戶提示:用戶輸入一個查詢或命令,LLM識別出需要調用特定函數。
  2. 函數觸發:LLM解析輸入內容,並確定需要調用的函數。
  3. 函數執行:LLM生成包含函數名稱和參數的JSON對象,並調用相應的函數。
  4. 響應交付:函數執行後返回結果,LLM處理該結果並以可理解的格式交付給用戶

Function Calling可以做到那些事情

  1. 有效的使用外部工具來回答問題
    例如:查詢「伯利茲的天氣怎麼樣?」將被轉換為類似 get_current_weather(location: string, unit: 'celsius' | 'fahrenheit') 的函數調用。
  2. 用來提取和標記數據
    例如:從維基百科文章中提取人名
  3. 將自然語言轉換為API調用或者做有效的資料庫查詢的應用程式
  4. 對話式的知識檢索並與知識庫互動

如何實現function calling

假如我們現在想要詢問某個地點的天氣,一般的LLM無法做到這件事情,因為訓練的數據集不會包括現在的即時數據。解決這個問題的方法是將LLM與外部工具結合。利用模型的Function Calling能力來確定要調用的外部函數及其參數,然後讓它返回最終的回應。

假設一位用戶向模型提出以下問題:

台北市今天的天氣如何

要實現function calling,需要在LLM的接口中註冊函數,並將這些函數的描述和使用說明一同發送給模型。模型會根據上下文智能地選擇並調用適當的函數。以下是一個簡單的實現示例:

這個範例會使用一個公共API:Weather.gov,要獲取預報,有兩個步驟:

  1. 用戶向 api.weather.gov/points API 提供緯度和經度,並收到 WFO(天氣預報辦公室)、grid-X 和 grid-Y 坐標。
  2. 這三個元素會輸入到 api.weather.gov/forecast API,以獲取該坐標的天氣預報。

首先,ChatGPT 會使用頂部的 info(特別是描述)來判斷此操作是否與用戶查詢相關。接著定義API的接口和每個接口的功能。

然後,下面的 參數 進一步定義了架構的每個部分。例如,我們正在告訴 ChatGPT,辦公室 參數指的是天氣預報辦公室 (WFO)。

openapi: 3.1.0
info:
  title: NWS Weather API
  description: Access to weather data including forecasts, alerts, and observations.
  version: 1.0.0
servers:
  - url: https://api.weather.gov
    description: Main API Server
paths:
  /points/{latitude},{longitude}:
    get:
      operationId: getPointData
      summary: Get forecast grid endpoints for a specific location
      parameters:
        - name: latitude
          in: path
          required: true
          schema:
            type: number
            format: float
          description: Latitude of the point
        - name: longitude
          in: path
          required: true
          schema:
            type: number
            format: float
          description: Longitude of the point
      responses:
        '200':
          description: Successfully retrieved grid endpoints
          content:
            application/json:
              schema:
                type: object
                properties:
                  properties:
                    type: object
                    properties:
                      forecast:
                        type: string
                        format: uri
                      forecastHourly:
                        type: string
                        format: uri
                      forecastGridData:
                        type: string
                        format: uri

  /gridpoints/{office}/{gridX},{gridY}/forecast:
    get:
      operationId: getGridpointForecast
      summary: Get forecast for a given grid point
      parameters:
        - name: office
          in: path
          required: true
          schema:
            type: string
          description: Weather Forecast Office ID
        - name: gridX
          in: path
          required: true
          schema:
            type: integer
          description: X coordinate of the grid
        - name: gridY
          in: path
          required: true
          schema:
            type: integer
          description: Y coordinate of the grid
      responses:
        '200':
          description: Successfully retrieved gridpoint forecast
          content:
            application/json:
              schema:
                type: object
                properties:
                  properties:
                    type: object
                    properties:
                      periods:
                        type: array
                        items:
                          type: object
                          properties:
                            number:
                              type: integer
                            name:
                              type: string
                            startTime:
                              type: string
                              format: date-time
                            endTime:
                              type: string
                              format: date-time
                            temperature:
                              type: integer
                            temperatureUnit:
                              type: string
                            windSpeed:
                              type: string
                            windDirection:
                              type: string
                            icon:
                              type: string
                              format: uri
                            shortForecast:
                              type: string
                            detailedForecast:
                              type: string

OpenAI很貼心的為我們提供了一個邦我們撰寫此Yaml的機器人

https://chatgpt.com/g/g-TYEliDU6A-actionsgpt

使用方法如下:

在測試API的時候,可以使用Postman來測試上面的OpenAPI架構。Postman 註冊是免費的,錯誤處理詳盡,並且在身份驗證選項上非常全面。它甚至還提供直接導入 Open API 架構的選項(見下文)。

如果要進行身分驗證,可參考以下文章

https://platform.openai.com/docs/actions/authentication

發佈日期:

在本機執行Breeze-7B-Instruct-v1_0

甚麼是Breeze-7B-Instruct-v1_0

huggingface頁面:https://huggingface.co/MediaTek-Research/Breeze-7B-Instruct-v1_0

線上DEMO: https://huggingface.co/spaces/MediaTek-Research/Demo-MR-Breeze-7B

聯發科的Breeze系列有好幾種不同的模型,在使用的時候要注意其微調順序

首先就是Breeze-7B-Base 是 Breeze-7B 系列的基礎模型。而Breeze-7B-Instruct 源自基礎模型 Breeze-7B-Base,使得最終模型可以直接用於常見任務。

Ollama library上的breeze模型總是使用簡體中文回答

我有嘗試使用Ollama在Library上面尋找別人訓練好的Library,但不太確定為什麼總是回答簡體中文,而無法好好使用繁體中文回應

https://ollama.com/search?q=breeze

我有嘗試過markliou/breeze-7bycchen/breeze-7b-instruct-v1_0jcai/breeze-7b-32k-instruct-v1_0

其中markliou/breeze-7b是回繁體中文沒錯但總是沒在理我問什麼,而剩的都用簡體中文

後來發現是問的問題的關係,以jcai/breeze-7b-instruct-v1_0為例,如果問的問題是台灣專屬的,那麼就會以繁體中文回覆,畢竟原本是以Mistral-7B-v0.1為基礎,如果後面的微調沒有微調到的資料,就仍會有簡體中文的出現,如果詢問台北有哪些地方好玩,則會都使用繁體中文

自己將Hugging Face上的檔案匯入Ollama

所以我嘗試使用下面的Makefile,並將https://huggingface.co/MediaTek-Research/Breeze-7B-Base-v1_0的檔案放置至同資料夾內

FROM mistral:v0.1
ADAPTER ./

然後用

ollama create my-breeze

中間有出了一些錯誤

panic: runtime error: index out of range [1] with length 1

這代表你的.safetensors 檔案的格式或內容不符合 ollama 轉換的要求。請檢查你所使用的 .safetensors 檔案是否與基礎模型匹配。例如我就是因為原本是使用Breeze-7B-Instruct,而基礎模型卻直接使用mistral:v0.1

Breeze-7B-Base-v1_0微調自:mistralai/Mistral-7B-v0.1

Breeze-7B-Instruct-v1_0 微調自:MediaTek-Research/Breeze-7B-Base-v1_0

所以我daapter用Breeze-7B-Instruct-v1_0,基礎模型卻使用mistral:v0.1,就會不行

後來有嘗試用正確的方式,仍然無法,原因是GPU不夠力

2024/10/03 01:22:18 routes.go:1153: INFO server config env=”map[CUDA_VISIBLE_DEVICES: GPU_DEVICE_ORDINAL: HIP_VISIBLE_DEVICES: HSA_OVERRIDE_GFX_VERSION: HTTPS_PROXY: HTTP_PROXY: NO_PROXY: OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_GPU_OVERHEAD:0 OLLAMA_HOST:http://0.0.0.0:11434 OLLAMA_INTEL_GPU:false OLLAMA_KEEP_ALIVE:5m0s OLLAMA_LLM_LIBRARY: OLLAMA_LOAD_TIMEOUT:5m0s OLLAMA_MAX_LOADED_MODELS:0 OLLAMA_MAX_QUEUE:512 OLLAMA_MODELS:D:\ollama\models OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:0 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:* app://* file://* tauri://*] OLLAMA_SCHED_SPREAD:false OLLAMA_TMPDIR: ROCR_VISIBLE_DEVICES:]”
time=2024-10-03T01:22:18.347+08:00 level=INFO source=images.go:753 msg=”total blobs: 50″
time=2024-10-03T01:22:19.031+08:00 level=INFO source=images.go:760 msg=”total unused blobs removed: 1″
time=2024-10-03T01:22:19.034+08:00 level=INFO source=routes.go:1200 msg=”Listening on [::]:11434 (version 0.3.12)”
time=2024-10-03T01:22:19.035+08:00 level=INFO source=common.go:49 msg=”Dynamic LLM libraries” runners=”[cpu_avx cpu_avx2 cuda_v11 cuda_v12 rocm_v6.1 cpu]”
time=2024-10-03T01:22:19.035+08:00 level=INFO source=gpu.go:199 msg=”looking for compatible GPUs”
time=2024-10-03T01:22:19.247+08:00 level=INFO source=gpu.go:292 msg=”detected OS VRAM overhead” id=GPU-e7a02a5a-c5d7-954e-8c0c-1e61accd6933 library=cuda compute=8.6 driver=12.6 name=”NVIDIA GeForce RTX 3090″ overhead=”216.4 MiB”
time=2024-10-03T01:22:19.252+08:00 level=INFO source=types.go:107 msg=”inference compute” id=GPU-e7a02a5a-c5d7-954e-8c0c-1e61accd6933 library=cuda variant=v12 compute=8.6 driver=12.6 name=”NVIDIA GeForce RTX 3090″ total=”24.0 GiB” available=”22.8 GiB”
[GIN] 2024/10/03 – 01:22:40 | 200 | 0s | 127.0.0.1 | HEAD “/”
[GIN] 2024/10/03 – 01:23:35 | 201 | 23.5449467s | 127.0.0.1 | POST “/api/blobs/sha256:db70372fb06ef4ea5b51aca748a054c8cfadd0e966340da549100bcabca00513”
[GIN] 2024/10/03 – 01:23:35 | 200 | 12.2951ms | 127.0.0.1 | POST “/api/create”
[GIN] 2024/10/03 – 01:29:09 | 200 | 8.9953ms | 162.142.125.45 | GET “/”
[GIN] 2024/10/03 – 01:29:19 | 200 | 0s | 162.142.125.45 | GET “/”
[GIN] 2024/10/03 – 01:29:20 | 404 | 8.2049ms | 162.142.125.45 | GET “/favicon.ico”
[GIN] 2024/10/03 – 02:36:30 | 404 | 0s | 47.89.254.25 | GET “/v2/_catalog”
[GIN] 2024/10/03 – 02:36:55 | 200 | 0s | 123.160.223.72 | GET “/”
[GIN] 2024/10/03 – 02:36:55 | 404 | 0s | 123.160.223.74 | GET “/favicon.ico”
[GIN] 2024/10/03 – 05:38:15 | 200 | 0s | 172.168.40.190 | GET “/”
[GIN] 2024/10/03 – 09:13:49 | 200 | 0s | 127.0.0.1 | HEAD “/”
[GIN] 2024/10/03 – 09:13:49 | 200 | 4.2285ms | 127.0.0.1 | GET “/api/tags”
[GIN] 2024/10/03 – 09:15:16 | 200 | 0s | 127.0.0.1 | HEAD “/”
[GIN] 2024/10/03 – 09:15:45 | 200 | 531.8µs | 127.0.0.1 | POST “/api/blobs/sha256:db70372fb06ef4ea5b51aca748a054c8cfadd0e966340da549100bcabca00513”
[GIN] 2024/10/03 – 09:16:03 | 200 | 17.7737368s | 127.0.0.1 | POST “/api/create”
panic: runtime error: index out of range [1] with length 1

每次都會在那個超過100%的時機點壞掉,我想這也是為什麼Ollama上面的模型都有先經過量化(quantization)的原因

直接使用transformers呼叫推理

以下為程式碼

# Load model directly
from transformers import AutoTokenizer, AutoModelForCausalLM

tokenizer = AutoTokenizer.from_pretrained("MediaTek-Research/Breeze-7B-Instruct-v1_0")
model = AutoModelForCausalLM.from_pretrained("MediaTek-Research/Breeze-7B-Instruct-v1_0")
chat = [
  {"role": "user", "content": "你好,請問你可以完成什麼任務?"},
  {"role": "assistant", "content": "你好,我可以幫助您解決各種問題、提供資訊和協助您完成許多不同的任務。例如:回答技術問題、提供建議、翻譯文字、尋找資料或協助您安排行程等。請告訴我如何能幫助您。"},
  {"role": "user", "content": "太棒了!"},
]
tokenizer.apply_chat_template(chat, tokenize=False)
outputs = model.generate(tokenizer.apply_chat_template(chat, return_tensors="pt"),
                         # adjust below parameters if necessary 
                         max_new_tokens=128,
                         top_p=0.01,
                         top_k=85,
                         repetition_penalty=1.1,
                         temperature=0.01)
                         
print(tokenizer.decode(outputs[0]))

回覆則會是:【很高興能為您服務!如果有任何需要,歡迎隨時詢問。】

PS: 這種方式執行速度非常的慢

發佈日期:

在Ollama中載入自己建立的模型

參考資料

官方教學:https://github.com/ollama/ollama/blob/main/docs/import.md

網路教學:https://www.youtube.com/watch?v=fnvZJU5Fj3Q

基於已有的模型導入 Safetensors 權重

首先就是建立一個Modelfile.txt

例如假如我是用https://ollama.com/markliou/breeze-7b這個做為基礎模型,然後自己建立的LORA微調檔案在data資料夾底下,

則Modelfile.txt的內容如下:

FROM mistral:v0.1
ADAPTER ./data/

現在從創建 Modelfile 的目錄運行 ollama create,可以使用-f來指定Modelfile路徑,如果不指定就會在你cmd當前資料夾尋找:

ollama create my-breeze -f ./Modelfile.txt

可以使用參數 --quantize來運行不同的量化級別

$ ollama create --quantize q4_K_M my-breeze
transferring model data
quantizing F16 model to Q4_K_M
creating new layer sha256:735e246cc1abfd06e9cdcf95504d6789a6cd1ad7577108a70d9902fef503c1bd
creating new layer sha256:0853f0ad24e5865173bbf9ffcc7b0f5d56b66fd690ab1009867e45e7d2c4db0f
writing manifest
success

如果你是下載別人的LoRA,而別人的LoRA用的是.bin檔案,則可以使用transformers庫來做轉換,轉成.safetensors

from transformers import AutoModel, AutoTokenizer

# 載入模型和標記器
model = AutoModel.from_pretrained("./")
tokenizer = AutoTokenizer.from_pretrained("./")
# 儲存為 GGUF 格式
model.save_pretrained("./")  
tokenizer.save_pretrained("./") 

直接導入GGUF的模型

Ollama的From所導入的模型應為GGUF格式,可以透過像 llama.cpp 這樣的工具來將模型轉換為 ggml 或 gguf 格式。

安裝llama.cpp

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make

接著將下載的 .safetensors 模型放置於適當位置,然後開始轉換

# 假設模型放置於 models/Breeze-7B-FC-v1_0 目錄下
./llama.cpp -m models/Breeze-7B-FC-v1_0/model.safetensors -t models/Breeze-7B-FC-v1_0/tokenizer.json -w models/Breeze-7B-FC-v1_0/ggml-model-f16.bin --quant 4

注意!不同模型的結構和參數可能有所差異,並非所有模型都能順利轉換為 GGUF。這邊有失敗經驗

https://github.com/ollama/ollama/issues/5195

要導入 GGUF 模型,創建一個Modelfile,包含:

FROM /path/to/file.gguf

接著就可以創建了,CMD需指向你Modelfile.txt的位置

ollama create my-model -f ./Modelfile.txt
發佈日期:

專門為繁體中文優化過的開源模型

聯發科的Breeze-7B

模型介紹

HuggingFace網址: https://huggingface.co/MediaTek-Research/Breeze-7B-Instruct-v1_0

DEMO網址: https://huggingface.co/spaces/MediaTek-Research/Demo-MR-Breeze-7B

聯發科的Breeze-7B模型是一個專為繁體中文和英文雙語環境設計的大型語言模型。由聯發科研究團隊開發的一個開源大型語言模型,基於Mistral-7B進行改進和優化。該模型擁有70億個參數,專門針對繁體中文和英文的語言處理進行了優化。

Breeze-7B主要特點

  • 雙語支持:Breeze-7B能夠流暢地理解和生成繁體中文和英文的文本,適用於即時翻譯、商業溝通和智能客服對話等場景。
  • 高效能:該模型在繁體中文的推理速度上比市面上其他同級別模型快一倍,能夠在短時間內生成精準且連貫的回應。
  • 多功能應用:Breeze-7B不僅能夠進行文本生成,還能精確解讀和生成表格內容,適用於數據分析、財務報表和複雜的排程任務。
  • 開源:Breeze-7B採用Apache 2.0開源授權,允許學術界和業界自由使用和修改,促進AI技術的發展。

模型比較

模型名稱參數量開發者授權功能調用指令跟隨
Breeze-7B-Instruct-v1_07BMediaTek ResearchApache 2.0
Breeze-7B-FC-v1_07BMediaTek ResearchApache 2.0
功能調用意味著它可以調用外部功能或API

BLOOM-zh

官方頁面:https://huggingface.co/ckip-joint/bloom-1b1-zh

iKala優化版本:https://huggingface.co/ikala/bloom-zh-3b-chat

BLOOM-zh 是由聯發科(MediaTek)基於 BigScience 的 BLOOM 模型進行改進和優化的。BLOOM 模型是由全球多個研究機構和研究人員共同開發的多語言模型,BLOOM-zh 是其專為繁體中文設計的版本。

模型使用了大量繁體中文和英文數據進行訓練,涵蓋了新聞、小說、百科全書等多種文本來源。適用於多種繁體中文文本生成和理解任務,如對話生成、文本摘要、翻譯等

與Breeze的比較

  • BLOOM-zh 更適合需要多語言支持和通用文本處理的應用場景,特別是在跨語言文本生成和理解方面有優勢。
  • Breeze 則更適合繁體中文的專業應用,特別是在需要高效能和專業知識的領域,如醫療、法律和電子製造等。

TAME (TAiwan Mixture of Experts)

Project TAME(TAiwan Mixture of Experts)是一個專為繁體中文及台灣產業需求設計的大型語言模型。該模型由多家領先企業與台灣大學資工系合作開發,旨在提升台灣在地化的AI應用能力。

TAME模型特點

  • 參數量:Project TAME擁有700億參數,專為繁體中文設計,能夠精準理解和生成繁體中文文本。
  • 訓練數據:模型使用了來自多個產業的專業數據進行訓練,包括石化業、電子製造、醫療服務、法律等領域,涵蓋了近5000億個詞元(token)。
  • 在地化與產業化:Project TAME特別強調在地化和產業化,能夠理解台灣文化和語境,並針對台灣產業的特定需求進行優化。

TAIDE-LX-7B介紹

官方網站:https://huggingface.co/taide/TAIDE-LX-7B-Chat

TAIDE-LX-7B 是由台灣國家科學及技術委員會(國科會)開發的一款大型語言模型,專為繁體中文和台灣在地需求設計。基於 Meta 的 LLaMA2-7B 模型進行改進和優化。TAIDE-LX-7B 擁有 70 億參數,這使得它在計算資源需求和性能之間達到平衡。

TAIDE功能與應用

  • 自動摘要:TAIDE-LX-7B 能夠高效地對長篇文本進行自動摘要,提取關鍵信息36
  • 寫信與寫文章:該模型在撰寫電子郵件和文章方面表現出色,能夠生成結構良好且語法正確的文本36
  • 翻譯:TAIDE-LX-7B 支援中英互譯,能夠準確地將繁體中文翻譯成英文,反之亦然36
  • 對話生成:該模型在對話生成方面也有優異表現,適合用於聊天機器人和虛擬助手等應用