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

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

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

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

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

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

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

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

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

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

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

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

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