一個 AI 智能體在簡單任務上跑得很順，加了幾個功能之後突然開始胡説八道、忽略指令、選錯工具、丟失上下文。這就是所謂的"單體智能體牆"：單個智能體從可用變成不可用的臨界點。 Anthropic 的研究數據表示當智能體掛載超過 10-15 個工具後性能就會斷崖式下跌。但企業級系統動輒需要上百個功能接口就不可能用單體架構撐住。 而且很多開發者還會堆智能體，當第一個智能體有問題的時候就往上加第二
用LLM給LLM打分，這個看起來很聰明的做法正在讓AI評估變得不可靠。KRAFTON AI的這個工作直指當前LLM評估體系的軟肋：作為評判者的語言模型本身就帶有系統性偏差，而這種偏差在Chatbot Arena等主流基準測試中可以達到30%左右。也就是説排行榜上那些令人興奮的性能提升，有相當一部分可能是評估方法的偏差。 評判機制的運作方式 LLM-as-a-judge就是讓一個語言模型去評價另一個
NeRF（Neural Radiance Fields，神經輻射場）的核心思路是用一個全連接網絡表示三維場景。輸入是5D向量空間座標(x, y, z)加上視角方向(θ, φ)，輸出則是該點的顏色和體積密度。訓練的數據則是同一物體從不同角度拍攝的若干張照片。 通常情況下泛化能力是模型的追求目標，需要在大量不同樣本上訓練以避免過擬合。但NeRF恰恰相反，它只在單一場景的多個視角上訓練，刻意讓網
Transformer的"二次方注意力瓶頸"的問題是老生常談了。這個瓶頸到底卡在哪實際工程裏怎麼繞過去？本文從一個具體問題出發，介紹Mosaic這套多軸注意力分片方案的設計思路。 注意力的內存困境 注意力機制的計算公式： Attention(Q, K, V) = softmax(QKᵀ / √d) × V 問題出在 QKᵀ 這個矩陣上，它的形狀是 (序列長度 × 序列長度) 。 拿150
標準 RAG 流水線有個根本性的毛病：檢索到的文檔一旦與用户意圖對不上號，模型照樣能面不改色地輸出一堆看似合理的胡話，既沒有反饋機制也談不上什麼糾錯能力。 而Agentic RAG 的思路截然不同，它不急着從檢索結果裏硬擠答案，而是先判斷一下拿回來的東西到底有沒有用，如果沒用則會重寫查詢再來一輪。這套機制實際上構建了一條具備自我修復能力的檢索鏈路，面對邊界情況也不至於直接崩掉。 本文要做的就是用
JAX跑得快的技巧其實很簡單：通過組合變換讓XLA能看到大塊連續的計算，比如説批處理、融合、分片，讓每一步在單設備或多設備同步時都像一個乾淨的kernel。 我們今天就來總結7個能夠提高運行速度的JAX變換組合 1、 jit 優先，形狀穩定 jit 對函數做一次追蹤後XLA負責融合算子，形狀穩定、無副作用時，Python處理的開銷就被分攤掉，可以提高運行速度。 形狀創建和靜態參數要麼挪到s
Google發佈的這個Code Wiki項目可以在代碼倉庫之上構建動態知識層的工具，或者説可以"自動生成文檔"。 第一層是結構解析：Code Wiki使用Tree-sitter對代碼進行語法樹分析，將源碼拆解成類、函數、方法、導入語句和依賴項。Tree-sitter是一個增量解析庫支持多種編程語言，能夠生成抽象語法樹（AST）。這比純文本處理要精確得多，因為系統真正"看懂"了代碼的語法結構
Scaling Laws 已經成為深度學習領域的共識：更大的模型配合更多數據效果往往更好。但當參數量攀升至百億乃至千億級別時一個棘手的問題是：訓練不穩定性。 現代大語言模型動輒堆疊數十甚至上百層，殘差連接、跳躍連接、跨層路由機制層出不窮。這些架構設計背後的邏輯就是為了改善梯度流、加快收斂、提升參數利用率。但是在實踐中這些技在大規模訓練時卻經常出現問題：損失函數突然飆升、梯度爆炸、表徵坍塌、訓練動態
大過節的qwen發佈了image 2512，DeepSeek這邊就偷摸的在arXiv 上掛出了這篇 mHC: Manifold-Constrained Hyper-Connections (arXiv:2512.24880)，哪個正經公司在最後一天還發論文啊。 簡單的看了一下，説説我的看法： 這回DeepSeek又要對 殘差連接（Residual Connection）出手了。 現在我們模型的底層
Lux 要是一個專門用於計算機操作的基礎模型。和那些只會生成文字的 AI 不同，Lux 能看懂屏幕內容並理解自然語言描述的任務目標，然後實時操控計算機完成工作。 比如説你對電腦説"打開瀏覽器，訪問 xxx"，然後它就真的執行了：鼠標移動、圖標點擊、網址輸入、頁面滾動，整個過程和真人操作沒什麼區別。 Lux 的技術實現 Lux 不依賴 API 接口所以能在任何應用中工作：瀏覽器、編輯器、郵件
精心構造的輸入樣本能讓機器學習模型產生錯誤判斷，這些樣本與正常數據的差異微小到人眼無法察覺，卻能讓模型以極高置信度輸出錯誤預測。這類特殊構造的輸入在學術界被稱為對抗樣本(adversarial examples)。 模型將右側圖像判定為長臂猿，置信度高達99.3%。 人眼看不出這兩張熊貓圖像有任何區別，而模型對左圖的預測是熊貓，置信度57.7%顯得不太確定。中間那張看起來像噪聲的圖案其實是
當文檔庫規模擴張時向量數據庫肯定會跟着膨脹。百萬級甚至千萬級的 embedding 存儲，float32 格式下的內存開銷相當可觀。 好在有個經過生產環境驗證的方案，在保證檢索性能的前提下大幅削減內存佔用，它就是Binary Quantization（二值化量化） 本文會逐步展示如何搭建一個能在 30ms 內查詢 3600 萬+向量的 RAG 系統，用的就是二值化 embedding。 二
FAISS 在實驗階段確實好用，速度快、上手容易，notebook 裏跑起來很順手。但把它搬到生產環境還是有很多問題： 首先是元數據的問題，FAISS 索引只認向量，如果想按日期或其他條件篩選還需要自己另外搞一套查找系統。 其次它本質上是個庫而不是服務，讓如果想對外提供接口還得自己用 Flask 或 FastAPI 包一層。 最後最麻煩的是持久化，pod 一旦掛掉索引就沒了，除非提前手動存盤。 Q
過去這些年語言模型的效率優化基本圍繞着兩條主線展開：參數規模和注意力機制的複雜度。但有個更根本的問題一直被忽視，那就是自迴歸生成本身的代價。這種逐token生成的模式讓模型具備了強大的通用性，同時也帶來了難以迴避的計算開銷。 現在有一種思路值得關注：不去替換現有的優化手段，而是在上層加一個潛在空間的映射層，直接削減前向傳播的次數。 每次讓GPT-5寫封郵件模型都得一個token一個token地往外
大語言模型的文本生成方式一直都是以自迴歸為主：一個token接一個token,從左往右,生成完就定了。 但現在有個不太一樣的思路開始在研究圈裏流行起來，那就是擴散語言模型(Diffusion LMs)。擴散模型在圖像生成領域已經證明了自己的可行性,但是問題是把這套東西用到文本上一直很麻煩——訓練難、評估難、更別提怎麼集成到現有的LLM工作流裏了。 dLLM是一個開源的Python庫,它把擴
做過電力負荷預測或者交通預測朋友，大概率都處理過時間特徵。這裏最直接的做法通常是把時間（比如分鐘或小時）直接扔進模型裏。這看起來邏輯自洽，但存在這一個大坑，就是“午夜悖論”。 比如説你的模型面對兩個時間點：23:59（一天的第1439分鐘） 和 00:01（一天的第1分鐘）。在我們的認知裏，這倆只差兩分鐘，但在模型的邏輯裏1439 和 1 可是不一樣的。大多數機器學習算法（線性迴歸、KNN、SVM
Anthropic 最近放出了一個叫 Bloom 的開源框架，專門用來測試大語言模型會不會出現某些特定行為。比如模型是不是會阿諛奉承用户、有沒有政治傾向、會不會為了自保撒謊或者試圖繞過監督機制這類問題。 這個框架跟常規的評估基準不太一樣。傳統基準都是固定的測試集而 Bloom 會根據你的配置“長”出不同的評估內容，這也是為什麼叫這麼個植物學的名字。 工作流程：四個階段搞定評估 Bloom 的整個流
DeepAgents的靈感源自 LangChain deepagents，但在設計上更做減法，它強調類型安全且內置了 Docker 沙箱 2025 年的Autonomous AI Agents早就不是實驗室裏的花架子了。在現實世界的自動化流程、代碼生成工具、數據管道以及各類智能助手中都能看到它們的身影。 現在的很多主流 Agent 框架越來越重。為了用上 Agent，你往往得引入一堆沉重的
Python 對象的靈活性大家都知道，可以隨時給對象添加屬性： class User: pass u = User() u.name = "Alice" u.age = 30 但這種靈活性的代價也很大，每個普通 Python 對象都有個 __dict__ 字典來存儲屬性，對象一多內存開銷就上來了，這時候 __slots__ 就派上用場。 slots 到底在幹什麼 __sl
在計算機視覺工程落地中我們常遇到一種現象：模型在驗證集上表現完美，但是一旦部署到生產環境準確率卻莫名下跌。這種“性能衰退”往往不源於模型架構本身而是歸咎於預處理管道的脆弱性。數據類型的隱式轉換、縮放算法的細微差異、或是未被矯正的幾何形變，這些看似微不足道的工程細節往往是系統失效的根源。 相比於盲目調整超參數，建立一套確定性強的預處理流程性價比更高。本文總結了基於 scikit-image 的十個工
Gemma 3 270M是 Google 推出的一款雖小但能力驚人的開放模型。它屬於 Gemma 家族，本質上是將 Gemini 模型中使用的相同技術帶入了輕量級、可定製的形式中。 你可以在 不到一小時內完成微調，並將其大小壓縮到 300MB 以下，讓他直接在你的瀏覽器中運行。 在這篇文章中，我將展示我是如何使用 Gemma 創建我自己的 emoji 翻譯器的——這是一個將文本轉換為表情符號並在本
在深度學習落地過程中，有一個常見的誤區：一旦推理速度不達標，大家的第一反應往往是拿着模型開到，比如：做剪枝、搞蒸餾、甚至犧牲精度換小模型。 實際上生產環境中的 Python 推理鏈路隱藏着巨大的“工程紅利”。很多時候你的模型本身並不慢，慢的是低效的數據搬運、混亂的線程爭用以及不合理的 Runtime 默認配置。在不改變模型精度的情況下，僅靠ONNX Runtime (ORT) 的工程特性，往往就能
Scikit-Learn 1.8.0 更新引入了實驗性的 Array API 支持。這意味着 CuPy 數組或 PyTorch 張量現在可以直接在 Scikit-Learn 的部分組件中直接使用了，且計算過程能保留在 GPU 上。 1.8.0 到底更新了什麼？ Scikit-Learn 開始正式支持Python Array API 標準。這是一個由 NumPy、CuPy、PyTorch、J
機器學習模型處理不了原始文本。無論是線性迴歸、XGBoost還是神經網絡，遇到 "red" 、 "medium" 、 "CA" 這類分類變量都沒法直接處理。所以必須把它們轉成數字這個過程就是分類編碼。 大家入門時肯定都學過獨熱編碼或序數編碼，
