(From PlantUML) 總結 我一直以來都是一個喜歡東看西看的人（聽說很多人跟我一樣），但是一直以來資訊流的整理一直是我很痛苦的事情。接下來可能會有一系列的文章記錄著我邊打造個人 LLM KM 系統的時候的一些記錄跟想法。 資訊流 原本資訊流還蠻簡單的，就是希望所有的資訊可以透過 twitter 去當 gateway 然後開始轉到其他地方。 這裡有點麻煩得時候，自從 Twitter 再也不接受免費 API 的申請後（最便宜 100$USD) 。 只好去購買 IFTTT 的服務幫我把資訊從 Twitter 打到 Webhook 。 這邊我以前有類似的文章: [TIL] 為了自己的習慣，弄了一個簡單的服務 Github issue bookmark 看到五年前開始打造的時候才 10 ~ 20 github issue ，現在卻有 1.3k 的數字。開始思考要如何整理相關資訊。 更多參考：

課程簡介 Deep Learning AI 新的課程，如何優化 IR/RAG on Chroma 。 講師是 Chroma co-founder 有以下三個技術： Query Expansion: 透過相關概念來擴展查詢。 Cross-encoder reranking: 透過不同檢索編碼來排序查詢結果。 Training and utilizing Embedding Adapters: 透過加入 adapter 來優化檢索結果。 課程資訊： https://learn.deeplearning.ai/advanced-retrieval-for-ai/ RAG Pitfall 經常查詢 RAG 結果回來會是不相關的，怎麼看出來？ 透過一個 umap 套件 import umap import numpy as np from tqdm import tqdm embeddings = chroma_collection.get(include=['embeddings'])['embeddings'] umap_transform = umap.UMAP(random_state=0, transform_seed=0).fit(embeddings) # 畫點出來 import matplotlib.pyplot as plt plt.figure() plt.scatter(projected_dataset_embeddings[:, 0], projected_dataset_embeddings[:, 1], s=10) plt.gca().set_aspect('equal', 'datalim') plt.title('Projected Embeddings') plt.axis('off') 比較相近的問題（單一問題，比較容易) 這樣看起來查詢的資訊跟我們問得蠻相近的，紅色是回答的。綠色是前面幾個相關的。 如果問句有兩個以上，或是問句本身就不太相關。 這樣就會出現差相當多的結果，造成查詢的資料相關度過少。出來的結果當然也就很差。 解決方式就要靠接下來的三個方法。 Query Expansion 透過延伸的假設答案，加上原來的問題。一起下去詢問: def augment_query_generated(query, model="gpt-3.5-turbo"): messages = [ { "role": "system", "content": "You are a helpful expert financial research assistant. Provide an example answer to the given question, that might be found in a document like an annual report. " }, {"role": "user", "content": query} ] response = openai_client.chat.completions.create( model=model, messages=messages, ) content = response.choices[0].message.content return content e.g. Q: Was there significant turnover in the executive team? 先用這個 Q 直接問 OpenAI 得到可能的解答 hypothetical_answer，但是因為沒有查詢特有...

前情提要： 2023 年 LINE Bot SDK 積極推動 OpenAPI (a.k.a. swagger) 的標準介面。透過與 OpenAPI 的整合， LINE Bot SDK 有了許多好處（文章後半段補充）。本篇文章將稍微解釋一下，OpenAPI 導入後的優點，並且帶著大家一起來將有使用 LINE Bot Go SDK v7 版本的升級到 v8 的版本。 本次的程式碼，會用前幾篇文章提到的: https://github.com/kkdai/linebot-gemini-pro 作為範例。 支援 OpenAPI 的好處 LINE Bot Go SDK 近期也在 2023/11 月也將版號更新到了 v8，並且正式支援 OpenAPI。 那麼簡單的來說，一個 SDK 套件支援 OpenAPI 有哪些好處呢？ 1. 標準化的 API 設計 許多 API 呼叫的方式，變得更加的直觀。也比較容易了解。後面也會稍微提到。 2. 程式碼自動生成 以往要開發新的 API Entry 的時候，都要透過發送 issue -> 發送 PR -> 審核 -> 發布後才能發送到開發者手中。 但是導入後， LINE Bot SDK 使用的方式，是透過 Github Action 來自動去將最新的 LINE OPENAPI Repo抓下來後，根據新的變動產生相關的對應程式碼。 (參考上圖)（參考 Code Generator 產生的commit) 更多好處： 自動化文件生成:有許多相關文件可以幫忙自動化產生 OpenAPI 的文件。 客戶端與服務端驗證:透過 OpenAPI 的導入可以達成自動化測試與 Consumer-Driven Contract 的驗證。 API 生態系統工具的整合等等 開始 Migrate LINE Bot Go SDK from v7 to v8 先修改套件版本 v7 -> v8 先加入以下三個套件，接下來會解釋一下： "github.com/line/line-bot-sdk-go/v8/linebot" "github.com/line/line-bot-sdk-go/v8/linebot/messaging_api" "github.com/line/line-bot-sdk-go/v8/linebot/webhook" linebot: 主要處理 v7 相關的內容，儘量不要使用。會逐步 deprecated 。 messaging_api : 發送訊息用。 webhook: 接受訊息與處理相關 event 用的。 接下來將慢慢整合，並且開始說明相關套件使用到的部分。 開始整合，並且說明相關變動之處： “github.com/line/line-bot-sdk-go/v8/linebot/webhook” 負責接受 Webhook 相關資料，裡面包括兩大系列： MessageEvent 要處理相關訊息 Webhook 包括: TextMessageContent: 文字訊息。 StickerMessageContent: 貼圖訊息 .. ImageMessageContent: 圖片訊息，由使用者上傳的相片或是圖片訊息。 其他相關 Event 處理，包括： FollowEvent: 有新的好友。 PostbackEvent: 這個比較常用，就是透過 postback...

前情提要： 有在持續關注我的部落格的朋友，都知道我喜歡透過 Heroku 來快速部署我自己的雲服務 (或是 LINE Bot)。 當初 Heroku 就打著好上手，並且有免費方案的流程來讓許多開發者都有使用到。但是在 2022 十一月之後，就開始收費的 Heroku 也開啟許多人跑走的路途。這邊可以查看以下相關資料： 關於從 Heroku 跳到 Render 這件事情 五個替代 Heroku 的平台免費測試執行 .Net Core 的文字辨識 OCR 網頁程式 從 Heroku 遷移至 Fly.io 由於我手上的 Hobby Project 大概有 50~80 個，所以也就選擇先留在 Heroku 看看？ (要搬移真的太累) 每個月五美金的費用，也算是中規中矩，畢竟也是某些程度吃到飽（1000 dyno hours) ，也足夠我用。 但是又聽到朋友們的提醒與鞭策，於是來認真看一下跟測試結果。 tl;dr 先講結論 Heroku ($5) 雖然沒有免費，但是共用的 Eco Dyno 其實後夠力。 Render ($7) 每一個要單獨收，有點貴。 我會開始放一些到 Render $0 的方案，原因後提。 兩個都部署跟發布，但是我還是會留在 Heroku ($5) (因為它是共用 1000 hours) 價位比較 (based: 2024/01/02) Render 的價格跟性能: (free/Starter) 根據 Render vs Heroku by Render 有一些比較表： 認真看了一下 Render 的費用 看起來 Free-tier 就有 512MB RAM，很不錯（但是要注意 CPU 0.15) 但是要注意 Free Bandwidth 是 100GB ，這個感覺會踩到。 更別說有免費 90 天的 PostgresSQL 資料庫 Redis 有 25MB 也夠用，但是會砍掉。 Heroku 的費用與效能部分 沒有 Free-tier 最低收費 Eco $5 根據 Heroku Dyno Types: 效能其實不比 $7 差太多（當然遠遠多於 Render Free-Tier) 快速測試結果 拿了專案 https://github.com/kkdai/linebot-gemini-prohttps://github.com/kkdai/linebot-gemini-pro 來測試，發現： 回覆速度上 Heroku ($5) 跟 Render ($0) 不會差太多。 (Golang App) 但是上傳照片後，要處理 Render ($0) 就會炸掉。 由於記憶體兩者都是 512MB ，考量可能問題出在 CPU 上面。 交叉測試： 加上我另外一個小專案： https://github.com/kkdai/pdf_online_editor?tab=readme-ov-file 測試結果 Render ($0) 一樣會炸掉。 測試檔案...

前提 前幾篇的文章 [Golang] 透過 Google Gemini Pro 來打造一個基本功能 LLM LINE Bot 曾經提過，如何整合基本的 Gemini Pro Chat 與 Gemini Pro Vision 兩個模型的使用。 本次將快速提一下，打造一個具有記憶體的 LINE Bot 該如何做。 相關開源程式碼： https://github.com/kkdai/linebot-gemini-pro 系列文章： 使用 Golang 透過 Google Gemini Pro 來打造一個具有LLM 功能 LINE Bot (一）: Chat Completion and Image Vision 使用 Golang 透過 Google Gemini Pro 來打造一個具有LLM 功能 LINE Bot (二）: 使用 Chat Session 與 LINEBot 快速整合出有記憶的 LINE Bot(本篇) 使用 Golang 透過 Google Gemini Pro 來打造一個具有LLM 功能 LINE Bot (三）: 使用 Gemini-Pro-Vision 來打造名片管理的聊天機器人 什麼叫做有記憶的聊天機器人 原本在 OpenAI Completion API 是採取一問一答的方式，也就是你問一次，他回答。 下一次詢問的時候，就會完全的忘記。這邊提供網頁上的說明程式碼： from openai import OpenAI client = OpenAI() response = client.completions.create( model="gpt-3.5-turbo-instruct", prompt="Write a tagline for an ice cream shop." ) 在之前，如果需要有記憶的功能，就需要把之前的問與答都附在問句的前面。到了之後， OpenAI 推出了 ChatCompletion 的功能，相關的程式碼如下： from openai import OpenAI client = OpenAI() response = client.chat.completions.create( model="gpt-3.5-turbo", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Who won the world series in 2020?"}, {"role": "assistant", "content": "The Los Angeles Dodgers won the World Series in...

講者資訊 UC Berkeley 的 Wei-Lin Chiang (Winston Chiang) 於 12/29(五) 來陽明交大演講, 主題是有關 Large Language Model (LLM), 尤其是將會提及他們在 UC Berkeley 開發的一個十分知名 LLM – Vicuna. 該LLM今年推出後即已有+500 citations, 超過百萬次下載, 江韋霖是主要作者之一. 歡迎有興趣的老師同學踴躍參與. 時間：112.12.29(五) 10:30-12:00 地點: 陽明交大工程三館 114室 演講者： Wei-Lin Chiang, 江韋霖 (University of California, Berkeley) 演講題目： Open-Source AI Projects at UC Berkeley & LMSys: Vicuna and Chatbot Arena 演講內容 Why Vicuna ? GPT-3 只使用 “Few-Shot” 開始產生其他語言結果。 LLM 成果遠遠比 NLP 的成效更好，開始大量投入相關的開發。 一開始 GPT3 只能 complete ，無法達到 Q&A 。 透過 “Instruct-GPT” 讓只會 Complete 的 GPT3 開始能做 Q7A Stanford 做了 Alpaca ，於是 UC Berkeyley 也想做。 七萬筆數據。 2023 三月 release https://lmsys.org/blog/2023-03-30-vicuna/ 資料 -> 質量提高 -> 發現產出的結果也會提高。 價錢便宜一半，資料量級跟 Stanford 差不多。 Vicuna - Demo site https://chat.lmsys.org/ Data 經過清洗 Blog 的影響： 500 引用 3M 訪問 看圖的 model 也做了。 Vicuna - Limitation 數學, coding 有限制，回答不好。 後來多拿相關資料去優化。 接下來面對問題： 成功來自於「高質量」的數據 (data) 支出不便宜，但是資料搜集不易。 沒有好的 Evaluation 機制。 Benchmark 可能已經被 LLM 看過了。 Chat Area 開放的 ChatGPT (免費) 有許多 model (開源) 學校希望有更多回饋，與相關 RLHF 的資料。 放上所有開源 models 讓使用者評分相關問題，誰回答比較好。 作為資料的搜集。...