Context One 是 Chroma 今年稍早推出的 20B 搜尋 sub-agent。CTO Hamad Bashir 上 Software Engineering Daily，跟主持人 Gregor Van 談 agent 已經用機器速度在查、在拆問題。舊的檢索基礎設施跟不上，也貴到划不來。Chroma 在做的，是把對的 context 塞進語言模型的那一層。
Gregor Van 做資安出身，當過資安、網路保險、一般軟體公司的 CTO，人在新加坡。Hamad 過去十年多半在機器學習、電腦視覺跟資料系統。Chroma 最早解的是電腦視覺的主動學習：線上系統每天看到一堆畫面，全標太貴，得挑哪些值得標。那是訓練時的資料挑選。語言模型起來之後，同一套問題搬到推論，變成搜尋：找出最相關的資料，讓下游應用把對的資訊送進模型。
庫、管線，再加上一個會搜的小模型
Chroma 核心要解的，就是讓模型拿到它需要的 context。平台上三塊可以拼在一起。
多數人碰到的是核心資料庫 ChromaDB。Hamad 說它現在是跟語言模型一起用得最廣的資料庫之一。資料灌進去之後，可以用向量搜尋、全文搜尋、metadata 搜尋，把可能相關的東西撈出來。
旁邊一塊叫 Sync，託管的 ETL。開發者多半不想自己做這條管線。資料要進搜尋庫，得清、轉成能向量化的形狀，最好再補 metadata，高吞吐時很煩。Sync 就是做這件事。
今年稍早他們推出 Context One。Hamad 說這多半還是研究，正在往產品化走。它是一個做 agentic search 的模型。常見的 RAG 是搜一次、把結果直接塞進 context window。Agentic search 是把一句高階的英文問題拆成對搜尋系統的低階查詢，讀文件、再發查詢、再讀，直到自己覺得夠了。人查資料也是這樣，不會打一次 Google、看前十個連結就收工。用前沿大模型做這件事很貴。Context One 用強化學習訓練，Hamad 的說法是在這套流程上跟前沿模型一樣好，成本低一個數量級，速度高一個數量級。對照 Opus 4.6，他們跑在大約每秒 400 到 500 token，Opus 大概每秒 40 到 80。品質對得上，答案來得快，也便宜。
AI 工作負載要很多小 index
他們一開始並不想做資料庫。Gregor 說他看這個領域，向量搜尋熱過一陣、冷過一陣，現在又回來；Hamad 當時用的就是市面上現成的向量搜尋。後來發現，那些系統幾乎都是為舊搜尋工作負載設計的：一個非常大的 index，一百萬份文件、十億筆資訊，全塞在一起。再加五十萬筆，就得重切 cluster、加減節點、重新平衡，操作很重。
AI 應用幾乎是反過來。index 切得很碎：每個客戶一個、每個團隊一個、每段聊天紀錄一個、每個 agent 一個。系統得存非常大量彼此獨立的 index，搜尋還得準。全塞進同一個 index，一是得一直把整坨掛在線上，二是向量搜尋擠在一起準度會掉。向量搜尋不擅長靠查詢時過濾來做分區，該在建 index 時就硬切開，邏輯上分開存。資料有這種可分區的結構，就該做很多小 index，品質跟成本的取捨會好很多。ChromaDB 就是因為沒有現成方案把這件事做好，才自己動手。
底下那層是物件儲存。AWS S3、GCP GCS、Azure 都開始支援 conditional write；Hamad 特別講 AWS，這東西 2024 年才出來。有了它，才能在物件儲存上蓋資料庫，經濟帳才撐得住「每個客戶、每個團隊、每個 agent 各有一份 index」。以前用三副本磁碟或 NVMe SSD，有些產品根本做不起來。他們先做給自己用，要在推論時決定塞什麼進語言模型。
Agent 起來之後，讀的壓力更大。Agent 會平行發五條查詢。人覺得快，大概是三十秒一次；agent 樂意每一到兩秒就查，而且每次五條、六條並行。核心架構如果是無狀態、底下是共享儲存，加節點就能消化讀。Hamad 說，當初蓋在物件儲存上，沒預料到這層彈性，事後卻很受用。
Context Rot：窗愈滿，模型愈差
Chroma 去年出過一篇 Context Rot，主持人說大約是 2025 年 6、7 月。Hamad 說，多數人憑感覺就知道 context 一肥，模型會變差；這篇是用實驗把這件事量清楚。做法很窄：反覆塞同一個詞，問模型「stop」出現在哪；或者把大海撈針的題目打亂順序，丟一堆文件進去，看它找不找得到那根針。結果在數萬 token 這個量級出現很陡的掉落，今天的前沿模型也一樣。報告出來之後又過了大約三代、或幾次小改款，掉落還在。
這逼出一件事：context window 裡放什麼，得有紀律。他們接受 context engineering 這個詞，講的就是下一輪、或下面幾輪要成功，該選什麼進去。查什麼、資料怎麼排、怎麼 prompt、模型能碰到哪些資料，都算。就算有一天 context rot 被解掉，無限把 window 拉大，成本也吃不消。這類系統很容易在很短時間把錢燒光。
這套實驗當時測了十八個模型，Anthropic 那些大的、也有很多開權重模型。Hamad 說對。當時開權重跟閉源前沿差很明顯；過去一年開權重追很快。他們內部還會在新模型出來時跑同一套，有些任務上開權重已經能勝過部分閉源。他講得很明白：這是一套很刻意、很窄的實驗，當健身房用。
干擾項一加，模型要忽略「看起來像對、但其實不是」的資訊，能力就往下掉。兩個事實沒有互相打臉、卻在講同一件事的不同面向，模型很不會拆。他舉的例子是問喬治亞的人口，文件裡同時有國家 Georgia 跟美國喬治亞州，題目已經指定要州，模型還是可能混。真實世界更常見：兩個人同名，把其中一人的工作安到另一人頭上，公司裡問錯人；寫程式的 agent 看到兩套認證系統，問的是其中一套，卻鑽進另一套。他們想量的就是：表面像、其實無關的資訊，模型能拆到什麼程度。
大模型派出的搜尋員
Context One 的用法是掛在更大的模型下面當 sub-agent。Codex、Claude Code、Cursor，還有不少開源 harness，已經會派出另一個語言模型去做一件事。這裡那件事是：把執行任務可能需要的資訊找出來，把 context 帶回來。它被設計成通用的搜尋 sub-agent，給任何大型推理模型用。
想法很傳統：把該分開的關心點分開。搜尋這件窄事，小模型就夠。要懂使用者意圖、拆成查詢、判斷文件相不相關、反覆做。多數時候要的是把這些事做很快，智力不必拉到前沿。他們用每秒多少 token 來想這件事。下一代甚至在想怎麼用平行跟分片去應付很大的語料。Sub-agent 在背景把它覺得相關的文件找回來，交給比較大的推理 agent 去做它真正要做的事。
再往前一步，大模型當編排者、規劃者，底下是一群小模型，平行派出。Hamad 說他們很信這套，寫程式的系統已經在這樣跑，他覺得接下來一年幾乎每個 agent 都會走到這條路上。Context One 要卡的就是這個位置。它的工作是搞清楚該找什麼、找到之後交出去。
主持人把工具列成向量加 BM25、hybrid search、regex-grep、讀文件，以及 prune chunks。Hamad 自己收得更短：標準的 agentic search harness 其實只要兩樣，搜，以及把結果取回來，像拿到十條藍連結再點進去。他們多加的，是自己編輯 context，也就是主動管 context。
長 context 現在主流是 compaction：coding agent 把 window 用滿了，就摘要、壓縮。小模型做這件事很容易丟東西，尤其它是被大模型派出去做一件很窄的事。他們改成邊走邊改自己的 context。Agentic search 很吃 token，碰到的文件都會進 window，很快堆出很大的量。Prune chunks 讓模型回頭把自己 context 裡的文件拿掉。這是 KV cache 連貫性跟整體 token 用量的取捨。模型判斷相不相關、把先前的資訊拿掉，這件事它本來就得會，否則搜尋做不成。
難的是：搜尋前期看起來不相干的文件，後面可能突然有用。訓練就得覆蓋夠多種相關程度，把回傳的文件擾動成夠難的例子，讓 prune 的時機準。底模是 GPT-OSS 20B。剛訓練時，prune 大約八成會選對該拿掉的文件，等於這工具對底模根本不能用，直接吃掉兩成準度。訓練完，在各種任務上大約九成五以上；內部最近的 checkpoint 接近九成七、九成八。剩下的錯，多半來自搜尋本身。模型判斷準不準、相不相關，已經相當好。
自己剪 context，整體 token 用量少很多，推論也快，因為 window 隨時壓在大約三萬二千 token。Prefill 跟 decode 都相對快。模型夠小，可以接受因為 prune 而反覆付 prefill。何時剪、剪多少，還有很多細節。他們也開始把延遲當成訓練目標，讓模型在訓練時自己找對速度也划算的 prune 策略。Harness 這邊真正多出來的想法，是模型改自己的 context、改自己的歷史。
節目裡提到，沒多久之前的數字，20B 的 Context One 在他們多數基準上對得上 Opus 4.5、Sonnet 4.5、Gemini 3.1 Pro。Hamad 接著講為什麼特化過的小模型做得到。
搜尋是一串窄任務
他把搜尋拆開之後，覺得行為比推理值錢。搜尋有一套可跟的程序，是很多很窄的子任務串起來：高階問題拆成對搜尋系統的低階查詢計畫；看一頁判相關；看一頁決定下一輪查什麼；對手上這批結果再做一次不一樣的相關判斷。這些可以分開用訓練例子練。
Context One 的課程是分階段的。早期只給一跳、兩跳就能滿足的簡單題，後面再把難度拉開。訓練也不只強化學習。前面還有一輪監督式微調，用合成資料，以及從開權重模型蒸餾出來的行為。光是把那些行為蒸進小模型，表現就會跳一截。先把「這種情況該怎麼做」的先驗塞進去，後面比較好優化。
光是教會它平行呼叫工具，就能少很多輪才找到資訊。GPT-OSS 20B 原生不會平行 tool call。做一點 SFT，從資料裡教會這個行為，強化學習還沒上，它就已經會用、而且用得很好。
這類任務不需要很多推理容量，也不需要很多細微決策。世界知識確實有幫助，對某個主題記得多，查詢會出得比較好，穩態下大模型大概永遠贏小模型。小模型卻便宜到可以用 LoRA 微調。語料夠窄，很快就能針對那份語料個人化。給它一份語料地圖，或教會它那份語料的詞彙，搜尋會準很多。人搜自己的 Google Drive 也是這樣，因為已經知道裡面有什麼。
Apache，本機就能跑
Context One 的權重用 Apache 授權開源。Chroma 是開源公司，核心資料庫也是 Apache 2.0。Hamad 說自己進 Chroma 之前不算開源死忠，這幾年才變成很堅持該開的東西就開。公司裡也有這份信念。
實際理由很直接：開源才有更多人用，才有人告訴他們哪裡好、哪裡爛，才有人把它接到他們自己接不到的地方。模型很小，本機跑得動。Chroma 當初在市場上長起來，靠的就是本機版資料庫。他們喜歡開發者在筆電、在家裡的機器上就能摸到接近前沿的東西，不必先花一大筆錢。之後每一個模型是不是都開源，他不打包票；至少現在，他看不到不繼續開的理由。他們自己訓練 Context One 就用了開權重模型，平常也在用。新聞上好像世界要被 AI 蓋過去了，他覺得還很早，現在不該用零和的方式想這件事。
開發者多半從本機嵌入式資料庫開始：pip install 一個套件，Jupyter 或 TypeScript 裡，機器上就跑起來了。原型做完，有 CLI 可以把資料推上雲。跟傳統關聯式資料庫不太一樣，這類應用常常會先整理一份知識庫或資料集，再從 staging 推到正式環境。
上正式有兩條。一條直接用資料庫，自己控切塊策略、embedding 模型、各種參數。這幾年實務慢慢收斂：稀疏向量配 splayed；dense embedding 要夠好、但不必太大。他說用不到 4096 維，比較小的維度準度差不多，成本低很多。不想自己選，就用 Sync：資料丟進 S3、上傳檔案，或接他們支援的來源，像 GitHub、網站，之後還會再加一堆上游連接器，來源跟 Chroma 會自動對上。
Context One 通常是後面才接。Agentic search 還新，多數人產品做到後期才認真想低延遲、高品質搜尋。放出來之後，有人開始用它當產品起點。一旦假設查詢是 agent 在做，產品會長得不一樣。有人問：那人幹嘛還自己改資料？已經有產品不准使用者直接改，只准透過模型改，因為他們覺得模型比較會在資訊空間裡走對路、改對地方。表單、勾選、拉桿不必樣樣都有，很多事可以直接用自然語言推進 agent。
一萬筆，Postgres 就夠
資料量小，Hamad 說丟進 Postgres 就行。只有一萬筆紀錄，大概不需要水平擴出去的 serverless 搜尋引擎。企業要不要 BYOC，是另一件事。Hamad 說 Databricks 早期做過混合部署，後來被問若重來會改哪兩件事，其中一件就是不做混合、直接走另一條。他也說這可能是事後才講得輕鬆，沒做混合，說不定根本走不到後來。Chroma 的 BYOC 是把程式部署進客戶 VPC，控制面留在自己這邊，拿回觀測資料來操作、更新、擴縮。客戶拿到託管服務的體驗，自己不用跑基礎設施。套 Terraform、跑 Helm chart 就能起來，day two 由他們團隊扛。這件事他們從第一天就打算做；不做進架構裡，後面要補非常難，整套設計都卡在這上面。團隊當初很難被說服，因為這樣蓋很痛、速度很慢，系統邊界也會畫得不自然。
除非這件事對生意成長是核心，否則他不建議做。對他們重要，是因為核心資料庫真正有用的客戶在大規模。他給 YC 那屆創辦人的建議是：做之前先確定這件事能賺很多錢、而且能重複部署，否則是很大的分心。買家這兩年開始會推，因為過得了資安跟合規。BYOC 剛出現時，網路上不少有名的人覺得這是最蠢的部署模型。它比較像組織稅：讓合規、資安睡得著，讓你保有控制感。是不是真的比較安全，還是得自己看裡面。
控制面仍在 Chroma 這邊，有客戶連遙測都不想讓他們碰。產品沒有基本遙測就跑不起來。他們這邊存的是 metadata：系統裡有什麼資料、用量、版本跟 epoch 計數，沒有直接暴露私人資訊。因為開源，控制面程式可以直接丟給客戶看 schema。Slack 上有人問存了什麼，他們把程式貼進去，叫 agent 把相關檔案走一遍，列出清單，答案對得回程式。資料平面預設不開埠，反向隧道，由資料平面向外連，他們不伸手進去。遙測先緩衝再推出去。操作也不是對資料平面發 POST，裡面有個服務在輪詢，把操作拉下來做。這是很怪的做法，零件很多，只為了在叢集裡做一件本來很單純的事。他們蓋在 Kubernetes 上，還能借宣告式的鉤子，仍然比直接發請求重很多。他說如果進公司六個月才有人說要做 BYOC，他會直接回做不到。
語言模型當 CPU，旁邊還需要一塊碟
Postgres 最近又熱，有人說 pgvector 就夠了。Hamad 的判斷是：語言模型永遠需要有人管它此刻該知道什麼。去 ChatGPT 問今天行程，就算接了 MCP，很多時候還是沒叫對工具、沒在對的時間講對的話。把對的資訊送進模型，這件事不會消失。
他拿 CPU 跟檔案系統來比。語言模型是 CPU，旁邊有一塊碟。碟裡面很複雜，介面、控制器、作業系統、韌體都在。Chroma 信的就是那層介面：一邊是用自然語言處理資訊的系統，一邊是決定模型該看到什麼、該存什麼、哪些該更新、該跟既有資訊合併的子系統。今天看起來很像資料庫。那一家做資料庫的公司為什麼自己訓練模型？因為他們覺得很快就不會再把資料庫跟智力拆成兩套，智力會跑在資料庫裡面，資料庫靠有智力的子系統做事。兩件事得一起想，為了效能，也為了懂這塊領域。
把大量資料搬來搬去、轉成各種下游要的表示、做 ETL、重排格式、重建 index、重新解析，都很貴。如果能在一個地方管完，用物件儲存、共享儲存層，把計算搬近資料，就可以在資料上跑非同步的語言模型工作，也可以讓帶查詢 index 的節點跟 GPU 放在一起，GPU 不必打遠端服務，打的是本地模型。他說今年大家當消費者用的模型，很可能跑到每秒一千 token；去年還在每秒一百。再過幾年每秒一萬，他覺得可以想像。今天的搜尋系統假設打一槍網路、等搜尋回來沒關係，因為模型很慢。模型不會一直慢。智力和資料該走低延遲路徑，將來甚至可能繞過 CPU，在 GPU 上直接起一個子 kernel 搜 index，再把資料餵回模型。
長期他們想做的，是一份非結構化資料丟進去，任何查詢都能在出口被滿足。他不覺得那套東西會長得像 Postgres，跟今天也會差很多。先把抽象跟積木放對，也許以後有資格去做那套系統。
開發者要上手，Hamad 說 pip install chromadb，再 chromadb run 就夠。想看更多，去 chroma.com。名字怎麼來的？短、好念、好記，聽起來順。