Lawrence Blog

很久很久以前，我寫過一個取得 Microsoft SQL Server 資料結構表文件的 小工具 。 那時候的需求很單純，把資料表的欄位資訊、約束條件、索引等等，全部匯出到一份 Excel 裡面，依照 Sheet 區分不同資料表，方便維護與交接。 時間快轉到 2025 年，我換了工作環境，也換了資料庫，從 SQL Server 變成了 Oracle，既然資料庫都換了，小工具當然也得進化，這次我不再使用 Excel，而是直接改成輸出 Markdown 格式。 這次改用 Markdown 格式，主要的原因是資料庫異動管控的考量（這裡水有點深😎）， Oracle 資料庫不像 MSSQL 那樣有專用的「資料庫專案」功能，因此過去大家常用 Excel 等檔案來做管制（或者沒有管制 ！？😤），但這種做法的缺點就是看不到異動歷程。 不同於 Excel，Markdown 的好處是，可以直接放進專案文件夾，搭配 Git 或其他版本控管系統，任何欄位變更、欄位刪減、索引調整，通通都能一目了然 ，但如果要人工維護表格可能就有點累了，因此這次才會再寫一個 Oracle 版的小工具方便自己管理，因此若你需要 MSSQL 版的工具請轉到 這頁 來下載。

致人工智慧時代各位辛苦的 IT 們，不知道你們最近是不是也跟我一樣，整天不是在忙著嘗試各式各樣的 AI Agent，就是在惡補各種新冒出來 AI 知識。 在某個悠閒假日的中午，我正在準備玩新的 AI Cli 的時候，老婆突然冷不防拋出一句話。「你那麼會叫 AI 寫程式，那等等幫我爬一份日本地震資料，整理出某某地區的地震資訊，然後定期丟一份 Excel 給我」。然後還補一句，啊對了，等等十五分鐘後桌子要收起來吃飯。 我心裡想， 這是在暗示我只有 15 分鐘寫完爬蟲還要完成部署吧？ 😱 問題是……這需求根本跟 AI 無關好嗎！

Hello 大家好，相信隨著 Vibe Coding 的熱潮，許多人終於能用自然語言來「說」出程式碼，跨出了過去難以逾越的那一步。 再加上近幾個月來，AI Agent、Model Context Protocol（MCP）、n8n 等結合 AI 相關的技術如雨後春筍般冒出，速度之快，幾乎是一覺醒來世界都變了樣。而這波大混戰中，Google 更在這幾天大方釋出 Gemini CLI 供大家免費使用，瞬間讓整個圈子都熱鬧了起來。但身為一個正被  AI 迫害的碼農 😜，怎麼能不親身體驗一下「用嘴巴寫程式」的威力呢？ 先說結論 你終究還是要學會寫程式，只是寫程式將不再是一項專業技能。未來需要的，是一個具備優秀表達能力，並且擅長與 AI 合作的軟體工程師。 在不久的將來， 那些只會寫程式的設計師終將被 AI 取代，留下來的會是那些擅長帶領 AI 團隊（我稱之為 LLM Coding），並協助 AI 找出問題的 AI 軟體架構師 。所以從今天起，開始改變吧。 因此，今天就是要跟大家分享如何使用 GitHub Copilot 來寫程式。一開始我也蠻好奇的，覺得寫完之後可能還是要改吧？但 你相信它只花了五分鐘就完成了嗎？ 相信你一看完，一定會震撼感十足！這也是我第一篇不寫程式的程式分享文章，下圖是最終實作出來的結果。 AI Agent 協助完成的 LINE 翻譯機器人 但在開始之前，先前情提要一下，之前我有一個系列文章，分享了如何 使用生成式 AI 技術實作屬於自己的 LLM 知識庫 ，其中某篇文章的範例提到了如何 運用 Prompt 提示工程 來幫助我們完成多國語系翻譯的功能，今天我就是要延續這個專案，來完成一個專屬的 LINE 翻譯機器人。 啟動 GitHub AI Agent 在開始使用 GitHub AI Agent 之前，我已在相同的專案內新增了一個名為 TranslateLineBotDemo 的 WebAPI 空白專案。接下來，直接看看我們的 Prompt 要怎麼下 需求說明 我正在幫一個製造業的工廠寫一個多國語言的 LINE Bot 機器人，而本次預計的需求目標如下 1. 需支援中文、英文、日文、越南、菲律賓等五國的多語系翻譯。 2. LINE Bot 僅能處理文字對話，當使用者送出文字以外的訊息，則回傳 "我現在只會翻譯文字喔" 的訊息。 3...

# 使用生成式 AI 結合 RAG 技術實做屬於自己的 LLM 知識庫系列文章 在完成前面幾篇的實作後，你應該已經學會如何呼叫 LLM 模型，也知道如何讓 LLM 模型記住你們的對話了。同時，我們也都知道，LLM 模型是一位通才型的專家，當你提出問題時，它會根據訓練過的大量語料，試著回答你相關的內容。 不過，LLM 並非萬能， 當它遇到沒見過或不知道的問題時，就可能產生幻覺 ，這也是我們之後要實作 LLM 知識庫中需要留意的重要課題（續會有另外一篇 RAG 來介紹如何減輕這個問題）。 那你有沒有想過，如果在某些情境下，你剛好提出一個跨領域的問題，LLM 模型又會怎麼回答呢?

# 使用生成式 AI 結合 RAG 技術實做屬於自己的 LLM 知識庫系列文章 前情提要 這篇文章是【 Hello Gemini，串接第一個 Gemini 生成式 AI 】的延伸篇，在完成上一篇的設定後，我們已經成功透過程式呼叫 Google Gemini，串起了第一個生成式 AI 的小程式了。  但，事情並不總是這麼順利... 請看下圖的情境，我一開始問了一個問題，而它也正確的回答，接著再問「那他的背景是什麼」，結果 Gemini 居然回了一個讓人摸不著頭緒回答，不知道它是害怕想起來還是擔心對岸會對它不利 XD，它似乎完全忘了我們上一個問題在問什麼了。 你可能會有疑問？我明明在 ChatGPT 或 Gemini 使用者介面都用的好好的，怎麼會串個 API 就不知道我第一個問題是什麼呢？難道我的 API 版本是金魚腦比較笨！！其實，這是因為像 ChatGPT 或 Gemini 這類平台的使用者介面，內建了「對話記憶」機制來解決這個問題 。 也就是說，這些平台它會自動把你之前說過的話保留下來，讓模型能理解整段對話的上下文，回應自然又有連貫性，就像是跟朋友說話一樣自然。當然，這種記憶也是有限度的( 畢竟模型的上下文長度是有限的，因此記憶也是有限的 ，這部分我們之後有機會可以再深入介紹)，不過至少最近幾輪的對話它都還能記住。  但當你透過 API 來串接 Gemini 或 ChatGPT 時， 模型並不會主動幫你記住對話的上下文 ，你得自己把對話的歷史維護好，並在每一次請求時都一併傳送過去，因此如同這篇的主題「做個有記憶力的 AI 機器人」，這篇將會示範如何實作基本的對話記憶機制。

# 使用生成式 AI 結合 RAG 技術實做屬於自己的 LLM 知識庫系列文章 Gemini 是什麼？ Gemini 是 Google 開發的生成式 AI 模型系列，它的前身你可能聽過的是 Bard(一開始被 ChatGPT 打的很慘，現在已經默默退場的那位)，而 Gemini 這個系列專為多模態任務設計，也就是說它不只會聊天，還能處理圖片、文字，甚至未來可能支援更多格式，你可以把 Gemini 想像成 Google 家的 ChatGPT，而且它也有自己的 API 可以串接。 為什麼選擇 Gemini？  回到本系列第一篇文章提到的，本次的目標是希望用 最低成本 打造出屬於自己的 LLM 知識庫，感覺這個目標聽起來不難，但現實往往不會那麼美好，實務上最理想的狀況當然是整套系統都跑在自己地端環境，不僅能確保資料不會外流，還能完全掌控模型運作細節。 不過嘛…… GPU 很貴的，不是每個人或者公司都願意砸大錢弄一台本地端跑 LLM 的伺服器，更別提現在使用者被 ChatGPT 養壞了，變得超沒耐心，超過 3 秒的回應時間可能就給負評 + 退訂了 XD。 因此我選擇 Google 的 Gemini 作為生成模型，原因很簡單，目前它提供免費呼叫 API 的額度 (至少本文撰寫的時候 Gemini 2.5 Flash 有一個免費額度可以使用，詳細可參考 Gemini Developer API 定價 ，但目前 AI 服務變化太快，未來就沒辦法保證了)。 怎麼串接 Gemini API？ 前置作業 在開始寫程式碼之前，你必須先完成底下幾個重要步驟，相關設定也可以參考 Gemini API 說明文件 。 擁有一個 Google 帳戶：這一定要的吧，哪家不是這樣。 申請 Google Cloud 帳戶：去 Google Cloud 註冊一個帳戶，開通免費試用額度。 取得 Gemini API 金鑰：登入 Google AI Studio 後，它會要求同意一些服務條款。 建立 API Key：完成上一個步驟後，理論上可以看到 Create API Key 的按鈕，點下去就對了。 記下 API Key：完成後你會得到一組可以呼叫 Gemini API 的 Key，請記下它(忘記了其實也沒關係，管理介面這邊還可以看到)，等等開發的時候會用到。 測試 API Key 拿到 API 照...

# 使用生成式 AI 結合 RAG 技術實做屬於自己的 LLM 知識庫系列文章 Word Embedding ? 維基百科的定義 詞嵌入（英語：Word embedding）是自然語言處理（NLP）中語言模型與表徵學習技術的統稱。概念上而言，它是指把一個維數為所有詞的數量的高維空間嵌入到一個維數低得多的連續向量空間中，每個單詞或詞組被映射為實數域上的向量。 Word Embedding 的輸入格式 輸入是一個或多個文字，通常是單字或是整句話，這些文字會先經過處理（例如分詞、去除標點），再送進詞嵌入模型中，舉例來說：「美國總統是誰?」，這句話可能會轉換成 ["美國總統", "是誰"] 這樣陣列。 Word Embedding 的輸出格式 針對上述陣列內的每個文字，詞嵌入模型會經過一連串的數學運算，將其轉換成一組向量，這些向量是由一串實數所組成的數字序列，代表該詞的語意特徵，輸出的格式通常會是像底下這樣的結構 { "美國總統": [0.12, -0.34, ..., 0.87], "是誰": [0.03, -0.56, ..., 0.45] } 所以到底是什麼? 好吧，其實對於有點技術背景的人來說，前面那些概念應該已經蠻清楚了。但如果你是完全沒碰過這塊的新手，可能還是會覺得，嗯？ 這到底在說什麼？ 我這邊用白話文來解釋，Word Embedding 其實就像是幫每個文字編碼成一張 數字小卡片 ，這張名片記錄了它的個性、興趣和關聯對象，而電腦就是靠這些卡片來判斷誰跟誰是好朋友（例如 蘋果 跟 香蕉 很像）或誰跟誰完全不像（像 香蕉 跟 國王） 。 圖片來源 : https://towardsdatascience.com/deep-learning-for-nlp-word-embeddings-4f5c90bcdab5/ 為什麼有這麼多不同的詞嵌入模型? 因為每種模型都有自己的擅長領域，而且技術一直在進步、需求也不一樣，所以自然就冒出很多種詞嵌入方式，主要可分成幾個面向 技術進步 ：早期像 One-hot 很簡單，但不夠聰明，後來 Word2Vec、GloVe 開始學語意，再後來 BERT、GPT 甚至能根據上下文「動態」理解每個詞。 應用場景 ：做分類、對話、翻譯、問答，每個任...

# 使用生成式 AI 結合 RAG 技術實做屬於自己的 LLM 知識庫系列文章 在 上一篇 文章中簡單介紹了這系列文章的目標與執行流程，今天這篇文章將記錄，開發 Gen AI 的 LLM 知識庫系統所需的環境設置，以下是我在開發過程中所使用的環境說明： 作業系統：Windows 10 企業版 LTSC Docker Desktop： Docker Desktop 4.38.0（181591） Word Embedding 模型：snowflake-arctic-embed2 LLM 模型：Google Gemini 開發語言：NET Core 8 使用套件：Semantic Kernel  Ollama 是什麼? Ollama 是個很方便的開源 LLM 框架，讓你可以在本地端輕鬆跑像 Llama 3、Mistral、Gemma 這些熱門的大語言模型，支援 Mac、Linux、Windows 多平台，重點是它已經把模型設定、權重下載、環境配置這些麻煩事都打包好了。 你也可以直接在開發環境上面安裝，但你知道的，有時候環境設定真的是地雷一堆，踩到就很 OOXX，所以我個人是直接使用 Docker 來裝，因此這篇文章會記錄用 Docker 來安裝 Ollama 的流程。

一直以來，我很少遇到需要一次性大量寫入資料的需求，印象中只有幾次需要將備份的歷史數據大量的轉回正式環境，那次因為不是很緊急，所以就直接下 SQL 讓他慢慢地寫（老實說真他 ○ × 的久），但在某次機會下，我查到 MSSQL 本身有提供批次寫入的語法（不好意思直白的說自己 SQL 不太好 XD），可以快速寫入大量的數據，因此這篇文章我要記錄一下如何在 MSSQL 和 MariaDB 批次寫入大量的資料。 MSSQL 批次寫入 Bulk Insert 是 MSSQL 提供給大量寫入資料庫的一個好用的語法，適用於一次性寫入數十萬甚至數千萬筆的資料，其主要由底下兩個實體檔案所組成。 Format File（格式檔）：用來定義要寫入的數據結構。 資料文字檔：實際要導入的數據，例如 CSV 或 TXT 檔案。 Format File  SQL Server 支援兩種類型的格式檔案：非 XML 格式和 XML 格式。 非 XML 格式是舊版 SQL Server 所支援的原始格式，詳細的說明可參考 官網 ，這邊我就用非 XML 格式，也就是文字檔的格式來說明。

# 使用生成式 AI 結合 RAG 技術實做屬於自己的 LLM 知識庫系列文章 前言 就在我停下追求技術腳步的跑去學界進修的這兩年，資訊領域發生了爆炸性的變化，生成式 AI（Generative AI）的技術在這段時間快速的成長，至今已有多家算是蠻成熟的 AI 公司，並發展了許多 AI 相關的服務，其中最著名的應用就是 ChatGPT，當然這些大型語言模型（Large Language Model, LLM）服務或多模態模型（Large Multimodal Models, LMM）服務提供商，也釋出了許多 API 給我們這些沒辦法自行架設環境的開發者，能透過他們提供的服務，讓我們自己的服務也跟上這一波 AI 的熱潮。 在這段時間，我一直很想抽空玩玩，但苦於時間真的是不太夠（真希望一天能有 48 小時 XD）。如今我進修的課程也到了尾聲，也差補不多是時候回來惡補我的 "技能債" 了。 關於如何自行架設 Gen AI 服務，或是串接各大廠商所提供 API，網路上已經有很多相關的文章，我敬仰的 Ian 大前輩，也在鐵人競賽寫了一系列關於  如何在 NET 中使用 GenAI 技術  的 文章 ，而自己在這領域也沒有玩太久，不敢在各位大神面前班門弄斧，所以本來沒有想要寫這系列的文章的，但回想當初寫這個部落格的目的，就是為了留下對於程式熱愛的記憶，因此我才決定寫下這一系列的記錄。