論文網址： https://arxiv.org/abs/2404.16130 Graph RAG 介紹 一種新的 Graph RAG 方法，透過建立基於圖形的文本索引，提升對全球性問題的回答品質。這種方法能夠有效地處理大規模文本語料庫，並且能夠擴展到用戶問題的普遍性和要索引的源文本數量。 Graph RAG 管道利用 LLM 衍生的文本圖索引進行資料處理。首先，該管道從來源文件中構建出實體知識圖，將文件中的實體與其關聯關係組織成網狀結構。接著，Graph RAG 使用 LLM 在索引建立階段進行群體預摘要，針對每個具有相似性的實體群體生成摘要，以便更快速地調用相關資訊。當查詢進來時，Graph RAG 可以在查詢時間使用這些預摘要來快速生成「全局答案」。這種方法不僅提升了答案的全面性和多樣性，還能有效降低生成回答時的 token 成本。 Graph RAG 系統的工作流程…

讓LLM記憶對話的幾種方式 參考資料: https://www.pinecone.io/learn/series/langchain/langchain-conversational-memory/ 這些模式是以LangChain的實作為範例，實現對話記憶可以使 LLM 能夠進行連貫的對話，這對於像聊天機器人這樣的應用來說非常重要。 對話記憶的不同形式，包括 每種記憶形式都有其獨特的應用場景，例如 ConversationBufferMemory 適合簡短對話，而 ConversationSummaryMemory 適合長對話，因為它通過總結歷史對話來節省令牌使用。此外，網頁還提到了其他類型的對話記憶，如 ConversationKnowledgeGraphMemory 和 ConversationEntityMemory。 雖然需要更多的調整來決定總結什麼以及在緩衝區窗口中保持什麼，但ConversationSummaryBufferMemory確實給了我們很多靈活性，也是我們的記憶類型中唯一一個（到目前為止）允許我們記住遙遠互動和以其原始——以及信息最豐富——的形式存儲最近的互動。 ConversationBufferWindowMemory的token使用比較圖 ConversationSummaryBufferMemory的token使用比較圖 進階的記憶模式 – 實體、圖形記憶 參考資料：https://www.comet.com/site/blog/advanced-memory-in-langchain/ ConversationEntityMemory(實體記憶) 實體記憶能夠幫助 AI…

什麼是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裡面寫的工具說明(英文)和參數說明，自動產生相對應的資料去呼叫函數，非常的聰明!但也因為這樣，工具說明和參數說明一定要認真寫，千萬不要亂寫，會影響到呼叫的成功率

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…

什麼是Function calling 官方介紹文檔：https://platform.openai.com/docs/actions/introduction 中文介紹文檔：https://openai.xiniushu.com/docs/plugins/getting-started Function calling是一種技術，允許LLM根據對話內容自主選擇並調用預定義的函數。這些函數可以用來執行各種任務，例如查詢實時數據、執行計算、生成圖像等。函數調用是建立 LLM 驅動的聊天機器人或代理(agents)的重要能力，這些聊天機器人或代理需要檢索 LLM 的上下文或通過將自然語言轉換為 API 調用來與外部工具互動。 功能調用使開發者能夠創建： Function Calling可以做到那些事情 如何實現function calling 假如我們現在想要詢問某個地點的天氣，一般的LLM無法做到這件事情，因為訓練的數據集不會包括現在的即時數據。解決這個問題的方法是將LLM與外部工具結合。利用模型的Function Calling能力來確定要調用的外部函數及其參數，然後讓它返回最終的回應。 假設一位用戶向模型提出以下問題： 台北市今天的天氣如何 要實現function calling，需要在LLM的接口中註冊函數，並將這些函數的描述和使用說明一同發送給模型。模型會根據上下文智能地選擇並調用適當的函數。以下是一個簡單的實現示例： 這個範例會使用一個公共API：Weather.gov，要獲取預報，有兩個步驟： 首先，ChatGPT…

甚麼是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-7b、ycchen/breeze-7b-instruct-v1_0、jcai/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的檔案放置至同資料夾內 然後用 中間有出了一些錯誤 panic: runtime error: index…

參考資料 官方教學：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的內容如下： 現在從創建 Modelfile 的目錄運行 ollama create，可以使用-f來指定Modelfile路徑，如果不指定就會在你cmd當前資料夾尋找： 可以使用參數 –quantize來運行不同的量化級別 如果你是下載別人的LoRA，而別人的LoRA用的是.bin檔案，則可以使用transformers庫來做轉換，轉成.safetensors 直接導入GGUF的模型 Ollama的From所導入的模型應為GGUF格式，可以透過像 llama.cpp 這樣的工具來將模型轉換為 ggml 或 gguf 格式。 安裝llama.cpp 接著將下載的 .safetensors 模型放置於適當位置，然後開始轉換…

聯發科的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-Instruct-v1_0 7B MediaTek Research Apache 2.0 ❌ ✅ Breeze-7B-FC-v1_0 7B…

官網介紹o1-preview 介紹 OpenAI o1-preview：https://openai.com/index/introducing-openai-o1-preview 首次瞭解：探索 GitHub Copilot 中的 OpenAI o1：https://github.blog/news-insights/product-news/openai-o1-in-github-copilot/ 在2024/9/12，OpenAI推出了o1-preview的模型，這個模型的最大特色就是具備有先進推理能力，可解決難題。測試顯示o1-preview在程式碼分析和優化方面效果良好。該模型能思考挑戰並能夠將複雜任務分解為步驟，這可以優化程式碼以解決性能問題，加速開發工作流程。 透過這樣的思考流程，ChatGPT可以完成更複雜的程式撰寫任務，過去，我們仍會需要透過人的思考將任務拆細後一步一步請ChatGPT幫忙完成，再由工程師將任務功能組合起來，而現在o1-preview則自己就能夠具備有將複雜任務拆細的能力。 從下圖可看見，ChatGPT的程式撰寫能力瞬間從11分進步到89分(圖片來源: https://openai.com/index/learning-to-reason-with-llms/) o1-preview 模型的新功能總覽 隨著 o1-preview 模型的推出，這個模型在性能、功能和未來更新方向上展現了許多新亮點。 o1-preview 模型功能實測 先說結論，真的非常的強，不論是產生程式、理解程式、修改程式，都和過去是完全不同等級的狀況！非常的厲害。 這是我今天使用o1-preview 來製作一個HTML的俄羅斯方塊的對話紀錄，可以看到ChatGPT完美的完成任務，真的是沒有BUG的完整的遊戲，而且修改的動作也都非常的完美，真的可以靠指令達到我的許多要求。我覺得這樣的程度的模型是真的會影響到許多工程師的未來性。 對話紀錄在此：https://chatgpt.com/share/66e6bcf1-4254-8005-a573-a250e1b51702…