文章

顯示從 6月, 2025 起發佈的文章

[筆記] RAG 檢索增強生成的技術概念

圖片
Q :為何需要 RAG 資料檢索? A :光靠 LLM 大語言模型無法準確回答問題,反而出現一本正經地胡說八道,專業術語稱為 LLM 的幻覺 (Hallucination) 。為了解決這問題,有兩種方法:第一種是對 LLM 的預訓練模型進行微調訓練,第二種是加入 RAG 做資料檢索和 LLM 的語句生成。前者需要花費硬體設備進行訓練,後者採用 LLM+RAG 架構可大幅節省成本,市面上比較接受後者方案。其系統架構如下: Q : RAG 的開發與架構? A :初期 RAG 開發階段,需要對資料進行多模態的處理,比如對 PDF 檔案擷取文字、表格、圖片 … 等多種模態,過程包含資料清洗,剔除一些符號、重複語句、無意義文字 … 等。然後,對清洗後的資料進行分塊和向量化,最後寫入向量資料庫。這裡的分塊和向量化會使用到現有的演算法來實現,向量資料庫也有現有的架構可使用。 前面是前期 RAG 的資料處理階段,後期是指 RAG 運行階段,需要對接到 LLM 模型,如下圖。 Q :如何資料擷取與清洗? A :客戶提供技術文件,可能是 TXT 或 PDF 檔案。首先,將檔案的文字擷取下來存放成自訂格式 (JSON) ,對於 PDF 檔案而言,內容包含文字、表格、圖片都必須分別寫 python 程式處理。即使把文字從檔案取出,在這一大堆文字裡面包含換行符號,語句切割不連續,無意義的詞或標題數字 … 等問題,這些問題需要靠程式來做清洗後才能進到下階段。 Q :如何向量化? A :資料清洗後,資料要進行切塊 (chunk) ,再將其向量化,這過程稱為 embedding 。有人研究中文 embedding 的檢索能力,參考 https://ihower.tw/blog/archives/12167 ,需要導入有支援多語言的 embedding model 效果最好。 切塊採用 Jieba 分詞的算法,文本會切成小的詞彙,以便之後檢索。這些詞彙換算成向量,而典型檢索的演算法為 BM25 ,優點為方法簡單效果不錯,因此使用廣泛,缺點是單純根據詞頻等統計和關鍵字檢索做判斷,無法理解語意。而 Word2Vec 使用高維向量來表示單詞,能分辨細微語意之差別。 向量化的數據要存放在向量資料庫,基礎型的有 ChromaDB 、 MilvusDB… 等可本地部署。

[筆記] 製作一個 STM32H750 的外部 Flash 燒錄器

圖片
        STM32H750這顆晶片是 Cortex-M7 核心,內部時脈 480MHz,在同級的 STM32 系列中屬於高效能晶片。不過,它有個問題就是內部 Flash 容量太小,只有 128MB 而已,為了解決這問題,通常外部會掛一顆 Flash 晶片。此時,我們需要自製一個燒錄程式,如下圖所示,紅線標示的 On-chip Flash 是官方提供的燒錄程式,而另一紅線標示的 Ext Flash SPI 就是我們要提供給 Keil IDE 的燒錄程式。         如何自製一套燒錄程式給 Keil IDE 使用呢?放心,IDE 有提供一個範例項目,放在 \Keil_v5\ARM\Flash\_Template 目錄底下,我們工作就是將 FlashDev.c 和 FlashPrg.c 兩個檔案的函數給實現了即可。在 FlashDev.c,我們填入外掛 Flash 的屬性,比如容量大小﹑STM32 存取的位址﹑Sector size, Sector Addr...等,如下。         在 FlashPrg.c,我們必須實現底下幾個函式的驅動。由於外掛 Flash 晶片型號為 W25Q256,也就是寫一套驅動這顆晶片的程式碼。不必擔心!這部分可以從網路的開源找到相關的驅動程式碼 ( https://pan.baidu.com/s/1LuH_zhXgZMqHJcKoLcepdQ   提取码:kmbf )。         筆者下載後,還是會遇上驅動的問題,必須再進行 debug 後才能使用。這裡有一點要注意的,W25Q256 預設的 SPI 通訊指令是 3-byte Address Mode,但是整個驅動程式都採用 4-byte 模式,於是在初始化過程要先設定為 4-byte Addr Mode 才能成功使驅動程式執行,如下圖。         最後,將這個 Flash 項目編譯後,產生的 .axf  複製成 .FLM 檔案,再把這檔案放到  \Keil_v5\ARM\Flash 目錄底下,這樣就完成自製外部燒錄器的功...