<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>OptiVerse 工程技術誌</title>
    <description>關於 AI 系統、檢索、代理、多模態智慧與推論基礎設施的雙語工程技術誌。</description>
    <link>https://optiverse-tech.com/zh-TW/</link>
    <atom:link href="https://optiverse-tech.com/zh-TW/feed.xml" rel="self" type="application/rss+xml"/>
    <language>zh-TW</language>
    <lastBuildDate>Sat, 09 May 2026 17:32:46 GMT</lastBuildDate>
    
    <item>
      <title>MoE 分片：混合專家模型的平行化策略</title>
      <link>https://optiverse-tech.com/zh-TW/blog/moe-sharding/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/moe-sharding/</guid>
      <pubDate>Fri, 03 Apr 2026 17:36:25 GMT</pubDate>
      <description>在 I-00 篇中，我們列出了 LLM 推論與傳統模型服務的五項差異。前四項——可變長度運算、兩階段資源特徵、不斷增長的記憶體需求，以及快取感知路由——每一項都已經在本系列的專文中討論過了。第五項則只用一句話帶過：「有些現代 LLM 使用混合專家模型（mixture-of-experts, MoE）架構，模型的不同部分會因不同的輸入而被啟用。把 MoE 模型分散到多個 GPU 上，需要跟密集模型不同的分片（sharding）策略。」</description>
      <category>Inference Infrastructure</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>前綴感知路由：考量快取狀態的請求分配</title>
      <link>https://optiverse-tech.com/zh-TW/blog/prefix-aware-routing/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/prefix-aware-routing/</guid>
      <pubDate>Fri, 03 Apr 2026 17:36:25 GMT</pubDate>
      <description>在 I-02 篇中，我們看到 PagedAttention 讓不同的請求能在同一個模型副本（model replica）上共用實體 KV 快取區塊。兩個使用相同系統提示詞（system prompt）的請求可以指向相同的實體區塊，不需要儲存重複的副本。這個共用機制確實有效——但前提是兩個請求必須落在同一個副本上。</description>
      <category>Inference Infrastructure</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>預填充-解碼解耦：將推論的兩個階段分開</title>
      <link>https://optiverse-tech.com/zh-TW/blog/prefill-decode-disaggregation/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/prefill-decode-disaggregation/</guid>
      <pubDate>Fri, 03 Apr 2026 17:36:25 GMT</pubDate>
      <description>I-00 確立了 LLM 推論具有兩個資源特性截然不同的階段。預填充以平行方式處理所有輸入 token，屬於運算瓶頸（compute-bound）——GPU 的運算單元是限制因素。解碼則逐一生成 token，屬於記憶體頻寬瓶頸（memory-bandwidth-bound）——限制因素在於從 GPU 記憶體讀取模型權重和 KV 快取的速度。I-01 介紹了連續批次處理，它透過在迭代層級而非批次層級進行排程，讓 GPU 保持滿載。I-02 則展示了 PagedAttention 如何消除記憶體浪費，讓更多請求能同時處於活躍狀態。</description>
      <category>Inference Infrastructure</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>分頁式 KV 快取：LLM 推論服務的 GPU 記憶體管理</title>
      <link>https://optiverse-tech.com/zh-TW/blog/paged-kv-cache/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/paged-kv-cache/</guid>
      <pubDate>Fri, 03 Apr 2026 17:36:25 GMT</pubDate>
      <description>在 I-00 篇中，我們走過了一次 API 呼叫從頭到尾通過推論流程的完整路徑，也認識了 KV 快取（key-value cache）——一種用來儲存注意力機制中 key-value 向量的資料結構，讓模型不必在每個解碼步驟重複計算這些向量。KV 快取會隨著每個生成的 token 不斷增長，而且在整個請求期間都必須留在 GPU 記憶體裡。到了 I-01 篇，我們又認識了連續批次處理（continuous batching）：它在迭代層級進行排程，不必等批次中最慢的請求跑完，因此能讓更多請求同時保持運作。</description>
      <category>Inference Infrastructure</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>連續批次處理：用一張 GPU 服務大量請求</title>
      <link>https://optiverse-tech.com/zh-TW/blog/continuous-batching/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/continuous-batching/</guid>
      <pubDate>Fri, 03 Apr 2026 17:36:25 GMT</pubDate>
      <description>I-00 追蹤了單一請求通過推論流程的完整路徑：預填充（prefill）以平行方式處理所有輸入 token，解碼（decode）逐一生成輸出 token，而 KV 快取（key-value cache）隨著每一步不斷增長。在那篇文章的結尾，我們注意到還有另外 49 位旅遊顧問幾乎同時提交了查詢。這個觀察不是隨口帶過——它直接指向推論服務的核心運作問題。</description>
      <category>Inference Infrastructure</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>呼叫 API 之後發生了什麼事</title>
      <link>https://optiverse-tech.com/zh-TW/blog/what-happens-after-you-call-the-api/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/what-happens-after-you-call-the-api/</guid>
      <pubDate>Fri, 03 Apr 2026 17:36:25 GMT</pubDate>
      <description>你已經建好一個旅遊 Copilot。使用者輸入一段查詢，你的應用程式把它送到 LLM 供應商的 API，幾秒後回應串流回來。對應用程式開發者來說，那就是一次函式呼叫。但從基礎設施的角度來看，這一次呼叫觸發了一整條流程（pipeline），牽涉到不同的運算階段、專用的記憶體結構、排程決策，還有硬體限制。這些因素加在一起，決定了使用者實際感受到的延遲、吞吐量和成本。</description>
      <category>Inference Infrastructure</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>實務中的代理迴圈：ReAct、工具與失敗模式</title>
      <link>https://optiverse-tech.com/zh-TW/blog/agent-loops-react-tools-failure-modes/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/agent-loops-react-tools-failure-modes/</guid>
      <pubDate>Sat, 21 Mar 2026 05:32:33 GMT</pubDate>
      <description>多數關於 agent 的工程討論，太早亮出 agent 這個詞，卻太晚才談營運迴圈。其實實務上真正重要的設計問題很簡單：模型一旦能執行不止一步，系統怎麼決定下一步做什麼？能呼叫哪些工具？可以從結果推斷什麼？又該在何時停下來？</description>
      <category>Agents &amp; Autonomy</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>打造旅遊 Copilot：端對端架構、核准閘門（Approval Gate）與稽核能力（Auditability）</title>
      <link>https://optiverse-tech.com/zh-TW/blog/building-travel-copilot-end-to-end-architecture/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/building-travel-copilot-end-to-end-architecture/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>當一個團隊準備建構進階 AI 旅遊 Copilot 時，真正的難題不是「用哪個模型」，而是「在系統能被正式環境信任之前，什麼事情必須發生、按什麼順序、憑什麼證據、在什麼狀態下、經誰核准？」這是架構問題——模型位於其中，但模型並不能解決這個問題。</description>
      <category>AI System Architecture</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>多模態證據系統：視覺語言模型（VLM）、圖像基礎化（Figure Grounding）與跨模態檢索（Cross-Modal Retrieval）</title>
      <link>https://optiverse-tech.com/zh-TW/blog/multimodal-systems-vlms-figure-grounding/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/multimodal-systems-vlms-figure-grounding/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>純文字系統一旦證據不再主要是文字，就會失效；在無障礙旅行規劃中，照片、平面圖、路線地圖、圖說和量測資料往往會共同決定答案。</description>
      <category>Document &amp; Multimodal Intelligence</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>超越 OCR 的文件智慧（Document Intelligence）：版面分析、表格與證據重建</title>
      <link>https://optiverse-tech.com/zh-TW/blog/document-intelligence-ocr-layout-tables/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/document-intelligence-ocr-layout-tables/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>多數團隊第一次接觸文件處理，都是從 OCR 開始。問題看起來很直覺：把頁面轉成文字、為文字建索引，然後讓檢索系統或 LLM 來回答問題。</description>
      <category>Document &amp; Multimodal Intelligence</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>當 RAG 不夠用時：快取增強生成（CAG）、混合檢索與工作記憶</title>
      <link>https://optiverse-tech.com/zh-TW/blog/when-rag-not-enough-cag-hybrid-retrieval/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/when-rag-not-enough-cag-hybrid-retrieval/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>基本的檢索增強生成（RAG）到現在還是多數正式環境系統最常用的基礎模式。語料庫很大、更新頻繁、又需要展示答案來源？檢索依然是最乾淨的起點。不過實務上會碰到一種極限情境——簡單的 RAG 開始力不從心：系統確實找到了正確的文件，但任務現在需要的是針對一組有限的證據持續推理，同時回答同一案件的多次後續追問。</description>
      <category>Retrieval &amp; Knowledge</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>助理、工作流程與代理：為適當的自主層級而設計</title>
      <link>https://optiverse-tech.com/zh-TW/blog/assistants-agents-autonomy-spectrum/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/assistants-agents-autonomy-spectrum/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>Agent（代理）已經成為 AI 中最被濫用的術語之一。產品團隊拿它來形容各種東西——從帶有檢索功能的聊天介面，到可以自行規劃、呼叫工具和採取行動的長時間執行程式，通通都算。這種詞彙漂移會造成實際問題：真正的設計問題明明是架構性的，團隊卻在爭論標籤。</description>
      <category>Agents &amp; Autonomy</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>記憶、狀態與知識：別再把所有東西都叫做「記憶」</title>
      <link>https://optiverse-tech.com/zh-TW/blog/memory-state-and-knowledge/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/memory-state-and-knowledge/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>一個為中型旅行社打造的旅遊規劃 Copilot，被問了一個很直接的問題：「這間飯店之前是否在輪椅使用者的無障礙審查中未通過？」</description>
      <category>Retrieval &amp; Knowledge</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>以 RAG 進行基礎化：AI 系統如何在回答之前檢索佐證</title>
      <link>https://optiverse-tech.com/zh-TW/blog/grounding-with-rag/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/grounding-with-rag/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>大型語言模型之所以有用，是因為它們能用流暢的語言綜合、解釋和轉化資訊。但一旦我們要求它們處理即時的、私有的，或需要可驗證依據的資訊，它們就變得不可靠。模型在訓練期間可能看過類似的素材，但這不代表它能存取當前任務需要的那份飯店合約、無障礙稽核或客戶回饋紀錄。</description>
      <category>Retrieval &amp; Knowledge</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>可靠的 LLM 流程與控制邏輯</title>
      <link>https://optiverse-tech.com/zh-TW/blog/reliable-llm-pipelines-and-control-logic/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/reliable-llm-pipelines-and-control-logic/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>有用的 AI 系統往往還沒遇到什麼奇特的模型問題，就先因為普通的軟體原因出狀況了。原型階段看起來很厲害——一個提示就能產生看似合理的答案。但正式系統面對的不是合理性，而是一筆筆需要路由、驗證（validation）、重試、儲存或拒絕的紀錄、決策和動作。</description>
      <category>AI System Architecture</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>從模型到複合式 AI 系統</title>
      <link>https://optiverse-tech.com/zh-TW/blog/from-models-to-compound-ai-systems/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/from-models-to-compound-ai-systems/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>真實 AI 產品裡的多數失敗，根本不是模型能力不夠。問題出在我們要求模型去做本該屬於更大系統的工作：擷取正確的資料、解讀混亂的文件、檢查 schema、追蹤跨步驟的狀態、為答案附上佐證。Demo 階段可以掩蓋這些問題，但一進正式環境，馬上就暴露了。</description>
      <category>AI System Architecture</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>AI 驅動的客戶支援 — 從聊天機器人到智慧型系統</title>
      <link>https://optiverse-tech.com/zh-TW/blog/ai-powered-customer-support-chatbot-to-intelligent-system/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/ai-powered-customer-support-chatbot-to-intelligent-system/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>客戶支援是很適合收束基礎概念的範例，因為一則訊息可能同時需要檢索、工具使用、記憶、路由和核准邊界。</description>
      <category>LLM Fundamentals</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>AI 助理、AI Agent，以及兩者之間的一切</title>
      <link>https://optiverse-tech.com/zh-TW/blog/ai-assistants-agents-everything-in-between/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/ai-assistants-agents-everything-in-between/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>一個有用的 AI 系統，關鍵不在於它被稱為助理還是 Agent，而在於它對下一步擁有多少控制權。</description>
      <category>LLM Fundamentals</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>為什麼 LLM 需要幫助 — 幻覺、Grounding，以及系統設計的必要性</title>
      <link>https://optiverse-tech.com/zh-TW/blog/why-llms-need-help-hallucinations-grounding-systems/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/why-llms-need-help-hallucinations-grounding-systems/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>大型語言模型能產出流暢又自信的文字。而這份自信，正是問題所在。模型可以把一筆已經下架的房源、一個上一季才變動的稅率、一則三年前的學校評分，講得頭頭是道。它沒有任何機制去查核——本來就不是為查核設計的。它的工作是根據訓練資料預測下一個最合理的 token，而合理不等於正確。</description>
      <category>LLM Fundamentals</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>提示詞、上下文視窗，以及你如何與 LLM 對話</title>
      <link>https://optiverse-tech.com/zh-TW/blog/prompts-context-windows-and-how-you-talk-to-an-llm/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/prompts-context-windows-and-how-you-talk-to-an-llm/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>上一篇裡，我們丟了一句話給 LLM——「幫我規劃一趟赫爾辛基（Helsinki）之旅」——然後拿到一份細節滿滿的行程表：餐廳名、交通路線、一日遊安排。讀起來很順，看起來也合理，但好幾個細節事後被證實是錯的。模型沒壞，只是輸入沒給它什麼限制條件可以依循。</description>
      <category>LLM Fundamentals</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
    <item>
      <title>大型語言模型到底在做什麼</title>
      <link>https://optiverse-tech.com/zh-TW/blog/what-large-language-models-actually-do/</link>
      <guid isPermaLink="true">https://optiverse-tech.com/zh-TW/blog/what-large-language-models-actually-do/</guid>
      <pubDate>Fri, 20 Mar 2026 17:46:32 GMT</pubDate>
      <description>你在某個 AI 應用裡打了一段話，幾秒鐘後螢幕上跑出好幾段文字——流暢、有條理，讀起來像某個很懂的人寫的。這種事現在大家都習以為常了。但如果你打算在這些系統上面蓋東西，真正該理解的是：從你按下送出到那些文字出現，中間到底發生了什麼。</description>
      <category>LLM Fundamentals</category>
      
      <dc:creator>Huang Tzu Lin</dc:creator>
    </item>
  </channel>
</rss>