伴隨著大語言模型（LLM）產(chǎn)生檢索增強(qiáng)（RAG）隨著技術(shù)的深度整合，智能客服、醫(yī)療輔助診斷、金融智能投資研究等場景已經(jīng)實(shí)現(xiàn)了知識庫檢索和問答系統(tǒng)的規(guī)?；５?，傳統(tǒng)的企業(yè)級知識交互場景下， RAG 在知識片段的語義聯(lián)系和跨模式結(jié)合推理等方面，技術(shù)遇到了瓶頸。當(dāng)檢索到的文本內(nèi)容分散在不同的段落、文檔和不同的數(shù)據(jù)源中時(shí)，如何高效、準(zhǔn)確地檢索和關(guān)聯(lián)所有相關(guān)片段，并準(zhǔn)確地總結(jié)和生成最終答案？

在 InfoQ 舉辦的 QCon 楓清科技合作伙伴、智能平臺事業(yè)部總經(jīng)理王傳陽在全球軟件開發(fā)大會(huì)(北京站)上分享了“在復(fù)雜的場景中 RAG 結(jié)構(gòu)演進(jìn):跨模態(tài)知識聯(lián)邦和統(tǒng)一語義推理實(shí)踐”，他深入剖析了基于跨模態(tài)知識的聯(lián)邦和統(tǒng)一語義推理。 RAG 結(jié)構(gòu)化，并結(jié)合生產(chǎn)實(shí)踐分享實(shí)際應(yīng)用效果，以及后續(xù)技術(shù)演進(jìn)方向進(jìn)行系統(tǒng)分享。

內(nèi)容亮點(diǎn)

• 面向復(fù)雜場景應(yīng)用：聚焦企業(yè)級復(fù)雜知識交互，解決實(shí)際業(yè)務(wù)痛點(diǎn)
• 跨模態(tài)知識聯(lián)邦：打破傳統(tǒng) RAG 模態(tài)限制，實(shí)現(xiàn)多模態(tài)數(shù)據(jù)的組合
• 統(tǒng)一語義推理：提高知識聯(lián)系和問答的準(zhǔn)確性，更加智能化

下面是演講實(shí)錄(經(jīng)典) InfoQ 不改變本意的編輯整理)。

RAG 技術(shù)概覽

當(dāng)模型出現(xiàn)時(shí)，我們發(fā)現(xiàn)它有許多問題，其中最典型的就是“幻覺”現(xiàn)象。因?yàn)榇笮湍Ｐ驮趯?shí)踐初期并沒有接觸到最新的知識，但是在應(yīng)用大型模型時(shí)，也沒有使其了解我們希望掌握的最新知識。所以，當(dāng)被問及較新的問題時(shí)，大模型很難獲得新的知識，從而產(chǎn)生各種幻覺。這樣就讓我們思考如何讓大模型了解這些知識。所以，我們在外部建立知識庫，并利用它。 RAG（Retrieval-Augmented Generation）框架，使大型模型能得到相關(guān)的前后文本，對其進(jìn)行潤色后，最終回到用戶的答案。

RAG 主要范式

在 RAG 在演變過程中，出現(xiàn)了多種形式。從最初的樸素開始 RAG，到高級 RAG，再到模塊化 RAG，其核心鏈接始終圍繞三個(gè)步驟：檢索、檢索和內(nèi)容生成。高級 RAG 更多的處理是在檢索階段前后增加的，而模塊化 RAG 然后將這三個(gè)步驟進(jìn)一步細(xì)化為五個(gè)不同的階段，使每一個(gè)部分都能夠更加專注于理論和技術(shù)突破。例如，在檢索部分，針對分層。（chunk）對許多論文和框架進(jìn)行了優(yōu)化?；谀K化 RAG，能衍生出適合不同場景的各種場景。 RAG 形態(tài)。另外，還有與組織安排有關(guān)的東西。 graph RAG，運(yùn)用知識圖譜（knowledge graph）對知識提取、實(shí)體與關(guān)系聯(lián)系等進(jìn)行操作，這些內(nèi)容也在相關(guān)圖中得到總結(jié)。

RAG 主要使用場景

RAG 過去一段時(shí)間的典型應(yīng)用領(lǐng)域包括但不限于下列。在判斷 RAG 是否適用，關(guān)鍵在于本場景中的知識庫或大模型是否需要參考動(dòng)態(tài)頻繁更新的知識庫。要是需要，那么 RAG 這幾乎是不可或缺的。盡管類似的功能可以通過大模型微調(diào)或使用私人信息進(jìn)行蒸餾來實(shí)現(xiàn)，但是從成本和速度來看，RAG 見效速度更快。例如，在智能客戶服務(wù)場景下，產(chǎn)品庫將實(shí)時(shí)更新， RAG 技術(shù)構(gòu)建外部知識庫，無論知識庫如何變化，大型模型都可以隨時(shí)從中提取最新產(chǎn)品的相關(guān)信息，以回答用戶的問題。

復(fù)雜的場景挑戰(zhàn) 一 異構(gòu)知識

在 RAG 在場景中，除了上面提到的一些簡單的場景，還會(huì)有各種復(fù)雜的場景，尤其是異構(gòu)知識的處理。異構(gòu)知識有很多特點(diǎn)。今天，我們主要關(guān)注兩個(gè)特點(diǎn):結(jié)構(gòu)的離散性和模式的多樣性。

結(jié)構(gòu)的離散性

異構(gòu)知識的結(jié)構(gòu)離散是一個(gè)復(fù)雜的問題。雖然“結(jié)構(gòu)離散”這個(gè)詞可能有點(diǎn)牽強(qiáng)，但是異構(gòu)知識確實(shí)有這個(gè)特點(diǎn)，同步知識也會(huì)面臨類似的問題。例如，相同主題的知識可能分散在不同的文檔和媒體中，甚至可能出現(xiàn)在照片、文檔、視頻或關(guān)系數(shù)據(jù)庫中。他們都可能描述同樣的事情。如果你想讓大模型統(tǒng)一理解這些知識，你需要考慮如何去做。

即使在同一文檔中，知識的離散也是一個(gè)問題。比如，一個(gè) 200 頁的 PDF 在文檔中，可能會(huì)在第一頁提到“我是張三，今年多大，綽號小三子”，而在最后一頁總結(jié)中，我提到“小三子這一生是輝煌的一生”。在這種情況下，如何讓大模型理解“小三子”其實(shí)就是“張三”，在文檔的不同部分取得聯(lián)系是一個(gè)實(shí)際問題。傳統(tǒng)的 RAG 在處理這一問題時(shí)，技術(shù)面臨著挑戰(zhàn)，因?yàn)楹茈y保證切片邏輯在語義上是連貫的，同一主題的內(nèi)容也不能切割在一起。另外，切片的大小也是個(gè)問題。若切片過大，將影響最終召回知識的準(zhǔn)確性；如果切片過小，內(nèi)容就會(huì)更加分散。與此同時(shí)，只要進(jìn)行切片和向量進(jìn)庫，就很難保證跨文檔知識的完整性。最后，客戶很難獲得關(guān)于某個(gè)知識主題的完整信息，大模型無法以此為前后回答客戶的各種問題，一般只能給出片面的答案。

多樣化的模態(tài)

模式多樣性是構(gòu)造離散的基本原因之一。知識模式包括文本、音頻、視頻、照片、關(guān)系數(shù)據(jù)庫、表格等。傳統(tǒng) RAG 過去，技術(shù)主要處理文本數(shù)據(jù)?，F(xiàn)在，雖然有些技術(shù)已經(jīng)開始處理多模態(tài)數(shù)據(jù)，但總的來說，很難有一個(gè)理想的。 RAG 該框架可以很好地處理各種多模態(tài)數(shù)據(jù)。它帶來了兩個(gè)主要問題：

多模式檢索：例如，提供一段文字，可以檢索出不同模式的內(nèi)容，如照片、視頻、表格等。

跨模態(tài)檢索:比較簡單，比如提供一段文字，可以檢索相關(guān)照片，或者反過來輸入一張圖片，檢索相關(guān)文字。

怎樣應(yīng)對異構(gòu)知識的考驗(yàn)？

面臨這樣的挑戰(zhàn)，我正在制作。 PPT 試著咨詢一下 DeepSeek 他們的觀點(diǎn)，他們給出的答案和思考過程在大方向上是可靠的。對于構(gòu)造離散的問題，他們提到可以動(dòng)態(tài)地將這些段落合并起來，這個(gè)指導(dǎo)方針很好，但是具體怎樣做到合并并不詳細(xì)。另外，他們還提到相關(guān)段落可以通過圖形結(jié)構(gòu)或者知識圖譜來連接，這似乎是一個(gè)比較接近解決方案的方向。對模式多樣性的問題，他們指出需要處理不同模式的數(shù)據(jù)，盡管這是一個(gè)正確的方向，但是感覺并不深入。它們提到圖像應(yīng)該怎么處理，文字應(yīng)該怎么處理，并且強(qiáng)調(diào)處理后需要處理。綜合多模態(tài)信息，結(jié)合兩者綜合生成?？偟膩碚f，這些想法是沒有問題的。但是，在細(xì)節(jié)上，如果繼續(xù)基于這些內(nèi)容提問，DeepSeek 有可能提供更多詳細(xì)的信息。

基于知識庫和統(tǒng)一語義層的結(jié)合 RAG 架構(gòu)

核心部件 —— 結(jié)合知識庫

結(jié)合知識庫主要是通過知識融合技術(shù)將左側(cè)分散的各種多元異構(gòu)數(shù)據(jù)整合到統(tǒng)一的知識庫中，包括指標(biāo)、結(jié)構(gòu)化數(shù)據(jù)、文檔、圖片等信息。知識融合的過程涉及到許多常用的技術(shù)手段。例如，對于文檔數(shù)據(jù)，將使用文檔分析器和切片工具進(jìn)行處理，并提取元數(shù)據(jù)。對關(guān)系數(shù)據(jù)庫中的數(shù)據(jù)源，將提取其中的指標(biāo)和元數(shù)據(jù)。另外，還可以通過可視化工具幫助用戶理解知識庫中融合了哪些數(shù)據(jù)及其關(guān)系。將不同粒度、不同模式的數(shù)據(jù)結(jié)合到知識庫中，作為一個(gè)邏輯存儲(chǔ)單元，位于結(jié)構(gòu)的底部。實(shí)際上，整個(gè)過程就是將多模態(tài)數(shù)據(jù)轉(zhuǎn)化為知識的過程。

從技術(shù)形式和產(chǎn)品形式來看，結(jié)合知識庫是一個(gè)邏輯概念。底層物理存儲(chǔ)是一致的。例如，向量數(shù)據(jù)庫中仍然存儲(chǔ)文檔，關(guān)系數(shù)據(jù)庫的數(shù)據(jù)源(例如 MySQL 或 PostgreSQL）它們?nèi)员Ａ粼谠瓉淼牡胤剑皇撬鼈兊脑獢?shù)據(jù)被提取出來，并以邏輯視圖的形式存儲(chǔ)在一個(gè)整合的知識庫中。

就產(chǎn)品形態(tài)而言，我們可以通過產(chǎn)品中的知識庫模塊向用戶展示結(jié)合知識庫的概念。例如，客戶可以創(chuàng)建文檔知識庫、網(wǎng)頁知識庫、數(shù)據(jù)庫知識庫、指標(biāo)知識庫等不同類型的單一知識庫，也可以創(chuàng)建知識庫。建立知識庫后，客戶有兩種選擇:一種是建立新的文檔庫、指標(biāo)庫、圖片庫等。在空洞的知識庫中，統(tǒng)一組織數(shù)據(jù)；二是將現(xiàn)有的文檔庫、指標(biāo)庫、數(shù)據(jù)庫等引入到知識庫中，以邏輯的方式組織起來，產(chǎn)生新的知識庫。另外，用戶還可以在整合知識庫中指定關(guān)注的領(lǐng)域模型，即關(guān)注的實(shí)體和關(guān)系。比如在教育行業(yè)的知識庫中，可以配置與教學(xué)相關(guān)的實(shí)體及其關(guān)系，如關(guān)注教師、考題、學(xué)生等，為后續(xù)統(tǒng)一語義層的生成鋪平了道路。

核心部件 —— 統(tǒng)一知識圖譜：圖譜生成

使用統(tǒng)一知識地圖時(shí)，首先要考慮如何生成，然后如何使用。通過一張圖片可以理解生成統(tǒng)一知識地圖的過程。在圖片的左側(cè)，我們有各種不同模式的數(shù)據(jù)，如文檔、照片、視頻和關(guān)系數(shù)據(jù)庫。當(dāng)我們在知識地圖中提取相應(yīng)的元素時(shí)，這些元素是不同的。

對文檔數(shù)據(jù)，我們使用了簡化版本 Graph RAG（比如 Graph RAG Light）從文檔中提取物理和關(guān)系。由于這會(huì)帶來更高的成本和性能問題，所以一般不會(huì)提取所有內(nèi)容。在建立知識庫之前，我們會(huì)指定關(guān)注的實(shí)體和關(guān)系，這與業(yè)務(wù)問題和領(lǐng)域模型的結(jié)合密切相關(guān)。假如在建立知識庫時(shí)明確了要解決的業(yè)務(wù)問題和支持的領(lǐng)域模型，那么在提取文檔內(nèi)容時(shí)就會(huì)更加有針對性和高效。

對于圖片和視頻，我們可以提取人民幣信息(這些系統(tǒng)在模型時(shí)代之前做了很多標(biāo)簽等工作)。通過多模式模型或客戶現(xiàn)有的系統(tǒng)，并將這些信息放入統(tǒng)一的知識地圖中。對于關(guān)系數(shù)據(jù)庫，我們會(huì)提取各種元數(shù)據(jù)，如數(shù)據(jù)表的用途、字段的業(yè)務(wù)意義等。，并將這些信息放入統(tǒng)一的知識地圖中。將知識圖譜放入其中，必然會(huì)涉及到實(shí)體的合并和關(guān)系的發(fā)現(xiàn)，最終形成一個(gè)完整統(tǒng)一的知識圖譜。

核心部件 —— 統(tǒng)一知識圖譜：圖譜檢索

有了這樣的知識地圖，我們?nèi)绾卧诳蚣苤惺褂盟?？從客戶問題出發(fā)，當(dāng)客戶提出問題或表達(dá)任務(wù)需求時(shí)，我們會(huì)先在向量庫中匹配實(shí)體和關(guān)系，這實(shí)際上是一種語義搜索。目的是了解客戶問題中涉及的實(shí)體和關(guān)系類型。然后，我們將根據(jù)這些實(shí)體和關(guān)系在統(tǒng)一的知識地圖中進(jìn)行。N 度拓展查詢(如二跳或三跳查詢)，提取相關(guān)子圖。二跳或三跳查詢的實(shí)際跳數(shù)可以根據(jù)實(shí)際需要配置。一般二跳查詢就夠了，因?yàn)槿樵兛赡芴罅恕Ｍㄟ^這種查詢，我們可以將問題中的其他相關(guān)實(shí)體和關(guān)系聯(lián)系起來，形成子圖。

這個(gè)子圖必須涉及多模態(tài)信息，包括文本、關(guān)系數(shù)據(jù)庫和音視頻文件的元數(shù)據(jù)?；谶@些元數(shù)據(jù)，我們從底層物理存儲(chǔ)中獲取具體數(shù)據(jù)，并將其發(fā)送到大型模型中進(jìn)行潤色和輸出，從而為用戶提供相對完整的答案。因此，這里的核心是基于統(tǒng)一的知識地圖，生成包括多模態(tài)數(shù)據(jù)在內(nèi)的子地圖。

與 GraphRAG 的對比

就文本處理而言，我們將使用它 GraphRAG 相關(guān)技術(shù)。每個(gè)人都可能會(huì)問，整個(gè)技術(shù)是否重點(diǎn)關(guān)注？ GraphRAG 這樣的想法實(shí)際上是有道理的。在文字處理方面，我們站在巨人的肩膀上，但是也做了一些改進(jìn)。例如，通過指定實(shí)體和關(guān)系，可以得到緩解 GraphRAG 盲目抽取工作。這與其說與 GraphRAG 與其說是對其進(jìn)行優(yōu)化和改進(jìn)，不如說是對比。

就多模態(tài)知識而言，GraphRAG 現(xiàn)在主要支持抽取實(shí)體關(guān)系，為文本(如單篇或多篇文檔)構(gòu)建圖譜。從計(jì)算率的角度來看，提前指定的領(lǐng)域模型、實(shí)體或關(guān)系可以使提取過程更加集中。在冷啟動(dòng)難度方面，在我們提到的架構(gòu)中，確實(shí)需要投入一些時(shí)間來整理和放入統(tǒng)一的圖表、指標(biāo)和其他元數(shù)據(jù)。就R&D的復(fù)雜性而言，我們 GraphRAG 在沒有使用完整鏈接的情況下，進(jìn)行了垂直簡化。同時(shí)，在橫向工程化方面進(jìn)行了拓展，如增加了元數(shù)據(jù)提取、多模態(tài)圖片和視頻識別等功能，構(gòu)建了包括多模態(tài)數(shù)據(jù)在內(nèi)的知識地圖。

基于知識庫和統(tǒng)一語義層的結(jié)合應(yīng)用架構(gòu)。

對我們提到的架構(gòu)進(jìn)行重新梳理，兩個(gè)關(guān)鍵字仍然是結(jié)合知識庫和統(tǒng)一語義層，它們都體現(xiàn)在這個(gè)結(jié)構(gòu)圖中。以下是知識庫的組合，包括不同粒度和模式的各種數(shù)據(jù)；上面是統(tǒng)一的語義層，包括統(tǒng)一的語義庫和統(tǒng)一的知識圖，為上層的語義服務(wù)提供支持。一般情況下，我們會(huì)通過公司知識中臺或其它平臺對底層的統(tǒng)一語義層和整合知識庫進(jìn)行優(yōu)化和更新。企業(yè)知識中臺也可以承前啟后，為上層應(yīng)用建設(shè)提供支持。由于我們需要把底層的知識和數(shù)據(jù)轉(zhuǎn)化為實(shí)用價(jià)值，最終還是要通過具體的應(yīng)用來實(shí)現(xiàn)。所以，公司知識中臺在這里提供了構(gòu)建應(yīng)用的能力，如智能體應(yīng)用、工作流應(yīng)用等多種形式的應(yīng)用。這類應(yīng)用結(jié)合了統(tǒng)一的語義層和整合的知識庫，最終交付給客戶并落地為特定的智能體。

分享生產(chǎn)情景實(shí)踐

案例分析一：某醫(yī)院電子病歷查詢與智能問答業(yè)務(wù)

我們在生產(chǎn)場景中有兩個(gè)具體的實(shí)踐案例，首先是某醫(yī)院的電子病歷查詢和智能問答業(yè)務(wù)。近幾年來，呼吸道傳染病頻繁發(fā)生，如甲流、乙流等，給醫(yī)療行業(yè)帶來了巨大的壓力。病人看病時(shí)常面臨“看病” 30 秒，排隊(duì) 3 “小時(shí)”的困境，醫(yī)生也希望有一個(gè)更智能的方法，幫助他們快速回顧過去患者的疾病、治療方法和恢復(fù)情況，從而為當(dāng)前患者提供更準(zhǔn)確的治療建議。

具體情況如下：張三因流鼻水、發(fā)熱等癥狀來看病，醫(yī)生將這些癥狀輸入智能助手，查詢推薦的治療方法。所以，我們采用了基于知識庫和統(tǒng)一語義層的方案。結(jié)合關(guān)系數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)(如病人信息、醫(yī)囑、住院記錄)和電子病歷中的文本數(shù)據(jù)。統(tǒng)一語義層定義了醫(yī)療相關(guān)的概念。例如，“熱”是指體溫在體溫中。 37℃到 在40℃之間，并描述了相關(guān)癥狀。

在統(tǒng)一的知識地圖中，我們構(gòu)建了以患者為中心的地圖結(jié)構(gòu)，包括醫(yī)生建議、住院記錄、手術(shù)記錄等實(shí)體，從電子病歷文本中提取疾病、治療方法和質(zhì)量信息，并將其與地圖相關(guān)聯(lián)。例如，具體癥狀(如支氣管炎)可以在患者節(jié)點(diǎn)下聯(lián)系起來。、治療方法(如藥物名稱)和療效(如康復(fù)狀態(tài))。

在實(shí)際應(yīng)用中，醫(yī)生提出了“張三有這些癥狀，需要治療”等問題。系統(tǒng)會(huì)根據(jù)時(shí)間段(如過去一個(gè)月)進(jìn)行語義搜索，找出相關(guān)的實(shí)體和關(guān)系，在知識地圖中獲取子地圖。例如，系統(tǒng)將通過向量庫快速搜索與“發(fā)熱”和“干咳”相關(guān)的患者記錄，并結(jié)合電子病歷中的詳細(xì)信息，生成綜合治療建議。最終，醫(yī)生可以看到歷史上類似病人的治療方案，并據(jù)此為張三提供參考。

案例分析二：某銀行風(fēng)險(xiǎn)監(jiān)管指標(biāo)分析助手

銀行風(fēng)險(xiǎn)指標(biāo)控制是第二種情況的業(yè)務(wù)背景。銀行已經(jīng)建立了風(fēng)險(xiǎn)指標(biāo)庫，并希望通過傳統(tǒng) BI 系統(tǒng)通過點(diǎn)擊按鈕等方式查詢指標(biāo)。當(dāng)前，許多產(chǎn)品和解決方案都支持通過歸因分析和輔助決策等自然語言查詢指標(biāo)，并在此基礎(chǔ)上進(jìn)行預(yù)測和分析。但是，顧客的需求并不止于此。它們指出，指標(biāo)不僅與數(shù)據(jù)有關(guān)，而且與許多文檔規(guī)定有關(guān)。例如，其它部門經(jīng)常發(fā)送與指標(biāo)和監(jiān)督有關(guān)的文件，提示指標(biāo)應(yīng)符合有關(guān)規(guī)定，或通知指標(biāo)算法的變更。在真實(shí)場景中，這些文件可能會(huì)干擾指標(biāo)系統(tǒng)的輸出。

對于這些問題，客戶提出了一個(gè)要求：在指標(biāo)應(yīng)用場景中，結(jié)合文檔分析，對指標(biāo)進(jìn)行全面的查詢和分析。具體效果如下:當(dāng)查詢“過去一個(gè)月不良貸款率是多少”時(shí)，一般的指標(biāo)系統(tǒng)可能只會(huì)回歸。 5.01% 因此，更高級的系統(tǒng)將進(jìn)一步分析相關(guān)數(shù)據(jù)的波動(dòng)。但是，如果文件庫中有明確規(guī)定不良貸款率不能高于不良貸款率的文件 5%，而且這份文件被列入知識庫，所以當(dāng)查詢記錄顯示超過時(shí)， 5% 當(dāng)時(shí)，系統(tǒng)需要額外的提醒，顯示具體的規(guī)定來源和內(nèi)容，提示業(yè)務(wù)人員注意這個(gè)問題。

這種效果的實(shí)現(xiàn)是基于我們之前提到的框架。具體來說，我們會(huì)根據(jù)知識庫中的指標(biāo)庫和文檔提取統(tǒng)一的元數(shù)據(jù)和數(shù)據(jù)實(shí)體。在分析模型的指標(biāo)時(shí)，通過提示引導(dǎo)模型檢查文檔庫中是否有相關(guān)的警告或規(guī)定。一旦發(fā)現(xiàn)相關(guān)規(guī)定，模型就會(huì)發(fā)出相應(yīng)的警告或提醒。通過這種方式，業(yè)務(wù)人員可以快速了解指標(biāo)問題的根源，從而做出更準(zhǔn)確的決策。

展望未來演進(jìn)方向

在共享的場景中，雖然很多案例都是成功的，但在實(shí)踐中確實(shí)存在一些挑戰(zhàn)。從積極的角度來看，這些挑戰(zhàn)可以被視為未來前景的方向；另一方面，也可以說這些方面還存在一些不足。以下是四個(gè)方面的分享。

動(dòng)態(tài)更新統(tǒng)一語義層

那是一個(gè)很實(shí)際的問題。由于使用了圖片（graph）與算法相關(guān)，圖紙的更新，尤其是實(shí)時(shí)動(dòng)態(tài)更新，并不容易。目前，雖然有一些工具或框架可以支持實(shí)時(shí)圖紙的更新和計(jì)算，但這些技術(shù)手段只能部分處理統(tǒng)一語義層動(dòng)態(tài)更新的問題。

高效處理圖像、視頻數(shù)據(jù)

目前，在處理圖像和視頻數(shù)據(jù)時(shí)，我們?nèi)匀惶幱谠獢?shù)據(jù)階段，沒有將圖像本身的數(shù)據(jù)和文本聯(lián)合嵌入，也沒有實(shí)現(xiàn)統(tǒng)一的召回。雖然我們肯定會(huì)評估和考慮相關(guān)的技術(shù)手段，包括它們的性能和質(zhì)量，但可以肯定的是，這是未來的發(fā)展方向。

賦能行業(yè)語義模型和行業(yè)圖譜。

目前，公司通常需要依靠自己的力量來構(gòu)建與自己業(yè)務(wù)相關(guān)的語義模型和地圖。如果現(xiàn)有的行業(yè)語義模型能夠在同行業(yè)之間共享，顯然會(huì)極大地促進(jìn)整個(gè)結(jié)構(gòu)的發(fā)展。但是目前這方面的建設(shè)還是比較薄弱的。

知識庫標(biāo)準(zhǔn)化與場景化相結(jié)合

在多種實(shí)踐場景中，我們發(fā)現(xiàn)有些模式組合非常流暢，可以反映指標(biāo)庫與文檔庫的匹配，或者文檔庫與關(guān)系數(shù)據(jù)庫的匹配等多種場景價(jià)值。但是，并非所有的模態(tài)組合都能找到相關(guān)的使用場景，因此需要進(jìn)一步探索。假如能夠更深入地分析和固化這些組合，例如建立一個(gè)“指標(biāo)” 文件中的知識庫，那么在效率、性能等方面都能有針對性地提高。與開放的隨意搭配相比，這顯然更容易實(shí)現(xiàn)。

盡管存在這些挑戰(zhàn)，但它們也為未來的發(fā)展提供了方向。通過不斷的探索和優(yōu)化，我們可以逐步克服這些問題，促進(jìn)技術(shù)的進(jìn)一步發(fā)展。

嘉賓介紹

王傳陽，楓清科技（Fabarta）合作伙伴，智能平臺事業(yè)部總經(jīng)理，曾任 IBM 認(rèn)知計(jì)算研究院企業(yè)數(shù)字化轉(zhuǎn)型R&D負(fù)責(zé)人擁有十余年的軟件開發(fā)和軟件工程經(jīng)驗(yàn)，以及豐富的圖形數(shù)據(jù)庫和圖形算法應(yīng)用實(shí)踐和客戶交付經(jīng)驗(yàn)。

本文來自微信微信官方賬號 “InfoQ”（ID：infoqchina），作者：QCon，36氪經(jīng)授權(quán)發(fā)布。

本文僅代表作者觀點(diǎn)，版權(quán)歸原創(chuàng)者所有，如需轉(zhuǎn)載請?jiān)谖闹凶⒚鱽碓醇白髡呙帧?/p>

免責(zé)聲明：本文系轉(zhuǎn)載編輯文章，僅作分享之用。如分享內(nèi)容、圖片侵犯到您的版權(quán)或非授權(quán)發(fā)布，請及時(shí)與我們聯(lián)系進(jìn)行審核處理或刪除，您可以發(fā)送材料至郵箱：service@tojoy.com