：數(shù)據(jù)清洗、Neo4j導入與可視化)
簡介這套資源定位為中醫(yī)藥知識圖譜實踐入門材料聚焦中藥與方劑兩類核心實體及其關系建模適合計算機、人工智能及中醫(yī)藥信息學方向?qū)W生用于課程設計、畢業(yè)設計或科研起步。包內(nèi)包含17個文件共1.82MB以Python腳本、JSON結構化數(shù)據(jù)、SVG圖譜、HTML交互頁面及Markdown文檔為主其中py文件負責圖譜構建與關系推理JSON數(shù)據(jù)為清洗后的實體關系集SVG與HTML可直接呈現(xiàn)節(jié)點和路徑。已有38人學習/下載適合直接對照README運行驗證無需復雜配置即可一鍵生成知識圖譜。資源不只提供可運行代碼還配有自動生成的可視化結果和詳細文檔便于理解屬性分布與路徑推理二次開發(fā)空間大可擴展實體類型、接入Neo4j圖數(shù)據(jù)庫或?qū)又嗅t(yī)問答模塊。需注意版權聲明僅限學習參考禁止商用。1. 中藥知識圖譜不再靠翻閱教材查關系做中醫(yī)藥數(shù)據(jù)分析的人大概率都經(jīng)歷過這種尷尬要回答“哪些方劑同時包含黃芪和當歸”“某味藥的歸經(jīng)在教材里寫了三處不一致”只能靠人工翻書、復制粘貼到Excel里慢慢比。知識圖譜這套資源解決的核心問題就是把“查數(shù)據(jù)”變成“查關系”。它的產(chǎn)物是一份可運行的Python工程清洗好的中藥與方劑結構化數(shù)據(jù)、Neo4j圖譜模型、SVG可視化圖譜和配套文檔。適合正在做中醫(yī)藥信息化的開發(fā)者、剛接觸知識圖譜想找實戰(zhàn)樣本的研究者以及需要在本地搭一套演示系統(tǒng)的工程師。數(shù)據(jù)量不大但正好覆蓋從建庫到可視化的完整鏈路。2. 先立本體后造數(shù)據(jù)實體、關系與結構化CSV規(guī)范2.1 為什么要先花時間定本體做知識圖譜最容易犯的錯是一上來就寫爬蟲、拉數(shù)據(jù)等數(shù)據(jù)堆到幾千條再想怎么建模。結果就是邊清洗邊改實體定義改到一半發(fā)現(xiàn)“藥”和“藥材”沒統(tǒng)一“方劑”和“處方”各有一套ID后續(xù)所有查詢都得打補丁。這套資源給出的順序是標準的自頂向下先畫本體再寫映射表最后才處理數(shù)據(jù)。核心本體只有四類實體和六類關系不追求覆蓋全部中醫(yī)概念但保證每個查詢路徑閉環(huán)。定本體的核心問題就三個實體分幾類、關系叫什么名字、屬性保留哪些。這里做的是經(jīng)典三元組設計實體有中藥、方劑、疾病/癥狀、藥對。關系的命名角度刻意用了最貼近原文的謂詞比如“主治”“組成”“歸經(jīng)”“配伍”而不是“has_symptom”這類為了泛化而犧牲可讀性的叫法。原因是中醫(yī)藥查詢場景里領域用戶習慣直接看到“某方劑組成含某藥”這種自然映射代碼里多寫幾個空格比解釋命名規(guī)范省時間。2.2 實體與關系的三元組拆法整套圖譜實際落地的三元組結構如下表導入時就是按這張表寫映射腳本。頭實體關系尾實體舉例方劑組成中藥四君子湯 — 組成 → 人參中藥歸經(jīng)經(jīng)絡/臟腑黃芪 — 歸經(jīng) → 脾經(jīng)中藥主治疾病/癥狀麻黃 — 主治 → 風寒感冒中藥藥性屬性值附子 — 藥性 → 大熱方劑主治疾病/癥狀麻黃湯 — 主治 → 惡寒發(fā)熱中藥配伍中藥柴胡 — 配伍 → 黃芩注意“藥對”這一類在表里其實是以“配伍”關系出現(xiàn)的沒有單獨建成實體節(jié)點。這樣做的好處是查詢“與某味藥存在配伍關系的所有藥”就是一次關系遍歷不必把藥對表單獨維護成節(jié)點再映射。已經(jīng)整理好的CSV數(shù)據(jù)里也保持了同樣的結構看完可以直接對比原始表格和體現(xiàn)本體的schema文件。2.3 把教材內(nèi)容整理成結構化CSV的分字段設計拿到手的數(shù)據(jù)文件里中藥表有幾個實際用得上、又容易在清洗階段被忽略的字段藥材名、別名、性味、歸經(jīng)、功效、主治、使用注意。方劑表是方名、組成、功用、主治、用法。最值得留意的字段是“組成”原始整理時很多方子的組成文本是“黃芪三錢、當歸二錢”這種混合寫法不是標準結構化數(shù)據(jù)。因此腳本里專門寫了組成字段的轉(zhuǎn)換規(guī)則拆出中藥名和劑量兩個子字段再映射到中藥表的ID。那種“三錢”“二錢”之類的古劑量單位沒有統(tǒng)一換算成克保留原文只是在建圖譜時把劑量當作屬性放在“組成”關系上而不是塞進藥名節(jié)點。這個決定挺重要因為一旦在數(shù)據(jù)層做了換算不少方劑考證時就會失真。清洗后的CSV可以在后續(xù)步驟里直接交給CQL腳本導入。3. Python數(shù)據(jù)工程爬取、清洗與去重的關鍵代碼3.1 數(shù)據(jù)來源怎么選、邊界在哪數(shù)據(jù)不是隨手抓的源頭的可信度直接決定這圖譜能不能拿出來給人看。資源里的數(shù)據(jù)來源是公開的中醫(yī)藥數(shù)據(jù)庫與整理好的教材附錄不依賴某個特定網(wǎng)站的在線接口因為在線接口隨時可能改版而且不少頁面對請求頻率有限制。整理方式就是把這部分公開資料下載成結構化表格后做清洗。邊界也說明一下這份圖譜的數(shù)據(jù)覆蓋范圍是常見中藥和經(jīng)典方劑不是全量醫(yī)學知識庫像少數(shù)民族藥、地方習用藥材基本沒納入。做藥物研發(fā)、臨床決策支持這類嚴肅用途數(shù)據(jù)量是不夠的但做教學演示、文獻計量、中醫(yī)藥知識問答原型這份數(shù)據(jù)量級剛剛好。3.2 清洗腳本別名、炮制、劑量與單位規(guī)范化拿到CSV之后第一件事是統(tǒng)一命名因為“黃芪”和“炙黃芪”在原始數(shù)據(jù)里經(jīng)常出現(xiàn)兩個完全獨立的行而圖譜里需要表達“炙黃芪是黃芪的炮制品”。這里用了一個很樸素的做法規(guī)避在中藥表里增加“基原名”字段炙黃芪、生黃芪這類行的基原名字段都指向黃芪。這樣既能保留炮制差異又不至于把節(jié)點數(shù)量膨脹一倍。對于這種清洗邏輯項目里的清洗腳本大概是這樣的思路import pandas as pd # 讀取原始中藥表格式name, alias, property, meridian, efficacy, indications df pd.read_csv(raw_herbs.csv, encodingutf-8-sig) # 炮制規(guī)范化對常見的炮制前綴做映射保留到炮制品字段 processed_patterns {炙, 炒, 生, 煅, 酒} def normalize_name(name): pure_name name processed_flag None for prefix in processed_patterns: if name.startswith(prefix) and len(name) 1: pure_name name[len(prefix):] processed_flag prefix break return pure_name, processed_flag df[[pure_name, processed_flag]] df[name].apply( lambda x: pd.Series(normalize_name(x)) ) df.to_csv(herbs_normalized.csv, indexFalse, encodingutf-8-sig) print(f共處理 {len(df)} 條中藥記錄保留原始name字段不變)邏輯說明先把原字段保留一份然后拆出“純藥名”和“炮制標記”。這樣關系導入時節(jié)點歸到純藥名屬性里保留炮制信息。參數(shù)上processed_patterns集合可以根據(jù)實際數(shù)據(jù)繼續(xù)加前綴比如“鹽”“麩炒”需要改集合就行。清洗之后原始name字段仍然留著方便溯源。3.3 去重與實體對齊等價類合并的通用寫法數(shù)據(jù)清洗里最耗時間的不是字段規(guī)整而是實體對齊。同一種藥在不同方劑里可能寫作“甘草”或“炙甘草”同一首方劑在數(shù)據(jù)里可能一個叫“麻杏石甘湯”、一個叫“麻黃杏仁甘草石膏湯”。不對齊的話圖查詢時會出現(xiàn)明明是一個實體卻分裂成兩個節(jié)點關系路徑全部斷裂。資源里的對齊方式是“別名表 歸一化鍵”。每個實體在CSV里預置一個canonical_id字段別名表里存了至少幾十個常見異名映射。代碼執(zhí)行時先按照canonical_id合并合并后重新分配內(nèi)部ID同時保留別名表為查詢提供入口。import json # 讀取合并規(guī)則canonical_id - 標準實體名 with open(alignment_rules.json, encodingutf-8) as fp: rules json.load(fp) # 原則所有別名都映射到標準名不做模糊匹配 def get_canonical(raw_name: str) - str: return rules.get(raw_name, raw_name) df[canonical_name] df[name].map(get_canonical) # 按canonical_name分組合并別名取合并集的并集 merged ( df.groupby(canonical_name, as_indexFalse) .agg({name: lambda x: |.join(set(x)), efficacy: first, meridian: first}) ) print(f合并前 {len(df)} - 合并后 {len(merged)} 個標準中藥實體)邏輯說明關鍵是get_canonical函數(shù)沒有做任何相似度計算完全靠對齊規(guī)則表做精確映射。理由很實際中醫(yī)藥名詞相似不等于同物“當歸尾”和“當歸”就差一個字功效完全不同拼音或編輯距離一類算法會引入大量噪聲。對齊規(guī)則表雖然維護起來費功夫但對錯完全可控也比訓練一個NER模型輕量得多。從這里能明顯看到數(shù)據(jù)工程環(huán)節(jié)大約貢獻了整份資源一半以上的價值建圖譜本身反而只占用很少時間。4. 入庫Neo4jCQL建模與查詢驗證4.1 為什么選Neo4j而不是純文件存儲數(shù)據(jù)清洗完之后面臨的決策是存在哪里。直接存成JSON或者SQLite也能做查詢但知識圖譜查詢本質(zhì)上是多跳關系遍歷。舉個例子“找出使用含黃芪的方劑來治療氣虛感冒的路徑”純文件存儲需要先把方劑表全部讀入內(nèi)存再循環(huán)匹配組成字段和主治字段復雜度高不說代碼也難維護。Neo4j的Cypher查詢對這種路徑檢索是原生支持的一條MATCH語句就能表達三跳以內(nèi)的全部路徑。這套資源自帶Neo4j的Cypher導入腳本和完整數(shù)據(jù)文件不需要自己從零寫ORM層。4.2 CQL建節(jié)點與關系參數(shù)化導入的寫法節(jié)點導入用的是Cypher的LOAD CSV語句腳本里分成兩步先建節(jié)點再建關系。節(jié)點使用MERGE而不是CREATE重復跑腳本不會制造重復節(jié)點這是部署的時候很省心的設計。// 導入中藥節(jié)點文件路徑是neo4j import目錄下的herbs_normalized.csv LOAD CSV WITH HEADERS FROM file:///herbs_normalized.csv AS row MERGE (h:Herb {id: row.canonical_name}) ON CREATE SET h.alias row.alias, h.efficacy row.efficacy, h.meridian row.meridian, h.taste row.taste, h.property row.property這段腳本的邏輯是一次性導入全部中藥字段。注意點是最底層的MERGE只以canonical_name作為唯一標識也就意味著前面清洗階段的實體對齊質(zhì)量直接決定最終圖譜的節(jié)點數(shù)量。如果在清洗階段沒做別名合并同一個藥會被拆成多個節(jié)點這個坑在下一章會專門展開。屬性上alias字段可以直接存豎線分隔的字符串表Neo4j里用split()函數(shù)查詢時再展開不必在導入階段建數(shù)組。關系導入需要兩張表的連接操作Cypher里寫在LOAD CSV語句的WHERE子句中匹配方劑表和中藥表// 導入“組成”關系一行一個方劑-中藥對 LOAD CSV WITH HEADERS FROM file:///formula_composition.csv AS row MATCH (f:Formula {id: row.formula_id}) MATCH (h:Herb {id: row.herb_canonical_name}) MERGE (f)-[r:COMPOSE {quantity: row.dosage}]-(h)邏輯說明先匹配兩端的節(jié)點再用MERGE建關系關系上掛dosage劑量屬性。這里的關系名用了COMPOSE而不是CONTAINS。因為語義上方劑是“組成”的主動方關系讀起來應該是Formula -[COMPOSE]- Herb這樣在后續(xù)做方劑拆解分析時Cypher查詢可以順著COMPOSE關系從方劑出發(fā)遍歷到所有藥材語義更順。4.3 查詢驗證歸經(jīng)、主治、配伍三條路徑圖譜建好之后第一步不是急著做上層應用而是先跑三條校驗查詢驗證數(shù)據(jù)沒有丟失或錯位。歸經(jīng)查詢看的是從某味藥出發(fā)能到多少個經(jīng)絡節(jié)點主治查詢驗證方劑到癥狀的路徑配伍查詢最有驗證價值因為藥對數(shù)據(jù)是后加的如果前置的實體對齊做得不對很多配伍記錄會指向不存在的藥材ID直接查不出來。// 查詢找出與黃芪有配伍關系的中藥及這些藥在方劑中的出現(xiàn)次數(shù) MATCH (h:Herb {id: 黃芪})-[:COMPOSE]-(f:Formula)-[:COMPOSE]-(other:Herb) WITH other, count(DISTINCT f) AS freq MATCH (h)-[:PAIR]-(other) RETURN other.id, other.efficacy, freq ORDER BY freq DESC LIMIT 20這段的重點是第一個MATCH先找“黃芪出現(xiàn)在哪些方劑里這些方劑還用了哪些其他藥”然后通過WITH把統(tǒng)計結果傳遞下去最后再匹配配伍關系。邏輯上是在做一種簡單的關聯(lián)驗證既然教材說“黃芪-當歸”是配伍藥對那圖譜里這兩味藥應該在同首方劑中頻繁共現(xiàn)。如果查詢結果里某個配伍對的共現(xiàn)頻率是0基本可以斷定清洗階段實體對齊出了問題回去看別名表就行。參數(shù)說明freq的閾值一般取10以上才認為共現(xiàn)有實際意義低于10的可能是偶然同方。LIMIT 20是為了先看排名實際使用中可以去掉限制輸出全量結果。這類查詢跑一遍大概只需要幾十毫秒數(shù)據(jù)量在幾千條節(jié)點級別完全不會有性能壓力。5. SVG可視化圖譜生成避坑與常見問題排查5.1 從關系數(shù)據(jù)到SVG力導向布局的計算邏輯Neo4j瀏覽器自帶可視化但做項目交付時總得把圖嵌入網(wǎng)頁或者導出成圖片。這套資源里的SVG圖譜是直接用Python從圖數(shù)據(jù)算出來的。核心邏輯并不是把Neo4j渲染的結果截圖而是導出節(jié)點關系JSON再用純Python計算力導向布局坐標最終寫成SVG文件。力導向布局的原理簡述假設每個節(jié)點之間有斥力每條關系邊有彈簧一樣的引力迭代幾百輪之后讓整個圖穩(wěn)定下來。代碼里實際用的就是這種經(jīng)典模型迭代輪數(shù)設成了200次慣性系數(shù)0.9。參數(shù)太大圖會震蕩半天不收斂太小又容易陷在局部扭曲的布局里出不來。200輪在小圖數(shù)據(jù)上大概幾秒鐘跑完屬于安全取值。import json import math def compute_force_layout(nodes, edges, iterations200, damping0.9): # 初始化坐標按圓心均勻分布 n len(nodes) for i, node in enumerate(nodes): node[x] 500 300 * math.cos(2 * math.pi * i / n) node[y] 400 300 * math.sin(2 * math.pi * i / n) for _ in range(iterations): for i, u in enumerate(nodes): for j, v in enumerate(nodes): if i j: continue dx v[x] - u[x] dy v[y] - u[y] dist max(math.hypot(dx, dy), 1e-6) # 斥力與距離平方成反比 force 6000 / (dist * dist) u[x] - force * dx / dist u[y] - force * dy / dist for edge in edges: u next(n for n in nodes if n[id] edge[source]) v next(n for n in nodes if n[id] edge[target]) dx v[x] - u[x] dy v[y] - u[y] dist max(math.hypot(dx, dy), 1e-6) # 引力距離越大拉力越強 force 0.01 * dist u[x] force * dx / dist u[y] force * dy / dist v[x] - force * dx / dist v[y] - force * dy / dist return nodes # 讀取Neo4j導出的圖譜JSON with open(graph_export.json, encodingutf-8) as fp: graph_data json.load(fp) nodes compute_force_layout(graph_data[nodes], graph_data[edges]) print(f布局計算完成共 {len(nodes)} 個節(jié)點)邏輯說明先在圓周上做等角初始化保證初始狀態(tài)下節(jié)點不重疊這是防止布局收斂到局部極值的樸素有效做法。然后每次迭代分兩步先全網(wǎng)節(jié)點兩兩計算斥力再對所有關系邊計算引力。參數(shù)上6000是斥力常數(shù)單位面積越大節(jié)點越分散0.01是引力系數(shù)值越大圖越緊湊。實際調(diào)試時看生成的SVG如果中間擠成一團就調(diào)大斥力常數(shù)如果邊長得太長就調(diào)大引力系數(shù)。5.2 渲染值節(jié)點顏色、大小、連邊粗細的調(diào)整布局算出來后渲染是另一個坑。中文節(jié)點名的長度差異很大“四君子湯”和“丹參”的寬度差了四五個像素直接固定節(jié)點半徑會導致文字溢出或者節(jié)點間遮壓。這里實際用的策略是節(jié)點半徑根據(jù)名稱長度動態(tài)計算最小半徑16像素每多一個字加2像素。顏色則按實體類型映射——中藥用淺綠色方劑用淺藍色癥狀/疾病用淺橙色。關系連邊不設箭頭純直線粗細按關系出現(xiàn)的頻次加權共現(xiàn)實體之間的關系線更粗。import html def build_svg(nodes, edges): svg_parts [svg width1200 height900 xmlnshttp://www.w3.org/2000/svg] svg_parts.append(rect width1200 height900 fill#f8f9fa/) for edge in edges: u next(n for n in nodes if n[id] edge[source]) v next(n for n in nodes if n[id] edge[target]) stroke_width min(2 edge.get(weight, 1) * 0.5, 8) svg_parts.append( fline x1{u[x]:.1f} y1{u[y]:.1f} fx2{v[x]:.1f} y2{v[y]:.1f} fstroke#adb5bd stroke-width{stroke_width:.1f}/ ) for node in nodes: radius 16 2 * max(0, len(node[name]) - 2) color {herb: #a3d9a5, formula: #a0c4ff, disease: #ffc9a3}.get( node[type], #dee2e6 ) safe_name html.escape(node[name]) svg_parts.append( fcircle cx{node[x]:.1f} cy{node[y]:.1f} r{radius} ffill{color} stroke#495057 stroke-width1/ ) svg_parts.append( ftext x{node[x]:.1f} y{node[y]:.1f} ftext-anchormiddle dominant-baselinecentral ffont-size12 fill#212529{safe_name}/text ) svg_parts.append(/svg) return \n.join(svg_parts) svg_content build_svg(nodes, graph_data[edges]) with open(graph_visualization.svg, w, encodingutf-8) as fp: fp.write(svg_content) print(SVG文件已生成)邏輯說明每個節(jié)點輸出兩個元素一個圓加一個文字標簽。注意safe_name調(diào)用html.escape這是必須的。原始數(shù)據(jù)如果混入特殊字符直接拼接SVG會生成非法XML。stroke_width做上限控制到8避免高權重邊視覺上蓋過所有節(jié)點。這套SVG可以直接拿瀏覽器打開也可以嵌進HTML報告。想發(fā)布成網(wǎng)頁加一層img標簽就夠了。5.3 避坑四條必須知道的踩坑記錄現(xiàn)象一部分藥材和方劑在Neo4j瀏覽器里有顯示SVG里卻找不到。 原因Neo4j瀏覽器會在結果集里默認做關系展開有些節(jié)點是查詢過程中動態(tài)帶出來的并沒有真正存在于圖數(shù)據(jù)庫里。而SVG生成腳本讀的是顯式導出的節(jié)點表天然缺了這批虛擬節(jié)點。 解決導出前先在Cypher里跑一遍MATCH (n) RETURN n把所有節(jié)點落庫再執(zhí)行導出JSON。我自己每次倒數(shù)據(jù)前都會強制跑一次這個全量查詢。現(xiàn)象二生成的SVG里節(jié)點和中文標簽的位置錯位文字全跑到圓外面。 原因字體寬度估算和SVG實際渲染寬度不一致。代碼用字符數(shù)估算中文寬度但Linux上渲染沒有中文字體時所有字形寬度幾乎一致計算完全失真。 解決在服務器上裝好中文字體或者把font-family顯式寫成系統(tǒng)已有的中文字體名稱。我在部署時發(fā)現(xiàn)最簡單的方案是SVG里直接用family-name: sans-serif大多數(shù)現(xiàn)代瀏覽器和PDF渲染器都能自動回退到系統(tǒng)中文?，F(xiàn)象三LOAD CSV導入時報“Couldnt load the external resource”錯誤。 原因CSV文件名或路徑和Neo4j的import目錄配置不匹配常見的是中文文件名沒轉(zhuǎn)碼或者直接把文件放在了項目目錄而不是import目錄。 解決把CSV統(tǒng)一放進NEO4J_HOME/import目錄且文件名全部改成拼音或英文比如herbs_normalized.csv不在路徑里保留中文?，F(xiàn)象四關系數(shù)量虛高圖譜邊密密麻麻SVG直接變成一團線球。 原因原始數(shù)據(jù)里“主治”關系沒有區(qū)分主次一張方劑動輒關聯(lián)幾十個癥狀全部建成關系后邊的數(shù)量是節(jié)點的十倍以上。 解決資源里給了一個解藥——為關系設置權重閾值只保留出現(xiàn)頻次超過閾值的關系。具體做法是在導出JSON時做個過濾低于閾值的關系直接丟棄。閾值通常取2到3低于2會丟失太多上下文高于5會過濾掉一大部分有效信息。6. 把圖譜能力往下沉拆方分析、替代藥味與問答式查詢6.1 用圖譜距離找替代藥味知識圖譜建好了純粹放在那兒看結構意義很有限它真正值錢的能力是關系推理。這里分享一個親測實用的技巧用圖譜距離來做替代藥推薦。思路很簡單兩味藥如果和同一個方劑群體保持相似的關系模式那它們大概率能互相替代。Cypher里不需要復雜算法一次子圖匹配加Jaccard相似度計算就能給你一個不像從教材里翻出來的替代名單。// 找出與“黃芪”共現(xiàn)方劑相似度最高的前10味替代藥 MATCH (h:Herb {id: 黃芪})-[:COMPOSE]-(f:Formula) WITH h, collect(DISTINCT f.id) AS source_formulas MATCH (candidate:Herb)-[:COMPOSE]-(f2:Formula) WHERE candidate.id h.id WITH h, source_formulas, candidate, collect(DISTINCT f2.id) AS target_formulas WITH h, candidate, source_formulas, target_formulas, [x IN source_formulas WHERE x IN target_formulas].size() AS intersection WITH h, candidate, source_formulas.size() AS s_size, target_formulas.size() AS t_size, intersection WHERE s_size 0 AND t_size 0 RETURN candidate.id, intersection * 1.0 / (s_size t_size - intersection) AS jaccard ORDER BY jaccard DESC LIMIT 10這段查詢不是數(shù)學上的嚴格Jaccard但語義上完全一致交集方劑數(shù)除以并集方劑數(shù)。相似度高的候選藥意味著它們和黃芪出現(xiàn)在同一批方劑里替換風險從經(jīng)驗層面被降下來了。實際使用時不要直接用輸出結果完稿我會把Top10拉出來再做一輪教材核對確認功效分類方向一致后才進入實驗報告。6.2 拆方分析把一首方劑變成知識點子圖另一個實用的進階用法是拆方。把一首方劑從“組成”關系出發(fā)順藤摸瓜找出每味藥的歸經(jīng)、主治和藥對關系然后渲染成一張局部子圖。這個過程特別適合做課程設計或教學演示能把一張方劑背后的知識網(wǎng)絡完整體現(xiàn)出來。// 提取一首方劑的完整知識子圖 MATCH (f:Formula {name: 四君子湯})-[:COMPOSE]-(h:Herb) MATCH (h)-[:MERIDIAN]-(m) MATCH (h)-[:INDICATES]-(d) RETURN f, h, m, d這個查詢出結果之后我用前面的SVG腳本重新生成一張獨立圖譜四君子湯在中心人參、白術、茯苓、甘草圍繞在四周每一個藥再展開歸經(jīng)和主治。效果比任何文字描述都直觀。對做答辯演示或者組內(nèi)分享的人這一招節(jié)省的時間非常可觀。6.3 把SVG快照接進日報的一個小習慣最后分享一個最簡單的落地技巧SVG文件不能直接在Windows照片查看器里打開總覺得不方便所以我每次都順手多做一步用Python的cairosvg庫把SVG轉(zhuǎn)成PNG。代碼只有一行。cairosvg graph_visualization.svg -o graph_visualization.png --output-width 1200 --output-height 900這樣得到的PNG能直接在文檔、課件、周報里引用。從那以后我每次換數(shù)據(jù)源跑完圖譜流程都會強制走一遍“導出JSON → 計算布局 → 生成SVG → 轉(zhuǎn)PNG”四步確認每個節(jié)點都渲染出來再往下做分析。希望這個工作流對你也有用少走點我當年踩過的彎路。本文還有配套的精品資源點擊獲取 中藥知識圖譜構建實戰(zhàn)：數(shù)據(jù)清洗、Neo4j導入與可視化
簡介這套資源定位為中醫(yī)藥知識圖譜實踐入門材料聚焦中藥與方劑兩類核心實體及其關系建模適合計算機、人工智能及中醫(yī)藥信息學方向?qū)W生用于課程設計、畢業(yè)設計或科研起步。包內(nèi)包含17個文件共1.82MB以Python腳本、JSON結構化數(shù)據(jù)、SVG圖譜、HTML交互頁面及Markdown文檔為主其中py文件負責圖譜構建與關系推理JSON數(shù)據(jù)為清洗后的實體關系集SVG與HTML可直接呈現(xiàn)節(jié)點和路徑。已有38人學習/下載適合直接對照README運行驗證無需復雜配置即可一鍵生成知識圖譜。資源不只提供可運行代碼還配有自動生成的可視化結果和詳細文檔便于理解屬性分布與路徑推理二次開發(fā)空間大可擴展實體類型、接入Neo4j圖數(shù)據(jù)庫或?qū)又嗅t(yī)問答模塊。需注意版權聲明僅限學習參考禁止商用。1. 中藥知識圖譜不再靠翻閱教材查關系做中醫(yī)藥數(shù)據(jù)分析的人大概率都經(jīng)歷過這種尷尬要回答“哪些方劑同時包含黃芪和當歸”“某味藥的歸經(jīng)在教材里寫了三處不一致”只能靠人工翻書、復制粘貼到Excel里慢慢比。知識圖譜這套資源解決的核心問題就是把“查數(shù)據(jù)”變成“查關系”。它的產(chǎn)物是一份可運行的Python工程清洗好的中藥與方劑結構化數(shù)據(jù)、Neo4j圖譜模型、SVG可視化圖譜和配套文檔。適合正在做中醫(yī)藥信息化的開發(fā)者、剛接觸知識圖譜想找實戰(zhàn)樣本的研究者以及需要在本地搭一套演示系統(tǒng)的工程師。數(shù)據(jù)量不大但正好覆蓋從建庫到可視化的完整鏈路。2. 先立本體后造數(shù)據(jù)實體、關系與結構化CSV規(guī)范2.1 為什么要先花時間定本體做知識圖譜最容易犯的錯是一上來就寫爬蟲、拉數(shù)據(jù)等數(shù)據(jù)堆到幾千條再想怎么建模。結果就是邊清洗邊改實體定義改到一半發(fā)現(xiàn)“藥”和“藥材”沒統(tǒng)一“方劑”和“處方”各有一套ID后續(xù)所有查詢都得打補丁。這套資源給出的順序是標準的自頂向下先畫本體再寫映射表最后才處理數(shù)據(jù)。核心本體只有四類實體和六類關系不追求覆蓋全部中醫(yī)概念但保證每個查詢路徑閉環(huán)。定本體的核心問題就三個實體分幾類、關系叫什么名字、屬性保留哪些。這里做的是經(jīng)典三元組設計實體有中藥、方劑、疾病/癥狀、藥對。關系的命名角度刻意用了最貼近原文的謂詞比如“主治”“組成”“歸經(jīng)”“配伍”而不是“has_symptom”這類為了泛化而犧牲可讀性的叫法。原因是中醫(yī)藥查詢場景里領域用戶習慣直接看到“某方劑組成含某藥”這種自然映射代碼里多寫幾個空格比解釋命名規(guī)范省時間。2.2 實體與關系的三元組拆法整套圖譜實際落地的三元組結構如下表導入時就是按這張表寫映射腳本。頭實體關系尾實體舉例方劑組成中藥四君子湯 — 組成 → 人參中藥歸經(jīng)經(jīng)絡/臟腑黃芪 — 歸經(jīng) → 脾經(jīng)中藥主治疾病/癥狀麻黃 — 主治 → 風寒感冒中藥藥性屬性值附子 — 藥性 → 大熱方劑主治疾病/癥狀麻黃湯 — 主治 → 惡寒發(fā)熱中藥配伍中藥柴胡 — 配伍 → 黃芩注意“藥對”這一類在表里其實是以“配伍”關系出現(xiàn)的沒有單獨建成實體節(jié)點。這樣做的好處是查詢“與某味藥存在配伍關系的所有藥”就是一次關系遍歷不必把藥對表單獨維護成節(jié)點再映射。已經(jīng)整理好的CSV數(shù)據(jù)里也保持了同樣的結構看完可以直接對比原始表格和體現(xiàn)本體的schema文件。2.3 把教材內(nèi)容整理成結構化CSV的分字段設計拿到手的數(shù)據(jù)文件里中藥表有幾個實際用得上、又容易在清洗階段被忽略的字段藥材名、別名、性味、歸經(jīng)、功效、主治、使用注意。方劑表是方名、組成、功用、主治、用法。最值得留意的字段是“組成”原始整理時很多方子的組成文本是“黃芪三錢、當歸二錢”這種混合寫法不是標準結構化數(shù)據(jù)。因此腳本里專門寫了組成字段的轉(zhuǎn)換規(guī)則拆出中藥名和劑量兩個子字段再映射到中藥表的ID。那種“三錢”“二錢”之類的古劑量單位沒有統(tǒng)一換算成克保留原文只是在建圖譜時把劑量當作屬性放在“組成”關系上而不是塞進藥名節(jié)點。這個決定挺重要因為一旦在數(shù)據(jù)層做了換算不少方劑考證時就會失真。清洗后的CSV可以在后續(xù)步驟里直接交給CQL腳本導入。3. Python數(shù)據(jù)工程爬取、清洗與去重的關鍵代碼3.1 數(shù)據(jù)來源怎么選、邊界在哪數(shù)據(jù)不是隨手抓的源頭的可信度直接決定這圖譜能不能拿出來給人看。資源里的數(shù)據(jù)來源是公開的中醫(yī)藥數(shù)據(jù)庫與整理好的教材附錄不依賴某個特定網(wǎng)站的在線接口因為在線接口隨時可能改版而且不少頁面對請求頻率有限制。整理方式就是把這部分公開資料下載成結構化表格后做清洗。邊界也說明一下這份圖譜的數(shù)據(jù)覆蓋范圍是常見中藥和經(jīng)典方劑不是全量醫(yī)學知識庫像少數(shù)民族藥、地方習用藥材基本沒納入。做藥物研發(fā)、臨床決策支持這類嚴肅用途數(shù)據(jù)量是不夠的但做教學演示、文獻計量、中醫(yī)藥知識問答原型這份數(shù)據(jù)量級剛剛好。3.2 清洗腳本別名、炮制、劑量與單位規(guī)范化拿到CSV之后第一件事是統(tǒng)一命名因為“黃芪”和“炙黃芪”在原始數(shù)據(jù)里經(jīng)常出現(xiàn)兩個完全獨立的行而圖譜里需要表達“炙黃芪是黃芪的炮制品”。這里用了一個很樸素的做法規(guī)避在中藥表里增加“基原名”字段炙黃芪、生黃芪這類行的基原名字段都指向黃芪。這樣既能保留炮制差異又不至于把節(jié)點數(shù)量膨脹一倍。對于這種清洗邏輯項目里的清洗腳本大概是這樣的思路import pandas as pd # 讀取原始中藥表格式name, alias, property, meridian, efficacy, indications df pd.read_csv(raw_herbs.csv, encodingutf-8-sig) # 炮制規(guī)范化對常見的炮制前綴做映射保留到炮制品字段 processed_patterns {炙, 炒, 生, 煅, 酒} def normalize_name(name): pure_name name processed_flag None for prefix in processed_patterns: if name.startswith(prefix) and len(name) 1: pure_name name[len(prefix):] processed_flag prefix break return pure_name, processed_flag df[[pure_name, processed_flag]] df[name].apply( lambda x: pd.Series(normalize_name(x)) ) df.to_csv(herbs_normalized.csv, indexFalse, encodingutf-8-sig) print(f共處理 {len(df)} 條中藥記錄保留原始name字段不變)邏輯說明先把原字段保留一份然后拆出“純藥名”和“炮制標記”。這樣關系導入時節(jié)點歸到純藥名屬性里保留炮制信息。參數(shù)上processed_patterns集合可以根據(jù)實際數(shù)據(jù)繼續(xù)加前綴比如“鹽”“麩炒”需要改集合就行。清洗之后原始name字段仍然留著方便溯源。3.3 去重與實體對齊等價類合并的通用寫法數(shù)據(jù)清洗里最耗時間的不是字段規(guī)整而是實體對齊。同一種藥在不同方劑里可能寫作“甘草”或“炙甘草”同一首方劑在數(shù)據(jù)里可能一個叫“麻杏石甘湯”、一個叫“麻黃杏仁甘草石膏湯”。不對齊的話圖查詢時會出現(xiàn)明明是一個實體卻分裂成兩個節(jié)點關系路徑全部斷裂。資源里的對齊方式是“別名表 歸一化鍵”。每個實體在CSV里預置一個canonical_id字段別名表里存了至少幾十個常見異名映射。代碼執(zhí)行時先按照canonical_id合并合并后重新分配內(nèi)部ID同時保留別名表為查詢提供入口。import json # 讀取合并規(guī)則canonical_id - 標準實體名 with open(alignment_rules.json, encodingutf-8) as fp: rules json.load(fp) # 原則所有別名都映射到標準名不做模糊匹配 def get_canonical(raw_name: str) - str: return rules.get(raw_name, raw_name) df[canonical_name] df[name].map(get_canonical) # 按canonical_name分組合并別名取合并集的并集 merged ( df.groupby(canonical_name, as_indexFalse) .agg({name: lambda x: |.join(set(x)), efficacy: first, meridian: first}) ) print(f合并前 {len(df)} - 合并后 {len(merged)} 個標準中藥實體)邏輯說明關鍵是get_canonical函數(shù)沒有做任何相似度計算完全靠對齊規(guī)則表做精確映射。理由很實際中醫(yī)藥名詞相似不等于同物“當歸尾”和“當歸”就差一個字功效完全不同拼音或編輯距離一類算法會引入大量噪聲。對齊規(guī)則表雖然維護起來費功夫但對錯完全可控也比訓練一個NER模型輕量得多。從這里能明顯看到數(shù)據(jù)工程環(huán)節(jié)大約貢獻了整份資源一半以上的價值建圖譜本身反而只占用很少時間。4. 入庫Neo4jCQL建模與查詢驗證4.1 為什么選Neo4j而不是純文件存儲數(shù)據(jù)清洗完之后面臨的決策是存在哪里。直接存成JSON或者SQLite也能做查詢但知識圖譜查詢本質(zhì)上是多跳關系遍歷。舉個例子“找出使用含黃芪的方劑來治療氣虛感冒的路徑”純文件存儲需要先把方劑表全部讀入內(nèi)存再循環(huán)匹配組成字段和主治字段復雜度高不說代碼也難維護。Neo4j的Cypher查詢對這種路徑檢索是原生支持的一條MATCH語句就能表達三跳以內(nèi)的全部路徑。這套資源自帶Neo4j的Cypher導入腳本和完整數(shù)據(jù)文件不需要自己從零寫ORM層。4.2 CQL建節(jié)點與關系參數(shù)化導入的寫法節(jié)點導入用的是Cypher的LOAD CSV語句腳本里分成兩步先建節(jié)點再建關系。節(jié)點使用MERGE而不是CREATE重復跑腳本不會制造重復節(jié)點這是部署的時候很省心的設計。// 導入中藥節(jié)點文件路徑是neo4j import目錄下的herbs_normalized.csv LOAD CSV WITH HEADERS FROM file:///herbs_normalized.csv AS row MERGE (h:Herb {id: row.canonical_name}) ON CREATE SET h.alias row.alias, h.efficacy row.efficacy, h.meridian row.meridian, h.taste row.taste, h.property row.property這段腳本的邏輯是一次性導入全部中藥字段。注意點是最底層的MERGE只以canonical_name作為唯一標識也就意味著前面清洗階段的實體對齊質(zhì)量直接決定最終圖譜的節(jié)點數(shù)量。如果在清洗階段沒做別名合并同一個藥會被拆成多個節(jié)點這個坑在下一章會專門展開。屬性上alias字段可以直接存豎線分隔的字符串表Neo4j里用split()函數(shù)查詢時再展開不必在導入階段建數(shù)組。關系導入需要兩張表的連接操作Cypher里寫在LOAD CSV語句的WHERE子句中匹配方劑表和中藥表// 導入“組成”關系一行一個方劑-中藥對 LOAD CSV WITH HEADERS FROM file:///formula_composition.csv AS row MATCH (f:Formula {id: row.formula_id}) MATCH (h:Herb {id: row.herb_canonical_name}) MERGE (f)-[r:COMPOSE {quantity: row.dosage}]-(h)邏輯說明先匹配兩端的節(jié)點再用MERGE建關系關系上掛dosage劑量屬性。這里的關系名用了COMPOSE而不是CONTAINS。因為語義上方劑是“組成”的主動方關系讀起來應該是Formula -[COMPOSE]- Herb這樣在后續(xù)做方劑拆解分析時Cypher查詢可以順著COMPOSE關系從方劑出發(fā)遍歷到所有藥材語義更順。4.3 查詢驗證歸經(jīng)、主治、配伍三條路徑圖譜建好之后第一步不是急著做上層應用而是先跑三條校驗查詢驗證數(shù)據(jù)沒有丟失或錯位。歸經(jīng)查詢看的是從某味藥出發(fā)能到多少個經(jīng)絡節(jié)點主治查詢驗證方劑到癥狀的路徑配伍查詢最有驗證價值因為藥對數(shù)據(jù)是后加的如果前置的實體對齊做得不對很多配伍記錄會指向不存在的藥材ID直接查不出來。// 查詢找出與黃芪有配伍關系的中藥及這些藥在方劑中的出現(xiàn)次數(shù) MATCH (h:Herb {id: 黃芪})-[:COMPOSE]-(f:Formula)-[:COMPOSE]-(other:Herb) WITH other, count(DISTINCT f) AS freq MATCH (h)-[:PAIR]-(other) RETURN other.id, other.efficacy, freq ORDER BY freq DESC LIMIT 20這段的重點是第一個MATCH先找“黃芪出現(xiàn)在哪些方劑里這些方劑還用了哪些其他藥”然后通過WITH把統(tǒng)計結果傳遞下去最后再匹配配伍關系。邏輯上是在做一種簡單的關聯(lián)驗證既然教材說“黃芪-當歸”是配伍藥對那圖譜里這兩味藥應該在同首方劑中頻繁共現(xiàn)。如果查詢結果里某個配伍對的共現(xiàn)頻率是0基本可以斷定清洗階段實體對齊出了問題回去看別名表就行。參數(shù)說明freq的閾值一般取10以上才認為共現(xiàn)有實際意義低于10的可能是偶然同方。LIMIT 20是為了先看排名實際使用中可以去掉限制輸出全量結果。這類查詢跑一遍大概只需要幾十毫秒數(shù)據(jù)量在幾千條節(jié)點級別完全不會有性能壓力。5. SVG可視化圖譜生成避坑與常見問題排查5.1 從關系數(shù)據(jù)到SVG力導向布局的計算邏輯Neo4j瀏覽器自帶可視化但做項目交付時總得把圖嵌入網(wǎng)頁或者導出成圖片。這套資源里的SVG圖譜是直接用Python從圖數(shù)據(jù)算出來的。核心邏輯并不是把Neo4j渲染的結果截圖而是導出節(jié)點關系JSON再用純Python計算力導向布局坐標最終寫成SVG文件。力導向布局的原理簡述假設每個節(jié)點之間有斥力每條關系邊有彈簧一樣的引力迭代幾百輪之后讓整個圖穩(wěn)定下來。代碼里實際用的就是這種經(jīng)典模型迭代輪數(shù)設成了200次慣性系數(shù)0.9。參數(shù)太大圖會震蕩半天不收斂太小又容易陷在局部扭曲的布局里出不來。200輪在小圖數(shù)據(jù)上大概幾秒鐘跑完屬于安全取值。import json import math def compute_force_layout(nodes, edges, iterations200, damping0.9): # 初始化坐標按圓心均勻分布 n len(nodes) for i, node in enumerate(nodes): node[x] 500 300 * math.cos(2 * math.pi * i / n) node[y] 400 300 * math.sin(2 * math.pi * i / n) for _ in range(iterations): for i, u in enumerate(nodes): for j, v in enumerate(nodes): if i j: continue dx v[x] - u[x] dy v[y] - u[y] dist max(math.hypot(dx, dy), 1e-6) # 斥力與距離平方成反比 force 6000 / (dist * dist) u[x] - force * dx / dist u[y] - force * dy / dist for edge in edges: u next(n for n in nodes if n[id] edge[source]) v next(n for n in nodes if n[id] edge[target]) dx v[x] - u[x] dy v[y] - u[y] dist max(math.hypot(dx, dy), 1e-6) # 引力距離越大拉力越強 force 0.01 * dist u[x] force * dx / dist u[y] force * dy / dist v[x] - force * dx / dist v[y] - force * dy / dist return nodes # 讀取Neo4j導出的圖譜JSON with open(graph_export.json, encodingutf-8) as fp: graph_data json.load(fp) nodes compute_force_layout(graph_data[nodes], graph_data[edges]) print(f布局計算完成共 {len(nodes)} 個節(jié)點)邏輯說明先在圓周上做等角初始化保證初始狀態(tài)下節(jié)點不重疊這是防止布局收斂到局部極值的樸素有效做法。然后每次迭代分兩步先全網(wǎng)節(jié)點兩兩計算斥力再對所有關系邊計算引力。參數(shù)上6000是斥力常數(shù)單位面積越大節(jié)點越分散0.01是引力系數(shù)值越大圖越緊湊。實際調(diào)試時看生成的SVG如果中間擠成一團就調(diào)大斥力常數(shù)如果邊長得太長就調(diào)大引力系數(shù)。5.2 渲染值節(jié)點顏色、大小、連邊粗細的調(diào)整布局算出來后渲染是另一個坑。中文節(jié)點名的長度差異很大“四君子湯”和“丹參”的寬度差了四五個像素直接固定節(jié)點半徑會導致文字溢出或者節(jié)點間遮壓。這里實際用的策略是節(jié)點半徑根據(jù)名稱長度動態(tài)計算最小半徑16像素每多一個字加2像素。顏色則按實體類型映射——中藥用淺綠色方劑用淺藍色癥狀/疾病用淺橙色。關系連邊不設箭頭純直線粗細按關系出現(xiàn)的頻次加權共現(xiàn)實體之間的關系線更粗。import html def build_svg(nodes, edges): svg_parts [svg width1200 height900 xmlnshttp://www.w3.org/2000/svg] svg_parts.append(rect width1200 height900 fill#f8f9fa/) for edge in edges: u next(n for n in nodes if n[id] edge[source]) v next(n for n in nodes if n[id] edge[target]) stroke_width min(2 edge.get(weight, 1) * 0.5, 8) svg_parts.append( fline x1{u[x]:.1f} y1{u[y]:.1f} fx2{v[x]:.1f} y2{v[y]:.1f} fstroke#adb5bd stroke-width{stroke_width:.1f}/ ) for node in nodes: radius 16 2 * max(0, len(node[name]) - 2) color {herb: #a3d9a5, formula: #a0c4ff, disease: #ffc9a3}.get( node[type], #dee2e6 ) safe_name html.escape(node[name]) svg_parts.append( fcircle cx{node[x]:.1f} cy{node[y]:.1f} r{radius} ffill{color} stroke#495057 stroke-width1/ ) svg_parts.append( ftext x{node[x]:.1f} y{node[y]:.1f} ftext-anchormiddle dominant-baselinecentral ffont-size12 fill#212529{safe_name}/text ) svg_parts.append(/svg) return \n.join(svg_parts) svg_content build_svg(nodes, graph_data[edges]) with open(graph_visualization.svg, w, encodingutf-8) as fp: fp.write(svg_content) print(SVG文件已生成)邏輯說明每個節(jié)點輸出兩個元素一個圓加一個文字標簽。注意safe_name調(diào)用html.escape這是必須的。原始數(shù)據(jù)如果混入特殊字符直接拼接SVG會生成非法XML。stroke_width做上限控制到8避免高權重邊視覺上蓋過所有節(jié)點。這套SVG可以直接拿瀏覽器打開也可以嵌進HTML報告。想發(fā)布成網(wǎng)頁加一層img標簽就夠了。5.3 避坑四條必須知道的踩坑記錄現(xiàn)象一部分藥材和方劑在Neo4j瀏覽器里有顯示SVG里卻找不到。 原因Neo4j瀏覽器會在結果集里默認做關系展開有些節(jié)點是查詢過程中動態(tài)帶出來的并沒有真正存在于圖數(shù)據(jù)庫里。而SVG生成腳本讀的是顯式導出的節(jié)點表天然缺了這批虛擬節(jié)點。 解決導出前先在Cypher里跑一遍MATCH (n) RETURN n把所有節(jié)點落庫再執(zhí)行導出JSON。我自己每次倒數(shù)據(jù)前都會強制跑一次這個全量查詢。現(xiàn)象二生成的SVG里節(jié)點和中文標簽的位置錯位文字全跑到圓外面。 原因字體寬度估算和SVG實際渲染寬度不一致。代碼用字符數(shù)估算中文寬度但Linux上渲染沒有中文字體時所有字形寬度幾乎一致計算完全失真。 解決在服務器上裝好中文字體或者把font-family顯式寫成系統(tǒng)已有的中文字體名稱。我在部署時發(fā)現(xiàn)最簡單的方案是SVG里直接用family-name: sans-serif大多數(shù)現(xiàn)代瀏覽器和PDF渲染器都能自動回退到系統(tǒng)中文?，F(xiàn)象三LOAD CSV導入時報“Couldnt load the external resource”錯誤。 原因CSV文件名或路徑和Neo4j的import目錄配置不匹配常見的是中文文件名沒轉(zhuǎn)碼或者直接把文件放在了項目目錄而不是import目錄。 解決把CSV統(tǒng)一放進NEO4J_HOME/import目錄且文件名全部改成拼音或英文比如herbs_normalized.csv不在路徑里保留中文?，F(xiàn)象四關系數(shù)量虛高圖譜邊密密麻麻SVG直接變成一團線球。 原因原始數(shù)據(jù)里“主治”關系沒有區(qū)分主次一張方劑動輒關聯(lián)幾十個癥狀全部建成關系后邊的數(shù)量是節(jié)點的十倍以上。 解決資源里給了一個解藥——為關系設置權重閾值只保留出現(xiàn)頻次超過閾值的關系。具體做法是在導出JSON時做個過濾低于閾值的關系直接丟棄。閾值通常取2到3低于2會丟失太多上下文高于5會過濾掉一大部分有效信息。6. 把圖譜能力往下沉拆方分析、替代藥味與問答式查詢6.1 用圖譜距離找替代藥味知識圖譜建好了純粹放在那兒看結構意義很有限它真正值錢的能力是關系推理。這里分享一個親測實用的技巧用圖譜距離來做替代藥推薦。思路很簡單兩味藥如果和同一個方劑群體保持相似的關系模式那它們大概率能互相替代。Cypher里不需要復雜算法一次子圖匹配加Jaccard相似度計算就能給你一個不像從教材里翻出來的替代名單。// 找出與“黃芪”共現(xiàn)方劑相似度最高的前10味替代藥 MATCH (h:Herb {id: 黃芪})-[:COMPOSE]-(f:Formula) WITH h, collect(DISTINCT f.id) AS source_formulas MATCH (candidate:Herb)-[:COMPOSE]-(f2:Formula) WHERE candidate.id h.id WITH h, source_formulas, candidate, collect(DISTINCT f2.id) AS target_formulas WITH h, candidate, source_formulas, target_formulas, [x IN source_formulas WHERE x IN target_formulas].size() AS intersection WITH h, candidate, source_formulas.size() AS s_size, target_formulas.size() AS t_size, intersection WHERE s_size 0 AND t_size 0 RETURN candidate.id, intersection * 1.0 / (s_size t_size - intersection) AS jaccard ORDER BY jaccard DESC LIMIT 10這段查詢不是數(shù)學上的嚴格Jaccard但語義上完全一致交集方劑數(shù)除以并集方劑數(shù)。相似度高的候選藥意味著它們和黃芪出現(xiàn)在同一批方劑里替換風險從經(jīng)驗層面被降下來了。實際使用時不要直接用輸出結果完稿我會把Top10拉出來再做一輪教材核對確認功效分類方向一致后才進入實驗報告。6.2 拆方分析把一首方劑變成知識點子圖另一個實用的進階用法是拆方。把一首方劑從“組成”關系出發(fā)順藤摸瓜找出每味藥的歸經(jīng)、主治和藥對關系然后渲染成一張局部子圖。這個過程特別適合做課程設計或教學演示能把一張方劑背后的知識網(wǎng)絡完整體現(xiàn)出來。// 提取一首方劑的完整知識子圖 MATCH (f:Formula {name: 四君子湯})-[:COMPOSE]-(h:Herb) MATCH (h)-[:MERIDIAN]-(m) MATCH (h)-[:INDICATES]-(d) RETURN f, h, m, d這個查詢出結果之后我用前面的SVG腳本重新生成一張獨立圖譜四君子湯在中心人參、白術、茯苓、甘草圍繞在四周每一個藥再展開歸經(jīng)和主治。效果比任何文字描述都直觀。對做答辯演示或者組內(nèi)分享的人這一招節(jié)省的時間非常可觀。6.3 把SVG快照接進日報的一個小習慣最后分享一個最簡單的落地技巧SVG文件不能直接在Windows照片查看器里打開總覺得不方便所以我每次都順手多做一步用Python的cairosvg庫把SVG轉(zhuǎn)成PNG。代碼只有一行。cairosvg graph_visualization.svg -o graph_visualization.png --output-width 1200 --output-height 900這樣得到的PNG能直接在文檔、課件、周報里引用。從那以后我每次換數(shù)據(jù)源跑完圖譜流程都會強制走一遍“導出JSON → 計算布局 → 生成SVG → 轉(zhuǎn)PNG”四步確認每個節(jié)點都渲染出來再往下做分析。希望這個工作流對你也有用少走點我當年踩過的彎路。本文還有配套的精品資源點擊獲取