八年前，RAG（檢索增強(qiáng)生成）還只是個(gè)學(xué)術(shù)概念。今天，幾乎每個(gè)想在大模型里用內(nèi)部數(shù)據(jù)的企業(yè)，都在重復(fù)造同一套輪子。

開發(fā)者Anmol Sharma最近開源了一個(gè)叫ORAG的項(xiàng)目。不是什么大模型，也不是新算法——而是一個(gè)用TypeScript寫的組織級(jí)RAG和MCP平臺(tái)。他的出發(fā)點(diǎn)很直接："每個(gè)團(tuán)隊(duì)在用內(nèi)部數(shù)據(jù)做AI功能時(shí)，都會(huì)撞上同一堵墻。"

這堵墻是什么？大模型不知道你的數(shù)據(jù)意味著什么。不知道誰擁有它，不知道它是否可信，更不知道某個(gè)AI代理該不該訪問它。結(jié)果是：AI給出自信但錯(cuò)誤的答案——這比沒有答案更糟。

Sharma認(rèn)為這是上下文層的問題，而非模型問題。模型本身沒問題，缺的是讓模型"理解"組織數(shù)據(jù)的中間層。ORAG的架構(gòu)分成三層：連接層、協(xié)議層、治理層。

連接層負(fù)責(zé)接入Notion、Confluence、S3、GitHub等數(shù)據(jù)源，處理分塊、嵌入和向量檢索。Sharma給檢索延遲定的目標(biāo)是50毫秒以內(nèi)。協(xié)議層把檢索能力暴露為MCP（模型上下文協(xié)議）服務(wù)器——一個(gè)配置文件，就能讓任何AI代理以結(jié)構(gòu)化、帶權(quán)限的方式訪問組織知識(shí)庫。治理層則處理角色權(quán)限、審計(jì)日志、團(tuán)隊(duì)工作區(qū)和SSO單點(diǎn)登錄。

技術(shù)選型上，ORAG完全基于TypeScript生態(tài)。連接層用Ingestion SDK，向量數(shù)據(jù)庫選的是Pinecone，MCP服務(wù)器層用FastMCP，治理層則依賴Clerk做認(rèn)證、Prisma做ORM、PostgreSQL持久化數(shù)據(jù)。

Sharma特別強(qiáng)調(diào)了MCP的價(jià)值。沒有它，每個(gè)新代理、每個(gè)新數(shù)據(jù)源都要寫定制膠水代碼：定制連接器、定制認(rèn)證、定制錯(cuò)誤處理。MCP給AI代理提供了一個(gè)標(biāo)準(zhǔn)接口，"一個(gè)配置，你的代理就能像調(diào)用其他類型化API一樣調(diào)用你的知識(shí)庫，自帶流式傳輸、認(rèn)證和可觀測(cè)性"。

這也是ORAG"可組合性"的來源：數(shù)據(jù)源只接一次，需要它的代理直接指向MCP服務(wù)器即可。

不過Sharma坦承，真正耗時(shí)的不是搭架子，而是生產(chǎn)環(huán)境的細(xì)節(jié)。筆記本里能跑的RAG很簡單，生產(chǎn)環(huán)境能用的RAG很難。分塊策略比多數(shù)人想象的更重要，檢索評(píng)分需要可觀測(cè)，延遲必須在負(fù)載下可預(yù)測(cè)。

他在可觀測(cè)層投入的時(shí)間最多：完整的請(qǐng)求追蹤，覆蓋檢索、工具調(diào)用和補(bǔ)全；延遲分解和檢索質(zhì)量評(píng)分，集成在一個(gè)視圖里。"沒有這些，性能下降時(shí)你就是在盲飛。"

權(quán)限控制是另一個(gè)關(guān)鍵戰(zhàn)場(chǎng)。Sharma的判斷很直接："企業(yè)AI真正崩掉的地方，不是模型，不是檢索，而是'這個(gè)代理能不能看這份數(shù)據(jù)'。"審計(jì)追蹤、工作區(qū)隔離——這些才是區(qū)分演示項(xiàng)目和可信生產(chǎn)系統(tǒng)的分界線。

ORAG目前已上線，GitHub倉庫也開放。Sharma的定位很明確：大多數(shù)AI工具聚焦模型層，但他想建的是上下文層的基礎(chǔ)設(shè)施——讓模型拿到"可信、受控、相關(guān)"的上下文。這是個(gè)"更難、更不起眼的問題"。

企業(yè)AI的競(jìng)爭，正在從"誰的模型更強(qiáng)"轉(zhuǎn)向"誰能讓模型用對(duì)數(shù)據(jù)"。ORAG的賭注是：后者才是基礎(chǔ)設(shè)施的缺口。