https://www.communeify.com/tw/tag/code/Communeify - Your Community PlatformHugohttps://www.communeify.com/tw/blog/jetbrains-mellum-2-1-coding-agent/https://www.communeify.com/tw/blog/jetbrains-mellum-2-1-coding-agent/Sun, 18 Oct 2026 01:20:00 +0800JetBrains 發布 Mellum 2.1 開源模型：專為 Coding Agent 打造的 12B MoE 輕量推理模型與本地 GGUF 部署指南JetBrains 於 2026 年 10 月 8 日正式推出 Mellum 2.1 (Mellum2.1-12B-A2.5B-Thinking)，這是繼 2026 年 6 月開源 Mellum 2 之後的重大更新版本。這款模型採用 Apache 2.0 授權開源，總參數量為 12B，但透過專家混合（Mixture-of-Experts, MoE）架構，每個 Token 僅需啟用 2.5B 參數。 與上一代相比，Mellum 2.1 的底層模型架構完全沒有改變，所有的效能突破都來自後訓練（Post-training）階段的大規模強化學習（Reinforcement Learning, RL）。經過在數千個真實軟體工程環境、數百萬次沙盒（Sandbox）執行訓練後，Mellum 2.1 具備了自主探索程式碼庫（Codebase）、編輯檔案並自行執行測試驗證修改結果的 Agent 能力，同時官方也同步釋出了 Mellum2.1-12B-A2.5B-Thinking-GGUF 量化權重，讓開發者能直接透過 llama.cpp、Ollama 或 LM Studio 在單張消費級顯卡或 Mac 上私有化部署。 核心架構與規格：維持 2.5B 啟用參數的高效 MoE 設計Mellum2.1-12B-A2.5B-Thinking 屬於具備思維鏈（Chain-of-Thought）能力的推理模型（Thinking Model），在輸出最終答案前會先於 <think> 標籤內進行邏輯推演。根據官方公布的技術規格，其核心架構設計如下： MoE 專家路由機制：模型共包含 28 層網路與 64 個專家（Experts），路由器（Router）在處理每個 Token 時僅會啟用其中 8 個專家，總參數 12B、實際啟用參數僅 2.5B。 混合滑動視窗注意力機制：採用分組查詢注意力（Grouped-Query Attention, GQA），配置 32 個 Query Heads 與 4 個 KV Heads。為了大幅降低長文本的記憶體消耗，28 層中有 21 層（每 4 層中的 3 層）採用 1,024 Tokens 的滑動視窗（Sliding Window），僅有 7 層使用全注意力（Full Attention）。 上下文長度與詞彙表：原生支援 131,072 Tokens（128K）上下文視窗，詞彙表大小為 98,304 Tokens，原始權重以 bfloat16（BF16）格式發布。 開源授權：採用商業友善的 Apache 2.0 授權條款。 受惠於 21 層滑動視窗設計，Mellum 2.1 在長上下文推論時的 KV Cache 記憶體佔用極低。在 llama.cpp 預設滑動視窗快取機制下，跑滿 131K 上下文僅需額外約 1.9 GB 的 VRAM（若設定為 32K 上下文則僅需約 0.5 GB），讓 12 GB VRAM 的消費級顯卡也能輕鬆負荷完整上下文。https://www.communeify.com/tw/blog/deepseek-v4-1-flash-1017-guide/https://www.communeify.com/tw/blog/deepseek-v4-1-flash-1017-guide/Sun, 18 Oct 2026 01:20:00 +0800DeepSeek-V4.1-Flash-1017 完整解析：552B 非對稱 CED 架構、11 項代理基準測試與本地部署指南DeepSeek（深度求索）於 2026 年 10 月 17 日正式開源並上線 DeepSeek-V4.1-Flash-1017，採用 MIT 開源授權。作為 DeepSeek-V4.1-Flash 的 10 月份更新版本，該模型延續了 552B 骨幹參數（含條件記憶與多模態模組之完整倉庫權重為 763B）的因果編碼器－解碼器（CED）稀疏混合專家架構，在預填充（Prefill）階段每 Token 僅激活 8B 參數、解碼（Decode）階段激活 16B 參數，並支援 100 萬（1M）Tokens 上下文視窗與原生圖像理解。根據 DeepSeek 官方發布公告，本次 1017 版本透過基於自反饋的強化學習（RL）大幅強化從零構建完整專案的「許願式編程」能力，在提升推理、程式開發、代理（Agent）與視覺基準表現的同時，進一步縮短任務執行時間與輸出 Token 長度。本文整理官方模型卡、技術報告與 API 文件的核心規格、11 項基準評測數據、部署方式與相關資訊。 DeepSeek-V4.1-Flash-1017 核心升級亮點根據 Hugging Face 官方模型卡與 DeepSeek API 官方新聞稿，本次 DeepSeek-V4.1-Flash-1017 更新聚焦於三個核心方向： 性能與成本的帕累托改進（更強、更快、輸出更精簡）：相較於 2026 年 9 月 10 日發布的初代 DeepSeek-V4.1-Flash，1017 版本在推理、程式碼、代理任務與多模態視覺基準上全面提升（例如 Terminal-Bench 4.0 從 31.2 分躍升至 42.3 分，ProgramBench 從 20.3 分提升至 29.1 分），同時縮短了模型執行代理任務的總耗時與輸出 Token 長度，在多個代理框架（Agent Harnesses）下降低單次任務的整體推論花費。 基於自反饋強化學習的「許願式編程」能力：官方公告指出，研發團隊採用基於自反饋的強化學習（Reinforcement Learning with Self-Feedback）後訓練技術，強化模型從零開始構建完整專案的端到端開發能力。在較少的提示詞與素材參考下，模型可在 DeepSeek Harness 等框架內以極短的互動輪次直接完成大型專案，官方展示案例包含： 故宮 3D 建模展示：直接透過程式碼建立精細的古建築群 3D 場景。 網頁版賽車遊戲：從零完成具備物理碰撞與賽道渲染的完整網頁遊戲。 基於 Godot 引擎的《傳送門 2》（Portal 2）復刻：構建包含傳送門空間邏輯與 3D 關卡的遊戲專案。 Valley of Ages 3D 動態歷史場景：以 3D 互動場景呈現從史前時代到現代文明的演進歷程。 主流代理框架適配與自研 Search / Fetch API 開放：本次更新特別針對 DeepSeek Harness（官方建議升級至 v0.2.1-rc.1 或以上版本）、騰訊 CodeBuddy、WorkBuddy、Claude Code 與 Mini-SWE-V2 進行最佳化。此外，支撐 DeepSeek 網頁端與 App 每日數億次請求的自研 AI 原生搜尋引擎，也隨本次更新正式對外開放 Search API 與 Fetch API（定價皆為每千次成功呼叫 5 元人民幣 / 0.75 美元，並具備過濾 SEO 作弊、GEO 操縱與低品質 AIGC 內容的識別機制）。 底層架構解析：為什麼骨幹是 552B，而模型頁顯示 763B？初次檢視 DeepSeek-V4.1-Flash-1017 模型卡的開發者常會注意到一個數字差異：官方技術報告《DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression》與相關評測頁均標示其為 552B 骨幹參數，但 Hugging Face 右側欄的 Safetensors 模型大小卻顯示 763B params（完整檔案總容量約 510 GB）。https://www.communeify.com/tw/blog/inclusionai-ling-3-1-flash/https://www.communeify.com/tw/blog/inclusionai-ling-3-1-flash/Thu, 15 Oct 2026 00:05:00 +0800inclusionAI（螞蟻集團旗下 AGI 研發團隊）於 2026 年 10 月 14 日在 Hugging Face 正式開源大規模混合推理語言模型 inclusionAI/Ling-3.1-flash。 該模型為前代 inclusionAI/Ling-3.0-flash 的架構升級版，採用 MIT 開源授權。其總參數量達 5,600 億（560B），每 Token 僅啟用 250 億（25B） 參數，具備高達 100 萬（1M）Tokens 的上下文視窗上限，兼顧龐大知識容量與推論經濟效益。 核心定位與設計重點Ling-3.1-flash 是 Ant Ling 語言模型產品線的旗艦分支，專為複雜的多步驟長流程任務與代理（Agentic）工作流設計： 代理工作流與工具調用：原生支援函數調用（Tool Calling）與深度推理模式切換，適用於數小時以上的終端機操作、多步驟自動化流程與辦公檔案處理。 軟體工程與長程式碼庫分析：針對大型專案問答、跨語言代碼重構、自動漏洞修復與編譯器建構進行專門優化。 專業垂直領域建模：加強金融檢索與分析、醫療專業溝通（HealthBench Professional），以及與北京大學合作評估的材料化學領域（Supermatbench）。 混合線性 MoE 架構規格為了在 560B 規模下維持低延遲與高吞吐量，Ling-3.1-flash 升級了混合線性注意力機制（Hybrid-linear Attention）與專家混合（MoE）設計，將線性注意力與全局注意力的比例調整為 7:1。 架構維度規格細節 模型類型原生混合線性專家混合架構（Hybrid-linear MoE，純文字輸入/輸出）參數規模總參數 560B，每 Token 啟用 25B（稀疏度約 1/22）上下文視窗架構原生支援最高 1,000,000 Tokens（線上 API 服務目前開放至 262,144 Tokens）注意力層配置共 72 層：63 層 KDA（Kimi Delta Attention，線性複雜度）+ 9 層 Gated MLA，採 7:1 比例堆疊FFN 與專家配置前 4 層為 Dense FFN（維度 10,240），後續為 512 個路由專家 + 1 個共享專家專家路由機制每 Token 啟用 8 個路由專家與 1 個共享專家（E512A8 + 1 shared expert），採用 ALF-LB 負載平衡關鍵超參數Hidden Size 4,096、專家中間層維度 1,280、Attention Heads 64、詞表大小 157,184訓練與權重格式Next-Token Prediction + 多 Token 預測（MTP），提供 BF16、FP8 (F8_E4M3)、FP32 Safetensors開源授權條款MIT License 官方基準測試表現官方公布了多項領域評測結果。需要注意的是，部分高分標註使用了螞蟻自家的 LingCode harness 或 AQ 專屬環境，屬於官方自測（Vendor-reported）成績：https://www.communeify.com/tw/blog/rea-reverse-engineer-anything-mcp-ai-agents/https://www.communeify.com/tw/blog/rea-reverse-engineer-anything-mcp-ai-agents/Mon, 12 Oct 2026 21:05:00 +0800REA 逆向工程工具解析：如何透過 MCP 串接 AI 代理與底層分析軟體本文解析開源逆向工程工具 REA（Reverse Engineer Anything）的核心架構與運作方式。REA 透過 Model Context Protocol（MCP）將 AI 代理連接至 Hopper、Ghidra 與 IDA 等分析工具，支援原生二進位檔案、Electron 應用、Android APK 與韌體等多種目標的靜態分析與動態追蹤，協助開發者深入理解軟體實作細節並取得完整證據鏈。 軟體開發與安全研究過程中，理解第三方應用程式或舊系統的底層運作邏輯，往往需要耗費大量時間手動操作反組譯器與偵錯工具。開源專案 morluto/rea GitHub 儲存庫 提出了一套整合方案，讓 AI 代理能夠透過標準通訊協定，直接調度各類逆向工程引擎與分析指令。 什麼是 REA：連結 AI 代理與底層分析工具的橋樑REA（Reverse Engineer Anything）是一套基於模型上下文協定（Model Context Protocol，簡稱 MCP）打造的本機逆向工程伺服器。開發者可以透過 REA 官方網站 取得完整指引，將 Claude Code、Cursor、Codex 等支援 MCP 的代理工具與 REA 連接。 以往透過語言模型輔助逆向時，使用者通常必須手動從反組譯器匯出組合語言或虛擬碼，再貼進對話視窗提問。這種方式容易遺失上下文，也無法讓模型進一步探索關聯函式。REA 則將逆向工具封裝為代理可呼叫的函式介面，讓 AI 代理能夠根據初步發現，自主發起追蹤查詢與代碼比對。 REA 的運作機制與分析流程REA 的核心精神在於「證據導向」。代理在分析軟體時，所有推論都必須附帶底層的原始依據，包含指令偏移量、字串參照或呼叫堆疊。 從自然語言提問到程式碼證據鏈當使用者向 AI 代理提出分析需求時，代理會將高階問題拆解為具體的檢查步驟，並透過 MCP 呼叫 REA 的工具集合。 REA 執行分析後，會回傳結構化的發現與對應證據，例如： 函式反編譯產生的虛擬碼與組合語言。 記憶體中的特定字串、符號表與外部匯入項目。 跨模組的呼叫關係與參照位址。 代理接收這些回傳資料後，可以進一步提出深入問題，或直接驗證演算法實作邏輯。 本機端靜態分析與執行階段動態追蹤REA 在架構上區分了靜態檢查與執行階段擷取。靜態分析（例如檢視 JavaScript 模組或 .NET 中繼資料）只會讀取檔案結構，不會啟動目標應用程式。https://www.communeify.com/tw/blog/jetbrains-mellum-2-1/https://www.communeify.com/tw/blog/jetbrains-mellum-2-1/Sat, 10 Oct 2026 00:05:00 +0800JetBrains 開源 Mellum 2.1 程式碼代理模型：強化學習微調與本機部署實測表現JetBrains 正式發表開源模型 Mellum 2.1，維持 12B 總參數與 2.5B 啟動參數的混合專家架構，透過大規模真實環境強化學習，加強儲存庫探索、檔案編輯與代碼檢驗能力。本文整理其模型架構、官方基準測試數據、推論效能以及自建部署方式。 JetBrains 在 官方技術公告 中發布了新一代模型 Mellum 2.1。這款模型是 JetBrains 在 2026 年 6 月開源的 Mellum 2 後續版本，同樣採用 Apache 2.0 授權釋出，允許開發者自由下載並部署在自有硬體環境中。開發團隊表示，雖然底層模型架構與參數量保持不變，但後訓練（post-training）流程經歷了重整，主要加強模型在實際專案專屬環境中的軟體工程處理能力。 模型架構與訓練方式：以真實環境為基礎的強化學習延續輕量混合專家架構Mellum 2.1 沿用了 Mellum 2 的混合專家（MoE）設計，總參數量為 12B，推論時實際啟動的參數量僅為 2.5B。根據官方在 Hugging Face 模型頁面 公布的規格，模型共包含 28 個層級，隱藏維度為 2304，並具備 64 個專家模組，推論時每次動態選取 8 個專家進行運算。 注意力機制方面，該模型採用群組查詢注意力（GQA），查詢頭（Q heads）為 32 個，鍵值頭（KV heads）為 4 個。上下文窗口長度達到 131,072 個 token，並在每 4 層中針對 3 層導入長度 1024 的滑動窗口（Sliding Window）設計，有助於降低長文本運算時的記憶體負擔。 擴大沙盒環境與資料篩選標準Mellum 2 雖然推論速度快，但在複雜專案程式碼庫內處理多步驟任務時表現有限。JetBrains 團隊針對這個問題調整訓練重心，將強化學習（RL）從原先簡短的收尾步驟，擴展為後訓練的核心階段。 為了讓模型具備實際操作程式碼庫的能力，開發團隊搭建了內部沙盒測試基礎設施，在訓練過程中啟動數百萬次沙盒環境。模型必須在配備終端機指令（shell）與檔案編輯工具的真實程式碼庫中操作，只有在測試成功通過時才會獲得獎勵回饋。此外，團隊也在數學、競賽程式設計、科學推理與工具調用等領域導入更多經過嚴格過濾的 RL 任務，剔除測試損壞或答案不可驗證的開放資料集樣本。https://www.communeify.com/tw/blog/agnes-3-0-flash/https://www.communeify.com/tw/blog/agnes-3-0-flash/Fri, 25 Sep 2026 17:07:22 +0800Agnes-3.0-Flash Preview：為高效能運算打造的多模態模型新選擇追求高階 AI 推理與多模態能力時，開發者常面臨頂級模型硬體門檻極高或完全封閉的困境。Agnes AI 發布了 Agnes-3.0-Flash Preview 開放權重多模態預覽模型，採用 Apache-2.0 開源授權，旨在讓開發者能在自有硬體上運行具備旗艦級推理、程式編碼與長上下文處理能力的模型。 該開放權重模型擁有 33B（330 億）參數與原生 262,144 tokens（262K） 上下文視窗，同時支援文字、圖像與影片的多模態輸入理解。 混合注意力機制與架構特點Agnes-3.0-Flash Preview 採用了高效的混合注意力解碼器（Hybrid-attention Decoder）： 72 層解碼器結構：由 54 層門控增量規則（Gated Delta Rule 遞迴層）與 18 層全域注意力（Global Attention）交替組成（比例為 3 : 1）。 降低 KV Cache 壓力：每 4 層中僅有 1 層需要維護會隨上下文長度增長的 KV Cache，其餘 3 層為狀態尺寸獨立於序列長度的遞迴層，能顯著降低長文本處理時的顯存需求。 視覺處理：內建 27 層 Vision Tower（隱藏層 1152、Patch 大小 16、2×2 空間合併），投影映射至 5120 主維度。 核心功能與推論控制 多模態理解：搭配內建的 AutoProcessor，可直接輸入圖像（Image）與影片（Video）進行理解與分析。 思考強度控制（Reasoning Effort）：Chat Template 支援可調式的思考強度，可傳遞 reasoning_effort="high"（預設，適合複雜推理）、medium、low，或設定 enable_thinking=False 直接關閉思維鏈以降低延遲。 原生工具調用（Tool Calling）：原生支援 Function Calling，模型會輸出 <tool_call> 標籤格式，便於掛載外部 API 或資料庫操作。 官方 Benchmark 評測（Preview 開放權重版本）官方模型卡公布了 Preview 開放權重 checkpoints 的評測結果：https://www.communeify.com/tw/blog/cursor-origin/https://www.communeify.com/tw/blog/cursor-origin/Tue, 18 Aug 2026 17:52:57 +0800Cursor Origin：AI Agent原生程式碼託管與開發流的整合在當前軟體開發流程中，開發環境（IDE）與程式碼託管平台（如 GitHub）的分離，往往會造成工作節奏的碎片化。開發者必須频繁切換視窗來管理 Pull Requests (PR)、追蹤 CI/CD 狀態或與團隊溝通。 為了解決這個工程痛點，Cursor 團隊正式推出了 Origin 程式碼託管服務。這不僅是一套標準的 Git 儲存庫代管方案，更是一套專為大規模 AI 智慧體（AI Agents）協作打造的智慧體原生（Agent-Native）開發基礎設施。 圖片來源: Origin 程式碼託管 · Cursor 什麼是 Origin？Origin 是 Cursor 為付費方案（Pro、Teams 與 Enterprise 企業版，不適用於免費版）使用者逐步推出的早期 Beta 版 Git Forge。 與其說它是一個傳統的程式碼託管平台，不如說它是一個專為 AI 智慧體提供底層操作介面的軟體倉庫。啟用 Origin 後，團隊管理員可以認領一個專屬的「程式碼庫名稱（Codebase Name）」，作為整個團隊的命名空間，例如：https://cursor.com/codebase/acme-corp。認領後，團隊便能在該空間內建立、儲存與共享內部（Internal）或私有（Private）的程式碼倉庫。 Origin 與 GitHub 的同步與防護機制Origin 的設計並非為了強迫開發者立即放棄既有的 GitHub 基礎設施，而是提供了極具彈性的雙向同步與鏡像機制： 從 GitHub 鏡像（Mirroring）同步： 開發者可以將 GitHub 倉庫直接複製到 Origin 作為鏡像。同步後，Git 提交歷史記錄、分支（Branches）與標籤（Tags）會完整保留在 Origin 上，以供本地或雲端智慧體進行深度程式碼分析。 對於已鏡像的倉庫，GitHub 依然是唯一的權威來源（Authority Source）。任何推送到 Origin 鏡像副本的變更，都會自動實時傳遞回 GitHub。 與 GitHub 解除關聯（Detach）： 如果團隊希望完全轉移至 Cursor 託管，可在倉庫的 常規設定（Settings -> General） 中選擇「從 GitHub 解除關聯」。此操作會停止兩者間的同步，並將 Origin 副本轉換為獨立託管在 Origin 上的儲存庫，使 Origin 成為唯一的權威來源，且不會影響原先在 GitHub 上的原始倉庫。 數據同步邊界： 鏡像包含：完整的 Git 變更歷史、所有分支、所有 Git 標籤，以及雙向即時同步的 PR 數據。 鏡像不包含：GitHub Issues、GitHub Actions 的秘密環境變數（Secrets），以及其對應的 CI 運作歷史。 雙向 PR 審查與執行緒管理PR（Pull Request）審查是 Origin 最具代表性的優勢之一。在 cursor.com/codebase 的 PR 標籤頁中，打開任意 PR 即可瀏覽完整的動態時間線、提交歷史、CI 檢查結果以及程式碼 Diff。https://www.communeify.com/tw/blog/gitskills-ai-agent-modularization/https://www.communeify.com/tw/blog/gitskills-ai-agent-modularization/Tue, 18 Aug 2026 17:40:55 +0800解析軟體開發新領域：GitSkills 資料集揭開 AI 代理技能的神秘面紗現代軟體開發中，AI 代理（Agent）的角色越來越吃重。為了讓這些代理精準處理特定任務，Anthropic 在 2025 年 10 月發布了一項開放規格，允許開發者以「技能」（Skill）的形式為代理編寫指令。在沒有統一註冊機制的環境下，這些指令究竟是如何被撰寫與重用的？ 近期發布的 GitSkills 資料集，對 GitHub 上高達 3,797,117 個 SKILL.md 檔案進行了系統性調查，試圖回答 AI 協作開發中的實證問題。這份資料集不僅是軟體工程（SE）研究社群的首創，也為理解人機協同開發開啟了全新的實證維度。 圖片來源: mvaccargiu/gitskills · Datasets at Hugging Face 什麼是代理技能？代理技能（Agent Skill） 就像是一套數位操作手冊。通常是一個包含 SKILL.md 核心檔案的資料夾，其中可能附帶執行腳本、配置範本或參考文件。當 AI 代理執行任務時，會根據當前任務需求，在運行時決定是否載入對應技能。Anthropic 在 2025 年 10 月發布了其目錄結構、YAML 前言（front-matter）限制以及階段式載入模型（staged loading model）的開放規格。其中，Claude Code 是其官方的參考實現（Reference Implementation），其預設將技能存放在 .claude/skills/ 目錄中。 這種做法與傳統程式碼或設定檔最大的不同在於其**「機率性（Probabilistic）」**： 無靜態驗證：模型是在執行過程中基於語意匹配自主判斷是否載入，缺乏編譯器或型別檢查（Type Checker）來確保正確性。 語意模糊風險：如果技能的描述（Description）過於模糊，模型可能無法正確選中該技能；若指令說明不清，則可能導致任務執行不完整或錯誤，且不會拋出明確的系統編譯報錯。 無套件管理器：目前此生態系缺乏中央註冊表（Central Registry）或套件管理器。因此，技能的擴散主要依賴於開發者手動在專案儲存庫之間「複製整套資料夾（Copying Folders）」。 GitSkills 的資料洞察由 Giuseppe Destefanis（倫敦大學學院）、Daniel Graziotin 與 Matteo Vaccargiu（霍恩海姆大學）以及 Marco Ortu（卡利亞里大學）組成的研究團隊，在 2026 年 7 月 採集了來自 282,200 個公開 GitHub 儲存庫（由 195,841 個開發者帳戶所持有）的資料，推出了 GitSkills 資料集。https://www.communeify.com/tw/blog/x-recommendation-algorithm-opensource/https://www.communeify.com/tw/blog/x-recommendation-algorithm-opensource/Fri, 14 Aug 2026 14:31:16 +0800剖析 X 推薦演算法：貼文是如何出現在你的「為您推薦」？X（原 Twitter）開源了決定「為您推薦」（For You）動態時報的核心推薦演算法原始碼（x-algorithm GitHub 倉庫）。這項舉措讓開發者與研究人員得以跳過行銷術語，直接檢視支撐全球最大社交平台之一的核心工程邏輯與系統架構。 圖片來源: GitHub - xai-org/x-algorithm: Algorithm powering the For You feed on X · GitHub 推薦系統的核心：雙管道協作架構在 X 的設計中，「為您推薦」動態時報的組裝是單次請求即時生成的。整個系統架構由兩大管道（Pipelines）協同工作，並在 home-mixer/ 模組中完成整合： 帖子管道（Post Pipeline / PhoenixCandidatePipeline）：負責候選帖子的檢索、過濾、排序與安全篩選。 混合管道（Blending Pipeline / ForYouCandidatePipeline）：負責在已排序的帖子中，插入非模型排序的內容，例如廣告（Ads）、推薦關注（Who to Follow）、系統提示（Prompts）以及推送引導，最終由 BlenderSelector 進行交織（Interleaving）輸出。 這兩個管道建構於名為 candidate-pipeline 的高效、可組合的 Rust 框架之上。該框架實現了業務邏輯與管道監控的分離，並支援多個候選源與過濾器的並行執行。 請求路徑（Request Path）的七大步驟當你打開 X App 載入「為您推薦」時，系統會在極短的延遲內執行以下請求路徑： 1. 查詢水合（Query Hydration）系統首先讀取使用者的即時情境。最核心的輸入是用戶的即時互動序列（User Action Sequence），同時載入關注列表、黑名單與靜音帳號、已靜音的關鍵字、當前會話中已讀或已送出的帖子，以及關注的主題等。 2. 並行檢索候選源（Candidate Sources）系統會同時在網內（In-Network）與網外（Out-of-Network）兩個方向平行調用候選源，目標是抓取數百到數千條潛在帖子： 網內（In-Network）：由 thunder/ 模組負責。它在記憶體中維護用戶關注帳號最新發布的帖子，並直接讀取出來。 網外（Out-of-Network）： phoenix/ 檢索：將用戶與帖子映射為高維向量，利用向量相似度檢索最接近用戶興趣的貼文。 simclusters/ 檢索：根據「誰與什麼互動」將帳號與帖子劃分為不同的社區（Clusters），再計算社區相似度來召回潛在的網外優質帖子。 3. 候選水合（Candidate Hydration）將初步召回的帖子補全完整的中繼資料（Metadata），包括帖子文本與媒體資源、作者詳情、帳號標籤、被引用的原始帖子、語言、實時互動計數（點讚、轉發數）以及作者的訂閱者狀態等。 4. 評分前過濾（Pre-Scoring Filters）在進行昂貴的模型計算前，系統會依次調用 home-mixer/filters/ 下的十多個過濾器以減少計算浪費：https://www.communeify.com/tw/blog/lg-exaone-2-0-750b-ai-model/https://www.communeify.com/tw/blog/lg-exaone-2-0-750b-ai-model/Thu, 13 Aug 2026 17:04:50 +0800探索 LG AI 最新模型：K-EXAONE 2.0 功能與部署指南在人工智慧邁向「具身智慧」與「自主代理（Agentic AI）」的時代，LG AI Research 正式推出了全新旗艦級開源多語言混合專家模型（MoE）—— K-EXAONE 2.0。 這款模型絕非單純的參數規模擴展，而是透過創新的**「向上循環（Upcycling）」**技術、多階段持續預訓練（Continual Pre-training），以及專為長文本與安全性設計的對齊微調，使其在邏輯推理、程式開發與工具調用上，具備了與頂尖開源模型一較高下的實力。 圖片來源: LGAI-EXAONE/K-EXAONE-2.0-750B-A37B · Hugging Face 一、 核心架構與技術特性K-EXAONE 2.0 擁有 7,500 億（750B）總參數，在推論時每個 Token 實際激活的運作參數僅為 370 億（37B）。這種「大體積、輕量推論」的 MoE 架構在多項硬體適應指標上實現了極佳的平衡，其核心技術規格與設計亮點如下： 1. 深度與寬度的雙向「向上循環」（Upcycling）開發團隊直接對前代 K-EXAONE（236B）進行模型結構擴充，使其規模擴大至三倍以上。為了解決極深層模型在訓練與推論中常見的「梯度與激活值爆炸」難題，K-EXAONE 2.0 在雙 SwiGLU 分支後引入了數值夾緊機制（Clamping after two SwiGLU branches），顯著穩固了 78 層（2 層 Dense 頭 + 76 層 Sparse MoE）超深層網路的數值流。 2. 混合注意力機制（Hybrid Attention Matrix）為了優化長文本處理的記憶體（VRAM）開銷，K-EXAONE 2.0 摒棄了全域自注意力的單一做法，改採高度精細化的混合結構： 全域注意力（Global Attention）： 基於無位置編碼（NoPE）架構。 滑動視窗注意力（Sliding Window Attention, SWA）： 包含 4096 窗口大小的局部 SWA 層，以及多個由「3層 128 窗口局部 SWA + 1層全域自注意力」組成的混合 Block，在提供高達 256K（262,144 tokens） 的超長上下文窗口之餘，極大程度壓縮了 KV 快取的硬體佔用。 3. 混合專家（MoE）與門控細節 總專家數： 256 個 MoE 專家 + 1 個始終激活的共享專家（Shared Expert）。 激活配置： 每次推論時，路由會精準激活其中的 8 個專家。 詞彙表規模（Vocab Size）： 擴大至 153,600，且原生支援的語言從 6 種全面擴展至 10 種多國語言（韓語、英語、西班牙語、德語、日語、越南語、法語、義大利語、波蘭語與葡萄牙語）。 二、 卓越的基準測試表現 (Benchmarks)K-EXAONE 2.0 BF16 模型在多個權威基準測試中展現出頂尖的開源競爭力，特別是在長文本檢索、代碼代理與安全性指標上表現優異：https://www.communeify.com/tw/blog/anydoc-markdown-converter/https://www.communeify.com/tw/blog/anydoc-markdown-converter/Thu, 13 Aug 2026 16:00:47 +0800AnyDoc：將辦公文件秒轉為 LLM 友善 Markdown 的開源利器在建構 RAG（檢索增強生成）系統或處理大量數位文件時，如何從不同格式中精準、快速地提取結構化資訊，一直是開發者面臨的巨大挑戰。不論是舊版的 Word、複雜的 Excel 試算表、PDF 還是 RTF 檔，這些格式常如同資料孤島。 由 Firecrawl 團隊開發的開源專案 AnyDoc 完美解決了這個痛點。它採用純 Rust 撰寫，能將多達 14 種主流辦公文件，以毫秒級的速度（中位數小於 5ms）轉換為統一、乾淨且符合 GitHub 風格的 Markdown (GFM) 格式，為 AI 應用與下游分析提供高質量的結構化資料。 圖片來源: GitHub - firecrawl/anydoc: Convert Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and PDF to clean Markdown. Built in Rust, with Node.js and Python bindings. · GitHub 為什麼需要通用的文件轉換器？處理真實世界的文件時，最棘手的問題在於檔案格式的多樣性與混亂。一份 .docx 檔案可能帶有複雜的巢狀樣式，而 .odt、.rtf 或 .pdf 則有完全不同的內部儲存與排版邏輯。 過去，開發者往往需要為每種格式引入不同的第三方解析套件（例如 PDF 專用、Excel 專用等），這不僅使專案依賴變得臃腫，且當遇到檔案輕微損壞或非常規編碼時，轉換管線極易崩潰。 AnyDoc 的核心優勢在於將轉換流程高度標準化。它並非逐個格式單獨開發轉換器，而是先將所有格式解析為一個統一的「共享文件模型（Shared Document Model）」，該模型會捕捉標題、段落、列表、表格與嵌入資源，最後再由單一的 Markdown 序列化器（Serializer） 輸出。這意味著，不論是 2003 年的舊版 .doc 還是昨天的 .pptx，產出的 Markdown 結構、轉義規則與表格呈現都具有百分之百的一致性。https://www.communeify.com/tw/blog/qwen3-8-2-4t-ai-development-agent/https://www.communeify.com/tw/blog/qwen3-8-2-4t-ai-development-agent/Thu, 13 Aug 2026 14:50:14 +0800突破開源邊界：Qwen3.8-2.4T-A95B 深度解析與部署指南在大型語言模型競相爭鳴的時代，開源社群迎來了里程碑式的突破。Qwen 團隊正式發布了 Qwen3.8-2.4T-A95B，這是官方首次將其最頂級的 Max 級別（Qwen-Max-class） 技術引入開源領域。 這款模型擁有高達 2.4 兆（2.4 Trillion） 的總參數規模，而在推論執行時，透過先進的混合專家（MoE）路由機制，僅需啟用其中 950 億（95B） 個活躍參數。這意味著開發者能在不犧牲推論效率的前提下，享受到超大規模密集模型的極致推理與表達能力。 圖片來源: Qwen/Qwen3.8-2.4T-A95B · Hugging Face 領先的混合專家（MoE）架構設計Qwen3.8 採用的並非傳統的簡單 MoE，其內部結構經過了高度精密的數學重構： 神經網路深度：模型總共包含 92 層（Layers）。 混合佈局（Hidden Layout）：採用 23 組「3 × (Gated DeltaNet → MoE) → 1 × (Gated Attention → MoE)」的循環佈局，其中創新性地結合了線性注意力機制 Gated DeltaNet（128 個 V 頭、16 個 QK 頭）與門控注意力機制 Gated Attention（64 個 Q 頭、4 個 KV 頭）。 專家路由規模：總專家數多達 512 個，推論時動態路由啟用 10 個路由專家與 1 個共享專家（10 Routed + 1 Shared），顯著平衡了專家間的協作效率。 多代幣預測（MTP）：模型引入了多步訓練的 MTP 預測機制，極大地提高了模型對未來 Token 軌跡的預測流暢度與推理一致性。 核心優勢與代理任務（Agent）執行Qwen3.8 在前代（Qwen3.5、Qwen3.6）的強大基礎上進行了全面升級，尤其在自動化編程、專業研究以及**長周期代理任務（Long-horizon Agentic Tasks）**上展現出顯著成效：https://www.communeify.com/tw/blog/google-gemini-code-assist-free-ai-code-completion/https://www.communeify.com/tw/blog/google-gemini-code-assist-free-ai-code-completion/Wed, 26 Feb 2025 08:00:46 +0800為開發者量身打造的 AI 助手Google 正式發佈了兩款全新的 AI 代碼助手工具：Gemini Code Assist for Individuals（個人版）與 Gemini Code Assist for GitHub。這次發佈不僅讓開發者擁有更強大的編程支援，也標誌著 Google 與微軟及其旗下的 GitHub 在開發者工具領域的競爭再次升級。 🌟 個人開發者的超強後盾：Gemini Code Assist for IndividualsGemini Code Assist for Individuals 是基於 Google 最新的 Gemini 2.0 AI 模型 打造，專為開發者提供智慧代碼補全與協助。你可以直接用自然語言與 AI 對話，讓它幫你修復代碼、補全邏輯、甚至解釋複雜的程式邏輯。 📦 主要特色包括： 每月高達 180,000 次代碼補全，比 GitHub Copilot 免費版的 2,000 次，足足多出 90 倍！ 每日 240 次聊天請求，幾乎是 GitHub Copilot 免費版的 5 倍。 128K token 上下文窗口，比競爭對手多出 4 倍，這意味著它能理解並處理更龐大的代碼庫，開發效率大幅提升。 無論是 VS Code 還是 JetBrains IntelliJ 等熱門 IDE，都能無縫整合。 支持 所有公開的程式語言，無論你寫的是 Python、Java、C++ 還是 JavaScript，它都能對應你的需求。 這些數據不只是漂亮的數字，更代表開發者在進行大型專案時，可以少掉許多人工處理的瑣碎事務，把更多心力專注在創新與解決方案上。