FDE從逐字稿建立本體論的步驟｜把名詞與動詞的辭典變成AI能追溯的形式

大家好，我是株式會社TIMEWELL的濱本。

這是FDE實務系列的第六篇。前五篇寫的是從現場蒐集的技術。用訪談記下名詞與動詞，用觀察確認，用民族誌加厚意義，用KJ法變成結構，用影片加上數字。五篇裡每一篇都出現「名詞與動詞的辭典」。這次寫的是，那本辭典怎麼變成AI能追溯的形式。

我在之前FDE與AI陪跑支援的差異的文章寫過，不教名詞與動詞，代理就跑不動。代理要做「把訂單分配」這個行為，必須以機器能讀的形式持有：在那家公司訂單是什麼、分配是做什麼、分配前後有什麼。這個形式就是本體論。詞很艱澀，但做的事是用那家公司的話語切分世界，交給機器。想先了解讓工程師團隊具備這種能力的方案，可以先看WARP的頁面。

什麼是本體論。用那家公司的話語切分世界

本體論這個詞來自哲學，但在資訊科學中，Tom Gruber於1993年將它定義為「概念化的明確規格」。以可共享的形式，明確寫下某個領域裡有什麼、它們如何關聯¹。簡言之，就是把那個領域的名詞、動詞與關係毫無歧義地寫下來的辭典。

把這個想法放在企業產品核心的是Palantir。該公司的文件中，本體論是放在整合後資料之上的層，把資料連結到現實世界的對應物，構成要素包括物件型別、屬性、連結、動作型別與函式²。物件對應名詞，連結對應關係，動作對應動詞。在Palantir擔任FDE八年的人把「ontology」列為該公司的老內部用語之一³，可以看出一個結構：FDE把在現場學到的業務意義回流到產品時，承接的容器就是本體論。

為什麼在AI代理的時代需要這個？理由是代理會行動。只做文章摘要的AI，即使那家公司的用語定義模糊也能動。但「把待核准的訂單分配後發出出貨指示」的代理，不知道待核准是什麼、分配是什麼、出貨指示是誰的權限，就動不了。就算動了，也會做出錯誤的分配。名詞與動詞的定義，是代理行動的依據。

從逐字稿到辭典。抽出名詞、動詞、關係、狀態、例外五項

接下來是步驟。材料是系列第一到第五篇蒐集到的東西：訪談逐字稿、觀察的五欄記錄、民族誌的三層筆記、KJ法的群名稱、影片的計數。從這裡抽出五項。

抽出的東西	是什麼	逐字稿的例子	辭典的寫法
名詞	那家公司使用的事物名稱	「訂單來了，先看庫存」	訂單、庫存
動詞	人對名詞做的行為	「把庫存分配後，改成保留」	分配（庫存給訂單）、保留（業務口頭）
關係	名詞與名詞的連結	「訂單一定會連結出貨」	訂單擁有出貨（一對一以上）
狀態	名詞可能處於的階段	「待核准的不碰」	訂單的狀態：受理、待核准、已核准、已出貨
例外	與平常不同的路徑與條件	「急件的時候股長蓋章」	核准的判斷者是課長，但急件類別時是股長

名詞不翻譯成系統用語，照那家公司的詞寫。「分配」和「保留」意義不同，就寫成不同的動詞。這裡KJ法那篇寫的群名稱派上用場。「核准的實際狀況，是股長判斷與課長蓋章的兩階段」這個群名稱，直接成為「核准」這個動詞的定義。辭典裡寫「核准，指股長判斷、課長蓋章」。把兩階段寫進辭典，代理就不會在第一階段停下來。

關係與狀態，從觀察與影片確認。逐字稿說「訂單一定會連結出貨」，但看螢幕錄影，可能有沒出貨就完成的訂單。這時關係修正為「訂單擁有出貨，但樣品出貨除外」。發言與觀察的落差，提高辭典的精度。

例外最重要，也最容易漏掉。「急件的時候股長蓋章」不會出現在功能清單，但會出現在辭典。代理是把急件類別的訂單停在課長的待核准，還是送到股長那裡，由這一行決定。

抽取使用AI。讓它讀逐字稿與觀察記錄，列出五項的候選。提出候選的速度機器較快，從幾百個片段幾分鐘就抽出幾十個名詞與動詞。不過確定由人來做。理由是同一個詞在不同部門有不同意義。業務的「保留」和倉庫的「保留」是不同的行為，機器的抽取會把它們合成一個。辭典裡分開寫「保留（業務）」「保留（倉庫）」，並附上依脈絡決定是哪一個的規則。這個切分，只有在民族誌中把意義加厚的人才做得到。

把辭典變成機器能追溯的形式。圖與代理

辭典完成後，變成機器能追溯的形式：名詞是節點、關係是邊的圖。狀態作為節點的屬性，動詞作為對節點允許的操作，例外作為操作的條件。

變成這種形式的理由，是代理不只回答問題，還會追溯並行動。要回答「這張訂單能出貨嗎」，必須從訂單節點依序追溯狀態（已核准嗎）、關係（庫存分配了嗎）、例外（急件類別的話股長核准就夠嗎）。只搜尋一堆文件做不到這種追溯。把大型語言模型與知識圖譜結合、回答橫跨整份文件的問題的方法，在2024年被系統化為GraphRAG⁴。我們的ZEROCK是以這種形式持有公司內部知識、讓代理能追溯的產品，在現場做的辭典會直接進入產品的結構。

這裡連到a16z在2026年1月文章中寫的「可重複使用的基元」。該文把真正的FDE型態整理為：不是為每個客戶做新功能，而是建立在資料模型、工作流程元件這些可重複使用的基元之上⁵。本體論是其中最基本的基元。「訂單有狀態」「核准可能有多階段」「例外依類別分岐」這些結構，換一家公司也不會變。變的是狀態的名稱、階段數與類別。所以結構放在產品的標準結構裡，名稱、階段數與類別成為每家客戶的設定。在三家公司看到的「核准是兩階段」成為產品的結構，「這家公司急件類別是股長」成為設定。KJ法那篇寫的型與分枝的區分，在這裡落地為產品的結構。

代理的運作細節，寫在脈絡工程的文章（英文）。辭典在交給代理的脈絡中，是最不容易變、錯了最痛的部分。

與委外資料建模的差異

委外開發也有資料建模的工序：找出實體、定義關係、落實為資料庫設計。寫出名詞與關係這一點看起來一樣。把差異列成表。

觀點	委外的資料建模	FDE的本體論
目的	設計系統的資料庫	建立AI代理行動的依據
出處	需求定義書	現場的發言、觀察、影片
動詞與例外	另外寫成功能規格	和名詞寫在一起，附條件
更新	在設計階段凍結	每週依可運作之物的反應更新
歸屬	客戶的資料庫	型放產品的標準結構，分枝作為客戶的擴充
擁有者	開發端	放在現場端，FDE離開後也能更新

最大的差異是動詞與例外的處理。資料建模處理名詞與關係，動詞另外寫成功能規格，例外則以「其他」寫在備註。本體論把動詞與例外和名詞寫在同一個地方，並附條件。對代理來說，「核准」這個動詞和「急件是股長」這個例外，和「訂單」這個名詞同樣重要。

另一個差異是擁有者。委外資料模型的擁有者是開發端，變更就是改修的合約。FDE的本體論把擁有者放在現場端。現場的當事人修改辭典「急件類別的判斷者換人了」，代理的行動就跟著變。做出這個狀態之後，FDE才離開現場。AWS在2026年6月成立的FDE組織，把結束時留下客戶能自行運作的狀態放在設計核心⁶；對我們而言，自行運作的條件是辭典的擁有者在現場。

現場的步驟。每週更新辭典，反映到可運作之物

步驟每週循環。星期一到星期四在現場蒐集，星期五用KJ法做群，從群名稱抽出五項更新辭典，下週一讓代理讀更新後的辭典放下可運作之物，聽當事人說「哪裡不一樣」，修正辭典。這一圈是一週。

辭典要編版本。「核准」的定義第一週是「課長蓋章」，第二週是「股長判斷、課長蓋章」，第三週是「急件類別只有股長」，這樣變化是正常的。留下版本，事後就能追溯代理行動改變的理由。當事人說「和上週的行為不一樣」時，給他看辭典的差異，說明就結束了。

然後決定辭典的擁有者。我們的工程師在現場期間由我們更新，但結束前交接給現場的當事人。交接的是抽出五項的步驟、各部門意義的分法、版本的留法。當事人能自己修改「急件類別的判斷者從股長換成主任了」之後，FDE就不再需要。不再需要，是這道工序的完成條件。

我們的實務與限制

坦白說，辭典是活的，不會完成。現場的話語會變，組織會變，例外會增加。我們帶回來的辭典半年後過時了，這種事發生在沒能把擁有者放在現場的時候。所以我們把擁有者的交接當成完成條件。

也寫限制。AI的抽取，只到提出候選為止。「同一個詞不同意義」「不同的詞同一個意義」，機器分不出來。逐字稿裡「保留」出現40次，其中幾次是業務的保留、幾次是倉庫的保留，由在場的人分類。另外，辭典無法超越蒐集到的片段的品質。訪談如果只在會議室進行，辭典就是「應該有的業務」的辭典，代理會在實際的業務中卡住。第一篇到第五篇的技術要先有，理由也在這裡。

最後坦白說明與產品的關係。我們的ZEROCK是以結構持有這本辭典的產品。所以我們的FDE一邊做辭典一邊培育產品。這不是利益衝突，正是FDE的型態本身。學習不回流到產品的話，那就是委外。不過，辭典的擁有者是客戶，辭典的內容屬於客戶。回流到產品的是結構，不是那家公司的名詞與動詞本身。

總結

在現場蒐集的名詞與動詞辭典，維持辭典的形式代理無法使用。從逐字稿與觀察記錄抽出名詞、動詞、關係、狀態、例外五項，做成圖的形式，讓代理能追溯。這就是本體論，是用那家公司的話語切分世界、交給機器的作業。

與委外資料建模的差異在於：動詞與例外和名詞寫在同一個地方並附條件、每週更新、型回流到產品的標準結構而分枝作為客戶的擴充持有、擁有者放在現場端。FDE不再被需要，是這道工序的完成條件。

想把自家的業務用語變成代理能追溯的形式，或想找把現場的辭典變成產品結構的夥伴，歡迎參考WARP的方案，或透過個別諮詢和我們聊聊。下一篇會寫至今的技術如何在一週之內運轉：FDE的一週，從第一天到星期五。

Footnotes

1. Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2), 199–220. DOI: 10.1006/knac.1993.1008。「概念化的明確規格（an explicit specification of a conceptualization）」依該論文 ↩

2. Ontology overview（Palantir Foundry 文件）。構成要素的說明為筆者對該文件的摘要 ↩

3. Reflections on Palantir（Nabeel S. Qureshi，2024年10月15日） ↩

4. Edge, D., et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130 ↩

5. The Palantirization of everything（Marc Andrusko，a16z，2026年1月16日）。可重複使用的基元（資料模型、工作流程引擎、UI元件）的指摘依該文 ↩

6. AWS invests $1 billion to embed AI forward deployed engineers with customers（Amazon，2026年6月30日） ↩