標籤: DeepSeek

  • 中國押注開放權重,逼美國改寫AI遊戲規則

    中國押注開放權重,逼美國改寫AI遊戲規則

    📌 本文重點

    • 中國將 open-weight 上升為國家級產業戰略
    • 美國封閉模式正被拖入「開源治理戰」
    • 開放權重同時帶來創新紅利與地緣政治風險

    中國選擇在大型模型上全面押注開放權重(open-weight),它不是技術細節,而是地緣政治級別的產業賭注:AI 權力版圖正在從「誰模型最強」,轉向「誰能用開放,組出最大、最靈活的生態系統」。如果美國只用制裁與封鎖去回應,中國的先發優勢將被放大,真正被消耗的會是全球開源社群,而非中國模型本身。


    一、中國的 open-weight:從技術選型變成產業戰略

    先把事實攤開來看:

    • Moonshot 的 Kimi K3阿里巴巴的 QwenDeepSeek v4 等一線中國模型,幾乎清一色走向權重開放、成本壓低、API 與本地部署並行的路線。The Verge 的測試甚至指出,Kimi K3 在部分基準上已逼近甚至超過多數美系商業模型,只次於 OpenAI
    • 在 Reddit 的 r/LocalLLaMA 社群,中國模型已經不是「便宜替代品」,而是在與 antirez 的 dwarfstar4 等歐美開源明星並列,成為推動玩家買高階本地算力的核心驅動。DeepSeek v4 正式版開放權重,被預期有機會取代 GLM 5.2 成為新一代本地標竿。
    • 連美國自身也在追 open-weight,如 975B 參數多模態模型 Inkling,刻意標榜「Open weights 975B multimodal model built for fine-tuning」,這是一種被中國策略逼出來的跟牌,而非自發選擇。

    💡 關鍵: 中國以近似頂尖的性能與極低成本,透過開放權重迅速擴大全球開發者生態與影響力。

    這些點拼在一起,形成一個清晰結構:

    1. 對開發者:開放權重用極低邊際成本,提供近似商業 SOTA 的能力,直接鎖死了「只有大公司玩得起強模型」的敘事。中國的策略是把算力集中在訓練端,然後用開放權重把推理端的創新外包給全球社群。

    2. 對中國企業與政府:開放權重在法律與心理上,降低了「使用國產模型」的阻力——你用的是全球可審視、可本地部署的權重,不再是封閉黑箱,這對信任建構與國產替代非常關鍵。

    3. 對全球市場:中國 open-weight 模型在性能與價格上形成穩定優勢,讓「以封閉 API 賣訂閱」的美系模式失去壟斷地位,迫使 OpenAI 等公司把遊戲轉向政策與治理戰場,而不只是技術迭代。

    關鍵結論:中國已把 open-weight 從「工程師文化」升級為「國家級產業策略」,用權重開放重塑了 AI 創新與商業化的分工。


    二、美國的封閉模式,正在被拖入「開源治理戰」

    美系巨頭走的是另一條路:封閉權重 + API 控制 + 嚴格使用政策。這在技術早期有助於安全與商業化,但中國 open-weight 的崛起正在把這套模式轉化成政治弱點。

    幾個信號很明顯:

    • TechCrunch 指出,OpenAI 對中國製造的 open-weight LLM 顯得格外焦慮,原因不只是市場競爭,而是開放權重讓任何人都能在本地做「不受 OpenAI 政策約束」的微調與應用。
    • MIT Technology Review 報導,美國 AI 圈因中國模型撕裂:David SacksAnthropic 模型罵成「lobotomized」與「woke」,Pentagon 官員 Emil Michael 公開嗆 OpenAI。這些衝突表面是政治立場,實質是:誰來主導美國對外國開源模型的治理?是商業公司,還是政府?
    • The Decoder 與 Reddit 爆料顯示,前川普政府正在醞釀對中國模型的「慢動作禁令」,包括:
    • 把中國 AI 實驗室列入制裁名單;
    • 對使用外國 open-weight 的美國企業施加安全責任;
    • 更進一步,對「外國開源模型」施行事實上的使用限制。

    這裡的核心變化是:

    技術競爭正在升級為「開源治理戰」:不是誰的模型跑得快,而是誰能在不摧毀開源創新的前提下,管控安全與地緣政治風險。

    如果美國政策圈選擇「一刀切式封鎖外國 open-weight」,會出現幾個反效果:

    1. 傷到自己開源社群:在 r/LocalLLaMA、Hugging Face 等平台,實務上大量最佳工具已混合使用中國、歐洲與美國模型。一旦管制外國權重,美國本地開源玩家被迫退回性能較差或成本較高的選項,競爭力直接下降

    2. 強化中國的「開源自由」敘事:當美國在封鎖,中國可以對全球開發者說:「來用我們的模型,我們不會因為你的政治立場封你的帳。」 在某些地區,這種敘事比純技術指標更有穿透力。

    3. 推動技術遷移與法律套利:封鎖只會促使更多開發者轉移到非美國司法管轄的節點,在歐洲、中東、東南亞等地部署中國 open-weight 模型,美國反而在全球治理對話中失去話語權。

    換句話說,若美國只拿「封閉與禁令」當答案,中國就能把 open-weight 的技術優勢,轉換成制度與敘事優勢。


    三、開放權重的雙面刃:創新紅利 vs 安全與地緣政治風險

    open-weight 並非完美解,它是一把極鋒利的雙面刃。

    1. 對開發者與中小企業:爆炸性的紅利,也是真實的風險

    紅利在於:

    • 成本結構改寫:中小企業可以直接拉 KimiDeepSeekInkling 的權重,做專屬微調,本地部署。模型本身幾乎零成本,付出的主要是算力與人才,這對 SaaS 新創是革命性的降門檻。
    • 產品形态自由度:你可以做完全離線、邊緣設備上的 AI;可以做極度垂直的行業模型;可以在法律允許範圍內,調整模型的「性格」與價值偏好。這些都是封閉 API 模式很難提供的。

    風險同樣巨大:

    • 安全與合規責任下移:封閉模型的「不給你做危險事」是由 OpenAI、Anthropic 提供的;open-weight 反過來,所有安全、偏誤、版權與資料保護責任都落在使用者身上
    • 地緣政治外溢:使用中國權重,會不會被未來制裁?會不會被要求做供應鏈切換?你不是只在選技術,而是在替未來的政治風險下注。

    開發者不能再只問「哪個模型跑分高」,而要問:「在我所在司法與產業環境下,哪些開放權重的法律、供應鏈與聲譽風險可以被接受?」

    💡 關鍵: 對企業與開發者而言,模型選型已從「技術比較題」升級為「政治與合規風險管理題」。

    2. 對美國與盟友:封鎖是最懶、也最昂貴的選項

    從政策視角來看,完全封鎖中國 open-weight是最直觀但最昂貴的路線:

    • 它會直接打擊自己開源社群的活力和技術層級
    • 會把美國推向「只剩商業封閉巨頭」的結構,削弱國內的技術民主化;
    • 更嚴重的是,會讓全球對開源的信任斷裂——大家開始預期,模型權重可以因為政治而被突然禁止,開源的長期承諾被削弱。

    更聰明的做法是:

    • 針對具體風險(如軍事用途、關鍵基礎設施滲透)做精準場景限制,而不是模型來源一刀切;
    • 強化透明度與可審計要求,讓使用外國權重的系統必須揭露模型來源與微調數據;
    • 對自家開源社群給予安全工具與法律支援,讓開發者能在不被政治與律師嚇退的情況下,持續使用與改造 open-weight 模型。

    3. 對一般使用者:模型來源將像「產地標示」,地理封鎖成常態

    對普通用戶而言,真正的變化會是:

    • 你使用的 AI 服務,會開始明示「模型產地」——中國、美國、歐洲或是混合體;
    • 某些模型只在特定區域可用(例如中國模型在美國被事實禁用,美系模型在中國被政策排除),AI 服務地理封鎖成為日常;
    • 不同來源模型在新聞、政治、價值議題上的表現,會出現三套甚至四套敘事體系,用戶的資訊世界被模型來源悄悄切割。

    這不是科幻,而是已經在發生的趨勢,只是尚未被一般用戶系統性理解。


    結語:真正的勝負在治理,而不是跑分

    從產業結構看,中國在 open-weight 上已建立先發優勢:模型性能逼近頂尖、成本極低、生態系統快速滾動。美國若只以制裁、禁令回應,最後可能得到一個尷尬局面——中國模型持續在全球跑,美國開源社群被自己政策掐住喉嚨。

    對不同角色,我的具體判斷與建議是:

    • 開發者與中小企業:把「模型來源與治理風險」正式納入技術選型流程。建立多來源架構:同時熟悉至少一套中國 open-weight、一套美國或歐洲模型,避免任何一方政策變動讓你整個產品斷線。
    • 政策制定者與大型企業:放棄「封鎖即等於安全」的直覺,轉向場景導向、透明導向、責任分層的治理框架,保留開源創新的空間。同時,避免把開源社群當作附帶犧牲品。
    • 一般使用者:開始在意你使用的 AI 服務背後「模型產地與治理模式」。當你選擇某個國家主導的模型,你也在選擇一套資訊與價值框架。

    AI 產業下一階段的關鍵分歧,不再只是模型好壞,而是誰能在「開放帶來的創新」與「安全與地緣政治風險」之間,設計出更聰明的治理系統。這場戰爭的真正變量,是全球開源社群,而不是任何一個總統或單一公司。

    🚀 你現在可以做的事

    • 盤點你或團隊正在使用的模型來源,標註中國、美國、歐洲等並評估各自風險
    • 在技術選型流程中加入「治理與合規」評分欄位,將 open-weight 的法律與政治風險量化
    • 挑選一個中國 open-weight 模型與一個歐美開源模型,實作多來源備援架構以分散政策風險
  • Haystack 實戰:一天做出公司 AI 助理

    Haystack 實戰:一天做出公司 AI 助理

    📌 本文重點

    • Haystack 把 RAG + Agent 流程統一成框架
    • 少寫檔案處理與檢索 script,快速做公司助理
    • 用範本與工具擴展成可連公司系統的 Agent
    • 一天內跑出第一個可給同事用的 QA 助理

    用 Haystack,你可以少寫一堆 RAG script,把「文件檢索、LLM 調用、Agent 流程管理」統一交給一個開源框架處理。

    官方網站:https://haystack.deepset.ai/


    為什麼不要再自己拼 RAG script?

    多數人做公司內部 AI 助理,走的流程都是:

    1. 自己寫檔案讀取、切 chunk、丟向量庫
    2. 自己串 LLM API,處理 history、retrieval 邏輯
    3. 想加一點工具(查 DB、叫 REST API)又多一支 script

    問題是:
    – 每新增一個資料源或工具,都要重構流程
    – 很難部署成穩定 API 給同事用

    Haystack 的定位很直接:把 RAG + Agent 的骨架先幫你做好,你只需要選模型、選向量庫、加自己工具,就能變成一個可上線的 AI 助理。

    💡 關鍵: 用框架統一 RAG + Agent 流程,可以讓你只專注在選模型、選向量庫與設計工具,少掉大量重複的整合工作。


    核心功能:你可以少寫的三件事

    1. 文件管線:多資料源 + 多向量庫

    Haystack 幫你處理「資料→文件→向量」的整條管線:

    你可以:
    – 選擇資料源:檔案夾、PDF、Markdown、Confluence、Notion 等
    – 選擇向量庫:FAISSWeaviateQdrantElasticsearch
    – 用同一套 API 建 index、更新文件,避免 N 種自訂 script

    實際行動:先在本地建一個簡單文件管線

    pip install haystack-ai
    

    範例(Python):

    from haystack import Pipeline
    from haystack.document_stores import FAISSDocumentStore
    from haystack.nodes import PDFToTextConverter, TextSplitter, EmbeddingRetriever
    
    # 建立向量庫
    doc_store = FAISSDocumentStore(faiss_index_factory_str="Flat")
    
    # 文件處理節點
    converter = PDFToTextConverter()
    splitter = TextSplitter(chunk_size=500, chunk_overlap=50)
    retriever = EmbeddingRetriever(document_store=doc_store, embedding_model="sentence-transformers/all-MiniLM-L6-v2")
    
    indexing = Pipeline()
    indexing.add_node(converter, name="converter", inputs=["File"])
    indexing.add_node(splitter, name="splitter", inputs=["converter"])
    indexing.add_node(retriever, name="retriever", inputs=["splitter"])
    
    indexing.run({"File": {"paths": ["./docs/handbook.pdf"]}})
    

    跑完,你就有一個可檢索的公司文件向量庫。


    2. 問答 / ChatBot 範本:已幫你處理 history + retrieval

    Haystack 內建多種 QA / ChatBot 範本,你不用自己寫:
    – 如何把 user 問題拿去檢索文件
    – 如何把檢索結果塞進 prompt
    – 如何處理多輪對話的 history

    你只要:
    1. 選用哪一個 LLM(雲端或本地)
    2. 綁定上一步建立好的向量庫

    範例:最小 QA API(搭配 Docker 跑一個 stack)

    docker run -p 8000:8000 deepset/haystack:latest
    

    在 Python 中寫一個簡單 QA pipeline:

    from haystack import Pipeline
    from haystack.nodes import PromptNode
    from haystack.document_stores import FAISSDocumentStore
    from haystack.nodes import EmbeddingRetriever
    
    # 連到既有向量庫
    doc_store = FAISSDocumentStore(faiss_index_path="faiss_index")
    retriever = EmbeddingRetriever(document_store=doc_store, embedding_model="sentence-transformers/all-MiniLM-L6-v2")
    
    # LLM(可改成你的雲端 / 本地模型)
    prompt_node = PromptNode("gpt-4o", api_key="YOUR_OPENAI_KEY")
    
    qa = Pipeline()
    qa.add_node(retriever, name="retriever", inputs=["Query"])
    qa.add_node(prompt_node, name="llm", inputs=["retriever"])
    
    result = qa.run({"Query": "我們的休假制度怎麼規定?"})
    print(result["results"][0])
    

    這樣就有一個最小的「公司文件 QA API」,可以包成 FastAPI / Flask 給同事使用。


    3. Agent 範本:多工具呼叫 + 任務分解

    當你想讓助理不只回答文件內容,還能查系統資料或叫內部 API,Haystack 的 Agent 範本就派上用場。

    你可以:
    – 定義多個工具(例如:查工時系統 REST API、查 CRM 客戶資料)
    – 讓 Agent 自己決定何時呼叫哪個工具,並把結果融入回答

    範例:加一個「查內部 REST API」工具

    from haystack.agents import Tool, Agent
    import requests
    
    # 定義工具
    def get_user_vacation(user_id: str) -> str:
        r = requests.get(f"https://internal-api.company.com/vacation/{user_id}")
        return r.json()["summary"]
    
    vacation_tool = Tool(
        name="vacation_lookup",
        func=get_user_vacation,
        description="查詢員工剩餘休假與最近申請紀錄。輸入 user_id。",
    )
    
    agent = Agent(tools=[vacation_tool], model="gpt-4o")
    
    answer = agent.run("幫我查一下員工 1234 的休假狀態,再用中文整理給我。")
    print(answer)
    

    到這一步,你已經從「純 QA 助理」升級成「簡單 Agent」,可以真正接公司系統工作流程。

    💡 關鍵: 一旦把公司內部 REST API 或 DB 封成工具交給 Agent,你的助理就能從「只會看文件」變成「真的能查系統、執行工作」的實用工具。


    適合誰用?兩個具體場景

    1. 公司內部文件助理(Confluence / PDF / Notion)

    目標:讓同事問「新人入職流程」「出差報帳規則」時,直接跟 AI 聊天,不必翻 Confluence / PDF。

    你可以這樣做:
    1. 把公司手冊、流程文件、政策 PDF 匯出到一個資料夾
    2. 用 Haystack 文件管線建立向量庫
    3. 用 QA 範本 + LLM 做一個 /ask-docs API
    4. 用簡單前端(React / internal tool)做一個聊天頁面給同事用


    2. 客戶 FAQ 機器人(網站 / LINE / Web Chat)

    目標:把客服中心常見問題、產品 FAQ 集中到一個聊天介面,讓客戶自助查詢。

    你可以:
    1. 用 Haystack 把 FAQ CSV / 網站內容抓下來做 index
    2. QA pipeline 對接你的 LLM(可以選較便宜模型,參考 AI 成本問題:https://blog.dshr.org/2026/06/ais-affordability-crisis.html
    3. 透過 Agent 工具連到訂單查詢 API,讓客戶問「我的訂單現在在哪?」時能真的查到資料


    怎麼開始:一天內跑出第一個可用助理

    步驟 1:本地快速上手

    1. 建環境

    bash
    python -m venv venv
    source venv/bin/activate # Windows 用 venv\Scripts\activate
    pip install haystack-ai

    1. 選模型
    2. 想省錢、保留隱私:用本地開源模型(例如 DeepSeek 輕量版,部署教學可參考:https://pub.towardsai.net/how-to-run-deepseek-locally-on-your-own-computer-and-the-catch-most-guides-skip-60517629d00d
    3. 想先跑順:用雲端 OpenAI / Anthropic 等

    步驟 2:選一個向量庫

    開發階段,可以先用:
    FAISS:本地測試快速、安裝簡單
    Qdrant / Weaviate:要多機部署再考慮

    把向量庫實例塞到 Haystack document_store,就能用同一套 pipeline 程式碼。


    步驟 3:照官方範例跑出第一個 QA API

    官方入門範例在:https://haystack.deepset.ai/tutorials

    你可以:
    1. 先照「Quickstart RAG」跑一遍(約 30 分鐘)
    2. 把示範資料換成公司文件
    3. 用 FastAPI 包一層 HTTP API:

    from fastapi import FastAPI
    from pydantic import BaseModel
    
    app = FastAPI()
    
    class Query(BaseModel):
        question: str
    
    @app.post("/qa")
    async def qa_endpoint(q: Query):
        result = qa.run({"Query": q.question})
        return {"answer": result["results"][0]}
    

    部署與實戰小訣竅

    1. 用環境變數切換雲端 / 本地模型

    實務上你會想在:
    – 開發:用本地開源模型省錢
    – 上線:用雲端模型提高穩定性

    可以這樣設計:

    import os
    from haystack.nodes import PromptNode
    
    MODEL_NAME = os.getenv("LLM_MODEL", "gpt-4o")
    MODEL_ENDPOINT = os.getenv("LLM_ENDPOINT")  # 本地時填自己的伺服器 URL
    
    prompt_node = PromptNode(MODEL_NAME, api_key=os.getenv("LLM_API_KEY"), url=MODEL_ENDPOINT)
    

    只要在部署時改環境變數,就能切換不同模型和推理後端。


    2. Prompt logging:先看清楚 Agent 在幹嘛

    Haystack 支援把 pipeline 執行資訊輸出,你可以:
    – 把每次 prompt、檢索結果、工具呼叫記錄到 DB / Log 文件
    – 用這些紀錄回頭調整 prompt、優化 Agent 行為

    簡單做法:
    – 在 FastAPI 層加 middleware,把 qa.run() 的輸入輸出存進 DB
    – 固定每週 review 一次錯誤回答,調整資料和 prompt


    3. 評估:不要只看「感覺」,要看準確率

    Haystack 有基礎評估工具,你可以:
    1. 準備 20-50 題真實問題 + 正確回答
    2. 用這些問題跑 pipeline,計算命中率、是否有 hallucination
    3. 調整 chunk 大小、retriever top-k、模型種類

    💡 關鍵: 用 20–50 題標註資料做簡單評估,比只看「用起來感覺不錯」更能掌握準確率與幻覺問題。


    總結:先用框架,把精力留給「你自己的工具」

    如果你已經寫過一次 RAG pipeline,就知道真正麻煩的不是 LLM,而是:文件流程、檢索、上下文管理、工具呼叫。Haystack 把這些基礎骨架收斂成一套可重複使用的框架,你可以把力氣放在:

    • 接公司內部系統(REST API / DB / CRM)
    • 整理與更新文件資料
    • 設計合乎業務邏輯的 Agent 行為

    照本文步驟,一天內做出第一個「真的可以丟給同事用」的公司 AI 助理,之後再慢慢疊功能,而不是每次都從一堆 RAG script 重寫。


    🚀 你現在可以做的事

    • Haystack 官方教學 跑一遍 Quickstart RAG,並把示範資料換成公司文件
    • 在本地用 FAISS + 一個你熟悉的 LLM(如 gpt-4o 或本地 DeepSeek)建立第一個 QA pipeline
    • 為公司內一個具體場景(例如新人入職或客服 FAQ)做出 /qa HTTP API,丟給 2–3 位同事試用並收集回饋