當 RAG 失效時,我們該如何讓 AI 真正“理解”企業(yè)系統(tǒng)?

0 評論 604 瀏覽 2 收藏 6 分鐘

RAG 曾是企業(yè)構建智能問答系統(tǒng)的“黃金方案”,但在復雜業(yè)務場景中,它的邊界正在顯現(xiàn)。本文將從 RAG 的失效機制出發(fā),探討如何通過 Agent 化、語義建模與系統(tǒng)協(xié)同,讓 AI 真正“理解”企業(yè)系統(tǒng),走出知識調(diào)用的淺層困境。

0. 結論先行

從“檢索即答案”到“上下文工程”:重新定義企業(yè)級 AI 的交互范式

1. 背景

在最近落地企業(yè)級智能體的過程中,我越來越清晰地意識到一個問題:我們不能指望一個通用大模型,僅憑幾段檢索到的文本,就能讓AI準確理解一個復雜、動態(tài)的企業(yè)系統(tǒng)。

我曾寄希望于 RAG(檢索增強生成)來幫助AI理解企業(yè)的一切數(shù)字資產(chǎn)。但現(xiàn)實是殘酷的:

  • 信息密度低:檢索到的文檔片段往往信息密度低且充滿噪音。
  • 結構化鴻溝:系統(tǒng)的Schema和配置規(guī)則是高度結構化的,而RAG提供的卻是非結構化文本
  • 知識更新滯后:系統(tǒng)能力不斷更新,但向量庫卻難以實時同步,導致知識嚴重滯后。

結果就是:AI 一本正經(jīng)地胡說八道,這對于容錯率極低的企業(yè)級 AI 應用來說是致命的。

2. RAG 已死?擁抱上下文工程

最近,Chroma 的創(chuàng)始人 Jeff Huber 拋出觀點:“RAG is dead”。這并非否定檢索本身,而是宣告簡單拼接文本的 RAG 范式已經(jīng)走到盡頭。他提出的替代方案是上下文工程(Context Engineering)。

這讓我開始思考:我們是否可以繞過RAG,直接為 AI 構建一個精確、動態(tài)提示詞?

于是,我嘗試了一個新思路:構建一個AI 配置中心。

3. 從“喂文檔”到“建沙盒”

我的目標很明確:實現(xiàn)一句話生成工作流(NL2Workflow),讓非技術人員也能通過自然語言指令,生成合法、可執(zhí)行的工作流。

為此,我們設計了一個核心系統(tǒng)——AI 配置中心。它不是另一個知識庫,而是一個上下文工程引擎,其核心思想是:不要讓 AI 去理解雜亂的文檔,而是為它提供一份清晰的“能力說明書”和“操作手冊”。

3.1. 能力說明書:結構化、清晰

我不再將原始配置文件扔進向量庫,而是將其解析為一系列結構化的 RESTful API:

  • GET/api/ai-config/triggers→獲取所有觸發(fā)器類型
  • GET/api/ai-config/nodes→獲取所有節(jié)點類型及其配置Schema
  • GET/api/ai-config/examples→獲取精選的高質(zhì)量工作流示例

這些 API 返回的不是自然語言描述,而是機器可讀、帶約束的元數(shù)據(jù)。例如,request節(jié)點的method字段只能是GET, POST, PUT…,且url為必填。

這相當于給 AI 一本“白名單手冊”,從根本上杜絕了幻覺。

3.2. 操作手冊:Few-shot Learning

我沒有讓 AI 從海量歷史工作流中“找相似”,而是手動維護 2-3 個高質(zhì)量的范例,作為 Few-shot Learning 的模板。

這些范例不是為了“模仿”,而是為了教會 AI:

  • 常見的節(jié)點組合模式(如“條件判斷→調(diào)用API→更新記錄”)
  • 如何正確填充復雜配置(如嵌套的filter和values)

3.3. 上下文工程:動態(tài)注入,實時同步

我使用模板引擎(如 Mustache),在運行時將上述元數(shù)據(jù)動態(tài)注入到 Prompt 中,生成最終的上下文。

更重要的是:當 n8n 平臺新增一個節(jié)點時,AI 配置中心會自動感知并更新 API,下一次 Prompt 生成時,AI 就“知道”了這個新能力。

這解決了知識更新的滯后性,實現(xiàn)了系統(tǒng)與 AI 的“共生演進”。

4. 效果與啟示

通過這套“AI 配置中心 + 上下文工程”的方案,我們實現(xiàn)了:

  • ?準確性提升:AI生成的工作流幾乎不再出現(xiàn)非法節(jié)點或錯誤配置。
  • ??可維護性增強:Prompt的維護從“手動更新文本”變?yōu)椤肮芾斫Y構化數(shù)據(jù)”。
  • ??用戶體驗飛躍:非技術人員只需說一句話,系統(tǒng)就能生成合法工作流。

5. 結語:從“AI 友好”到“工程友好”

這場實踐讓我深刻體會到:企業(yè)級 AI 落地,不是比拼誰的模型更大,而是比拼誰的“上下文工程”做得更好。

未來的 AI 系統(tǒng),不應是“黑箱猜測”,而應是“白箱協(xié)作”。我們需要的不是更多文檔,而是一個為 AI 量身打造的、動態(tài)的、可編程的認知基礎設施。

也許,這正是 Jeff Huber 所說的“RAG 之后”的下一個篇章。

本文由 @Hughugh 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!