基于古籍疫病醫案數據挖掘的AI智能體建設研究

分類號 R2-52;G254.929.1

DOI10.16810/j.cnki.1672-514X.2025.07.008

Research on the Construction of an AI Agent Based on Data Mining of Ancient Medical Records of Epidemics

Xu Jie，Liang Guoqing， Ni Liqiang， Zhang Huaiqiong，Wu Tingting

AbstractThis paper takes the ancient medical records of epidemics inthe library colection as theobject of data mining and proposes an AI paradigm based on a multi-level RAG-Rerank architecture.This paradigm innovates the traditional means of data pre-processing and methods of data mining.Furthermore，by using the LLMs application development framework （SemanticKernel），combined with software engineering methodology，and adopting advanced development technologies （Python，C#）andthe integrateddevelopment environment （Visual Studio），across-platform AI agentapplication is formed.Tests show that theAI agent effctively alleviates the cost problem caused by term standardization inthe traditional data pre-processing stage.Italsoaddresses issuessuch as model hallucination during the AI-empowerment process，abnormal accuracyof the traditional RAG low-code platform，andthe inability to customize thecore logic.In thecontext ofAI+，this paper explores afeasible cross-research method fordata mining and auxiliary diagnosis and treatment research based on ancient Chinese medical literature.

KeywordsAncient medical records.AI agent.RAG.LLMs.Data mining.Software engineerint

0引言

中華文明綿延5000余年，歷久彌新；而中醫藥則是這漫長歷史留給我們的珍貴禮物，不斷傳承至今。在科技高速發展的今天，這古老的智慧與現代科技不斷碰撞，產生了新的火花。習近平總書記指出：“要加強古典醫籍精華的梳理和挖掘，建設一批科研支撐平臺，改革完善中藥審評審批機制，促進中藥新藥研發和產業發展。\"在這種背景下，傳統大數據挖掘的技術模式與流程在浩如煙海的古籍文獻數據面前捉襟見肘，更需要采用最新現代信息情報學、人工智能學等方法，對中醫古籍文獻進行全面、系統的挖掘、整理。

隨著人工智能（AI時代的降臨，是否能以高維向量數據庫、大語言模型推理等AI模式對古籍進行挖掘，進而從源到流，梳理中醫疫病古籍文獻中的病因病機、治則治法、辨證論治、有效方劑、用藥規律、非藥物治療、預防調攝與康復等內容？如能以此為切入點，并在此基礎上形成一個以自然語言為基礎、能夠進行人機交互的AI智能引擎，進而形成一個基于古籍病種的數據挖掘科研范式，必將對貫徹落實習近平總書記提出的堅持“以人民為中心”的發展思想，以及“健康中國戰略\"的實施，起到一個正面的、積極的作用。

1中醫文獻挖掘領域AI賦能現狀及問題

眾所周知，在傳統數據挖掘流程中，數據預處理需要大量的時間和人工成本。這是因為數據數據預處理的每個步驟都需要仔細操作和驗證。例如，檢測和處理缺失值、異常值，進行數據轉換和特征選擇等都需要詳細的分析和決策；數據編碼和標準化也需要根據具體的數據類型選擇合適的方法，這無疑都增加了工作的復雜性和時間成本。

具體到中醫文獻挖掘領域，中醫藥術語尤其是各類病證所表現出的癥狀名稱的標準化，往往起著基礎、前驅、先導的作用。但在實際應用時，術語往往存在一義多詞或一詞多義的現象，概念間語義關系復雜，概念表述不規范，容易造成理解偏差和記錄重復，嚴重阻礙中醫藥的交流和信息共享。然而，中醫藥術語標準化的現狀不容樂觀，在短時間內形成一個具有廣泛共識，且在全國具有影響力認可度的中醫術語標準化庫是不現實的，全國有多個團隊在從事中醫藥術語的標準化工作，然而，耗費了幾十年的時間，動用了大量的人力、經費，目前只有地區性的一些小項目上的小范圍共識，而這些基于不同標準的項目，使得挖掘成果不能互通，甚至不能取得理想的挖掘效果。

自2022年末生成式AI進入大眾視野以來，傳統的大數據挖掘領域經歷了一場地震，從基于標引和結構化數據的，基于統計學的傳統數據分析和挖掘；過渡到了基于自然語言、非結構化數據的，以大語言模型為基礎的模糊挖掘和分析推理。于是，基于嵌入式（Embedding）的向量數據庫出現。向量（矢量）對語義的理解及對同義詞、多詞一義的適配性，以及模糊檢索能力，均大大強于傳統關系型數據庫的傳統檢索，這使得在中醫文獻挖掘中對中醫藥術語標準化及歸一化的迫切性降低。

而生成式大語言模型（LLMs的出現，因其強大的對非結構化數據及流式數據的語義理解能力、歸納能力、模糊檢索能力，使得數據挖掘不再必須依賴結構化數據，從而使得簡化分詞、標引等大量人力、時間成本成為可能。

2023年以來，由于向量數據庫及大語言模型的出現和其所表現出的強大特性，圖書館、中醫藥領域都有一些嘗試性應用，前者如海恒智能藍鯨大語言模型應用系統，后者如華東師范大學等聯合開發“數智岐黃\"中醫藥大模型，并迭代推出“數智岐黃2.0\"中醫藥領域多模態大模型。具體到中醫藥領域，通常將通用性大語言模型作為基座模型，以一定數量的中醫藥文獻的提取數據作為數據集，將數據集直接作用于基座模型，耗費大量計算機算力進行微調（Finetuning），進而形成中醫藥垂直領域的垂直大語言模型。

但是，垂直LLM也存在著各種問題。這是由于大模型的輸出通常能反映出基于大量訓練數據的某種常識。但在垂直領域，互聯網公共區域中，領域內的專業知識的數量遠遠小于通用常識，導致垂直領域的模型訓練集缺乏足夠的語言示例，或存在大量爭議性示例。這就導致模型可能產生看似合理實則錯誤的回答，在大模型處理垂直領域的專業復雜、有爭議、小眾的問題時，就更有可能出現幻覺現象[1。

為了解決這一問題，檢索增強生成（RAG）應運而生，在這種架構中，一般應用基于向量數據庫作為載體，將垂直領域的專業知識，比如某一專病的醫案甚至中醫古籍本身作為本地知識，進行切片并向量化后嵌入（Embedding）向量數據庫中。如此，用戶提問后，RAG架構會將用戶提問向量化后與向量數據庫的參考數據進行匹配，最后將問題與檢索結果一起提交大語言模型生成自然語言輸出。

由于這種模式能夠快速構建知識問答，因此，目前出現了很多基于傳統RAG低代碼平臺，例如BISHENG（畢升）等。雖然這種模式有效避免了垂直領域的幻覺回答，但依舊存在許多問題。一是它只檢索一次并生成一次。如果上下文信息不足，無法動態搜索更多信息。二是無法處理復雜查詢的推理問題。三是系統無法根據問題調整其策略[2]。

各類基于傳統RAG架構的大模型平臺，類似網站通用內容管理系統（CMS），只能進行有限的低代碼開發，比如自定義文檔知識庫、頁面樣式等，無法對大量核心邏輯進行重構。這就導致匹配效率與精確度隨之變差，很多較為專業問題的響應，變得空洞沒有營養。傳統RAG模式如圖1所示。

圖1傳統RAG模式圖

而我們也在不斷探索和努力，是否可以基于RAG的理念，以本地多模態關系型數據庫、高維向量數據庫為知識擴展，在傳統挖掘算法構建的輔助決策系統所形成的較為精準結果的基礎上，通過工作流分層，形成檢索增強，再對檢索增強內容進行評價過濾后，重構提示詞prompt，再由基座大語言模型推理生成，從而構建一個消除幻覺的、多層級的、精準的、內容可控的、基于古籍疫病醫案的數據挖掘AI智能體。

2技術路線與整體架構

2.1 解決方案的設計

我們首先構建傳統數據挖掘（關聯規則）為驅動核心的輔助系統，將其作為多層級RAG及代理架構的其中的一個層級，以供智能體代理驅動，輔以傳統關系型數據庫、基于嵌入（Embedding）模型的向量數據庫、生成式大語言模型（LLMs）、ReRank模型構成多層級RAG-Rerank架構及AI代理。

其中，關系型數據庫保證了范式響應的精準性，但代價是降低命中率；而在向量數據庫中，小范圍向量知識庫（如醫案庫）兼顧了精準性和命中率，在保證一定準確度的情況下大大提高了匹配率；而大范圍向量知識庫（如中醫病種古籍庫），以犧牲精準性來確保用戶問題的極高命中率和響應率。此三個層級基于AI代理的遞進式工作流，輔以基于傳統數據挖掘的病種輔助決策子系統的響應結果，以檢索增強生成（RAG）的形式，經Rerank后，再提交大語言模型（LLMs），最終生成自然語言輸出。

如此，共同保證了這種“基于多層級RAG及代理架構的AI智能體為驅動核心的古籍病種挖掘科研范式”的精準性和高命中率，進而緩解了數據預處理帶來的時間、人力成本問題，從根本上解決了垂直大語言模型的幻覺響應問題，并在很大程度上緩解了傳統RAG帶來的匹配精確性相關性問題。

2.2 智能體的整體架構

我們以模塊化構建智能體：首先，以傳統數據挖掘（關聯規則）為驅動核心的輔助系統，基于古籍抽取醫案的問答數據集、古籍醫案文檔向量庫、Rerank相關性評價模型及基于基座LMMs的中醫藥大語言大模型，構建多層級RAG-Rerank模塊，嵌人AI智能體，以此作為AI服務的核心。其次，在AI服務模塊的前端和后端，構建用戶交互模塊、數據支撐模塊，以形成完整的智能體模塊化架構。每個模塊承擔著不同的職責，分別負責用戶交互、問題處理與數據支撐。 ① 用戶交互模塊：用戶在這里輸入問題并獲得系統的回答； ② AI服務模塊：負責理解和處理問題，包括問答匹配、向量化處理和大模型生成答案等任務； ③ 數據支撐模塊：管理和處理文檔及數據，提供知識庫的基礎數據，確保系統有足夠的知識儲備來回答問題。通過這種模塊化的設計，使得整個智能體的工作流程得以順暢運轉。智能體模塊如圖2所示。

圖2智能體模塊圖

2.3 多層級RAG及代理Agent業務流程

智能體以用戶提問輸入為起始，獲取提問后進行prompt構造，通過代理Agent，對LLM進行RAG提問，判斷是否為中醫藥問答，如果為“否”提示用戶重新提問，如果為“是\"則將提問進行分詞、重構，若為中醫藥問診則增加相關癥狀的提取，最后將重構后的若干相似、等價問題輸入AI服務環節。

在AI服務環節，如果智能體通過代理Agent能夠從已有的關系數據庫中的問答對中直接查詢到相關答案，那么它會立刻向用戶返回答案，減少等待時間，提升用戶體驗。如果系統沒有找到現成的答案，則會根據問題的復雜程度，選擇進一步調用AI服務模塊中的向量化問答服務或大語言模型（LLMs服務來尋找或生成答案。這種遞進式的響應模式，根據不同的問題處理路徑，采用不同的響應策略：

第一層，通過代理Agent從關系型問題庫中找答案：通過系統中已有的問答對，直接找到答案。這種方式速度最快，適用于常見的、重復率高的問題。

第二層，通過輔助決策系統挖掘答案：智能體以AI代理的形式，通過調用基于傳統數據挖掘的醫療輔助決策子系統所提供的API，獲取中醫藥知識或者診療參考信息及相關古籍原文。

第三層，基于向量數據庫匹配答案：當系統無法在QA問答關系庫找到直接答案；或者在輔助決策系統中，關聯規則的支持率無法達到閾值時，系統會調用向量數據庫中的相關信息，通過向量化服務找到匹配的內容進行響應。此部分分為兩個步驟：（1）從QA古籍醫案向量庫中歸納總結答案，如果匹配不符合相應閾值，則進入下一步。2）從相關古籍的整體文檔向量庫中歸納提取相匹配的答案。

第四層，通過大語言模型（LLMs生成答案：對于那些復雜或無直接答案的問題，系統會調用大語言模型（如GPT、Qwen）進行輔助智能生成，隨后與前幾層的資料一起進行Rerank，最后返回更加復雜、個性化的回答。

智能體旨在盡量減少用戶的等待時間，同時保證回答的準確性和相關性。這種遞進式多層次的響應機制確保了無論問題多么復雜，系統都能通過不同路徑找到最優解。多層級RAG-Rerank架構Agent流程如圖3所示。

圖3智能體MultilayerRAG-Rerank架構及運行流程圖

3本地知識庫及向量數據庫的構建

本模塊是智能體的數據支撐部分，也是RAG檢索增強生成的本地知識庫和數據處理的核心，主要負責管理和維護系統運行所需的數據和文檔。它為用戶交互和AI服務提供知識支持，確保問題能夠得到充分、準確的響應。其知識內容的構建由以下幾個部分組成：

（1）館藏疫病類古籍善本文檔。根據館藏古籍書目，經選定，將51種古籍書目列為本智能體第一批遴選書目。名錄如下：《麻科活人全書》《廣瘟疫論》《叢桂草堂醫案》《白喉條辨》《臨證指南醫案》《王旭高臨證醫案》《感證輯要》《溫熱論》《證治準繩》《隨息居重訂霍亂論》《濕熱病篇》《存存齋醫話稿》《吳鞠通醫案》《溫病指南》《傷暑論》《瘟疫發源》《保嬰撮要》《溫證指歸》《包氏喉證家寶》《霉新書》《傷寒瘟疫條辨》《松峰說疫》《旌孝堂醫案》《溫病研究》《眉壽堂方案選存》《臨診醫案》《得心集醫案》《證治匯補》《重訂通俗傷寒論》《時病論》《集驗方》《瘟疫論》《葉天士曹仁伯何元長醫案》《齊氏醫案》《張聿青醫案》《傷寒撮要》《小兒痘疹方論》《痧脹玉衡》《江澤之醫案》《溫熱暑疫全書》《邵氏方案》《經驗麻科》《白喉全生集》《溫病條辨》《徐養恬方案》《溫病正宗》《王應震要訣》《溫熱經緯》《丁甘仁醫案》《痧疹輯要》《傷寒指掌》。

將上述古籍掃描并OCR后，提取其古文、譯文的電子文檔存人關系型數據庫，并由嵌入（Embedding）模型M3E向量化后，在向量數據庫中生成相關向量信息。向量化處理的核心是通過將文檔中的內容表示為高維向量，來實現語義上的精準匹配。這一過程大幅提高了智能體對于非結構化數據（如文本、報告等）進行問題響應的能力。此部分是智能體在向量數據庫層面響應用戶問題的最后一層保障，涵蓋了館藏疫病類古籍的全文數據。

（2）基于上述古籍中疫病類提取醫案的古文原文及現代譯文。基于上述古籍，針對疫病的臨床表現和病因病機，在《傷寒瘟疫條辨》《臨證指南醫案》等古籍中查找有關治療時疫的醫案。選取其中有關病因病機為：外感戾氣、感染疫毒、感受時疫的疾病，以及類似關鍵字的條目，共取得8170組醫案。將醫案原文及譯文導人關系型數據庫，之后向量化存入向量數據庫。

（3）基于上述醫案的譯文，形成的QA問答數據集。將所有醫案的譯文重寫成問答形式，以問答數據集形成json或者xml結構化文件，并同步存入關系型數據庫、向量數據庫。

（4）基于上述醫案，提取其中癥狀，病機、處方等生成的結構化數據。將每組醫案根據原文進行拆解，分解成表頭字段為病名、證型、癥狀、治法、處方明細、用法、加減、病因病機、辨證論治、原文、原文出處等的結構化數據，最后僅存入關系型數據庫，作為智能體子模塊“疫病癥-藥輔助決策系統\"的來源數據。

（5）基于公開網絡的中醫藥QA問答數據集。該數據集是智能體QA問答知識結構的補充，增加了問題命中的概率，擴充了智能體在中醫藥垂直領域內響應用戶問題的范圍。

4基于傳統數據挖掘的子系統構建

該系統是整個智能體的一個子模塊，也是多層RAG架構中的一個層級，用于對用戶關于問診咨詢類的問題，給出一個可能的用藥組合，作為最終輸人LLMs的參考資料之一。本系統以古籍中的疫病醫案為切入點，基于關聯規則算法，挖掘醫案中癥與藥的關系。

該挖掘方法主要挖掘常見疫病的癥狀與用藥之間的頻繁項集，進而得出關聯規則。基于這種關聯規則，通過輸入癥狀集合可以得出最有可能的用藥集合。運用經過Hash改進的FP-Growth算法3，對8000余條古籍疫病醫案的癥-藥記錄進行挖掘，獲得了若干頻繁項集（L）及其支持度（SUP）；以上是計算數據集關聯規則前提。

關聯規則是形如X $$ Y的蘊含式，其中，X和Y分別稱為關聯規則的先導（LHS）和后繼（RHS）其中，關聯規則XY，存在支持度和置信度。支持度（Support）是事物集D中事務同時包含X、Y的百分比，即概率；置信度（Confidence）是D中事務已經包含X的情況下，包含Y的百分比，即條件概率。

那么經過算法挖掘后，設S1、S2是癥狀事物集S其中的2個頻繁項集，同時SUP（S1）SUP（S2）分別是S1、S2的支持度。那么關聯規則S1一S2的置信度則可通過如下式得出：

本項目旨在構建基于古籍疫病醫案的數據挖掘模型，從而形成關于癥-藥的關聯規則，進而發現針對特定癥狀的用藥規律，由此，可以對特定癥狀產生建議藥方，進而形成針對疫病的“診斷-開方\"輔助決策。

就實現而言，即基于輸人癥狀，根據上述算法、尋找癥狀 處方明細 （Φ_x，Pi） 的置信度集合，隨后遍歷所有關聯規則，若置信度高于一定閾值，則將該規則的明細藥物納入輸出集合。

該輔助決策系統系本地部署，并以web應用程序及API接口兩種方式提供服務。其中，web應用程序可獨立發布，API方式則供智能體的代理Agent調用并提供服務。

5智能體對大語言模型的整合與開發實現

所謂AI智能體，是感知環境、做出決策并采取行動的人工智能實體。而基于大語言模型（LLM）的智能體，就是利用LLM進行復雜任務執行的應用。智能體通過結合LLM與關鍵模塊（在本系統中，即交互模塊和數據支撐模塊）來執行任務。而LLM充當著控制中心或“大腦”的角色，負責管理完成任務或響應用戶請求所需的一系列操作。由于LLM出色的自然語言理解、處理和生成能力，在記憶檢索、決策推理及行動順序選擇等方面為智能體提供了有力支持，從而使其不僅在對話和語言理解方面表現出色，還能利用豐富的知識庫和環境反饋做出高效決策。

5.1模型的本地部署

智能體選取Qwen2.5開源版72B作為基座大語言模型;選取通用文本向量模型m3e-large為Embedding向量化嵌人模型；選取bge-reranker-large作為Rerank模型，基于本地部署，以Ollama或者LM-Studio作為模型本地化運行工具，對外發布基于OpenAI標準的服務接口。其中：

LLM的Http協議Post方法調用地址為：http：//本地IP/compatible-mode/v1/chat/completionso

向量化服務Embedding模型的Http協議Post方法調用地址為：http：//本地IP/compatible-mode/v1/embeddings。

Rerank模型的Http協議Post方法調用地址為：http：//本地IP/rerank。

5.2 大語言模型應用開發架構

目前，大模型開發領域比較常用的應用開發框架有LangChain、SemanticKernel等，其中，LangChain是一個專門為利用語言模型創建應用程序而設計的全面框架，旨在幫助開發人員輕松構建基于語言模型的應用5。該框架與多種語言模型兼容，尤其與OpenAI的ChatGPT無縫集成。而SemanticKernel是一個微軟開發的基于LLMs的應用開發框架，旨在通過提供一系列工具和功能，幫助開發人員快速構建高性能、可擴展的LLMs應用。該框架支持多種編程語言，如Python、Java、C#等，并提供了豐富的API接口，方便開發人員進行定制開發。

因此，本系統基于SemanticKernel框架，以VS2022為集成開發環境，引人KernelMemory來管理智能體本地知識庫及其多層級RAG。

5.3基于多層級RAG-Rerank智能體的實現

5.3.1 框架配置

在VS2022的NuGet包管理器中引人Microsoft.SemanticKernel及Microsoft.KernelMemory，并使用Kernel.CreateBuilder（語句對實例初始化，同時配置文本生成模型及文檔解析向量模型的APIKey、ModelID、TextModel、EmbeddingModel等參數。其中，SemanticKernel用于自然語言生成;KernelMemory用于本地知識庫的管理、文檔處理流程控制及向量化檢索。

由于框架本身默認基于OpenAI的ChatGPT的無縫集成，因此還要在程序中使用newHttpClientO重定義一個符合OpenAI標準的大模型本地API服務地址。關于本地API在5.1章節中已經聲明。

5.3.2 文檔的導入、標簽、切分與向量化的實現

系統使用KernelMemory中的Document類來管理本地知識文檔，對在用戶交互模塊中獲取的文檔進行導入，并根據3.1章節知識層級分類，進行標簽化（Tag）預處理，其中古籍譯文文檔設置標簽“type”為“book”“name”，共51個文檔;8170組醫案文檔設置標簽“type\"為“case”，同樣根據書目數量拆分為51個文檔；醫案問答設置標簽“type\"為“caseQA”；中醫藥問答設置標簽“type”為“tcmQA”，之后調用memory.ImportDocumentAsync（方法進行向量化存儲。

需要注意的是，在ImportDocumentAsync方法中，對文檔的默認處理管道流程包括文本提取、切分、存儲、向量化、存入向量數據庫等幾個步驟。其中關于“切分”，由于文檔往往比較大，如果直接進行檢索使用的話，會導致最終的prompt提示詞上下文太長，從而造成Token的浪費。另外prompt提示詞太長的話，生成的速度也會變慢，從而導致花銷過大。另一個最主要的原因是embedding的接口是有token限制的，所以太長的話要么造成信息丟失，要么引起生成錯誤。因此，最好的方法就是將文本進行切分。由于前述知識庫文檔包含多種文檔類型，很難用一種默認的文本切分方法準確地切分。因此，我們根據不同類型的文檔內容分別自定義3種切分方法，分別適用于普通文檔、醫案、問答對。

5.3.3 智能體分層級工作流實現

在實際業務環境中，我們將用軟件工程的程序流程實現第3章所提到分層級工作流，其中包括若干個代理Agent異步任務。以用戶問診咨詢為例：

第一步，選擇判斷為中醫藥知識問答、中醫藥問診或者其他。

構造異步任務：isMedQA（string input）。

程序從用戶交互模塊獲取用戶提問變量input，隨后，構造提示詞prompt：“你是一位中醫藥專家，用戶輸入為：‘{input}'，請判斷并選擇：1、以上用戶輸入為中醫藥相關知識問答2、以上用戶輸入為問診咨詢，需要開方建議。3、其他。請給出選擇，用‘1’、‘2'或者‘3'回答，不要有多余的字數。\"

隨后調用SemanticKernel的CreateFunctionFromPrompt方法，基于prompt創建提示詞函數AgentPrompt;再調用InvokeAsync（AgentPrompt）方法獲取LLM的響應回答。

第二步，抽取問題中的癥狀數據。

構造異步任務：GetSymptom （string input）。

獲取類別為“問診咨詢\"的用戶輸入input后，重構提示詞prompt：“你是一位中醫藥專家，請基于以下內容回答問題：‘{input}'，在以上描述中，屬于癥狀的有哪些？給出的答案中，癥狀之間請用‘，分隔。”

第三步，在關系型數據庫中檢索答案，并進行閾值判斷。

構造異步任務：public async Task Get DBInfo （string symptom， string input，string asktype ）。

根據代理1的asktype分類結果，如類別為問診，則將癥狀進行數組化后，分別經LLM擴展近義詞后，構造SQL循環查詢，如癥狀集匹配率高于設定閾值，則將查詢的處方結果存入候選變量allinfo。

第四步，在子系統以關聯規則或神經網絡獲取答案，并進行閾值判斷。

構造異步任務：public async TaskGetSubInfo （string symptom）。

根據代理1的asktype分類結果，如類別為問診，則將癥狀進行數組化后，與子系統癥狀術語表進行匹配。若輸入癥狀集與癥狀術語表匹配率達到設定閾值，則進行關聯規則分析，并將處方結果存入候選變量allinfo。

第五步，在高維向量數據庫中檢索答案，并進行閾值判斷。

構造異步任務：public async TaskGet VectorDBInfo （string symptom， string input， string asktype ）

根據代理1的asktype分類結果，如類別為問診，則將癥狀進行數組化后，重構提示詞prompt：“你是專業的中醫師，現有病人出現如下癥狀‘{key}’，請問是什么原因，該如何治療？”，調用memory.SearchAsync（promptinput，filter：newMemoryFilter.ByTag（“type”，\"caseQA”），limit：1），將prompt輸人，并根據業務需求指定向量庫的醫案子庫，檢索并選取匹配度最高的檢索結果，最后存入候選變量allinfo。

第六步，將符合條件的所有候選結果進行Rerank后輸出。

構造異步任務：public async TaskGet RerankFinalInfo （List allinfo，string input， string asktype）。

將之前所有代理工作流的答案匯總allinfo，根據Rerank接口規范，構造含有問題query和相關的文本texts這2個參數的json進行提交，返回json的結果表示每個文檔和問題的相似度分數，然后按照分數大小來進行排序。最后以相似度順序區分主輔，順序文本輸出。

第七步，將經Rerank后的參考結果連同用戶提問提交LLMs以自然語言輸出。

構造異步任務：publicasync Task GetLLMAnswer（string finalinfo， string input， string asktype）。

此工作流為主工作流，重構提示詞prompt：“你是專業的中醫師，現有病人出現如下癥狀‘{keyl’，請問是什么原因，該如何治療？參考資料如下‘{finalinfo]’，請根據參考資料回答問題。”，隨后調用SemanticKernel的CreateFunctionFromPrompt方法，基于prompt創建提示詞函數AgentPrompt;再調用InvokeStreamingAsync（AgentPrompt）方法獲取LLM響應的流式數據，同時經SignalR組件流式發送至客戶端。

第八步，多層RAG-Rerank工作流簡化后的偽代碼如圖4所示。

6 測試及結論

6.1術語在未標準化語境下的檢索召回測試

基于疫病8170組醫案，分別以 100% 癥狀重合率以自然語言構造提示詞進行問診咨詢（癥狀隨機以非標準化近義詞表述）共構造50條問診咨詢信息，并對每條問診信息進行癥狀抽取。根據關系型數據庫和向量數據庫特性分別進行無標準化術語檢索召回測試。

關系型數據庫Agent流程：通過LLMs對構造的問診信息及數據庫原始醫案的癥狀進行抽取，并構造prompt通過LLMs進行抽取癥狀的循環匹配，若原始醫案與構造醫案癥狀匹配率達到 80% 以上，則對原始醫案進行SQL召回。

向量數據庫Agent流程：將測試的問診信息經過Embedding后輸入向量庫匹配相關性，輸出所有具有相關性的醫案切片記錄，并以相關性排序，并對相關性最高者進行召回。結果表明，經關系型數據庫召回率達到 96% ，經向量數據庫召回率達到 100% 。

6.2 智能體工作流測試

（1）中醫藥醫案問診。基于疫病8170組醫案，分別以 100% 、 50% 、 10% 癥狀重合率構造提示詞進行問診咨詢（癥狀隨機以近義詞表述）。每種重合率下構造50條問診提示詞進行測試。平臺在已有醫案的復現上有較好的表現，在全新癥狀組合下，對單個癥狀或簡單組合癥狀的用藥建議、病因病機解析的應對上也有較好應對。但隨著癥狀組合數量的增加，其響應傾向于對單個癥狀或簡單組合癥狀應對的簡單堆砌合并，缺少整體觀。

（2）中醫藥相關疫病知識問答。中醫藥相關疫病知識問答測試顯示，根據用戶輸人的中醫藥領域關鍵詞，經LLMs進行近義詞表述擴展，也僅有少數問題（約 10% 可以在關系型數據庫中的中醫藥知識QA庫中直接命中。工作流數據采集多數都在下一層向量知識庫中，才能獲取具有相關性的文檔數據，其來源包括向量古籍文檔庫的知識段落、向量中醫藥知識QA問答庫的相關問答對、向量醫案庫的相關醫案等。

向量庫參考資料召回率相較預期更多，其相關性也參差不齊，經過Rerank進行相關性篩選后，僅保留若干高相關性資料，并進行主輔排序后再交由LLMs整合歸納后輸出。

平臺在中醫藥知識問答上有較好的表現，基本能根據用戶問題查找到相關資料并進行高相關性回復，較為成功地控制了幻覺響應及低相關性的泛泛而談。

6.3結論

為解決傳統數據挖掘中數據預處理階段開銷巨大的問題，以及在AI賦能過程中出現的模型幻覺、傳統RAG低代碼平臺精度失常、核心邏輯無法自定義等問題，本文提出了一種基于多層次RAG-Rerank架構的數據挖掘范式，并基于此范式，以軟件工程的方式構建基于疫病古籍醫案的智能體平臺。測試表明，智能體對疫病相關的問診咨詢、中醫藥知識咨詢有一定的實用性，其輸出建議有一定的專業性，特別是多層次RAG-Rerank架構的應用，使得本平臺相較于目前市面上的純中醫大數據模型，有效避免了垂直大模型的幻覺問題；相較于傳統RAG單次檢索低代碼平臺生成的問答系統，更具精準性和專業性。同時，基于LLMs的智能體（Agent）和向量數據庫的結合，能在一定程度上有效緩解前期數據預處理過程中對術語標準化的依賴性。

參考文獻：

[1]LEE M.A mathematical investigation of hallucination and creativityin GPTmodels[J].Mathematics，2023， 11（10）：2320.

[2]SINGHA，EHTESHAMA，KUMARS，etal.Agentic retrieval-augmented generation： a survey on agentic RAG[J/OL].[2024-10-20].https：//arxiv.org/abs/2501. 09136.

[3］陳茵，閃四清.采用映射哈希表的頻繁模式挖 掘方法[J].計算機工程與應用，2008，44（36）：164 -167.

[4]MINSKY M. The society of mind[C]/：Simon amp; Schuster，1986：19-32.

[5]Building applications with LLMs through composability [EB/OL].[2023-11-03].https：//github.com/yab/ langchain.

[6]Introductionto Semantic Kernel[EB/OL].[2024- 06-25].https：//learn.microsoft.com/uk-ua/semantickernel/overview/.

許潔上海中醫藥大學圖書館研究館員。上海，201203。

梁國慶上海中醫藥大學圖書館副研究館員。上海，201203。

倪力強上海中醫藥大學圖書館常務副館長。上海，201203。

張懷瓊上海中醫藥大學圖書館高級顧問。上海，201203。

吳婷婷上海中醫藥大學圖書館館員。上海，201203。

（收稿日期：2025-02-08編校：謝艷秋，陳安琪）