作者: kerwin77106

  • Hippo 記憶:讓本機 AI Agent 真正記住你

    📌 本文重點

    • Hippo 讓 AI Agent 具備結構化長期記憶
    • 不只用向量搜索,而是多維度記憶召回
    • 可直接接入 LangChain / LangGraph 現有架構

    如果你受夠了每次開新對話 AI 就失憶,Hippo 是一個專門幫 AI Agent 建長期記憶結構 的開源工具,讓模型可以跨對話記住你、記住專案、記住世界觀。

    專案連結:https://github.com/kitfunso/hippo-memory


    核心功能:它跟「塞進向量資料庫」有什麼不一樣?

    1. 生物啟發的記憶結構:不是只靠 embedding 搜索

    一般「加記憶」做法:

    • 把所有對話 / 文件轉成向量,丟進向量資料庫
    • 查詢時用 embedding 相似度召回

    這樣會遇到:

    • 記憶越多越慢
    • 容易抓到語意相似但情境不對的內容
    • 很難做「時間感」與「重要程度」的區分

    Hippo 的做法更像大腦海馬迴:

    • 把記憶拆成多種型態(事件、事實、偏好、任務等)
    • 每種記憶有自己的欄位:時間戳、重要性、來源、關聯 id
    • 召回時不只看相似度,還會考慮:
    • 時間距離(最近 / 很久以前但被多次提及)
    • 重要性(例如「明天要開會」權重更高)
    • 記憶種類(對話中問的是偏好,就優先找偏好類)

    💡 關鍵: Hippo 透過「記憶類型 + 時間 + 重要性」多維度過濾與排序,比單靠 embedding 更接近人類大腦的記憶方式。

    你可以採取的行動

    • 在設計 Agent 時,把「要記住什麼」先分類(例:使用者設定、長期專案狀態、一次性任務)
    • 對應到 Hippo 的不同記憶類型,而不是全部塞進單一向量庫

    2. 高效寫入 / 召回:不是每一句話都存

    Hippo 會讓 LLM 幫忙「過濾」哪些內容要進長期記憶:

    • 每輪對話結束時,呼叫一次 LLM:
    • 請它輸出:要存什麼?是什麼類型?重要性幾分?
    • 只有被標註為「值得記住」的內容才寫入記憶庫

    召回時則是:

    • 先根據 當前任務類型 過濾可疑記憶(例如問「專案」時,優先專案類)
    • 再用 embedding + 時間 + 重要性加權排序

    效果:

    • 記憶庫不會無限膨脹
    • 查詢時間穩定,對話變長也不會暴漲

    💡 關鍵: 透過 LLM 篩選與加權排序,Hippo 在長期對話下仍能維持穩定的查詢速度與記憶品質。

    你可以採取的行動

    • 在對話 loop 中加入一個 summarize_and_store_memory() 步驟
    • 規劃一份提示詞,教 LLM:什麼東西需要記住(例如使用者偏好、長期任務)

    3. 可以直接當「記憶模組」接到 LangChain / LangGraph

    Hippo 把核心封裝成一個獨立記憶層:

    • 暴露簡單的 API:add_memory(), retrieve_memories(), summarize_dialogue()
    • 你可以把它包成一個自訂的 LangChain Memory 類或 LangGraph node

    這代表你不必改整個 Agent 架構,只要:

    • 把原本「向量記憶」的那一層換成 Hippo
    • Prompt 裡多餵一段:{relevant_memories}

    你可以採取的行動

    • 先用 Hippo 做一個獨立小腳本,確定記憶寫入 / 召回正常
    • 再把它接進現有的 LangChain / LangGraph 專案

    適合誰用?三種具體場景

    1. 客服 / 助理型 Agent:跨對話記住使用者

    問題:

    • 今天跟你聊過喜好,明天又得重講一次

    用 Hippo 可以:

    • 把「使用者個人偏好」「公司規則」「歷史問題」分成不同記憶類型
    • 在每次新對話開始前,先用使用者 id 去 retrieve_memories()

    具體做法:

    • 每個 user 綁一個 user_memory_store
    • 首輪對話後,寫入:
    • 常用產品 / 方案
    • 語氣偏好(喜歡簡短回答、或喜歡詳細教學)
    • 下次對話開頭,在系統 prompt 裡加:
    • 你已知這個使用者的偏好:...

    2. 工具型 Agent:追蹤專案長期狀態

    像是:

    • 本機程式碼助手
    • 專案管理 / 自動化腳本編排 Agent

    用 Hippo 可以把:

    • 已完成的任務
    • 未完成的 TODO
    • 決策理由(為什麼選 A 而不是 B)

    長期存起來,讓 Agent 未來做決策時可以「回頭想」,而不是只看當前 prompt。

    具體做法:

    • 每次工具成功執行後,寫入:操作內容、輸入、輸出、錯誤紀錄
    • 下次 Agent 在決定要不要呼叫同個工具時,先查過去的失敗 / 成功案例

    💡 關鍵: 對工具型 Agent 來說,持續累積「決策與結果」記憶,可以大幅降低重複犯錯與無效操作。

    3. 遊戲 / 模擬:角色人格與世界觀持久化

    如果你在做:

    • 文字冒險遊戲中的 NPC
    • 模擬城市 / 社會裡的多 Agent 系統

    Hippo 可以:

    • 把 NPC 的「人生事件」「人際關係」「信念」拆成不同記憶
    • 讓同一個角色在不同局遊戲中保有成長、偏好

    具體做法:

    • 每次玩家與 NPC 互動後,將關鍵事件寫入該 NPC 的記憶庫
    • 下次載入遊戲時,先載入角色記憶,再生成回應

    怎麼開始:本機跑一個有長期記憶的 Agent

    下面示範:在本機用一個輕量開源 LLM + Hippo 跑出一個最小可用的長期記憶 Agent。

    1. 安裝依賴(Python)

    假設你有 Python 3.10+,先開一個虛擬環境:

    python -m venv venv
    source venv/bin/activate  # Windows 用 venv\Scripts\activate
    
    pip install hippo-memory
    pip install transformers accelerate sentence-transformers
    

    如果你想用 Ollama / 本機模型,也可以只要 HTTP API,把 llm_call() 改成呼叫本地端服務即可。

    2. 建一個最小記憶介面

    概念流程:

    1. 使用者說話
    2. Agent 回應(用 LLM)
    3. 用 LLM 檢查這輪對話有沒有值得記住的東西
    4. 需要記住的就丟給 Hippo
    5. 下一輪對話前,從 Hippo 取出相關記憶加進 prompt

    簡化版範例(偽代碼結構):

    from hippo_memory import HippoMemory
    
    memory = HippoMemory()
    
    def llm_call(prompt: str) -> str:
        # TODO: 換成你實際使用的本機 LLM(Ollama / vLLM / transformers)
        ...
    
    
    def summarize_for_memory(dialogue: str) -> list[dict]:
        """讓 LLM 決定要存哪些記憶,回傳 list[{"type":..., "content":..., "importance":...}]"""
        prompt = f"""
    你是記憶管理員。以下是剛剛的一段對話:
    {dialogue}
    
    請列出值得長期記住的事情(使用者偏好、長期目標、重要事件)。
    用 JSON 陣列輸出,每個元素包含 type, content, importance(1-5)。
    如果沒有,回傳 []。
    """
        import json
        res = llm_call(prompt)
        return json.loads(res)
    
    
    def add_dialogue_to_memory(history: list[tuple[str, str]]):
        # history = [(user_msg, assistant_msg), ...]
        text = "\n".join([f"User: {u}\nAssistant: {a}" for u, a in history[-3:]])
        items = summarize_for_memory(text)
        for item in items:
            memory.add_memory(
                mem_type=item["type"],
                content=item["content"],
                importance=item.get("importance", 3),
            )
    
    
    def chat_loop():
        history = []
        while True:
            user = input("你:")
            if user.strip().lower() in {"exit", "quit"}:
                break
    
            # 1) 先查記憶
            relevant = memory.retrieve_memories(query=user, top_k=5)
            memory_text = "\n".join([f"- {m.content}" for m in relevant])
    
            # 2) 組 prompt
            prompt = f"""你是一個會記住使用者的助理。
    以下是你對這位使用者的已知記憶:
    {memory_text or '(目前沒有特別記憶)'}
    
    現在的對話:
    使用者:{user}
    請根據記憶與對話回應。
    """
            assistant = llm_call(prompt)
            print("Agent:", assistant)
    
            history.append((user, assistant))
            add_dialogue_to_memory(history)
    
    
    if __name__ == "__main__":
        chat_loop()
    

    你可以採取的行動

    • 把上面程式框架複製到自己的專案
    • llm_call() 替換成你現用的 LLM(如 Ollama 的 /api/chat
    • 用幾輪「自我介紹 → 問之前說過什麼」來測試記憶效果

    3. 接到 LangChain / LangGraph 的 memory 模組

    如果你已經在用這些框架,可以這樣思考:

    • LangChain:
    • 寫一個 HippoMemoryWrapper,實作 load_memory_variables + save_context
    • 內部直接呼叫 HippoMemory.add_memory() / retrieve_memories()
    • LangGraph:
    • 把 Hippo 抽成一個 node:「更新記憶」與「擷取記憶」
    • 在主對話 graph 中,讓每輪都經過這兩個 node

    這樣你不用推翻原有設計,只是把記憶 backend 換成更聰明的 Hippo。


    小結:什麼時候值得上 Hippo?

    你可以用一個簡單判斷:

    • 只做「單次任務、一次對話就結束」的 Agent → 一般向量資料庫就夠
    • 需要「跨天、跨專案、角色長期成長」的 Agent → 值得導入 Hippo 記憶

    先從一個很小的場景開始:例如讓你的本機助理 記住你的個人偏好。當你發現它真的記得你說過的事,再把同樣的記憶結構,複製到客服、專案管理或遊戲 NPC 上。

    專案原始碼與設計細節: https://github.com/kitfunso/hippo-memory

    🚀 你現在可以做的事

    • 打開專案頁面,閱讀 Hippo 的 README 與範例程式碼:https://github.com/kitfunso/hippo-memory
    • 在本機建立一個小腳本,實作文中 llm_call() 並跑起示範的記憶型 Agent
    • 將 Hippo 接入你現有的 LangChain / LangGraph 專案,先讓一個特定 user 或 NPC 擁有長期記憶
  • 把 ChatGPT 變成科研助理:URSA 本地實戰

    📌 本文重點

    • URSA 是多代理 + 工具的科研自動化框架
    • 能接上現有模擬軟體,跑實驗到寫報告一條龍
    • 適合科研人、工程團隊與開發者做本地小實驗

    URSA 的用處很直接:把「只能聊天的 ChatGPT 類模型」,變成會幫你查文獻、寫程式、跑模擬、整理成報告的本地科研助理。

    原文與架構介紹:URSA: The Universal Research and Scientific Agent(arXiv:2506.22653)


    核心功能:URSA 到底多了什麼

    URSA 不是單一模型,而是一個「多代理 + 工具」的框架,核心可以拆成三件事:

    💡 關鍵: URSA 的核心不是換模型,而是用多代理 + 工具把整個科研流程自動化。

    1. 多代理分工:把「做研究」拆成幾個專職角色

    URSA 把一般研究流程拆成多個 Agent,例如:

    • Research Planner:幫你把模糊想法拆成可執行研究計畫
    • Literature Agent:負責關鍵字搜尋、整理文獻重點
    • Coding / Simulation Agent:寫程式、呼叫模擬工具
    • Writer Agent:根據結果產出段落與報告

    實際可做的事:

    • 用一段自然語言描述研究想法,例如「我想做 2D 渦街流場阻力係數的敏感度分析」。
    • 讓 URSA 的 Planner 產生任務列表,後續由不同 Agent 自動接手,例如:
    • 查 10 篇相關文獻 → 摘要 → 提案 3 個實驗設計 → 選 1 個方案 → 產生程式骨架 → 跑模擬 → 整理成報告

    2. 與科學工具整合:直接調用你已在用的軟體

    URSA 內建「工具調用」能力,可以把任何命令列或 Python 函式包成工具:

    • 物理模擬:CFD、材料模擬、分子動力學等(例如 OpenFOAMLAMMPS
    • 數值計算:Python + NumPy / SciPy、機器學習框架
    • 資料處理:CSV/Parquet 讀寫、繪圖、指標計算

    使用效果:

    • 你不用重寫模擬程式,只要告訴 URSA:
    • 怎麼改輸入檔(例如改網格大小、時間步長、邊界條件)
    • 怎麼啟動軟體(例如 simpleFoamlmp_mpi -in in.lammps
    • URSA 的 Coding / Simulation Agent 就能自動:改檔案 → 呼叫模擬 → 讀回輸出 → 繪圖與整理結論。

    3. 端到端科研流程:從找題目到初版報告

    URSA 目標是覆蓋一整輪研究週期:

    1. 題目定義與拆解
    2. 文獻搜尋與整理
    3. 提出實驗 / 模擬設計
    4. 生成初版程式碼與配置
    5. 執行實驗 / 模擬
    6. 分析結果、生成圖表
    7. 撰寫初稿報告(可對應論文結構)

    你可以把 URSA 當成一個「主導整個 pipeline 的研究 PM」,人類主要負責:

    • 設定研究方向與約束(時間、算力、可用工具)
    • 審核 Agent 的決策與修改設計
    • 在關鍵節點給出 domain 知識修正

    適合誰用?三個實戰場景

    場景 1:科研人——自動跑一輪「從想題目到初版報告」

    假設你是實驗室博士生,想快速探索一個新題目。

    目標流程:

    1. 找題目構想
    2. 查文獻,了解已有方法
    3. 做一版實驗/模擬設計
    4. 產出可改寫的初版報告

    你在 URSA 裡可以這樣操作:

    1. 輸入研究方向
      在入口提示中說清楚:
    2. 領域(例:流體力學、材料、電機)
    3. 限制(只有 CPU、只能用現成開源資料集、實驗期限 2 週等)

    4. 啟動 Literature Agent

    5. 授權它查公開資料庫(可對接 arXiv APISemantic Scholar 等)
    6. 請它輸出:

      • 關鍵詞列表
      • 10–20 篇代表性文獻摘要
      • 一個「研究空缺清單」
    7. 讓 Planner 組合研究方案

    8. 指定:「請根據上述文獻,提出 2–3 個可在 X 週內完成的小型研究設計,並列出:變因、假設、指標、所需工具」。
    9. 手動挑一個你覺得可行的方案。

    10. Simulation / Coding Agent 生程式骨架

    11. 若是數值實驗:請它用 Python + 你常用的框架(如 PyTorch / Scikit-learn)產生:
      • 資料載入與前處理程式
      • 兩三個 baseline 模型設定
      • 指標計算與繪圖(Matplotlib / Seaborn
    12. 在本地編輯器簡單檢查後執行。

    13. Writer Agent 出初版報告

    14. 把結果 CSV / 圖檔路徑給 Writer Agent
    15. 指示「請以論文 IMRaD 結構草擬 4–6 頁報告,以及 1 頁 slide 講稿要點」

    這一輪做完,你至少會拿到一份:

    • 有文獻引用的研究動機整理
    • 清楚的實驗設計(可再細化)
    • 可重跑的程式骨架
    • 一份可以交給指導教授討論的初版報告

    💡 關鍵: 一次完整流程就能得到從文獻到程式到報告的「可直接拿去討論」成果,大幅壓縮試題與準備時間。

    場景 2:工程/技術團隊——接上現有仿真軟體,變成「自動調參 + 報告生成」

    假設你在公司負責 CFD 或材料模擬,日常工作是:

    • 調不同幾何 / 邊界 / 材料參數
    • 批量跑模擬
    • 整理結果給 PM / 客戶

    用 URSA 可以把這條線變成半自動。

    1. 把模擬工具包成「工具函式」

    以 CFD + OpenFOAM 為例:

    • 寫一個 Python 函式:
    • 輸入:幾何尺寸、入口流速、黏度等
    • 步驟:
      • 修改 system / constant / 0 目錄的檔案
      • 呼叫 blockMeshsimpleFoam
      • 收集結果(壓降、阻力係數、流場截面圖)
    • 輸出:整理好的數值與圖檔路徑
    • 在 URSA 的工具描述中,把這個函式暴露給 Simulation Agent。

    2. 定義「優化任務」

    讓 Planner 具體知道要做什麼,例如:

    「目標:在給定壓降限制下,最小化翼型阻力係數。可調參數:攻角 0–10 度、翼型厚度 8–14%。預算:最多 50 次模擬。」

    Simulation Agent 就可以:

    • 根據策略(grid search / Bayesian optimization)提出一批參數組合
    • 呼叫你包好的 CFD 工具函式批次跑
    • 寫程式自動畫出:
    • 參數 vs 目標指標曲面
    • 最佳設計附近的敏感度分析

    3. 自動生成技術報告

    最後交給 Writer Agent:

    • 輸入:
    • 最佳參數組合
    • 設計約束(例如壓降限制)
    • 圖表路徑
    • 請它產出:
    • 面向 PM 的 2–3 頁技術報告(重點是結論與 trade-off)
    • 一份可貼進你們內部 Wiki / Confluence 的紀錄頁。

    這個模式可以平移到任何模擬:材料疲勞、熱傳、電磁、電池壽命等,只要你本來就能從命令列或 Python 啟動模型,URSA 就能接上去。

    場景 3:開發者——用公開數據集做一個「本地小實驗」

    如果你是工程師 / 資料科學家,想先用最小代價試試看 URSA,可以從一個公開數據集開始,例如 UCI 的經典表格數據。

    目標:

    • 用 URSA + 本地 LLM + Python 工具
    • 自動探索幾個模型設定
    • 生成一份結果報告

    怎麼開始:本地入門路徑

    以下是一條「最簡可跑通」的路線,假設你有一台能跑基本 LLM 的機器(也可以接外部 API)。

    1. 取得 URSA 框架

    目前 URSA 的詳盡描述在論文中,你可以:

    • 先讀架構概念:arXiv:2506.22653
    • 在 GitHub 搜尋是否已有開源實作(關鍵字:URSA scientific agent
    • 若尚未正式開源,可用任一「多代理框架」(如 AutoGenLangGraph)照著論文架構仿做一個輕量版。

    2. 準備前置環境

    建議環境:

    • Python 3.10+(condavenv
    • 常用科學套件:numpypandasmatplotlibscikit-learn
    • LLM 後端二選一:
    • 本地模型(如 llama.cppOllama 等)
    • 或外部 API(OpenAIAnthropic 等)

    3. 定義你的「工具函式」給 Agent 用

    用 Python 寫幾個簡單工具,並在 URSA 的工具列表中描述:

    • load_dataset()
    • 從本地 CSV 載入資料,回傳 DataFrame
    • train_model(config)
    • 根據 config 中的模型類型、超參數,訓練並回傳指標
    • plot_results(results)
    • 畫出不同設定的表現比較圖

    在工具描述裡用自然語言寫清楚:

    • 這個工具什麼時候用
    • 會輸入 / 輸出什麼

    讓 URSA 的 Coding / Simulation Agent 能自動決定要呼叫哪個工具。

    4. 跑一個最小實驗流程

    在主入口給 URSA 一段任務描述,例如:

    「資料集:UCI XXX。任務:二元分類,指標 F1。請自動探索 Logistic Regression、Random Forest、XGBoost 三種模型,為每種模型試 3 組超參數,輸出:
    1. 各模型的最佳設定與 F1。
    2. 一張結果比較圖。
    3. 一份 1500 字以內的分析報告。」

    觀察它的行為:

    • 是否能合理呼叫 load_datasettrain_modelplot_results
    • 是否會自行調整不合理的超參數
    • 報告是否有對應圖表、數據、結論

    這個「本地小實驗」跑通之後,你就可以:

    • train_model 換成你的 CFD / 材料模擬指令
    • 把 UCI 資料集換成你們內部數據

    💡 關鍵: 先用公開數據集驗證「Agent 能從工具調用一路走到報告」,再導入真實內部 pipeline,風險與改動都更可控。


    小結:URSA 要帶你做的事

    如果用一句話總結 URSA 的定位:

    它不是另一個聊天機器人,而是一個可以接上你現有程式與模擬工具、幫你自動完成「查文獻 → 寫程式 → 跑實驗 → 整理報告」一整輪工作的科研代理框架。

    想要實際用起來,你可以從最小的本地實驗開始:

    • 裝好 Python + LLM 後端
    • 定義 2–3 個工具函式給 URSA 呼叫
    • 讓它自動跑完一輪小實驗並產出報告

    等你對這套流程熟悉,再把它接到實驗室的模擬軟體或公司內部 pipeline,就能把很多重複的調參、報告整理工作交給代理處理,自己專注在決定題目與判讀結果上。

    🚀 你現在可以做的事

    • 先讀一遍 URSA 原始論文架構說明,畫出你自己的科研流程對照表
    • 在本地用 AutoGenLangGraph 仿做一個最小版多代理流程,實作 load_dataset / train_model / plot_results 等工具
    • 選一個你現在在做的小題目,嘗試讓 URSA 跑完「文獻整理 → 實驗腳本 → 初版報告」一輪,並拿結果和你原本工作流比較
  • 手機就能跑!Google Gemma 4 在地端 Agent 實測指南

    用一句話講清楚:Gemma 4 讓你只靠手機或筆電,就能有一個「不連網也能用、多模態又顧隱私」的 AI 助理和小型 Agent。

    📌 本文重點

    • 手機就能離線跑多模態 Gemma 4
    • 所有推論都在本機完成、隱私不出裝置
    • 一般用戶與開發者都有清楚實作路徑

    參考:The Decoder 對 Gemma 4 的介紹(英文)
    https://the-decoder.com/googles-gemma-4-puts-free-agentic-ai-on-your-phone-and-no-data-ever-leaves-the-device/


    核心功能:一機在手就有 AI 助理

    1. 完全 on-device:資料不出手機

    Gemma 4 的設計重點,是全部推論都在你的裝置上完成

    • 文字、圖片、音訊的處理都不丟上雲端
    • 查維基百科、地圖等工具時,是由系統端的「工具」去連網,不是把你原始資料上傳給 Google 模型
    • 你可以直接在飛機上、沒訊號的地方,照樣請它整理筆記、翻譯、做摘要

    💡 關鍵: 所有推論留在本機跑,代表敏感內容(合約、成績單、醫療報告)可以在離線環境安心處理。

    你可以馬上做的事:

    • 把 Gemma 4 當成「離線版 ChatGPT」:問行程、請它改寫文章、整理會議重點
    • 在處理敏感資料(合約、成績單、醫療報告)時,改用 Gemma 4,而不是雲端聊天機器人

    2. 多模態輸入:文字 + 圖片 + 音訊

    Gemma 4 支援文字、圖像、音訊輸入,實際上就是:

    • 拍照給它:讀紙本文件、便條紙、白板內容
    • 錄音給它:會議錄音、語音備忘
    • 文字問它:一般對話、寫作、程式輔助

    你可以馬上做的事:

    • 用手機拍下紙本會議紀錄,請它:
    • 先「轉成可複製的文字」
    • 再「整理成條列重點 + 待辦清單」
    • 用錄音把腦中的想法唸出來,讓 Gemma 4 自動整理成筆記或行銷文案草稿

    3. 小型 Agent:自動調用維基 / 地圖等工具

    The Decoder 提到,Gemma 4 內建 agent skills 概念:

    • 模型可以自主判斷,什麼時候要去查維基百科、叫出互動地圖等工具
    • 你只要用自然語言下指令,它會自己拆成步驟去執行

    例如:

    • 「幫我規劃台北 3 天 2 夜行程,包含交通方式和粗略預算。」→ 它會去看地圖、估算時間
    • 「介紹一下奈良的歷史背景,重點就好。」→ 它會查維基,再產出整理版

    你可以馬上做的事:

    • 嘗試用「一句話、比較模糊的旅遊需求」丟給它,看它能拆出幾個步驟
    • 把「查資料 + 整理」這種以前要開十個分頁的流程,改成 Gemma 4 一次完成

    適合誰用?幾個具體場景

    一般使用者:日常生活小助理

    • 學生 / 上班族:整理紙本講義、會議記錄
    • freelancer / 創作者:隨手語音記錄靈感,交給 Gemma 4 轉成文章大綱
    • 常出國的人:旅遊路線規劃、即時翻譯、口說練習
    • 重視隱私的人:不想把醫療、財務資料丟上雲端

    💡 關鍵: 對不想把個資交給雲端的人來說,on-device AI 是「使用體驗接近雲端模型、但風險小很多」的折衷選擇。

    開發者 / 技術使用者

    • 想在 app 或硬體裝置上,塞一個「離線 AI 助理」
    • 想做 IoT / 邊緣裝置(攝影機、嵌入式裝置)的本地推論
    • 想快速試玩 agent 架構,但又不想每次都打雲端 API

    工具與安裝方式總覽

    下面表格整理幾個常見入口,你可以依身份選:

    名稱 核心功能 免費方案 適合誰
    Google AI Edge Gallery App 官方 App,Gemma 4 on-device 聊天、多模態、agent skills App 本身免費 一般使用者、想快速試玩者
    VS Code 外掛(例如官方 Gemma 擴充) 在編輯器裡用 Gemma 4 做輔助 coding/寫作 擴充多為免費 開發者、工程師
    Ollama 桌機本地載入 Gemma 4,命令列 + API 工具免費,自己下載模型 想在 macOS/Linux 簡單跑本地模型者
    LM Studio 圖形介面載入 Gemma 4,支援聊天、API 工具免費,模型自選 想要 GUI、少寫指令的使用者

    官方與模型資源(之後正式釋出 Gemma 4 時可留意):
    – Google AI / Gemma 官方頁面:https://ai.google/
    – 開源模型多會同步到:https://huggingface.co/


    一般使用者篇:最快上手路徑

    1. Android 手機:用官方或第三方 App

    以 Android 為例(流程概念相近):

    1. 到 Google Play 搜尋類似「Google AI Edge」「Gemma」等官方 App(依正式名稱為準)。
    2. 安裝後,開啟 App,選擇 Gemma 4 模型(通常會有不同尺寸)。
    3. 第一次會下載模型檔(幾 GB 起跳,建議 Wi‑Fi + 充電)。
    4. 下載完成後,就可以開始:
    5. 文字聊天
    6. 用相機拍照問問題
    7. 用麥克風說話請它轉文字、翻譯

    建議設定:

    • 找到「隱私 / 資料收集」選項,關掉「分享使用紀錄」「雲端改善」之類的勾選。
    • 如果手機 RAM < 8GB,優先選較小的 Gemma 4 版本(例如 4B 而不是 40B)。

    實戰 workflow 1:整理拍下來的紙本資料

    1. 打開 App → 選擇「拍照問問題」。
    2. 對準講義 / 手寫筆記拍照。
    3. 輸入提示:

      「請先幫我把內容完整打成文字,再整理成 5 點重點,最後列出 3 個可能考試會問的題目。」

    4. 把輸出結果貼到你的筆記軟體(Notion、Obsidian、Google Keep 都可以)。

    實戰 workflow 2:旅遊路線規劃

    1. 在聊天模式輸入:

      「幫我規劃 3 天 2 夜東京自由行,出發地成田機場,預算每天約 1.5 萬日圓,偏好:美食、二手書店、下午不要排太滿。」

    2. 再補充:

      「請用表格列出:時間、區域、景點/餐廳、交通方式、預估費用。」

    3. Gemma 4 會透過地圖工具估時間與交通方式,你只要校正細節即可。

    實戰 workflow 3:即時翻譯與口語練習

    1. 開啟語音模式,設定目標語言(例如英文)。
    2. 對它說:

      「接下來我會用中文說一句話,你幫我:先翻成英文,再幫我修成自然口語,最後給我 2 個替代表達。」

    3. 每次講完一句,就照上述格式回你,等於在做口說家教。

    實戰 workflow 4:離線筆記整理

    1. 沒網路時也可以開 App,直接貼一大段雜亂筆記。
    2. 提示範例:

      「這是我今天的工作雜記,請幫我:1/ 先分成『已完成』『未完成』『待討論』三類;2/ 每類做條列;3/ 幫我列出明天前三件優先處理的事。」

    3. 把結果貼回你的待辦清單工具。

    2. 桌機:VS Code + 本地模型

    如果你常用 VS Code,可以這樣:

    1. 開啟 VS Code → Extensions(擴充套件)。
    2. 搜尋「Gemma」「Google AI」或支援本地模型的外掛(例如 ContinueCline,之後多半會加入 Gemma 4 選項)。
    3. 安裝後,在設定中選擇「本地模型」→ 指定 Gemma 4 款式與路徑。
    4. 之後就能在側邊欄用聊天方式:
    5. 叫它重構程式碼
    6. 產生測試案例
    7. 寫文件、重寫說明

    行動建議:
    選一個你平常會用的環境(手機 App 或 VS Code),先讓它幫你解決「每天都要做一次」的小事(例如整理會議紀錄),用一週感受一下差異。

    💡 關鍵: 不用一次學很多工具,先在日常工作流裡挑一個最常重複的任務讓 Gemma 4 接手,效果最明顯。


    開發者篇:在自己裝置上跑一個邊緣 Agent

    下面用桌機 + 本地框架示範概念,你可以依實作環境調整。

    1. 選擇本地推論框架:Ollama or LM Studio

    Ollama(https://ollama.com/):

    • macOS / Linux / Windows(透過 WSL)
    • 安裝簡單:下載安裝檔 → 打開終端機
    • 一行指令載入模型,例如未來會是:

    bash
    ollama pull gemma4:4b
    ollama run gemma4:4b

    • 也可透過 HTTP API 呼叫(適合做後端 / 小服務)

    LM Studio(https://lmstudio.ai/):

    • 有圖形介面,適合不想敲指令的人
    • 下載安裝 → 搜尋 Gemma 4 → 選模型大小 → Download + Load
    • 內建 API 伺服器,啟用後就能當一般 LLM API 用

    2. 裝置規格與模型大小建議

    • RAM 8GB:建議跑小型 Gemma 4(例如 4B),上下文長度不要設太高
    • RAM 16GB:可嘗試中型版本(例如 12B 級別),適合多輪對話與 coding
    • GPU:有獨顯會更流暢,但 CPU-only 也能跑,只是延遲較高

    實際操作:

    • 先用最小的 Gemma 4 模型跑通流程,再換大一號,避免一開始就撞記憶體不足

    3. 串一個簡單邊緣 Agent:拍照 → 識別 → 查維基 → 語音回覆

    假設你有:

    • 一支手機 / Web 前端可以拍照上傳
    • 一台裝著 Ollama / LM Studio 的本地伺服器
    • 一個簡單的後端(Node.js / Python 都可)

    流程拆解:

    1. 拍照上傳
    2. 前端:用 <input type="file" accept="image/*" capture="environment"> 讓使用者拍照。
    3. 上傳到後端(HTTPS)。

    4. 圖片丟給 Gemma 4 做理解

    5. 後端把圖片編碼成 base64,放到 Gemma 4 的多模態輸入。
    6. 提示範例:
      > 「你會先閱讀圖片內容,幫我找出裡面主要提到的關鍵名詞(人名、地名、專有名詞),輸出為 JSON 陣列。」

    7. 後端根據關鍵字查維基百科

    8. 用公開 Wikipedia API:https://www.mediawiki.org/wiki/API:Main_page/zh

    9. 查第一個關鍵字的摘要,取得一段中文或英文內容。

    10. 再丟回 Gemma 4 要求整理 + 轉成口語回答

    11. 提示範例:
      > 「以下是維基百科內容,請用 10 行內的口語中文,向一般國中生說明這個主題。請避免專有名詞堆疊。」

    12. 文字轉語音(TTS)

    13. 可用系統內建 TTS 或任何本地 TTS 模型

    14. 把結果在手機端播放,完成「拍照 → 聽解說」的 Agent

    隱私注意事項:

    • 圖片、維基內容、Gemma 4 輸入輸出全部留在你自己的伺服器或裝置
    • 只有「查維基」這一步連網,但不需要把原始圖片或個資傳出去
    • 設定後端日誌時,避免把原始圖片和使用者 prompt 長期存檔

    怎麼開始:一步步啟用你的在地端 AI 助理

    如果你是 一般使用者

    1. 在手機上裝一個支援 Gemma 4 的 App(先從官方入口找起)。
    2. 下載一個小型模型,試 3 個情境:整理紙本、旅遊規劃、翻譯練習。
    3. 覺得順手後,把「每天重複的文書/溝通」其中一項固定交給它做。

    如果你是 開發者

    1. 安裝 Ollama 或 LM Studio,載入最小的 Gemma 4 版本。
    2. 用官方 API 或 SDK 跑通「單輪問答 + 圖片理解」。
    3. 再加上維基 / 地圖工具,做出你自己的第一個邊緣 Agent prototype。

    Gemma 4 的重點不是跑分,而是:你現在可以在自己的手機和筆電上,實際把一個「會看圖、會聽、會查資料」的小助理跑起來,而且資料不出門。

    🚀 你現在可以做的事

    • 在手機或平板上安裝支援 Gemma 4 的 App,實測一次「拍照→整理重點」流程
    • 在電腦上裝 Ollama 或 LM Studio,載入最小的 Gemma 4 模型跑通本地對話
    • 挑一個日常重複任務(例如旅遊規劃或會議紀錄),連續一週都交給 Gemma 4 處理,體驗工作流差異
  • AI 詐騙升級:防守錯位比技術更致命

    📌 本文重點

    • 防線重點應從「辨識真假」改為「打斷決策鏈」
    • AI 讓詐騙轉向工業化、代理化的「合成信任攻擊」
    • 監管、產業流程與個人行為都要圍繞高風險決策重新設計
    • 「冷靜、檢查、確認」需被制度化,而非僅是宣導口號

    AI 成為詐騙軍火庫時,真正失效的不是深偽偵測技術,而是我們整個社會把防線放錯了位置——還停留在「看得出真假」的幻覺上。下一波攻擊不是做出更逼真的假臉,而是系統化操控你的決策流程,把每一個人變成可被編程的行為端點。


    從「看得出深偽」到「你的決定被寫好了」

    Synthetic Trust Attacks(合成信任攻擊) 的關鍵,不是生成逼真的假內容,而是工業化製造「可信度」本身。

    根據論文 《Synthetic Trust Attacks: Modeling How Generative AI Manipulates Human Decisions in Social Engineering Fraud》

    • 人類對深偽影像的辨識準確率只有 約 55.5%,幾乎等於丟銅板。
    • 研究設計的 LLM 詐騙代理(scam agents)成功率約 46%,是人類詐騙操作者 18%2–3 倍
    • 這些代理還能有效繞過模型內建的 safety filter。

    💡 關鍵: 當人類辨識深偽的準確率只比隨機好一點時,把防線放在「看出真假」在統計上註定會輸。

    換句話說,我們以為「多看幾眼」、「訓練大家辨識深偽」,就能建立防線,事實上只是把人類丟進一個他註定會輸的賭桌。防禦重心如果停留在「辨識內容真偽」,在統計上就是注定失敗。

    論文提出的 STAM 八階段攻擊模型 很重要的一點是:攻擊者真正下功夫的,是從偵察、建立情境、堆疊信任線索,一路推到受害者的「服從決策」那一刻。所有合成媒體——深偽影像、仿聲電話、多模態對話——只是為了把那個「同意」按鈕推過去。

    這顛覆了我們既有的安全假設:

    • 假設一:只要提升「深偽識別能力」,人就能自保 → 被實證為接近隨機。
    • 假設二:AI 模型內建 safety 機制,可以阻止被拿來詐騙 → 實驗顯示繞過相對容易。

    接下來,真正被重寫的,是產業流程、開發方式與個人防禦習慣。


    產業端:KYC 從「查身份」變成「打斷決策鏈」

    銀行、電信、社群平台與客服外包,是合成信任攻擊的天然靶場,因為它們本質上就是「遠端決策中介」。

    1. 銀行與金融服務:零成本深偽電話銀行時代

    香港 2024 年那起 「假 CFO 影音會議,轉走 2500 萬美元」,就是 STAs 的範本。KYC 和反詐騙系統多半假設:

    • 電話、視訊、聲紋、一次性驗證碼組合起來,足以確認「你是你」。
    • 客戶一旦在「可信管道」中說了「是」,系統就應該尊重。

    在合成信任攻擊下,這兩點通通變得不可靠:聲音、臉、語氣、職稱、背景聲,全都可以合成;唯一難偽造的是「不合理流程本身」。

    因此金融防禦要從:「這通電話是不是假的?」轉成:「這個請求是否有被迫繞過正常流程?

    具體方向:

    • 對「異常大額、異常急迫」的請求,強制多通道、延遲確認(例如:從視訊改成獨立 App 再確認一次,而不是同一通訊道)。
    • 把「冷靜期」制度化:敏感操作要求強制時間緩衝,而不是以「快速服務」為最高指標。

    • 電信與社群平台:從攔截內容到攔截模式

    詐騙電話與簡訊早已工業化,AI 只是把工廠升級為全自動:聲紋克隆、語音代理、個人化腳本,全部可批量生成。未來防詐騙的主戰場不再是內容審查,而是「行為圖譜」:

    • 同一號碼在短時間內大量撥出、高度相似的說詞,卻針對不同族群微調。
    • 社群帳號短時間內加入大量社群、發送高度情緒化的「緊急求助」。

    電信與平台業者,遲早得承擔「高風險互動場景的行為監管責任」,而不是把所有風險推給用戶教育。

    1. 客服外包:深偽客服系統變成攻擊跳板

    很多企業把客服外包給第三方,使用語音機器人、聊天機器人。當 合成客服 被駭或被仿冒時,用戶會在一個「看起來完全正常的客服體驗」中被引導做出錯誤決策——改帳戶、改收款人、交出驗證碼。

    核心改變應該是:

    • 客戶驗證不再只是「你說出幾項個人資料」,而是引入不可被複製的第二通道與行為驗證(例如在既有 App 內的風險提示與多步操作)。
    • 將「詐騙對話腳本」反向商品化:把研究中的 信任線索分類與 17 項事件編碼標準 變成客服監控與訓練的一部分,主動偵測異常說服結構,而不是只看黑名單關鍵字。

    開發者端:幾行程式碼就能搭一個詐騙工作台

    今天任何一個懂點程式的開發者,都能在 「幾行程式碼」 裡組出一個完整的詐騙代理:

    • 前端:語音克隆 + 視訊深偽,即時模仿目標對象;
    • 中台:多模態 LLM 代理,根據受害者語氣、臉部表情調整話術;
    • 後端:自動化外聯工具(批量撥號、寄信、加好友、發訊息)。

    這裡有兩個殘酷事實:

    1. 模型內建 safety filter 完全不夠

    研究顯示,詐騙代理可以透過:

    • Prompt 包裝成「安全測試」「研究用途」,輕易繞過濾器;
    • 在本機或開源模型上直接 fine-tune,跳過商業 API 的政策限制。

    再加上 Lyptus Research 對網路攻擊能力的規模定律分析:

    • 2019 以來,前沿模型在 cyberattack 任務上的能力,大約 每 9.8 個月翻倍,2024 年後加速到 每 5.7 個月翻倍
    • 尖端模型如 GPT-5.3 Codex、Opus 4.6 在部分攻擊任務上的成功率達 50%,而人類專家要花數小時。

    💡 關鍵: 攻擊能力「每幾個月就翻倍」代表風險呈指數成長,只要防線有小縫隙就可能被放大成系統性災難。

    把這種攻擊能力與社交工程詐騙結合,你得到的是 「自動化、可擴散、低門檻」 的詐騙生產線。安全過濾只要漏一點,規模效應就會把「一點」放大成「災難」。

    1. 工具層才是應該被監管的焦點

    如果監管還只盯在「限制模型能力」,很快會被開源模型與灰色市場繞過。真正需要規範的,是:

    • 批量外呼 API、批量簡訊/社群外聯 SDK;
    • 能接入個人資料、財務操作的 代理框架與插件系統
    • 自動化「真人在迴路」假象的深偽客服與銷售系統。

    政策重點應該轉向「高風險用例與渠道」:

    • 對批量外呼、深偽客服、代理自動化聯絡工具,強制 審計、記錄與授權門檻
    • 要求這些系統內建「決策中斷機制」,例如在偵測到高風險行為模式時,強制插入人工審核、冷卻時間與第二通道驗證。

    使用者端:資訊素養已失效,需要「行為 SOP」級防禦

    在 STA 模型下,傳統的「資訊素養教育」——教你看網址、查來源、辨識影像細節——其實只是在 55.5% vs 46% 的賭局裡加碼。人類判斷被證實接近隨機,就不該再被當作主防線。

    💡 關鍵: 當人類在深偽辨識上的表現只略高於隨機時,「資訊素養」只能當輔助,真正防線必須搬到行為流程上。

    研究提出的 「冷靜、檢查、確認」 三步驟,是目前少數有實證支撐的行為級防禦:

    • 冷靜:遇到「緊急、保密、恐嚇、獨家」這類高壓語境時,先暫停,不在同一對話通道做關鍵決定。
    • 檢查:在另一個獨立通道(親自打電話給公司總機、開官方 App,而不是點對方給的連結)確認請求是否合理。
    • 確認:對於任何「轉帳、給驗證碼、交出帳密」的要求,當作 高風險醫療處置 一樣,要求至少兩項獨立證據才執行。

    這套東西必須被制度化,而不是寫在海報上:

    • 公司內規:員工必須遵守「超額交易冷靜期」「換管道複核」流程,違反不是「不小心」,而是違反作業標準。
    • 家庭與學校教育:像教小孩「不要亂點釣魚信」一樣,把「遇到緊急消息先冷靜 5 分鐘」變成反射動作。

    結論:別再談抽象「風險」,開始具體阻斷「決策鏈」

    AI 詐騙真正可怕的地方,不在於假內容做得多真,而在於它把操控人類決策這件事,變成可工程化、可規模化的產業。

    這意味著:

    • 監管焦點必須從「限制模型能力」轉向「規範高風險用例與渠道」:批量外呼、深偽客服、代理外聯工具,需要強制審計與授權門檻。
    • 產業端要重新設計流程,把 KYC 與客戶驗證從「識別真假」轉成「破壞攻擊者設計好的決策節奏」。
    • 開發者要認真看待自己做的不是「酷炫自動化」,而可能是下一代詐騙工廠的生產線,故意忽視威脅等於主動站在攻擊方一邊。
    • 使用者與組織必須把「冷靜、檢查、確認」這種行為 SOP 內建到日常流程,用制度強迫自己慢下來。

    如果我們不在渠道、流程與行為層上重新畫出防線,那麼合成信任攻擊接下來帶來的,就是一個 「零成本深偽電話銀行」 的時代:你的每一個「照流程走」的動作,都有可能是攻擊者早就寫好的腳本。

    現在能做的,不是等法律慢慢跟上,而是從今天開始,把「辨識真假」降級,把「打斷決策鏈」升級為新的安全常識與產品設計原則。

    🚀 你現在可以做的事

    • 盤點自家產品或流程中所有「高金額轉帳、改帳戶、給驗證碼」節點,設計強制冷靜期與第二通道確認。
    • 在團隊或家庭內部,正式寫下並演練一次「冷靜、檢查、確認」SOP,當成固定流程而非口頭提醒。
    • 若你是開發者或管理者,檢視正在使用或計畫導入的批量外呼、客服與代理工具,為高風險操作加上審計與授權門檻。
  • In-Place Test-Time Training 讓模型邊推理邊變強

    📌 本文重點

    • In-Place TTT 讓 LLM 在推理時就地微調
    • 只更新 MLP projection,成本可控又穩定
    • 對小模型與超長 context 任務效果特別明顯

    傳統 「先訓練後部署」 的模型,在上線後面對新 domain、新長文檔,只能靠 prompt/RAG「繞著問題走」,權重本身完全不會變。In-Place Test-Time Training(In-Place TTT)要解決的就是:

    在不重新訓練整個模型、不影響服務穩定性的前提下,讓 LLM 在推理過程中針對當前 context 做「就地微調」,即用即學。

    對開發者的直接好處:

    • 小模型 + 超長 context 的 任務表現大幅提升(paper 裡 0.4B 模型在 128k context 明顯變強)
    • 某些固定 domain(公司內知識庫、特定專案)可以在 session 內 自動做 domain adaptation,不用頻繁 retrain
    • 不需要新架構、不改 attention,只在 MLP projection 上動手腳,工程改動可控

    💡 關鍵: In-Place TTT 用少量 MLP 投影更新,就能在 128k 這種超長 context 下明顯強化 0.4B 等小模型的表現,達到「小模型大任務」的效果


    重點說明

    1. TTT 是什麼?為什麼舊做法不適合 LLM?

    Test-Time Training(TTT) 的想法很簡單:

    1. 推理時,先根據當前輸入做一點訓練(更新一小部分參數 = 快權重 fast weights
    2. 再用更新後的模型做真正的預測

    在 CV/小模型上,常見做法是加一個小 head、對自監督目標(rotation、jigsaw 等)做幾步 gradient update。

    但直接搬到 LLM 會踩坑:

    • 架構不兼容:很多 TTT 方案假設有額外 head 或特定 feature,LLM 一般沒有設計這種 TTT head
    • 計算太貴:如果動 transformer block 的多數權重,長 context 下反向傳播非常重
    • 目標不對齊:TTT 的 loss 不是 next-token prediction,會和原本的語言建模目標衝突,容易越調越壞

    In-Place TTT 的貢獻,就是解決這三個問題:

    • 不改架構,只把 MLP 最終 projection matrix 視為快權重
    • 只在這些 projection 上做反向,成本可控
    • 設計與 自回歸 NTP(next-token prediction)對齊 的訓練目標

    2. 為什麼選 MLP 最終 projection 當快權重?

    以典型 transformer block 的 FFN 為例:

    x -> W1 -> act -> W2 -> 殘差加回
    

    In-Place TTT 把 W2(MLP 最終 projection) 變成可更新快權重,原因:

    1. 局部但影響力大:W2 直接把非線性特徵投回主 hidden space,調這一層可以改變 token 的語義表徵,但不動 attention 結構
    2. 參數量適中:比動整個 block 或 embedding 便宜得多,長 context 反向成本可接受
    3. 穩定性好:不動 attention,有助於保持原模型的「語言能力」,在此之上做局部適配

    實務上的感受是:這種類似 LoRA 但只開在 MLP output projection 的調整方式,對長上下文裡的 pattern 適配非常有效,且容易控制範圍。

    💡 關鍵: 只動 MLP 的最後投影 W2,等於用最小的權重區塊,撬動整個 hidden space 的語義調整,兼顧效果與穩定性


    3. 如何設計與 next-token prediction 對齊的 TTT 目標?

    In-Place TTT 不再另外設計自監督任務,而是直接基於 自回歸 NTP

    • 你有一段長 context:[x1, x2, ..., xT]
    • 原本推理只 forward,loss 不回傳
    • 現在在部分 token 上:
    • 用原模型 logits 做 next-token cross-entropy
    • 但只對 MLP W2 回傳梯度並更新(其他權重 frozen)

    為了讓計算量可控,實作上會:

    • 把長 context 切成多個 blocks(例如每 512 或 1024 tokens)
    • 每個 block:
    • 先 forward 得到 loss
    • 只在該 block 上做一兩步梯度更新
    • 不回頭修正舊 block 的輸出(in-place)

    這樣:

    • 目標和原 pretrain 任務完全一致,不會「學歪」
    • 計算複雜度近似於「多做一輪 forward+backward」,可以和現有 KV cache/長 context 優化一起用

    4. 分塊更新如何兼容長上下文與多請求並行?

    對系統工程師來說,最大問題是:

    長 context + 反向傳播 + 多 request,會不會把 GPU 打爆?

    In-Place TTT 的分塊策略大致如下:

    • Block-wise TTT
    • Example:128k context,每 1k tokens 一塊,共 128 個 block
    • 每個 block:forward、算 loss、只更新 W2 的少量參數
    • 不需要保留整段的中間梯度,只需要當前 block 的 activations
    • 和 KV cache 相容
    • KV cache 還是照原本自回歸生成方式累積
    • TTT 僅對當前 block 的 MLP projection 做 backward,不需要對 KV 做反向
    • 多請求並行
    • 每個 request 自己帶一組「快權重 state」(或 delta)
    • 服務層可以:
      • 把 base 模型權重設為 read-only
      • 為每個 session 存一個 快權重 buffer(例如低秩 delta 或 mask 更新)

    這點和 KV cache 管理框架(vLLM, InfiniGen, H2O 等) 類似:

    • KV cache 管 context-dependent activations
    • 快權重則是 context-dependent 權重偏移

    兩者一起用時要特別小心記憶體分配和 eviction 策略:TTT 的 state 不宜無限制累積。

    💡 關鍵: 把 TTT 的更新設計成 per-session 的小型權重偏移,就能在保持多並發與穩定性的前提下,讓每個請求都「自己學自己」


    實作範例:在推理服務中加一層簡單的 In-Place TTT

    以下用 PyTorch 風格虛擬碼示意,重點是流程與邊界,而非完整訓練程式。

    1. 模型改造:標記可更新的 MLP projection

    class TTTMLP(nn.Module):
        def __init__(self, inner_dim, hidden_dim, enable_ttt=False):
            super().__init__()
            self.w1 = nn.Linear(hidden_dim, inner_dim)
            self.act = nn.GELU()
            self.w2 = nn.Linear(inner_dim, hidden_dim)
    
            # 只在 TTT 模式下允許 w2 被更新
            self.enable_ttt = enable_ttt
            for p in self.w1.parameters():
                p.requires_grad = False
            for p in self.w2.parameters():
                p.requires_grad = enable_ttt
    
        def forward(self, x):
            return self.w2(self.act(self.w1(x)))
    

    在整個 transformer 裡,只需要把原本 MLP 換成 TTTMLP(或只在指定層啟用 enable_ttt)。

    2. 推理 + In-Place TTT loop(單 request)

    def run_with_ttt(model, tokenizer, input_ids,
                     max_new_tokens=128,
                     ttt_block_size=1024,
                     ttt_steps=1,
                     ttt_lr=1e-4):
        """
        model: 已載入的 LLM,除了 MLP.w2 之外都 frozen
        input_ids: 長 context token ids
        """
        device = next(model.parameters()).device
        input_ids = input_ids.to(device)
    
        # 建一個專用 optimizer,只管 MLP.w2
        ttt_params = [p for n, p in model.named_parameters()
                      if p.requires_grad and 'mlp.w2' in n]
        optimizer = torch.optim.AdamW(ttt_params, lr=ttt_lr)
    
        model.eval()
    
        # === 1) 先在 context 上做 block-wise TTT ===
        for start in range(0, input_ids.size(1) - 1, ttt_block_size):
            end = min(start + ttt_block_size, input_ids.size(1) - 1)
            block = input_ids[:, start:end+1]  # [B, L_block+1]
    
            with torch.enable_grad():
                logits = model(block[:, :-1])  # predict next token
                target = block[:, 1:]
                loss = torch.nn.functional.cross_entropy(
                    logits.reshape(-1, logits.size(-1)),
                    target.reshape(-1),
                )
    
                optimizer.zero_grad()
                loss.backward()
                # 只會更新 MLP.w2
                optimizer.step()
    
        # === 2) 使用更新後的模型繼續生成 ===
        generated = model.generate(
            input_ids=input_ids,
            max_new_tokens=max_new_tokens,
            do_sample=False,
            use_cache=True,
        )
        return generated
    

    重點:

    • TTT 階段
    • torch.enable_grad() 打開梯度
    • 只在 context token 上跑 1~數步更新
    • 生成階段
    • 關掉梯度,只用更新後的快權重

    3. 服務層:何時開啟/關閉 TTT?

    可以在 serving config 裡加一個 flag:

    model:
      name: my-ttt-llm
      enable_ttt: true
      ttt_block_size: 1024
      ttt_steps: 1
      ttt_lr: 1e-4
      ttt_max_tokens: 32768   # 超過就不再做 TTT,避免過度漂移
    
    policy:
      enable_ttt_for:
        - domain: "enterprise_qa"
        - domain: "long_doc_summarization"
      disable_ttt_for:
        - domain: "safety_sensitive"
        - domain: "code_generation_prod"
    

    路由層可以依「任務類型」或「租戶設定」決定是否啟用 TTT。


    建議與注意事項

    1. 哪些任務適合/不適合開 TTT?

    適合:

    • Domain adaptation:企業內知識庫 QA、專案文件解讀、特定產品 FAQ
    • 超長 context 理解:法律條文、技術規格書、長期會議紀錄
    • 單 session 可犧牲一點穩定性、換取更高表現 的任務(例如 research 助理)

    不太適合:

    • 安全敏感場景(合規、法務、金融決策):
    • TTT 可能放大 prompt 中的偏見或惡意樣本
    • 多人共用同一快權重的情境
    • 不建議跨 user 共用 TTT state,否則有「資訊污染」風險
    • 需要行為高度穩定可重現 的任務(例如 production codegen、評測 pipeline)

    建議做法:

    • 預設 關閉 TTT,只對少數實驗/內部使用場景逐步開啟
    • 透過 A/B 測 和離線 eval 確認收益和風險

    2. 如何限制更新範圍,避免「越調越壞」?

    可以採幾個防護措施:

    1. 學習率和步數上限
    2. ttt_lr 通常比 finetune 更小(例如 1e-4 或更低)
    3. 每個 block 最多 1~2 步更新即可
    4. Layer 範圍限制
    5. 只開啟 中後段幾層的 MLP.w2,減少對基本語言能力的影響
    6. 正則化 / 參考權重
    7. 在 loss 中加入對 base 權重的 L2 正則
    8. 或採 低秩 delta/adapter(權重不直接改動,易於 reset)
    9. TTL / Reset 策略
    10. TTT state 掛在 session 上,session 結束就丟棄
    11. 長 session 內可定期 reset:例如每處理 64k token reset 一次

    3. 與 RAG、cache、LoRA 等架構的整合與踩坑

    與 RAG:

    • RAG 解決「資料更新」,TTT 解決「怎麼更好地用同一份長 context
    • 組合策略:
    • RAG 提供切好的 chunks
    • In-Place TTT 在讀完多個 chunks 後,讓模型更懂這批文件中常見的 schema/名詞
    • 踩坑:
    • 若檢索結果品質不穩,TTT 可能被噪音「帶偏」,建議在高 confidence 檢索結果上才啟用 TTT

    與 KV cache:

    • 注意 權重更新與 KV cache 一致性
    • 一般做法是 TTT 階段只用來更新權重,不直接用於生成
    • 開始生成時,重新用更新後權重+原 context 做一次 forward 建立 KV(或只從 TTT 後的 block 開始)
    • 若使用 vLLM 類似框架,要確保:
    • 同一 session 的 KV cache 與 TTT 權重版本對齊,避免「舊權重產生的 KV」搭配「新權重」

    與 LoRA / adapters:

    • 一種實務上更穩的做法:
    • base 模型 frozen
    • 安裝一個 LoRA-adapter 只開在 MLP.w2
    • TTT 只更新 LoRA 權重
    • 好處:
    • 快權重是「外掛」,可以 per-session 建立、銷毀
    • 也可以在 A/B 測時方便地比較「有/無 TTT adapter」

    4. 小模型 + 超長 context:何時值得導入?

    In-Place TTT 對 參數較小、context 很長 的組合特別有價值:

    • 小模型在長 context 內本來就容易「記不住 pattern」,TTT 可以在當前 session 內補強
    • 和 LongSpec 等 長 context + speculative decoding 技術搭配:
    • 先用 LongSpec 等提升解碼效率
    • 再用 In-Place TTT 提升長文本任務表現

    可以用以下 heuristics 判斷是否值得導入:

    • 模型 ≤ 7B,context ≥ 32k,而且任務高度依賴長文本理解 → 強烈建議實驗 TTT
    • 模型很大(70B+)且 context 不長(≤ 8k) → TTT 收益相對有限
    • 對 latency/成本極敏感的線上服務 → 可以先在 async 或批次任務(離線總結、分析)試水溫

    總結:In-Place TTT 提供了一個工程上可落地的途徑,讓 LLM 在推理時針對當前長 context 做小幅度、可控的「就地學習」。

    若你正在:

    • 用小模型硬扛超長 context
    • 常常為某個固定 domain 調 prompt/RAG 卻仍覺得不穩

    那麼在 pipeline 中加入 MLP projection 級別的 In-Place TTT,是很值得 A/B 測的一步升級。


    🚀 你現在可以做的事

    • 在現有 LLM 服務中挑選一個長文本任務(如長文總結)實作一版只更新 MLP W2 的 In-Place TTT PoC
    • 針對「開/關 TTT」設計離線與線上 A/B 測試,觀察長 context 任務指標與 latency、成本變化
    • 若已有 RAG pipeline,在高信心檢索場景下試著加入 block-wise TTT,評估對 domain QA 準確率的提升
  • 本地部署 Hermes Agent:打造會成長的專屬 AI 助理

    📌 本文重點

    • Hermes Agent 幫你把零散腳本變成長期共事的本地 AI 助理
    • 核心是模組化 Agent、工具調用與長期記憶設計
    • 今晚就能跑起第一個專職 Agent,逐步接腳本與內部系統

    Hermes Agent 要解決的事很單純:幫你把「一堆零散的 AI 工具 + 腳本」,整理成一個會記憶、會學習、能長期陪你工作的本地 AI 助理。

    專案連結:https://github.com/NousResearch/hermes-agent


    核心功能:它跟一般 Agent 框架哪裡不一樣?

    Hermes Agent 的關鍵,不是「能不能叫 LLM 寫程式」,而是怎麼把它變成一個可以長期共事的 Agent。下面三個核心設計,是你決定要不要採用它時最值得看的一段。

    💡 關鍵: Hermes Agent 的設計重點在「長期共事與成長」,而不是一次性的自動化腳本。

    1. 模組化 Agent:一個框架養多個專職助手

    多數像 LangChain、AutoGen 的用法,是「專案導向」:

    • 你先有一個目標(爬資料、寫報告)
    • 再拼一條 Chain 或一組 Agent 協作

    Hermes Agent 反過來:先有一個固定的人格 / 角色,再依需求加能力

    實際上你可以:

    • 建一個 ResearchAgent:只管幫你找資料、整理重點
    • 一個 CodeAgent:負責修 bug、寫測試
    • 一個 OpsAgent:每天早上拉資料、產報表寄給你

    架構上,它把一個 Agent 拆成幾塊:

    • Profile / Persona:這個 Agent 是誰、擅長什麼
    • Tools:它能調用哪些工具(API、資料庫、shell、Python 腳本…)
    • Memory / Skills:過去學到的東西、可重複使用的任務流程

    你可以先只開一個最簡單的 Agent,之後慢慢加工具,讓它越來越懂你的工作流,而不用每個新專案都重寫一套 Chain。

    可行動:想像一下,你現在桌面上有哪兩個「常做但不想做」的工作,可以各拆成一個 Agent?寫下名字,後面實作會用得到。

    2. 工具調用:把「你會的事」都變成它的工具箱

    Hermes Agent 支援類似 OpenAI function calling 的工具呼叫模式,但更偏向「長期維護」的設計:

    • 工具用 Python 寫一個函式就行
    • 透過結構化的 schema 告訴模型:這個工具是幹嘛的、要什麼參數
    • Agent 會根據任務,自動決定要不要用工具、用哪個工具、多次串聯

    這代表你可以很快把現有腳本變成工具:

    • 讀 Notion / Confluence / Obsidian 資料
    • 呼叫公司內部 REST API
    • 對 PostgreSQL / MySQL / DuckDB 下查詢
    • 跑你原本就有的 ETL 或報表腳本

    與其每次手動開 terminal 跑腳本,你只要跟 Agent 說:「幫我產出本週銷售報表,照上次格式寄給 A、B、C」,它會用工具補完細節。

    可行動:列出你現有最常用的 1–2 個 Python 腳本/內部 API,等等會示範怎麼把其中一個包裝成 Hermes 的工具。

    3. 記憶與長期學習:越用越像你的專屬助理

    Hermes Agent 的 slogan 是「The agent that grows with you」,核心是記憶與技能抽象

    • 短期記憶:一次對話內的上下文、工具使用結果
    • 長期記憶:跨對話保存的重點資訊(你常用的資料來源、專案結構、偏好格式)
    • 技能學習:對常見任務的「解題路徑」可以被抽出來,下次直接套用,而不是每次都重新探索

    實際效果是:

    • 第一次要它寫測試,你可能要講得很細
    • 第三次之後,它知道專案架構、測試風格,提示可以短很多
    • 長期下來,它就像專門懂你的專案的「半自動同事」

    💡 關鍵: 同一個 Agent 會隨使用次數累積記憶與技能,提示成本會隨時間明顯下降。

    可行動:想一個你希望 Agent 逐漸學會的任務,例如「幫我維護這個 Side Project」,後面可以把相關 repo、規則慢慢餵給它,形成長期記憶。


    適合誰用?幾個今晚就能跑起來的場景

    1. 個人知識管理:把本地筆記變成可對話的知識庫

    場景:你用 Obsidian/Notion 存了很多筆記,但查資料時還是要開搜尋、翻一堆頁。

    用 Hermes Agent 可以:

    • 做一個 KnowledgeAgent
    • 工具:讀本地 .md 檔、全文檢索、建立向量索引
    • 任務:
    • 「幫我列出這個月我學過的 LLM 評估方法,附連結」
    • 「整理跟 X 專案相關的 meeting notes,產出一頁總結」

    今晚就能做的最小版本

    • 先不管向量資料庫,只寫一個工具:給定關鍵字,在一個資料夾裡用 grep 或 Python 搜尋文字,回傳找到的段落
    • 讓 Agent 用這個工具找資料 + 組合答案,你得到一個「能全文搜尋你筆記、附整理」的聊天助理

    💡 關鍵: 即使不建向量資料庫,只用全文搜尋工具也能立刻把舊筆記升級成「可對話知識庫」。

    2. 專案協作機器人:懂 repo 結構、會寫測試的小隊友

    場景:你在一個中型 repo 開發功能,最常做的是:

    • 找相關 module
    • 看舊實作怎麼寫
    • 照既有風格補測試

    用 Hermes Agent 可以:

    • DevAgent,給它:
    • 工具:讀檔案、在 repo 內全文搜尋、執行測試、跑 ruffpytest
    • 記憶:專案目錄結構、常用 pattern、測試風格
    • 工作流:
    • 「這個 PR 變更幫我看一遍,列出可能爆的地方」
    • 「幫這個新 function 補上 pytest,照之前我們的 pattern」

    今晚就能做的最小版本

    • 做一個工具:給檔名 + 行號範圍,回傳該段程式碼
    • 一個工具:在 repo 裡 rg 關鍵字
    • 再用 Hermes Agent 替你「問 repo」,比一般 Code Assistant 更懂上下文(因為記憶可以長期保留)

    3. 定時報表與小型自動化:每天幫你跑例行公事

    場景:你每週要手動:

    • 打 API 拉數據
    • 用 pandas 處理
    • 貼到 Google Sheet 或寄 Slack

    用 Hermes Agent 可以:

    • OpsAgent
    • 工具:呼叫內部 API、跑處理腳本、寄 email/Slack webhook
    • 任務:
      • 「每天 9 點幫我跑一次報表 A,失敗時 ping 我」

    今晚就能做的最小版本

    • 先只做一個「手動觸發」的 Agent:
    • 工具:呼叫你現有的報表腳本,回傳路徑或結果
    • 每次要報表時,開 chat 說:「幫我產本週報表」
    • 之後再加排程(crontab / systemd / Airflow 都行)

    怎麼開始:從 clone 到跑起第一個 Agent

    以下以本機開發環境為例(Linux / macOS / WSL 都可)。詳細以官方 Repo 為準:NousResearch/hermes-agent

    步驟一:安裝與啟動最小可用 Agent

    1. Clone 專案

    bash
    git clone https://github.com/NousResearch/hermes-agent.git
    cd hermes-agent

    1. 建立虛擬環境並安裝依賴

    bash
    python -m venv .venv
    source .venv/bin/activate # Windows 改用 .venv\Scripts\activate
    pip install -r requirements.txt

    1. 設定 LLM API Key(先用你有的即可,如 OpenAI / Anthropic / 本地模型)
      新增 .env(或依官方文件的設定方式):

    env
    OPENAI_API_KEY=你的_key

    1. 啟動範例 Agent
      官方通常會附 demo / example,假設有:

    bash
    python examples/simple_agent.py

    終端機應該會出現一個互動提示,你可以直接輸入:

    「幫我總結一下這個資料夾裡 README 的重點」

    可行動:先照 repo README 跑通官方範例,不要一開始就改架構;確定 Agent 能穩定對話後,再進入下一步。

    步驟二:加一個你自己的工具(以讀檔案為例)

    假設你想讓 Agent 讀本地 markdown 筆記,我們新增一個最小工具:

    # tools/read_file.py
    from pydantic import BaseModel
    
    class ReadFileInput(BaseModel):
        path: str
    
    async def read_file_tool(args: ReadFileInput) -> str:
        try:
            with open(args.path, "r", encoding="utf-8") as f:
                return f.read()
        except FileNotFoundError:
            return f"檔案不存在:{args.path}"
    

    再在 Agent 設定裡掛上這個工具(實際寫法依官方 framework 為準):

    from tools.read_file import read_file_tool, ReadFileInput
    
    agent.register_tool(
        name="read_file",
        description="讀取本地文字檔內容,適合用來看筆記或程式碼。",
        func=read_file_tool,
        args_schema=ReadFileInput,
    )
    

    之後你就可以跟 Agent 說:

    「請讀 notes/ai/hermes-agent.md,幫我整理成 5 個 bullet points。」

    可行動:把上面工具改成你需要的腳本,例如呼叫公司 API、或對資料庫下查詢,先做一個,成功後再慢慢擴充。

    步驟三:保存記憶、接內部系統,讓它真正「隨你成長」

    1. 選一個持久化記憶的方式

    2. 簡單:用 SQLite / 本地檔案存對話摘要與關鍵資料

    3. 進階:用向量資料庫(如 Chroma、Qdrant)存 embedding,讓 Agent 能在舊對話裡 retrieval

    4. 接公司內部 API

    5. 為每個核心系統做一個工具(get_user_info, get_order_status…)

    6. 在工具描述裡寫清楚用途,讓模型知道何時該用

    7. 版本控制與演進建議

    8. 把 Agent 設定(persona、工具列表)與「技能腳本」都放進 Git

    9. 每次大改前先開一個 branch,確保舊版 workflow 還能跑
    10. 用 README 記錄:這個 Agent 現在會做哪些事、還有哪些坑

    可行動:先挑一個「你每週一定會做」的任務,為它做一個專門 Agent,並在 README 寫下:

    • 它會用到哪些工具
    • 成功完成任務需要哪些資料
    • 未來想追加哪些能力

    小結:把 Hermes Agent 當成「長期共事的同事」,不要當玩具

    Hermes Agent 的價值,不在於多炫的 Prompt,而在於:

    • 你可以為每個常見任務,做一個專職 Agent
    • 把腳本和內部 API 收進同一個工具箱
    • 用記憶與技能,讓它越來越懂你的工作方式

    從今晚可以做的三件事開始:

    1. clone 專案 + 跑通官方範例
    2. 為一個你已有的 Python 腳本包一個工具
    3. 幫其中一個重複性工作建一個專職 Agent

    只要你願意每週花一點時間「教它」,這個本地部署的 Hermes Agent,會越來越像一個熟悉專案脈絡、能幫你扛瑣事的長期同事。

    🚀 你現在可以做的事

    • 打開 GitHub,clone 下來 NousResearch/hermes-agent,跑通 README 範例
    • 挑一個現有 Python 腳本或內部 API,按照文中範例包成一個 tool
    • 為一個最常做的重複性工作,寫出一個專職 Agent 的 persona 與需要的工具清單
  • 巨頭封鎖中國抄模組:防禦還是反噬創新?

    📌 本文重點

    • 防「抄模型」同時加高巨頭護城河
    • AI 正被納入新冷戰的科技武器庫
    • 指紋與監管合流恐拖慢開源與創新

    OpenAI、GoogleAnthropic 聯手防堵「中國抄模組」,表面是在保護智慧財產,實際上也在把 AI 從「全球公用基礎設施」往「陣營技術」推回去。短期這是合理防禦,長期若缺乏國際規則與透明證據標準,將反噬全球開源、生態多樣性與創新速度。


    一、從產業面看:防「抄模型」,同時加高自家護城河

    這次由 OpenAI、Anthropic、Google 主導的合作,名義上是對抗中國團隊對其模型的未授權複製。在技術上,「抄模型」可以是幾種形式:

    • 直接竊取權重、在本地重新部署
    • 拿到權重後做 微調→漂洗,讓來源變得難以追溯
    • 透過 API 大量查詢,訓練「蒸餾模型」模仿行為

    針對前兩者,新一代 模型指紋技術(如論文中的 AttnDiff)正在改變遊戲規則。AttnDiff 強調:即便你對模型做 PPO/DPO 微調、剪枝、模型融合,在注意力行為層面仍然留下可辨識的「內在路由習慣」,可以用極少的提示抽取指紋,相似度高達 0.98。這一套技術配上律師團,會讓「偷拿開源權重、稍微洗一洗就說是自己家模型」的灰色區域急速收縮。

    💡 關鍵: 相似度高達 0.98 的指紋技術,等於讓「洗權重」這條灰色路線幾乎無所遁形。

    產業權力結構來看,這件事的象徵意義更大:

    1. 閉源巨頭把「可執行的 IP 保護工具」握在自己手上
    2. 越多雲端服務、SDK 接入這類指紋驗證機制,越容易把「合法模型」與「黑箱來源模型」分出兩個世界。
    3. 被標記為「高風險來源」的模型,可能直接被雲端、應用市場下架。

    4. 開源與中小團隊的風險成本被整包加上去

    5. 很多創業團隊是基於 Llama、Qwen 等開源模型做二創,未來一旦巨頭主導的指紋與合規框架變成「事實標準」,
    6. 你不只要搞懂授權條款,還得擔心:某天有人說你在「模型溯源」上相似度可疑,要你舉證清白。

    7. API 模式被抬升為「最乾淨的合規路徑」

    8. 自訓或拿權重自託管,法律與合規責任通通在你身上。
    9. 用巨頭 API,合約寫好「一切合理合法、責任共擔」,反而成為很多公司的風險最小解。

    💡 關鍵: 指紋與溯源一旦成為「事實標準」,會把自訓與自託管變成高風險行為,間接強化「API first」的產業格局。

    這會導致一個微妙結果:「防中國抄模型」的敘事,順便把全球中小玩家更緊地鎖回巨頭雲平台。


    二、從地緣政治看:AI 正在被武器化成新冷戰核心

    同一時間,幾個看似不相關的事件,其實是在同一條線上:

    • 美國五角大樓把 Anthropic 列入國防黑名單,法院目前暫不阻止;理由是「國家安全風險」。
    • 佛州對 OpenAI 啟動刑案調查,把模型風險上升到刑事責任層級。
    • 美國持續收緊對中國的 高階晶片與 EDA 軟體出口管制,再加上台灣國安單位指出,中國正積極挖角台灣半導體人才、技術,企圖繞過封鎖。

    把這些拼起來,你會發現:

    1. AI 公司已經變成「準國安資產」
    2. 被黑名單的不是小型軍工承包商,而是 主流水平的大型模型公司 Anthropic
    3. 這訊號非常直接:頂尖模型本身就是戰略武器,政府有正當性以「國安」為理由介入;不只是出口限制,還包括誰可以跟誰合作、誰可以接政府案。

    4. 「保護先進模型不被中國抄走」很快會被寫進出口與制裁框架

    5. 現在是企業間結盟,下一步就是配合美國商務部、國防部,把「模型指紋+溯源」納入出口管制與制裁證據鏈
      • 指紋相似度高 → 認定為「源自受管制技術」,限制其進入美國市場或雲端基礎設施。
    6. 結果就是全球 AI 地圖被硬切成:「美國陣營模型」、「中國及其友軍模型」,中間地帶愈來愈窄。

    7. 安全事件會被當成政治工具放大

    8. 俄羅斯 APT28 利用 1.8–4 萬台路由器做情報攻擊,已經展示了一個現實:網路基礎設施早就是戰場
    9. 一旦 AI 模型被視為跟路由器、5G、衛星同級的戰略基礎設施,「抄模型」、「中毒攻擊」(如 IoA、FFT 中的模型 poisoning)都很容易被上升為國安事件,順勢合理化更嚴格的技術封鎖。

    💡 關鍵: 當 AI 模型被正式納入國安與出口管制框架,技術競賽就會全面轉化為陣營對抗。

    結果是:AI 不再是全球性一般技術,而是被納入新冷戰的科技武器庫。 技術保護與出口管制不只是保護創新,而是在重畫地緣政治邊界。


    三、從治理與開源生態看:IP、指紋、監管三者合流,可能變成新枷鎖

    防中國「未授權複製」,表面上站在道德高地。但一旦這套框架被寫成政策模板,副作用會很大。

    1. IP 保護 × 模型指紋 × 監管框架,將形成可程式化的「技術邊界」
    2. 有了 AttnDiff 這類工具,政府可以說:
      • 任何在我國使用的大模型,都必須接受指紋檢測,確保不是來源不明的「抄模組」。
    3. 再把最近關於「微調會激活模型對受版權保護書籍的逐字回憶」研究加進來,

      • 你就可以主張:有能力記憶、回吐受版權保護內容的模型,都是潛在侵權工具,必須強管。
    4. 各國會把「防中國」模板本地化 → 實際上是保護自家國產模型

    5. 今天是防中國,明天可能變成:
      • 歐盟保護「歐洲數據主權與開源社群」;
      • 印度保護「國產語言模型」;
      • 其他國家則用來打壓外國雲端服務。
    6. 名義上是防抄襲、防監聽、防國安風險,實際上是數位保護主義的新版本。

    7. 學術與開源研究的「默認罪推定」風險升高

    8. 做模型壓縮、蒸餾、聯邦微調的人,未來很可能遇到:
      • 「請證明你的模型沒有源自受限制權重。」
    9. 而模型 poisoning 研究(像 GRMP 那種高隱蔽攻擊)本來是為了強化安全,但在高度政治化環境中,也可能被解讀為「製造武器」。

    換句話說,防中國抄模型這套論述,極容易被全球各國複製成「我國優先」的技術護城河工具。受影響最大的不是真正的國家級攻擊者,而是缺乏法務與外交資源的研究者與中小型團隊。


    對開發者與使用者的實際建議:活在冷戰化 AI 時代,要怎麼自保?

    在這個「技術保護」與「科技冷戰」交疊的局面裡,如果你是:

    • 模型開發者 / 研究者
    • 盡可能選擇 授權清晰的開源基礎模型(含商用條款),避免「權重來源說不清」。
    • 為自己的模型建立可公開說明的訓練與微調紀錄,必要時可以對外證明清白。
    • 在做安全研究(如蒸餾、poisoning、fingerprinting)時,保留完整實驗紀錄與倫理聲明,降低未來被政治化解讀的空間。

    • 產品團隊 / 創業者

    • 商業上若無強烈自訓理由,API first 會是風險最低路徑:把合規責任部分外包給雲端巨頭。
    • 若一定要自訓或自託管模型,預先預算法務與合規成本,不要假設「開源=無風險」。

    • 終端使用者與企業採購方

    • 在導入 AI 服務時,開始把「模型來源與溯源能力」視為評估項目之一。
    • 避免使用來源不明、無法說清權重責任的「便宜模型」,因為未來的法律與制裁風險可能遠高於你現在省下的成本

    最後要說清楚的判斷是:OpenAI、Google 聯手防中國抄模組,在當前地緣政治下是完全可預期、也一定會發生的防禦行為;但如果我們任由企業結盟與單邊制裁、出口管制來主導規則,而沒有國際層級的透明證據標準與開放協定,AI 將從「全球基礎設施」退化成「陣營技術」。 那不是某個國家的損失,而是整個創新生態的共同折扣。

    🚀 你現在可以做的事

    • 檢查自己或團隊正在使用的模型來源與授權條款,整理一份可對外說明的「權重與數據來源」文檔
    • 若有自訓或微調模型,開始建立與備份完整的訓練流程與實驗紀錄,必要時可作為溯源證據
    • 針對未來要上的新專案,評估一次「API first vs 自訓 / 自託管」的風險與合規成本,調整技術策略
  • LatentAudit:用殘差幾何盯住 RAG 幻覺

    📌 本文重點

    • 光看檢索分數與事後自評難以即時監控幻覺
    • LatentAudit 直接讀殘差流幾何結構估真實度分數
    • 可在 RAG pipeline 中低延遲加入實時 guardrail

    在實務 RAG 專案裡,光靠「檢索品質 + 事後自評/投票」抓幻覺是不夠的
    – 檢索成功 ≠ 回答一定忠於證據(模型還是會自由發揮)
    – 自評 / judge 模型會 吃額外 Token 和延遲,流量大時成本爆炸
    – 多輪對話、串接工具後,哪一步開始幻覺常常完全沒監控

    💡 關鍵: 只靠檢索分數和事後評審,既無法即時阻斷幻覺,又會讓延遲與成本大幅增加。

    LatentAudit 提供另一條路:直接讀取生成模型的 殘差流(residual stream)幾何結構,在推理中測量「模型內部狀態」與檢索證據之間的 馬氏距離,做到:

    • 不需要額外 judge 模型
    • sub-millisecond 延遲、可 16-bit 固定點實作
    • 少量標註就能校準成實用的 真實度分數,在 API 層或 UI 層直接觸發 fallback

    重點說明

    1. 為什麼傳統 RAG 監控做不到「實時 + 便宜」

    實務上的典型做法:

    1. 只看檢索分數:例如 cosine 相似度、BM25 分數
    2. 問題:檢索到對的文獻,但模型回答的細節錯了(over-generalize, mis-attribute)完全抓不到。

    3. 事後自評 / 多模型投票

    4. judge LLM 問「這個回答是否根據檢索到的內容?」
    5. 或讓多個模型生成,再投票 / 聚合。
    6. 問題:

      • 推理路徑變成:檢索 → 回答 → 評審,延遲翻倍以上
      • 成本和吞吐量吃不消,很難在大規模 production 開啟
      • judge 模型本身也會幻覺,還得再校準
    7. log 後離線分析

    8. 用人審 / labeling 分析錯誤 pattern
    9. 問題:無法 實時阻斷 危險輸出(醫療/法律/金融)

    LatentAudit 直接把監控塞進 生成時的 forward pass

    • 白盒讀取中後段 殘差流 activation
    • 與「證據 representation」做幾何對齊度測量
    • 即時計算 距離 → 真實度分數 → 決策(放行 / fallback)

    💡 關鍵: 把監控邏輯塞進 forward pass,能在幾乎零額外延遲下拿到可用的真實度分數。

    2. LatentAudit 的核心做法(殘差幾何 + 馬氏距離)

    架構概念:

    1. 選定幾層殘差流:例如 Llama-3-8B 的 layer 20–30 殘差向量 ( h_l )

    2. 建一個 evidence representation ( e ):

    3. 通常來自:

      • 把所有檢索到的 passages 拼在一起,取 encoder / 第一層 decoder 的 CLS / BOS 向量
      • 或平均檢索 chunks 的 embedding
    4. 在訓練(校準)階段

    5. 收集 (question, evidence, answer) 三元組,並有「忠於證據 / 不忠」標註
    6. 對每個樣本取出中後段殘差流,做 pooling(例如平均或拼接):

      [
      z = P(h_{l_1}, …, h_{l_k})
      ]

    7. 在 latent 空間中估計「忠實」分佈的均值 ( \mu ) 和協方差 ( \Sigma )

    8. 定義馬氏距離規則

    9. 把 residual 表示 ( z ) 投影到 evidence 表示空間,或做簡單線性對齊,最後計算

      [
      d_M(z, e) = (z – W e – b)^T \Sigma^{-1} (z – W e – b)
      ]

    10. 這就是 LatentAudit 的核心:一條二次判別規則(不需要深 judge 模型)

    11. 校準成真實度分數

    12. 用 held-out 集合做 threshold / logistic calibration,得到:

      [
      s_{faith} = \sigma(\alpha \cdot d_M(z,e) + \beta)
      ]

    13. ( s_{faith} ) 越接近 1 表示越「有可能忠於證據」。

    因為只做矩陣乘、向量內積和少量逆協方差運算,
    可以用 16-bit fixed point 實作,延遲在 0.x ms 級別,可進一步配合 Groth16 做可驗證計算(不展開細節)。

    💡 關鍵: 使用 16-bit 固定點與馬氏距離,使得真實度評估可以在 sub-millisecond 延遲下完成。


    如何嵌入既有 RAG pipeline

    你需要:
    可白盒存取的模型(LlamaQwenMistral 等開源或自託管)
    – 在 forward 裡 hook activation,並在生成過程中同步喂入 evidence 表示

    常見 stack:

    • OpenAI compatible API(自託管 vLLM / Ollama 上掛開源模型)
    • 各種向量庫(PGVectorMilvusWeaviateQdrantElastic,…)

    典型 pipeline:

    1. user query → 檢索(向量庫) → 構造 prompt + evidence
    2. 呼叫 自託管模型(非黑盒雲 API)生成
    3. 在生成中,LatentAudit 模塊監控殘差流 → 算馬氏距離 → 輸出真實度分數
    4. API 返回:{ answer, faithfulness_score }
    5. 前端 / Orchestrator 根據 score 做 fallback 策略。

    實作範例

    以下以 vLLM + Llama3 自託管為例,展示核心落地點(偽碼 + Python 範例)。

    1. 在 HF 模型上 hook 殘差層

    from transformers import AutoModelForCausalLM, AutoTokenizer
    import torch
    
    MODEL_NAME = "meta-llama/Meta-Llama-3-8B-Instruct"
    model = AutoModelForCausalLM.from_pretrained(
        MODEL_NAME, torch_dtype=torch.bfloat16, device_map="auto"
    )
    tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)
    
    TARGET_LAYERS = [20, 24, 28]
    residual_acts = []
    
    
    def make_hook(layer_idx):
        def hook(module, input, output):
            # input[0] 通常是 residual stream
            # 只取最後一個 token 的向量,減少開銷
            h = input[0][:, -1, :].detach().to(torch.float32)
            residual_acts.append((layer_idx, h))
        return hook
    
    
    for idx, blk in enumerate(model.model.layers):
        if idx in TARGET_LAYERS:
            blk.register_forward_hook(make_hook(idx))
    

    2. 建立 evidence representation

    假設你已經從向量庫拿到 top-k passages:

    def build_evidence_rep(passages: list[str]):
        text = "\n".join(passages)[:4096]  # 避免太長
        inputs = tokenizer(text, return_tensors="pt").to(model.device)
        with torch.no_grad():
            out = model.model(**inputs, output_hidden_states=True)
        # 用最後一層 hidden state 的 BOS / 第一 token 表示
        e = out.hidden_states[-1][:, 0, :].detach().to(torch.float32)
        return e  # shape: [1, d]
    

    3. 馬氏距離計算 + 校準

    事前你要離線擬合:
    WbΣ^{-1}αβ(可用 sklearn 或手寫)

    線上部分簡化為:

    # 假設以下參數已離線訓練好並載入
    W = torch.load("wa_projection.pt")         # [d_residual, d_e]
    b = torch.load("wa_bias.pt")              # [d_residual]
    Sigma_inv = torch.load("wa_sigma_inv.pt")  # [d_residual, d_residual]
    alpha, beta = torch.load("wa_logistic.pt")
    
    
    def latent_audit_score(evidence_vec, residual_acts):
        # pooling residual: 取指定層平均
        hs = [h for idx, h in residual_acts if idx in TARGET_LAYERS]
        H = torch.stack(hs, dim=1).mean(dim=1)  # [1, d_residual]
    
        # 對 evidence 做線性對齊
        e_proj = (evidence_vec @ W.T) + b  # [1, d_residual]
    
        diff = (H - e_proj)  # [1, d_residual]
        # 馬氏距離
        d_M = (diff @ Sigma_inv @ diff.transpose(0,1))[0,0]
    
        # logistic 校準成 [0,1]
        score = torch.sigmoid(alpha * d_M + beta).item()
        return score
    

    生成時流程:

    def rag_answer_with_faith(query, passages):
        residual_acts.clear()
    
        evidence_vec = build_evidence_rep(passages)  # [1,d]
    
        prompt = build_rag_prompt(query, passages)  # 你的 RAG prompt 模板
        inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
    
        with torch.no_grad():
            out = model.generate(
                **inputs,
                max_new_tokens=256,
                do_sample=False,
            )
    
        answer = tokenizer.decode(out[0][inputs.input_ids.shape[1]:], skip_special_tokens=True)
        score = latent_audit_score(evidence_vec, residual_acts)
    
        return {
            "answer": answer,
            "faithfulness_score": score,
        }
    

    這邊只在 一次 forward + generate 裡多做幾個矩陣運算,延遲增量極小;你可以把結果包成 OpenAI 兼容 API 回傳:

    {
      "id": "chatcmpl-...",
      "object": "chat.completion",
      "choices": [
        {
          "message": {
            "role": "assistant",
            "content": "...",
            "faithfulness_score": 0.82
          }
        }
      ]
    }
    

    前端或 Orchestrator 可以直接讀 faithfulness_score 做決策。

    💡 關鍵: 直接在 API 回傳中加入 faithfulness_score,可讓前端與協調層即時採用不同的 fallback 策略。

    4. Fallback 策略示例(醫療 / 法律 / 客服)

    簡單策略:

    THRESHOLD_WARN = 0.7
    THRESHOLD_BLOCK = 0.4
    
    
    def route_by_faithfulness(result):
        s = result["faithfulness_score"]
    
        if s < THRESHOLD_BLOCK:
            # 高風險:重新檢索 + 明確要求引用 evidence,或升級人工
            return {
                "mode": "escalate",
                "message": "本次回答可信度較低,已轉交人工處理。",
            }
        elif s < THRESHOLD_WARN:
            # 中風險:要求模型引用更多 evidence / 提示使用者核對
            return {
                "mode": "warn",
                "message": "以下回答可能不完全可靠,請以實際條文/文獻為準。",
            }
        else:
            # 正常放行
            return {
                "mode": "ok",
                "message": "",
            }
    

    實際場景:

    • 醫療問答mode == "escalate" 時強制顯示「非醫療建議」,並把 case 丟進人工客服隊列
    • 法律諮詢mode == "warn" 模式時要求模型 列出具體條文/條號 並顯示原文片段
    • 客服查詢:低分時先做 重新檢索(不同索引 or 更寬鬆 query) 再生成一次,若仍低分再轉人工

    多模型 / 多輪對話:
    – 對每輪回答都算一個 faithfulness_score,記錄在對話 state
    – 對 工具返回 / 多模型投票輸出 也可以跑 LatentAudit,看哪個候選與 evidence 更對齊,再做投票加權


    建議與注意事項

    1. 必須白盒存取模型

    • 無法在 OpenAI / Anthropic 純雲端黑盒模型上做(拿不到殘差流)
    • 適合:
    • 自託管 Llama / Qwen / Mistral
    • Ollama / vLLM,但要在本地 wrap core HF 模型 做 hook,而不是只用遠端 HTTP

    2. 殘差層選擇與標準化影響很大

    • 中後段層(例如 60–80% depth)通常信號最好
    • 建議在校準時網格搜尋:
    • 選幾組 layer subset + pooling 策略(最後 token / mean / concat)
    • 對每組分別訓練 WΣ^{-1},選 AUROC / AUPRC 最佳
    • 標準化:
    • 建議對 residual 做 per-dimension z-score 或 whitening,有助於 Σ^{-1} 穩定

    3. 校準集的 domain mismatch 是大坑

    • 如果你用 PubMedQA 上的校準結果直接套到法律問答,誤報 / 漏報會很嚴重
    • 建議:
    • 至少針對你的業務 domain 收集 數百到數千個標註樣本
    • type 要包含:
      • 正確且完全有證據支撐
      • 幻覺 / 瞎掰
      • 部分支持(evidence 裡只有一半說法)

    4. 隱私與合規下收集校準資料

    • 若資料有 PHI / PII:
    • 在內網做標註與訓練,不要把 prompt / evidence / answer 傳出公司
    • 可以只存 殘差向量 + 二元標籤,丟棄原文內容,以降低隱私風險
    • 若需要對外可驗證(尤其在金融 / 公共服務):
    • 考慮用論文中的 16-bit fixed-point 實作 + Groth16,在不洩漏權重/activation 的前提下提供「監控邏輯正確執行」的證明

    5. 與現有評估/監控系統的整合

    • LatentAudit 不是 用來取代離線評估(BLEU, Rouge, factuality benchmark),而是:
    • 補上一層 以模型「內在狀態」為基準的實時 guardrail
    • 建議實務策略:
    • 離線:用 benchmark / 人工評估確認 RAG pipeline 基本可靠
    • 線上:啟用 LatentAudit,只作「低分拋錯/告警」,不要一開始就用來做 aggressive block
    • 每隔一段時間(例如每週)抽樣「被 block / warn 的案例」做人工 review,調整 threshold / 校準

    對你的專案的實際好處
    – 在不引入第二個 LLM 的前提下,把幻覺監控塞進現有 RAG 路徑,几乎不加延遲
    – 增加一個 可量化、可調整的真實度分數,方便 API / UI / workflow 做自動化 fallback
    – 線上問題不再只有「出事後看 log」,而是可以 即時標記高風險回答,甚至直接攔截,特別適合醫療、法律、金融、客服等高風險場景。


    🚀 你現在可以做的事

    • 在現有自託管 Llama / Qwen / Mistral 專案中,加上殘差層 hook 並輸出簡單的 faithfulness_score
    • 針對你的業務 domain 收集一批「忠於證據 / 幻覺 / 部分支持」標註樣本,用來擬合 WΣ^{-1} 與校準參數
    • 在 API 回傳中加入 faithfulness_score,並在前端或 Orchestrator 中實作最簡版本的 warn / block / escalate 策略
  • 用 W-RAC 讓你的 RAG 省錢又好查

    📌 本文重點

    • W-RAC 目標是在不犧牲 RAG 效果下大幅壓低 chunking 成本
    • 先把網頁拆成可定址的小單元,再用 LLM 只做「分組決策」
    • 保留結構化資訊有助於 debug、調優與控制向量庫容量

    一件事先講清楚:W-RAC 的目的,就是在不犧牲 RAG 效果的前提下,把「為了 chunking 花給 LLM 的錢」砍到最低。

    參考論文:Web Retrieval-Aware Chunking (W-RAC)


    為什麼你現在的 chunking 很可能在燒錢

    多數團隊做 RAG,會遇到幾個典型做法:

    • 固定長度切分(例如 500 tokens 一刀)
    • rule-based(照標題、段落、HTML tag 切)
    • 直接丟給 LLM「幫我分合理的 chunk」

    這幾種方法的共通問題:

    1. 重複內容被 embed 很多次
      尤其是網頁側邊欄、導覽列、footer,幾乎每個 chunk 都有一份。

    2. LLM 成本被當 tokenizer 用
      用 LLM 來重寫、分段、產生摘要,等於把整個網站內容吃一遍,token 直接爆掉。

    3. 不好 debug
      一個查詢跑出來一堆 chunk,很難追:

    4. 這個 chunk 為什麼被這樣切?
    5. 是哪個頁面、哪個段落?

    W-RAC 的核心想法:先把網頁拆成結構化「可標號的小單元」,LLM 只負責決定「哪些單元湊成一個 chunk」,完全不改寫原文。

    這樣可以:

    • LLM 只看「結構化 outline + 短內容片段」,token 使用大幅下降
    • chunk 是由原始小單元組合而成,可追蹤來源、可重建原文
    • 重複小單元只存一次,減少向量庫容量

    💡 關鍵: 先抽取可定址小單元,再用 LLM 只做分組規劃,可以在保留 RAG 效果的前提下,把 chunking 相關的 LLM token 成本壓到最低。


    核心功能:W-RAC 在做什麼?

    1. 把網頁拆成「可定址單元」

    具體做法:

    1. 用瀏覽器自動化抓頁面(例如 Playwright)
    2. 保留 DOM 結構,轉成一棵樹:
    3. 節點:標題、段落、表格列、列表項目等
    4. 每個節點給一個 ID(例如 page_123.h2_3.p_2
    5. 把每個節點變成一個「原子單元」,包含:
    6. id
    7. tag(h1/h2/p/li/td…)
    8. text(文字內容)
    9. path(在頁面中的位置)

    你可以實作的步驟:

    pip install playwright beautifulsoup4
    playwright install
    

    用 Playwright 拉 HTML,再用 BeautifulSoup 做 DOM 清洗、節點提取,最後存成 JSON:

    {
      "id": "page_123.h2_3.p_2",
      "tag": "p",
      "path": ["body", "main", "section[2]", "h2", "p[2]"],
      "text": "本方案適用於企業內部知識庫..."
    }
    

    行動:先做「乾淨的節點抽取」,還不要想 embedding 和 LLM,確保每個網頁能拆成穩定、可追蹤的小單元。


    2. 用 LLM 做「分組決策」,而不是改寫文本

    傳統 agent 會:把整頁文字丟進 LLM,請它「改寫 + 切 chunk」。

    W-RAC 則是:

    1. 給 LLM 的不是全文,而是「節點清單 + 結構資訊」:
    2. 節點 ID
    3. 簡短前幾個字(preview)
    4. tag / 標題層級
    5. 要 LLM 回傳的,只是ID 分組規劃,例如:
    [
      {"chunk_id": 1, "node_ids": ["...h2_1", "...h2_1.p_1", "...h2_1.ul_1"]},
      {"chunk_id": 2, "node_ids": ["...h2_2", "...h2_2.p_1"]}
    ]
    

    範例提示詞(可直接改用自己的模型):

    你是一個文件分組器。給你一個網頁節點清單,每個節點有:id、tag、text_preview、heading_level。
    
    目標:
    - 將相關的節點分成多個 chunk
    - 每個 chunk 內容長度約 300–800 字
    - 優先讓同一個小節(同一個 h2/h3 底下)的節點在同一個 chunk
    
    輸出格式:只回傳 JSON 陣列,每個元素包含:
    - chunk_id:整數
    - node_ids:字串陣列
    
    不要產生任何說明文字。
    

    接下來你在程式裡做:

    • 根據 node_ids 把原子單元的 text 串起來
    • 生成真正要 embed 的 chunk 文本

    行動:選一個便宜的小模型(例如本地 LLM 或雲端小模型),先在 1–2 個頁面上跑一輪「ID 分組」,確認輸出格式與 chunk 長度合理,再批次上線。


    3. 保留結構化資訊,提升可觀測性與調優效率

    因為每個 chunk 只是「小單元的組合」:

    • 每個 chunk 知道自己由哪些 node_id 組成
    • 每個 node_id 可以反查 DOM path → 原頁面位置

    你可以做到:

    • 查詢輸出時,在後台顯示:
    • chunk 來源頁面 URL
    • 對應的標題、段落位置
    • 線上觀察「常被命中的 chunk」長什麼樣,是否太長或太短

    簡單的監控策略:

    1. 在 RAG pipeline 中記錄:query / 命中 chunk_id / 來源 page_id
    2. 定期統計:
    3. 哪些頁面 chunk 命中率高但回答不精準 → 調整該頁 chunk 最大長度
    4. 某些 tag(例如 table)被切得太散 → 調整「表格應視為一組」的規則

    行動:把 node_idchunk_id 一起寫入向量庫的 metadata,之後才能在 dashboard 上做查詢與可視化。


    適合誰用:三個典型場景

    1. 公司知識庫 / 文件中心

    情境:

    • 你有 Confluence、Notion、GitBook 或自建 docs 站
    • 想做內部問答助手,但頁面一多,embedding 成本驚人

    W-RAC 的落地方式:

    1. 用 Playwright 把內部 docs 網站轉成 HTML
    2. 用 BeautifulSoup 抓出 h1–h3、段落、列表,做節點抽取
    3. 用小模型做 chunk 分組
    4. 把完成的 chunk 丟進現有向量庫(如 OpenSearch、PGVector、Weaviate)

    效果:

    • 導覽列、側邊欄只存一次,不會每個 chunk 重複
    • 每個問題能對應到具體章節,方便文件 owner 微調內容

    💡 關鍵: 對於大量公司文件,W-RAC 可以避免重複 embed 導覽與樣板內容,顯著降低向量儲存與 embedding 成本。

    2. 官網 FAQ / 產品說明頁

    情境:

    • 產品 FAQ 分散在多個頁面、Accordion、tab 裡
    • 用固定長度切,很容易一個 chunk 內混到不同問題

    W-RAC 做法:

    • 把每個 Q/A 區塊視為一個原子單元
    • LLM 分組時以「一問一答」為最小單位

    好處:

    • 用戶問「退款怎麼算?」時,命中的 chunk 幾乎就是整個退款 FAQ,不會混到完全不相干的條款

    3. 大量公開網頁做 RAG(爬站型應用)

    情境:

    • 你在做垂直搜尋 / 行業資料聚合
    • 動輒幾十萬頁 HTML,要控制成本

    W-RAC 的優點在這裡會放大:

    • LLM 只負責分組計畫,成本可比「全 LLM 分 chunk」少一個數量級(論文的主張)
    • 分組邏輯可重跑:
    • 想換 chunk 長度,只要重新跑 LLM 分組,不必重新爬網

    行動:挑一個實際場景(知識庫、FAQ、或爬站),先對 50–100 個頁面做 W-RAC pipeline,算出:LLM token vs 傳統做法的差異,作為是否全面導入的依據。


    怎麼開始:從技術棧到實作指引

    建議技術棧

    類別 推薦選項 備註
    抓網頁 Playwright / Puppeteer Playwright 對登入、動態頁面支援較好
    HTML 解析 BeautifulSoup / lxml 把 DOM 轉成節點樹、抽取文字與 tag
    分組 LLM 任一小模型(如本地 Qwen/LLama) 只做規劃決策,不改寫文本,成本壓得很低
    向量庫 PGVector / Qdrant / Weaviate 支援 metadata 查詢較重要,以便 debug
    嵌入模型 開源 embedding 或雲端 embedding 固定長度輸入即可,和 W-RAC 本身無強耦合

    行動:先決定你現有的向量庫與 embedding 方案,再把「抓網頁 + W-RAC 分組」當作前處理模組接進去。


    最快上手路徑(簡化版流程)

    1. 抓一頁 HTML
    2. 用 Playwright:

    “`python
    from playwright.sync_api import sync_playwright

    with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto(“https://your-site.com/faq”)
    html = page.content()
    browser.close()
    “`

    1. 用 BeautifulSoup 拆節點
    2. h1–h3pli、table row 都變成節點
    3. 幫每個節點生成 idpath

    4. 呼叫 LLM 做分組

    5. 使用前面提供的提示詞
    6. 控制每次輸入的節點數量(例如 100–200 個),避免 context 太大

    7. 依照 node_id 組 chunk

    8. 按分組結果串 text,加入 metadata(node_idspage_url

    9. 寫入向量庫 + 接到現有 RAG

    10. 查詢時流程不變,只是每個 chunk 背後多了完整來源資訊

    線上觀察 chunk 品質與調優策略

    觀察重點:

    1. 回答不準時,回頭看 chunk
    2. 是否同一個 chunk 裡混了太多主題?
    3. 是否重要上下文被切開?
    4. 調整策略
    5. 提示詞裡明確告訴 LLM:
      • 表格應盡量保持在同一 chunk
      • 同一個 h2 底下不要分太多 chunk
    6. 調整每個 chunk 的目標字數(例如從 800 改成 500)

    行動:在你的 RAG 後台加一個「檢視來源 chunk」按鈕,點下去就顯示該 chunk 的 node 列表與原頁面位置,方便你和 PM / 內容 owner 一起 review。


    小結:把 LLM 用在刀口上

    W-RAC 的重點不是多厲害,而是很務實:

    • LLM 只做「分組規劃」這種高價值決策
    • 文本本身盡量保持原樣,避免幻覺與重寫成本
    • 一旦你有了「結構化可定址單元」,後面調優都變簡單

    如果你正在為 RAG 成本與效果卡關,先不要換模型,先把 chunking 換成類似 W-RAC 的流程,很可能就能省下一大筆 embedding/LLM 費用,還順便讓系統更好 debug。

    🚀 你現在可以做的事

    • 選一個實際頁面,用 Playwright + BeautifulSoup 做出「乾淨節點抽取」JSON
    • 用一個便宜的小模型,照文中提示詞跑一輪「ID 分組」,實際組出 chunk 並寫入向量庫
    • 在你的 RAG 後台加上 chunk_id / node_id 的 metadata 顯示與檢視來源 chunk 按鈕,開始觀察與調整 chunk 策略
  • Compiled AI:把提示變成可審計工作流

    📌 本文重點

    • 用 LLM 在編譯階段產生狹義程式碼,執行期不再依賴 LLM
    • 業務邏輯可測試、可審計,安全面積與成本大幅下降
    • 特別適合高要求、高流量且規則穩定的企業級工作流

    在多數專案裡,我們會每個請求都叫一次模型,把非結構化的 prompt 丟給 LLM,期待它「大致照規則」行事。問題是:結果不穩、難回溯、成本高,還容易被 prompt injection 玩壞。Compiled AI 要解的是這個痛點:

    把原本寫在 prompt 里的業務邏輯,在編譯階段用 LLM 產生狹義程式碼,透過型別檢查、靜態分析與測試驗收,一旦通過就當成普通程式部署,執行期不再依賴 LLM

    對開發者的直接好處:

    • 結果可預測且可審計:輸出由 deterministic code 決定,不是每次抽樣
    • 安全面縮小:執行期不再接受任意自然語言指令
    • 成本與延遲大幅下降:大量交易共用同一份已編譯邏輯,token 成本被攤薄

    💡 關鍵: Compiled AI 把「每次都叫 LLM」改成「先編譯一次,再重複執行」,大幅提升穩定性並攤平成本。


    重點說明

    1. 架構:LLM 只在「編譯階段」出現

    典型 Compiled AI 架構可以拆成三層:

    1. 模板/SDK 層(受控框架)
    2. 你先定義好已驗證的 workflow 模板與 SDK,例如:HTTP 呼叫、DB 查詢、RAG 檢索、權限檢查等
    3. LLM 只能在模板內部空洞生成狹義業務邏輯函式,例如 select_customer_segment()build_rag_query()

    4. 編譯管線(有 LLM)

    5. Step 1 – Prompt 設計:描述任務、提供 API 規格 & 範例,要求輸出符合特定語言/框架(如 TypeScript + 自家 SDK)
    6. Step 2 – 產生 code artifact:LLM 產生一份或多份候選程式碼
    7. Step 3 – 謝與測試:型別檢查、靜態分析、單元測試/合約測試,不過關就自動 loop 回 LLM 要求修正
    8. Step 4 – 人工審核 + 簽章(視風險):例如醫療或金流流程

    9. 執行期(無 LLM)

    10. 線上請求只執行已編譯出的 code artifact,全程 deterministic,可以完整 log & replay

    核心概念:限制 LLM 的自由度,換取可測試、可版本控管的業務邏輯程式碼


    2. 工作流設計:把一個傳統 RAG / Agent 重構成 Compiled AI

    以一個典型 RAG QA 流程為例:

    使用者問問題 → LLM 根據 prompt 決定如何搜尋 → 呼叫向量庫 → LLM 基於檢索結果生成答案

    在傳統設計中,LLM 負責檢索策略 + 答案生成,兩段都高度隨機。重構成 Compiled AI,可以這樣拆:

    1. 編譯階段
    2. 用 LLM 生成一個狹義函式:build_search_plan(question: string) => SearchPlan,被嵌在已驗證的 RAG 模板中
    3. SearchPlan 僅包含:要查哪個 index、使用哪些 filter、topK、是否需要 fallback 等
    4. 再用 LLM 生成:synthesize_answer(question, contexts) => string,但這個函式需遵守強約束(例如:不可編造、必須引用 context id)

    5. 執行階段

    6. 每次 QA 時:
      • 用 deterministic code 呼叫 build_search_plan() → 打 DB / 向量庫
      • 把檢索到的 contexts 丟給 synthesize_answer()(也是普通函式)
    7. 整個過程再也不直接丟自然語言給 LLM,所有 decision path 都是可測試、可覆盤的程式碼

    8. 版本控管與灰度發布

    9. 每次重新編譯:產出新版本如 rag_workflow_v3.ts
    10. 用 Git tag & CI pipeline 把版本與測試報告綁在一起
    11. 線上:用 routing 或 feature flag 灰度流量,對比 v2 / v3 的成功率、平均延遲、查詢成本

    3. 工程實務:與「每請求叫一次模型」的差異

    基於現有研究與業界實測,Compiled AI 在幾個維度的典型差異:

    • 可靠性(確定性 vs 隨機)
    • 傳統:每次請求都用 sampling(temperature > 0),同一輸入結果可能不同
    • Compiled AI:執行期只跑 deterministic code + DB/RAG,相同輸入必然同樣輸出

    • 安全

    • 傳統:使用者輸入直接進 prompt,prompt injection 面積很大
    • Compiled AI:執行期輸入只餵進已定義的函式參數(string / enum / id 等),無法直接改變控制流

    • 成本與延遲

    • 編譯階段比較貴,但只做一次,之後可在大量請求上攤平
    • 實務上常見:十幾次交易後就開始比傳統架構便宜,長期 token 使用量可降數十倍

    💡 關鍵: 只要請求次數夠多,執行期省下的 token 成本與延遲,會很快抵消一次性的編譯開銷。


    實作範例

    以下用 TypeScript + 假想 SDK 示範一個簡化版 pipeline。

    1. 已驗證模板/SDK

    // sdk.ts - 由你維護的安全 SDK
    
    export type SearchPlan = {
      index: 'faq' | 'policy' | 'logs';
      topK: number;
      filters?: Record<string, string>;
    };
    
    export async function runRagWorkflow(
      question: string,
      buildSearchPlan: (q: string) => SearchPlan,
      synthesizeAnswer: (q: string, ctxs: string[]) => string
    ): Promise<string> {
      const plan = buildSearchPlan(question);
      const contexts = await vectorSearch(plan.index, question, plan.topK, plan.filters);
      return synthesizeAnswer(question, contexts);
    }
    
    async function vectorSearch(
      index: string,
      query: string,
      topK: number,
      filters?: Record<string, string>
    ): Promise<string[]> {
      // 已驗證的檢索實作
      /* ... */
      return [];
    }
    

    2. LLM 產生的狹義業務邏輯(編譯產物)

    在編譯階段,你用一個 prompt 要求模型只實作兩個函式:

    // generated_v3.ts - 由 LLM 產生,但要通過型別檢查與測試
    
    import { SearchPlan } from './sdk';
    
    export function buildSearchPlan(question: string): SearchPlan {
      const q = question.toLowerCase();
    
      if (q.includes('退款') || q.includes('billing') || q.includes('invoice')) {
        return { index: 'policy', topK: 5, filters: { category: 'refund' } };
      }
    
      if (q.includes('錯誤') || q.includes('error code')) {
        return { index: 'logs', topK: 10 };
      }
    
      return { index: 'faq', topK: 8 };
    }
    
    export function synthesizeAnswer(question: string, contexts: string[]): string {
      // 嚴格規定:
      // 1. 不得回答與 contexts 無關內容
      // 2. 必須在文末列出引用的 context 索引
      const summary = summarizeWithRules(question, contexts); // 你事先實作好的工具
      const citations = contexts
        .map((_, i) => `[#${i + 1}]`)
        .join(' ');
    
      return `${summary}\n\n引用來源:${citations}`;
    }
    

    3. 編譯 pipeline(CI 裡跑)

    // compile.ts - 只在 CI / 開發環境執行
    
    import { z } from 'zod';
    import { callLLM } from './llm_client';
    import { execSync } from 'child_process';
    
    const schema = z.object({
      code: z.string(),
    });
    
    async function generateCode() {
      const prompt = `
    你是一個 TypeScript AI,請只輸出一個檔案內容,實作:
    - export function buildSearchPlan(question: string): SearchPlan
    - export function synthesizeAnswer(question: string, contexts: string[]): string
    
    必須符合已存在的型別定義:
    - SearchPlan { index: 'faq' | 'policy' | 'logs'; topK: number; filters?: Record<string, string> }
    
    禁止:
    - 呼叫任何未在註解中允許的函式
    - 使用 eval / new Function
    - 動態匯入
      `;
    
      const raw = await callLLM({
        model: '**gpt-4.1**',
        temperature: 0,
        response_format: { type: 'json_schema', schema },
        messages: [{ role: 'user', content: prompt }],
      });
    
      const { code } = schema.parse(JSON.parse(raw));
      return code;
    }
    
    async function main() {
      const code = await generateCode();
      require('fs').writeFileSync('generated_v3.ts', code, 'utf8');
    
      // 1) 型別檢查
      execSync('npx tsc --noEmit', { stdio: 'inherit' });
    
      // 2) 靜態分析
      execSync('npx eslint generated_v3.ts', { stdio: 'inherit' });
    
      // 3) 測試
      execSync('npm test -- generated_v3.test.ts', { stdio: 'inherit' });
    }
    
    main().catch((err) => {
      console.error(err);
      process.exit(1);
    });
    

    搭配 CI/CD:

    • CI:觸發 compile.ts → 產出 generated_v3.ts → 跑測試 → 產出報表
    • CD:若通過,打 tag rag_workflow_v3,並更新配置讓 5% 流量導到 v3;監控成功率、latency、成本指標再逐步擴大

    💡 關鍵: 把 LLM 產物納入 CI/CD(型別檢查、靜態分析、測試與灰度發佈),就能像管理普通程式碼一樣管理 AI 邏輯。


    建議與注意事項

    1. 業務規則變更頻率

    Compiled AI 適合:

    • 規則相對穩定、但正確性要求高的流程(客服 QA、金融函數呼叫、醫療文件處理)

    不適合:

    • 每天都在改規則、或依賴即時實驗的場景,因為每次改都要走「重新編譯 + 測試」流程
    • 高度探索型、open-ended 任務(創作、策略 brainstorm、UX 研究等)

    實務建議:

    • 把流程拆成兩層:核心決策邏輯用 Compiled AI,外層的探索與創意仍然用即時 LLM

    2. 測試覆蓋不足 = 把錯誤「編進系統」

    Compiled AI 的風險是:一旦編譯出的邏輯有 bug,它會一直穩定地錯

    必做:

    • 為生成函式設計合約測試:同一輸入 → 必須產出指定的 SearchPlan / 函式呼叫序列
    • 對關鍵場景建立 golden QA 測試集,每次編譯都跑完整 regression
    • 對模型產物加上防呆檢查(如:topK 不可大於 50,index 只能是白名單)

    3. 安全與最小權限

    • 模板 / SDK 層要實施 最小權限
    • 不給生成函式直接打 DB 連線,只能呼叫封裝好的 queryCustomerById(id) 等高階 API
    • 不允許檔案寫入、外網 request 等敏感操作
    • 透過靜態分析檢查:是否有 eval、動態 import、直接執行 shell 等 pattern

    4. 成本模型與「何時值得編譯」

    可以用簡單估算:

    • 編譯一次成本:C_compile(幾萬 token)
    • 傳統架構每次請求成本:C_online
    • Compiled AI 每次請求成本:C_compiled(通常 ≪ C_online

    只要請求數 N 滿足:

    C_compile + N * C_compiled < N * C_online

    就值得改成 Compiled AI。研究與實務常見:十幾到幾十次請求後就開始回本,高流量業務會很划算。

    5. 與現有專案整合的落地步驟

    1. 先挑一個穩定且高流量的子流程(例如:FAQ RAG 檢索策略、金融 function calling 的參數整理)
    2. 為它抽象出一個窄介面函式(例如 buildSearchPlanprepareFunctionCallParams
    3. 建立 minimal 的編譯 pipeline(LLM → 生成 code → tsc + 測試)
    4. 先 offline 對比:新老流程在測試集上的正確率 / 成本
    5. 小流量灰度上線,配合 metrics 監控,逐步拓展到更多流程

    結論:Compiled AI 的核心不是「用 LLM 寫程式」,而是把 prompt 中模糊的規則,轉成可測試、可簽章、可審計的程式碼工件。對需要穩定性、安全與成本控制的企業工作流,特別是 RAG、function calling、金融與醫療場景,是非常值得實驗的架構升級方向。

    🚀 你現在可以做的事

    • 在現有系統中挑一段高流量、規則穩定的 RAG 或 function calling 流程,先抽象出一個窄介面函式如 buildSearchPlan
    • 建一個最小可行的編譯 pipeline:用 LLM 產生 TypeScript 函式 → 跑 tsc + 單元/合約測試 → 輸出 generated_v1.ts
    • 用 feature flag 灰度導入新流程,監控正確率、延遲與 token 成本,評估轉為 Compiled AI 的回本點