在人工智能飛速發(fā)展的當(dāng)下，AI正在深刻改變我們的工作方式，甚至有可能替代部分人類的工作。然而，AI的訓(xùn)練和發(fā)展并非孤立存在，它背后依賴的是大量的行業(yè)知識（KnowHow）和數(shù)據(jù)。本文將深入探討如何通過RAG（Retrieval-Augmented Generation，檢索增強生成）技術(shù)，將行業(yè)經(jīng)驗與AI相結(jié)合，實現(xiàn)知識的可信化和結(jié)構(gòu)化沉淀。

對AI項目有理解的同學(xué)會有深刻認(rèn)知，當(dāng)前AI應(yīng)用的核心其實全部在圍繞幻覺與模型增強兩點做展開。

而這在積累層面的核心是行業(yè)KnowHow，其最終體現(xiàn)為公司的結(jié)構(gòu)化數(shù)據(jù)；在技術(shù)方面以RAG與模型訓(xùn)練為主。

并且公司會“樂此不?！钡淖鲞@方面的調(diào)優(yōu)，因為從模型層面來說，這些工程應(yīng)用的細(xì)節(jié)，基座模型很難兼顧處理。

而數(shù)據(jù)一塊非一朝一夕之事，所以很多公司的關(guān)注點全部放在了RAG技術(shù)的平臺化或者做延伸，阿里的KAG框架就是這類產(chǎn)物。

后續(xù)我們會持續(xù)討論類似這種RAG框架，包括DeepSearch、LazyGraphRAG等。而今天我們先來說說think的問題。

一、think變成習(xí)慣

由于實際效果或者行業(yè)教育，人們已經(jīng)習(xí)慣看到界面中出現(xiàn)長篇大論的“思考內(nèi)容了”，甚至他們會主動去學(xué)習(xí)這個內(nèi)容，覺得是一種進(jìn)步或享受。

之前AI聚會明叔就一再強調(diào)think是非常好的創(chuàng)新，但宜博會站在技術(shù)實現(xiàn)角度認(rèn)為他是一種工程優(yōu)化或者工程創(chuàng)新，真實情況也如宜博所述，DeepSeek與4o的例子：

請按以下格式回答問題：

##思考過程##

1. 分析需求：首先我會理解用戶的核心訴求是…（拆解隱藏需求）

2. 知識檢索：關(guān)于這個問題，我需要調(diào)用的知識包括…（列出相關(guān)領(lǐng)域）

3. 邏輯推演：可能的解決路徑有： – 方案A（優(yōu)勢/劣勢） – 方案B（適用條件分析）

4. 風(fēng)險評估：特別注意…可能存在…認(rèn)知偏差

5. 自我驗證：通過…方法可以驗證結(jié)論的可靠性

##最終答案##

（經(jīng)過上述思考后的最佳方案）

問題：管理的本質(zhì)是什么

從大模型特性來說，通過提示詞的方式雖然能達(dá)成目的，但沒有大量高質(zhì)量數(shù)據(jù)微調(diào)后達(dá)成的效果（主要體現(xiàn)在泛化與學(xué)習(xí)這個維度）。

二、RAG的切入

當(dāng)然以上僅僅是非常淺顯的描述，實際在使用過程中，差距很大，比如我這里給出一段法律用于強化學(xué)習(xí)的片段：

為什么會著重介紹這些內(nèi)容呢，因為無論是對大模型直接的使用還是微調(diào)都是無法溯源的，而無法溯源的東西，都會被懷疑成不可信，于是RAG的含金量還在上升，特別在think里面具備溯源的信息，表明對哪些信息的引用。

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

比如以下文字就特別讓人安心：

根據(jù)《勞動合同法》第三十條規(guī)定，“用人單位未按照約定支付勞動報酬，勞動者可以解除勞動合同。” 同時，根據(jù)最高人民法院的相關(guān)判例[2020]XX法判字第999號案件，法院認(rèn)定雇員在工資未按時支付的情況下有權(quán)解除合同，并獲得補償。 因此，依據(jù)這些法律條文和相關(guān)司法解釋，雇員可以依法解除勞動合同，并要求支付相應(yīng)的補償。

在推理大模型的框架下，R1越發(fā)期待用戶提示詞的手法能像描述需求一樣，不僅舉報指令，還有完整的上下文，不僅提供問題還要提供問題的背景信息，這個拆解過程與5W2H很是類似，如果再加上權(quán)威引用，那就更妙了！

三、RAG本質(zhì)：可信化解構(gòu)

邏輯上以下四個問題，模型都無法解決，越是大的模型越難解決：

1. 領(lǐng)域內(nèi)部知識庫，比如公司、醫(yī)院內(nèi)部知識庫如何AI化；
2. 信息過時，雖然模型信息更新迅速，但其信息依舊有一些滯后性，這對于被抖音教育的各位，顯然是不夠的。雖然有網(wǎng)頁搜索功能但其成本和質(zhì)量還需要做技術(shù)突破；
3. 幻覺，這應(yīng)該是模型最難的問題，特別是參數(shù)量大的問題，在不同領(lǐng)域之間源數(shù)據(jù)就可能產(chǎn)生邏輯層面的沖突，暫時看來能避免、難以根治，比如領(lǐng)域知識的模糊泛化（法律條文誤讀風(fēng)險達(dá)37%）、決策過程的不可追溯（醫(yī)療診斷錯誤無法溯源）；
4. 安全，因為模型海量數(shù)據(jù)來源于網(wǎng)絡(luò)，那一定會有傾向性，比如R1模型在男性傾向性上就很大，如果做心理類咨詢，多半是不能直接使用的；

RAG通過動態(tài)知識注入+向量檢索+溯源標(biāo)記構(gòu)建三重防線以解決上述問題，其目的只有一個：用用戶相信我的回答，并且讓自己相信產(chǎn)品的回答！以法律場景為例：

A[用戶提問] –> B(法條向量庫)
B –> C{相似度閾值>0.82}
C –>|是| D[返回民法典第1073條]
C –>|否| E[觸發(fā)人工審核]
D –> F[生成帶條款編號的解析]

而RAG技術(shù)在每個公司都有一個持續(xù)增進(jìn)的過程，大概是這樣的：

以下是傳統(tǒng)提示詞工程 與 結(jié)構(gòu)化Think框架的一些對比：

# 傳統(tǒng)方式
prompt = f”請詳細(xì)解釋管理的本質(zhì)，需要包含經(jīng)典理論案例”

# Think框架
think_template = {
“分析需求”: “識別用戶的知識層級（學(xué)生/管理者）”,
“知識圖譜”: [
“德魯克MBO理論”,
“明茨伯格管理角色”,
“華為鐵三角案例”
],
“推理約束”: “避免混淆領(lǐng)導(dǎo)與管理的區(qū)別”,
“溯源要求”: “標(biāo)注理論出處與案例來源年份”
}

其實所謂可信度也就是一個感覺罷了，不過是一個評價指標(biāo)，我隨便都可以胡謅幾個玄的：

• 時空錨點：法律條文需標(biāo)注”2023年修訂版《民事訴訟法》第58條”；
• 置信度標(biāo)注：醫(yī)療建議注明”基于2024年NEJM論文，置信度89.7%”；
• 反事實校驗：”如果采用泰勒科學(xué)管理理論，可能產(chǎn)生哪些現(xiàn)代管理沖突？”；

這里的核心依舊是行業(yè)KnowHow的數(shù)字化沉淀。

四、數(shù)字化沉淀

其實所有的RAG本質(zhì)都是結(jié)構(gòu)化的數(shù)據(jù)庫，只不過這個庫能到什么程度端看行業(yè)認(rèn)知以及持續(xù)建設(shè)情況，一般來說有四個評價維度：

1. 基礎(chǔ)圖譜

比如醫(yī)療領(lǐng)域基于ICD所做的疾病關(guān)系，很多CDSS的底層就是圖譜；

金融領(lǐng)域也有FIN-NLP金融術(shù)語體系；

2. 流程規(guī)則

與其說流程規(guī)則不如說SOP，比如：化療方案決策樹、信貸審批流程圖等。

邏輯上，只要能SOP就能數(shù)字化，能夠數(shù)字化就一定能夠AI化。

3. 數(shù)據(jù)更新

基礎(chǔ)圖譜只是第一步，更重要的是持續(xù)的更新，比如如何用專家會診記錄、操盤手交易日志分析等數(shù)據(jù)去持續(xù)自動化更新基礎(chǔ)庫，這是關(guān)鍵。

4. 異常處理

一定會有跳出圖譜框架、SOP框架的行為，我們這里稱之為AI意圖溢出Case，這種Case要有專業(yè)的預(yù)案，要么放給大模型處理，嚴(yán)謹(jǐn)點就不處理。

其本質(zhì)是黑天鵝事件，這種Case是系統(tǒng)升級的關(guān)鍵。

為了幫助各位理解，這里做更深入點的介紹：

5. 基礎(chǔ)庫案例

比如常見CDSS案例：ICD-11疾病分類本體

# ICD-11本體片段示例
class 疾病實體: def __init__(self):
self.名稱 = “冠狀動脈粥樣硬化性心臟病”
self.編碼 = “BA41.0”
self.父節(jié)點 = [
“心血管疾病”,
“慢性病”
]
self.關(guān)聯(lián)癥狀 = [
“胸痛”,
“呼吸困難”
]
self.診斷標(biāo)準(zhǔn) = {
“必要條件”: [
“心電圖ST段改變”,
“心肌酶升高”
],
“排除條件”: [
“應(yīng)激性心肌病”
]
}

這種是最理想的RAG數(shù)據(jù)源，比如：當(dāng)AI處理”患者主訴胸痛”時，能自動關(guān)聯(lián)到冠心病診斷路徑，而非停留在字面理解。

再列舉個金融案例，F(xiàn)IN-NLP金融術(shù)語體系，會有很多黑話：

• 銀行語境：收益互換 = 利率風(fēng)險管理工具；
• 投行語境：收益互換 = 結(jié)構(gòu)化衍生品；
• 監(jiān)管文件：收益互換 = 需備案的場外交易；

其底層依舊是數(shù)據(jù)庫的結(jié)構(gòu)化和后續(xù)的檢索。

6. 流程規(guī)則

醫(yī)療案例：化療方案決策樹

傳統(tǒng)依賴大模型跟醫(yī)生靠自覺沒什么兩樣，但如果遵循一套SOP，其下限就能得到充分保障：

graph TD A[患者特征] –> B{癌癥類型}
B –>|乳腺癌| C[檢測HER2表達(dá)]
C –>|陽性| D[曲妥珠單抗方案]
C –>|陰性| E[評估化療敏感性]
E –>|敏感| F[AC-T方案]
E –>|耐藥| G[基因檢測驅(qū)動]

這里的SOP還能多樣化，可以是協(xié)和醫(yī)院頂級專家的決策模式、也可以是華西的決策邏輯，其本質(zhì)都是可復(fù)用的算法。

信貸審批流程圖也是同樣，其規(guī)則是很簡單的：

1. 1.0時代：收入證明 > 2萬 → 通過；
2. 2.0時代：多頭借貸數(shù)據(jù) + 手機行為分析 → 風(fēng)險評分；
3. 3.0時代：供應(yīng)鏈數(shù)據(jù)交叉驗證 + 工商信息動態(tài)監(jiān)控；

我的一個咨詢客戶通過分析企業(yè)主抖音賬號經(jīng)營數(shù)據(jù)（非結(jié)構(gòu)化→結(jié)構(gòu)化），發(fā)現(xiàn)隱性經(jīng)營能力證據(jù)。

7. 飛輪系統(tǒng)的雛形

AI產(chǎn)品在使用過程中會產(chǎn)生各種數(shù)據(jù)，而這些數(shù)據(jù)都應(yīng)該反哺系統(tǒng)本身。

比如傳統(tǒng)專家的會診意見以自由文本形式散落在病歷系統(tǒng)中，我們應(yīng)該將其結(jié)構(gòu)化：

{
“病例ID”: “C202405001”,
“爭議點”: “肺部結(jié)節(jié)性質(zhì)判定”,
“張院士意見”: {
“觀察維度”: [
“CT值變化曲線”,
“血管穿透特征”
],
“推理邏輯”: “雖體積<1cm但分葉征明顯→建議PET-CT”,
“反共識說明”: “不同于指南但符合個人200例類似病例經(jīng)驗”
},
“知識標(biāo)簽”: [
“影像學(xué)特征”,
“診斷決策邊界”
]
}

類似這種數(shù)據(jù)如果有個1000份，便會有巨大意義，李飛飛的1000個微調(diào)數(shù)據(jù)樣本，其實也是精挑細(xì)選出來的。

再比如快遞員配送日志分析：

# 數(shù)據(jù)庫原始字段
delivery_log = {
“運單號”: “SF123456”,
“配送員”: “王師傅”,
“派件時間”: “2024-03-15 14:30”,
“包裹重量”: 3.2, # 公斤
“簽收狀態(tài)”: “已簽收”
}

備注文本 = “客戶電話要求放菜鳥驛站，因家中老人住院需陪護(hù)”

# NLP解析結(jié)果
deep_info = {
“需求類型”: “變更收貨地址”,
“原因分類”: “家庭突發(fā)事件”,
“客戶畫像標(biāo)簽”: [
“家有老人”,
“醫(yī)療相關(guān)”
]
}

def 挖掘暗模式(配送記錄):
# 關(guān)聯(lián)外部數(shù)據(jù)源
天氣數(shù)據(jù) = 查詢氣象局API(配送記錄[“時間”])
交通數(shù)據(jù) = 獲取交警事故通報(配送區(qū)域)
社區(qū)公告 = 爬取街道辦公眾號(日期)

# 構(gòu)建關(guān)聯(lián)模型
if 天氣數(shù)據(jù)[“降雨量”] > 50mm:
return “極端天氣影響系數(shù)”
elif “道路施工” in 社區(qū)公告:
return “基礎(chǔ)設(shè)施變更預(yù)警”
elif 配送延遲 and 交通數(shù)據(jù)[“事故數(shù)”]激增:
return “突發(fā)交通事件響應(yīng)”

# 輸出示例 暗知識標(biāo)簽 = “03-15暴雨紅色預(yù)警期間，繞行導(dǎo)致平均配送時長增加22分鐘”

最終業(yè)務(wù)場景應(yīng)用：

A[新訂單] –> B{解析地址}
B –> C[歷史配送記錄]
C –> D[天氣預(yù)警數(shù)據(jù)]
D –> E{生成策略}
E –>|晴天| F[常規(guī)路線]
E –>|暴雨| G[自動切換防澇路線]
E –>|社區(qū)施工| H[推送物業(yè)聯(lián)絡(luò)人電話]

這個案例通過層級化數(shù)據(jù)分析，結(jié)合天氣、交通等外部因素，優(yōu)化配送路徑、提升客戶體驗和資源調(diào)度，能有效降低延誤風(fēng)險和提高服務(wù)效率。

總之，可以看出，所有的這些都是業(yè)務(wù)的規(guī)則理解后的實踐，都是工程層面的優(yōu)化，其本質(zhì)是行業(yè)KnowHow。

最后是超出AI試圖識別的其他處理，大家自己思考吧…

五、結(jié)語

AI項目，本質(zhì)是一場對抗幻覺/輸出增強的持久戰(zhàn)。當(dāng)前這場戰(zhàn)役的主戰(zhàn)場，正從“大模型軍備競賽”轉(zhuǎn)向“行業(yè)KnowHow的數(shù)字化深潛”。

誰能將行業(yè)經(jīng)驗編碼為可檢索的知識圖譜，比如將法律條文的微妙解釋轉(zhuǎn)化為可溯源的推理鏈條，誰就能在AI落地的“百團(tuán)大戰(zhàn)”中搶占先機。

RAG的技術(shù)其實很簡單，其意義在于打開AI黑盒，讓知識可以溯源。

比如當(dāng)《勞動合同法》第三十條與字節(jié)跳動的OKR系統(tǒng)在同一向量空間出現(xiàn)，當(dāng)?shù)卖斂说墓芾碇腔弁ㄟ^Think框架的推演不停的以分身的形式出現(xiàn)，其意義可不僅是技術(shù)迭代，他帶來的可能是認(rèn)知范式的升維！

隨著RAG類技術(shù)在各行各業(yè)中的應(yīng)用加深，我們正在見證從“泛化的模型”向“行業(yè)定制化模型”轉(zhuǎn)型的過程。

從醫(yī)療領(lǐng)域的個性化診療方案，到金融領(lǐng)域的風(fēng)險控制決策，再到法律行業(yè)中對條文的精準(zhǔn)解讀，AI在行業(yè)中的應(yīng)用將不再是單一的信息處理工具，而是深入行業(yè)骨髓，成為決策支持的核心動力。

但技術(shù)的背后，依然是行業(yè)KnowHow的深度挖掘與沉淀。如何將行業(yè)的精髓轉(zhuǎn)化為可持續(xù)發(fā)展的數(shù)字資產(chǎn)？如何構(gòu)建起具備自我迭代能力的知識圖譜，并確保其隨著行業(yè)發(fā)展不斷更新和完善？這些問題不僅挑戰(zhàn)著技術(shù)的實現(xiàn)，也考驗著行業(yè)參與者的眼光與耐心……