跳到主要內容

發表文章

Nuxt vs Vue 技術選型與渲染模式比較

Nuxt vs Vue 技術選型與渲染模式比較 為 Dashboard 管理介面選擇最適合您的開發與部署模式 ⚖️ Vue + Element UI vs. Vue + Nuxt 面向 Vue + Element UI Vue + Nuxt UI 整合 內建套件,快速上手 須選擇 UI 套件,如 Element Plus、Naive UI、Tailwind 開發體驗 需手動整合 router、store、i18n 自動化,結構規範清楚 (auto-import, DevTools) ...
最近的文章

RAG整理

RAG(檢索增強生成)課程重點整理 RAG,全名為檢索增強生成(Retrieval-Augmented Generation),有時也稱作檢索增強語言模型(Retrieval-Augmented Language Model, RALM)。它是一種旨在透過允許語言模型從外部來源檢索資訊來增強其能力的技術。 一、 RAG 的基本框架與必要性 1. RAG 是什麼? RAG 是一種提升語言模型(LM)能力的方法,使其能「查閱」外部知識庫,而非僅依賴訓練時所學的靜態資訊。 2. RAG 為何必要?語言模型的局限性: 長尾知識與幻覺 (Hallucination) :語言模型難以準確回憶訓練資料中不常出現的「長尾」資訊,容易產生看似合理但實際上錯誤的「幻覺」。例如,模型能正確識別蔡英文,但可能對陳縕儂的細節產生幻覺。RAG 透過查詢外部知識來補充這些「小眾」知識。 知識過時 (Outdated Knowledge) :語言模型的知識固定在其訓練時間點,無法獲取即時或頻繁更新的資訊(如即時股價、最新選舉結果)。雖然「知識編輯」是更新LM知識的研究領域,但RAG提供了一種透過即時資料檢索來解決過時知識的方法。 缺乏溯源性與可驗證性 (Lack of Traceability and Verifiability) :傳統語言模型通常不提供資訊來源,難以驗證其答案。RAG 可以為檢索到的文件提供明確的來源,提升答案的可驗證性。 3. 基本 RAG 的實作流程 (早在2020年就已存在) 最基礎的 RAG 方法包含在生成過程開始時進行單次檢索: 查詢輸入 (Query Input) :使用者提供一個查詢。 檢索 (Retrieval) :檢索器元件從外部知識來源(如網路或內部資料庫)搜尋相關的文本片段或文件,這就像是當你不確定時「打開書本」查找資訊。 拼接 (Concatenation) :將檢索到的資訊直接與原始查詢拼接起來。 生成 (Generation) :這個組合後的輸入(查詢 + 檢索到的上下文)隨後被送入語言模型的輸入層,LM 根據這些資訊生成回應。這種方法能顯著減少幻覺並解決資訊過時問題。WebGPT 模型就是一個例子,它模仿人類搜尋行為,生成搜尋查詢,選擇相關結果,並引用來源來回答知識密集型問題。 二、 進階 RAG 技術:提升性...

淺談機器學習原理-估模型好壞

評估模型好壞 淺談機器學習原理筆記-- 評估模型好壞 MSE (Mean Squared Error) 是用來評估模型預測值與實際值之間差異的一種常用指標。將預測誤差平方後平均,懲罰大誤差, MSE 的值越小,表示模型的預測越準確。公式如下: M S E = 1 n ∑ i = 1 n ( y i − y ^ i ) 2 MSE = \frac{1}{n} \sum_{i=1}^{n} (y_i - \hat{y}_i)^2 MSE = n 1 ​ i = 1 ∑ n ​ ( y i ​ − y ^ ​ i ​ ) 2 其中: ( n ) 是樣本數量 ( y_i ) 是實際值 ( \hat{y}_i ) 是模型的預測值 適合用 MSE 的情境 : 回歸(Regression)問題 不適合用 MSE 的情境 : 資料尺度差異大 : 對離群值敏感的場景:資料裡常有極端值 分類問題(Classification) RMSE (Root Mean Squared Error) RMSE (Root Mean Squared Error) RMSE 是 MSE 的平方根,能夠將誤差的單位與原始數據保持一致,因此更容易解釋。公式如下: R M S E = 1 n ∑ i = 1 n ( y i − y ^ i ) 2 RMSE = \sqrt{\frac{1}{n} \sum_{i=1}^{n} (y_i - \hat{y}_i)^2} RMSE = n 1 ​ i = 1 ∑ n ​ ( y i ​ − y ^ ​ i ​ ) 2 ​ 其中: ( n ) 是樣本數量 ( y_i ) 是實際值 ( \hat{y}_i ) 是模型的預測值 適用情境 : 與 MSE 類似,適合回歸問題。 結果的單位和原數據一樣,例如房價是 $10,000,那 RMSE = 8,...

Mac安裝python

  安裝Python 使用brew安裝Python https://diveintopython.dev.org.tw/learn/install/mac > brew install python  安裝失敗 > brew reinstall python@3.13 > export PATH="$PATH:/usr/local/bin/python3" > sudo ln -s /usr/local/bin/python3 /usr/local/bin/python >python

UUID&ULID

UUIDs&Uild 應用 UUIDs&Uild 應用 UUIDs 概念 UUID 出自 RFC 9562標準 可以保證跨空間與時間的唯一性,長度總共16bytes或128bits,表示隨機產生這些字串並在某些條件下保證不會重複,這種方式對分散式系統在建立物件ID的地方是很有效益,因為可以保證在分散式系統是唯一值或是保證碰撞的可能性較低,也常應用在微服務架構中。當產生一組隨機序號,字串其中中間4表示UUID的版本,9隨機亂數。 C#呼叫Guid.NewGuid()就是產生UUID字串的方式 範例: cb9ec1e3-0cb1- 4 e33- 9 ee1-e86b725964f8 UUID v4範例 for ( int i = 0 ; i < 10 ; i++) Console.WriteLine(Guid.NewGuid()) /* 輸出 cb9ec1e3-0cb1-4e33-9ee1-e86b725964f8 d7250a44-9ccf-4b21-af55-e13cef7bc09b 3793f197-2d7b-4cad-b5f3-2c88946feb97 08845d8c-cf31-4cc2-b4fb-c23d2426ec56 88bd93f7-116b-4418-8954-b116f2995ebf 2ac06c87-8e2d-4515-9d84-25ee324d9efd b9e911b0-a509-4d24-88ef-bc5739cc6024 91b2185c-92f7-4656-9bce-f9e0aba17181 7ca9976e-6cc4-424b-8453-2c591d9ba17f 1b4af183-d3cc-4571-b2c6-3b76a419b9c8 */ UUID 缺點 (1) UUID在資料庫insert會比較慢,如果大量寫入會很明顯 (2) UUID會造成index fragmentation, 因為UU...

C# DI 輕鬆學

C&num; DI 輕鬆學 C# DI 輕鬆學 DI 概念 IoC (Inversion of Control) - 控制反轉 定義:IoC 是一種設計原則,將對象的控制權從內部轉移到外部。具體而言,應用程式不再負責控制物件的建立與管理,而是將這些工作交給外部的容器或框架。 作用:通過將控制權反轉,可以讓應用程式更具彈性、更容易測試,並提高可維護性。 舉例: 傳統設計:類別 A 自行建立類別 B 的實例(new 關鍵字)。 IoC 設計:類別 A 的類別 B 由外部容器或框架提供,類別 A 不直接控制物件的建立。 DIP (Dependency Inversion Principle) - 相依反轉原則 定義:DIP 是 SOLID 原則中的一部分,主要指: 高層模組不應該依賴低層模組;兩者應依賴於抽象(介面或抽象類別),處處都介面。 抽象不應該依賴細節;細節應該依賴抽象。 目的:降低模組間的耦合性,使程式更靈活、更易於擴展。 舉例: 壞設計:類別 A 直接依賴類別 B。 好設計:類別 A 依賴於一個介面,由類別 B 實現該介面。 說明: 當使用 MSSQL 建立的 Repository 來存取資料表時,Service 類別會依賴該 Repository 類別進行資料操作。 也就是說,Service 與低層的 Repository 類別存在相依性。然而,假設有一天需要將 Repository 的實現改為使用 NoSQL 來存取資料,此時勢必需要重新改寫 Repository 的實作,而這種改變也會影響到 Service 類別的內部結構, 導致高層模組(Service)與低層模組(Repository)的耦合性過高。 為了解決這個問題,我們可以採用 DIP(依賴反轉原則) 的設計模式。在此模式下,我們會建立一個 IRepository 介面 ,定義高層模組與低層模組之間的契約。Service 類別只依賴於該介面,而不關心具體的...