從 LM5155 出發：理解 Neo4j 的設計原理

一開始，我想做一個跟硬體工程有關的 AI 專案，也想透過這個專案學 Neo4j。

但討論到怎麼存元件、怎麼拆節點的時候，我反而有點不知道：我們本來要做什麼？LM5155 是從 BOM 表來的嗎？為什麼現在需要 Neo4j？

所以這篇先把目的講清楚，再用這個元件，慢慢看 Neo4j 為什麼要這樣設計。先不寫程式碼。

我們要做的是「AI 替料評估助手」。工程師想換一顆料，需要整理需求、查候選元件的規格、比較差異。我希望 AI 能協助這些工作，但結果要有資料可以查回去，不能只回答一句「可以換」。

目前的案例來自一則公開的 TI 論壇替料提問：原本想替換的是 LT8301ESS，需求包含輸入 14–30 V，回覆中提到了 LM5155。這次沒有匯入真實 BOM。我們拿它當候選來研究，不代表已經確認可以替換。

判斷有依據、有規則；未知有原因，補齊有動作、有標準。

意思是，說符合，要能講出根據哪份資料、用了什麼判斷規則。說不知道，也要講清楚為什麼不知道。

知道缺什麼，才知道下一步要補什麼。補完之後，還要能確認這個問題真的有被回答。

這是我們希望系統做到的事，不代表目前所有補件和覆核流程都已經做完。

一、先想要回答什麼，不要先決定建立幾個節點

那 Neo4j 要放在哪裡？如果只是記住「這顆叫 LM5155」，存一行文字就好了，好像也不需要圖資料庫。

所以我想先問：資料存下來以後，我們到底想查什麼？

• 這個案件要求什麼？
• 為什麼把 LM5155 列為候選？
• 要檢查的規格，在什麼條件下成立？
• 這條規格來自哪份文件？
• 如果來源需要重新核對，哪些案件可能需要跟著重查？

這些問題串起來，就是一條初步的關係路徑：

案件 → 候選元件 → 條件規格 → 文件版本

這樣比較能理解：我們不是為了畫一張圖，而是希望問到這些問題時，找得到對應的資料。不過，連得起來還不夠，接下來要看每一段有沒有連對。

二、為什麼「元件」應該是一個節點？

先從比較直覺的開始。我們會想查 LM5155 有哪些規格，也會想知道哪些案件考慮過它。既然會單獨找到它，就有理由把它做成一個節點。

但這裡又有一個問題：我們說的「一顆元件」，到底是型號、完整訂購料號，還是某張板子上實際裝的那顆？這三件事不一樣。

這篇先談型號層級的 LM5155。不能因為名稱相近，就自動把其他尾碼或不同型號合併；也不能把同一型號在不同電路中的實際接法，當成元件永遠固定的性質。

所以畫第一個圓圈之前，要先說清楚它代表什麼。

對照另一個領域也一樣：一本書、一個版本，以及圖書館裡某一本實體藏書，可以是三種不同身分。

三、為什麼不能只在 LM5155 上寫「最大電壓 45 V」？

接著我會想：既然有元件節點，那把電壓上限直接放在它上面，不就好了？

問題是，光看「最大電壓 45 V」，我們不知道它在講哪個腳位，也不知道什麼情況下能用這個數字。

專案保存的 LM5155 規格草稿中，就有兩筆不同條件的 BIAS 建議工作電壓範圍：

兩筆還附有接面溫度 −40 至 125°C 的條件，以及文件頁碼、章節和註腳。這些是從 SNVSB75E、Rev E 整理的待覆核規格草稿，依據是 TI 的 LM5155 資料表，不是對實際電路的核准。

如果只留下「最大電壓 45 V」，第二種接法的差異就不見了。系統可能看到需求上限是 30 V，就說符合。可是我們連應該用哪一筆規格都還沒確認，怎麼能先比數字？

到這裡，把「規格」另外做成節點，就有理由了。

這裡的規格節點不是整份資料表，而是：

這顆元件的哪一項規格？在什麼條件下成立？是哪份文件說的？

同一個元件可以連到多個規格節點。正常工作範圍與絕對最大值也應分開，不因為都是電壓就混為一談。

四、那數值、單位與條件，為什麼不全部變成節點？

既然規格值得獨立，45、V、溫度、接法是不是也要各畫一個圓圈？

不一定。拆得越細，不代表設計越好。

我們目前需要獨立追蹤這條規格，而數值、單位、接法和溫度是在描述它。先把它們放成規格的屬性，已經能保留必要資訊。

我會先用這個方式分：

這不是永遠不變的規則。假如未來要管理一組可被多個設計共用、有獨立版本與證據的接法配置，接法就可能值得成為節點。

所以不是看到一個名詞，就把它拆成節點。要看我們需不需要單獨找它、引用它，或追蹤它的變化。

Neo4j 官方也介紹了中介節點的建模方式：當一個連結背後承載了需要獨立組織的情境，可以讓它成為對象。我們把規格獨立出來，是為了追蹤條件與出處的設計選擇，不是所有專案都必須遵循的固定 schema。官方建模說明

五、線連起來了，但這條線在說什麼？

現在我們有案件、LM5155、規格與文件。把它們連起來時，不能只寫一個含糊的「相關」。

比較下面兩句：

• 這個案件「考慮」LM5155。
• LM5155「可以替代」LT8301ESS。

這兩句看起來都在連元件，但意思差很多。「考慮」只是先放進候選名單，「可以替代」已經是在下結論了。

因此，這張圖可以表達：

• 案件「要求」某個輸入範圍。
• 案件「考慮」LM5155。
• LM5155「有一條規格」。
• 這條規格「擷取自」某份文件版本。

但在證據不足時，不建立「可以替代」的關係。

每一條線都應該能讀成一句話，而且那句話不能超過我們的證據。

把線畫進 Neo4j，不會讓這句話自動變成真的。還是要回頭問：我們有什麼資料，可以支持這樣連？

六、為什麼需求要和元件分開？

14–30 V 是這個案件提出的需求，不是 LM5155 自己的規格。

如果把需求直接放在元件上，另一個案件需要不同的電壓範圍時，就會混在一起。元件是被查詢的對象，需求則屬於案件。

這裡我覺得要分清楚三件事：

需求方想要什麼、文件記載元件在何種條件下能做什麼，以及這次實際設計是什麼。

尤其要注意：案例的「板端輸入電壓」，不能只因為單位也是 V，就直接當成候選元件的 BIAS 腳位電壓。兩者如何對應，需要實際設計資訊。

同樣地，規格寫「某接法下成立」，不表示本案就是那種接法。文件提供的適用條件，與實際電路滿足條件的證據，必須分清楚。

那現在卡在哪裡？我們知道有這些規格，卻不知道這次電路應該用哪一筆。這就是一個需要記下來的「缺口」。

缺口不一定一開始就是節點。只要標記一個欄位未知，可能用屬性就夠；若要追蹤它阻擋哪項檢查、下一步做什麼、何時算補上，就有理由讓它獨立存在。

不能只存一句「資料不足」就結束。以 BIAS／VCC 接法還沒確認為例，我們要繼續問下去：

未知的原因，會帶出下一個補齊動作。不是少一個欄位，就叫模型填一個值。也不是收到一份附件，就當作已經補完。要看新資料是不是真的回答了原本的問題。

補齊資料，只代表這項檢查可以繼續，不代表檢查必然通過，更不代表整顆元件已核准替換。

七、為什麼文件需要版本，案件也需要快照？

接著還有一個問題：兩個月後，資料更新了怎麼辦？

如果我們直接把原本的規格覆蓋，回頭查看舊案件時，就可能看到一份當時根本沒用過的資料。系統雖然顯示「有來源」，卻已經無法解釋當時的判斷。

所以回頭查一個案件時，至少要知道：

• 當時引用哪份文件內容。
• 當時整理出的規格是哪一版。
• 當時案件採用哪一組需求與證據。

文件版本不只是網址：同一個網址可能提供更新後的檔案。版本標示與內容指紋，可以協助區分保存的內容；指紋用來辨識變更，不會證明內容正確。

這也是為什麼要留案件快照。名字聽起來有點技術，其實就是留一張「當時用了哪些資料」的清單。新資料進來，再留新的版本，不要把舊案件的依據一起改掉。

這還帶出關係屬性的用途。假設同一個 LM5155 節點連著多批規格，「案件考慮 LM5155」這條連線可以附上當時引用哪一批規格。那是這次案件與元件之間的情境，不是 LM5155 本身永久不變的屬性。

有路徑可以走到資料，不代表沿路找到的每份資料都適用於這個案件。

八、這樣的圖，究竟能幫我們回答什麼？

設計完成後，可以從不同方向讀同一批關係：

從案件出發，追問它的候選、規格與來源；從文件出發，反查哪些規格引用它，再找出哪些案件可能需要重新核對。

但查到一個案件「可能需要重看」，不代表它一定有問題。它可能只是考慮過這顆料，最後沒有採用；文件更新了，也不代表原本的答案一定會變。

若未來要追蹤「哪個正式判斷實際使用了哪幾條證據」，還需要另外保存判斷本身與它的證據連結。不能拿候選關係假裝已有這些資料。

所以 Neo4j 幫我們做的是把關係和依據找出來。至於新資料會不會改變判斷，還是要按照規則重新檢查，必要時交給工程師確認。

同樣的關係也可以用關聯式資料庫設計。若只有一個案件、幾筆規格與一次數值比較，JSON 或表格可能更簡單。選 Neo4j，是因為希望把跨對象的連結當成主要查詢方式；不能只因為用了圖資料庫，就宣稱更快或更準。

最後，我想帶走的是設計的思路

我不想只記住「LM5155 要這樣存」。換一個元件、換一個專案，如果又不知道怎麼設計，那就沒有真的學到。

所以比起記這張圖，我更想記住這幾個問題：

1. 我要用資料回答什麼？
2. 哪些對象需要獨立身分？
3. 哪些值只是描述這個對象？
4. 每一條關係，有什麼證據支持？
5. 資料更新後，能不能還原案件當時使用的依據？

問完這些問題，再來決定節點、關係和屬性，才知道自己為什麼這樣設計。

這是我想用這個專案練習的事：知道每一份資料為什麼要留、現在能回答什麼，以及還不能回答時，下一步要做什麼。