表紙・介紹・目次的文字內容讀作：把 AI 放在資料旁邊。

愛與前輩的保守支援系統設計

製作・原作：荒川裕二

這部漫畫的簡介

這是一個故事，描述被指派負責保守窗口支援系統的新進工程師青山愛，透過與同一開發團隊的前輩神宮寺一起進行文件搜尋、契約查詢，以及 AI Agent 的設計與試作，逐步獲得設計 AI 系統的自信。

本作將把 AI 功能放在資料旁邊的「In-Database AI」，以及支撐 AI Agent 的「Harness」，與最新的 Oracle AI Database 功能一併介紹。

本作品是根據作者（荒川裕二）在 Qiita 公開的部落格文章改編、重構而成。

感謝公開本漫畫製作所使用的 Manga Generator 的月森ナギ。

本漫畫內容為原作者個人的經驗與見解，並不代表其所屬的日本 Oracle 立場。

目次

1. 在同一個 DB 中管理文件與業務資料 將文件的語意搜尋與業務資料查詢結合起來
2. 將嵌入模型放進 DB 內部 在 DB 中產生向量
3. 在保護客戶範圍下搜尋 依據案件的客戶與機種縮小範圍進行向量搜尋
4. 以檢視表守護 RAG 以檢視表篩選出的文件作為根據，透過 RAG 回答
5. 用 Select AI，從語句轉成 SQL 以 NL2SQL 查詢契約資訊
6. 把工具交給 Select AI Agent 將文件搜尋與契約查詢做成 Agent 的工具

補充指南

原作：荒川裕二的技術文章（Qiita） · 線上研討會「Oracle AI Jam Session」的存檔影片（YouTube） · Demo 的公開 GitHub 儲存庫

登場人物、對話、設計委託皆為漫畫用的創作。企業、機種、保守手順皆基於原始文章中的虛構 demo。繪圖使用了生成式 AI。文章內容僅代表我個人的經驗與見解，並不代表其所屬的日本 Oracle 立場。

序章

這一章的對話文字版01-1

愛： 神宮寺前輩，保守窗口的支援系統，變成由我來設計了。

神宮寺： 這是愛第一次接到 AI 案件呢。設計部分我會陪你一起確認。

01-2

愛： 我有 SQL 經驗。不過 AI 要交給它什麼工作才好呢……

神宮寺： 先從想在窗口回答的詢問開始思考吧。

02-1

預想的詢問

說明： 伺服器的管理畫面打不開。該怎麼辦？

說明： 可以安排現場維護嗎？

02-2

愛： 需要確認現況與操作步驟，還有是否符合可到場的條件。

神宮寺： 需要公司內最新手順，以及這台設備的契約。

02-3

回應詢問的方案

愛： 我希望能把有根據的確認步驟，以及這台設備的契約條件一起回答。

第1章 文件與業務資料，在同一個 DB 中

從兩種問題出發，選擇資料基礎架構

這一章的對話文字版37-1

第1章

文件與業務資料，在同一個 DB 中

將文件的語意搜尋與業務資料查詢結合起來

03-1

神宮寺： 手順和契約確認時要查什麼呢？

03-1b

愛： 手順是產品手冊之類的文件。契約則是依客戶或機器分類的表格。

03-2

手順書：非結構化

契約表：結構化

神宮寺： 文件是找與問題在意義上相似的內容，契約則是找符合客戶資訊等條件的內容。

03-3

愛： 也就是用語意搜尋和條件篩選搜尋，兩者結合起來。

04-1

神宮寺： 向量搜尋可以找到像「打不開」「當掉了」「沒有回應」這類意義相近的字詞呢。

04-1b

愛： 因為不是比對字串是否一致，而是依意義是否相近來搜尋。

04-1c

愛： 契約的部分，如果叫 LLM 判斷「可以現場維護嗎？」它會幫忙判定嗎？

04-2

神宮寺： 這裡要注意。LLM 在相同條件下，答案也可能改變。

04-2b

愛： 那是不是把對 LLM 的指示寫得更明確就好？

30-2

神宮寺： 就算想辦法改善指示，也無法把錯誤和波動完全消除。

神宮寺： 像契約條件這類需要嚴謹性的判定，不能全交給它。

30-3

愛： 用程式做確定性的判定嗎？像 Python 之類的？

神宮寺： 是的。也可以在 DB 的檢視表中，用 CASE 式建立判定欄位。

30-4

三個條件都符合時，就是現場維護對象

無解約・無停用

契約期間內

提供現場維護

Y：現場維護對象 N：非對象

CREATE VIEW contract_judgement AS
SELECT c.*,
       CASE
         WHEN c.status = 'ACTIVE'
          AND TRUNC(CURRENT_DATE) BETWEEN c.start_date AND c.end_date
          AND c.service_scope = 'ONSITE'
         THEN 'Y' ELSE 'N'
       END AS onsite_eligible
FROM contracts c;

30-5

愛： 轉成檢視表有什麼好處？

神宮寺： 可以把規則套用從 LLM 分離出去。同一份契約資料與同一天日期，結果就會一樣。

30-7

愛： 之後要讓 AI 產生 SQL 時也能用嗎？

神宮寺： 可以。AI 只要把「現場維護對象」當成判定欄位的 Y 來讀就好。不必每次都重新組合這三個條件。

30-9

在同一個業務規則下共用

畫面顯示

自然語言轉 SQL

AI 的契約查詢處理

相同的檢視表判定欄位。在不同呼叫位置，規則也不會改變。

30-10

愛： 非對象的契約要從檢視表中刪掉嗎？

神宮寺： 不刪。保留資料列，只把判定欄位設為「N：非對象」。例如，即使在契約期間內，如果只有遠端維護的契約，也不屬於現場維護對象。

30-12

神宮寺： 像這個檢視表一樣，在 LLM 外部支援處理，並與 LLM 搭配推進工作的機制，稱為「Harness」。

30-12b

愛： Harness 是做什麼的呢？

30-14

設計的思考方式

Harness

呼叫 LLM，並串接周邊處理以推進工作的機制

LLM

①

②

③

④

① 準備指示與上下文

② 呼叫作為工具的處理

③ 管理狀態與歷史紀錄

④ 控制執行並檢查結果

30-15

愛： LLM 會讀取語意，思考回答與下一步處理。Harness 負責支援它的執行呢。

神宮寺： 沒錯。應該要保護的權限與業務規則，不能只依賴 LLM 的判斷，而要由 Harness 端來確認。

30-15b

這次的具體例子

愛： 以這次來說，契約判定交給 DB 的檢視表。回答或處理是否與判定值一致，則由程式碼來檢查。

神宮寺： 那個組合就是這次 Harness 的一部分。

DB 的檢視表：回傳契約判定值

檢查程式：將回答或處理與判定值比對

38-8

設計的思考方式

VIEW as a Harness

把判定與範圍放進檢視表，AI 只看檢視表

不是產品功能名稱，而是設計思考方式

05-0

愛： 文件資料和契約資料，應該在哪裡管理比較好呢？

05-1

愛： 把文件放在向量 DB、契約放在業務 DB 的做法呢？

神宮寺： 可以獨立擴充搜尋。不過，契約變更或文件下架，必須持續同步到搜尋端。

05-2

如果複製資料更新延遲

業務 DB：已取消

搜尋用複本：尚未同步

愛： 如果解約或文件下架沒有傳過去，就會把說明說錯。

05-3

神宮寺： Oracle AI Database 的話，可以在同一個 DB 中同時處理業務表與向量。

神宮寺： 直接使用最新的業務表，因此能減輕搜尋用複本與同步的負擔。

38-1

產品

Oracle AI Database

業務表、文件、向量，全都在同一個 DB 中

05-4

愛： 因為在同一個 DB 裡，所以可以用 JOIN 或 EXISTS 與最新的業務表比對，進而篩選文件呢。

38-2

Oracle AI Database 的功能

AI Vector Search

將向量作為表格欄位，並可用 SQL 搜尋語意相近的文件。與業務表的 JOIN 也可直接進行

SQL 搜尋

向量欄位

向量距離

31-1

以鐵路公司為假想的分析範例

神宮寺： 能在同一個 DB 中處理的，不只有表格與文件。來看一個會用到位置資訊的鐵路例子。

31-2

愛： 除了車輛類型與期間之外，還能調查是否進入新潟縣嗎？

神宮寺： 類型與期間是關聯式表格。是否進入該縣，則透過行駛位置與縣的地理空間資訊來調查。

31-4

神宮寺： 那份車輛・期間報告中，本文是否包含「煞車」或「制動機」，可用全文搜尋。

神宮寺： 在那之中，找出與凍結影響語意接近的報告，則是向量搜尋。

31-6

愛： 把表格、地圖、文章的條件，都能用同一個 DB 的 SQL 組合起來呢。

07-1

愛： 我們的系統也希望使用文件的公開狀態與契約資訊的最新資料。

愛： 為了就地使用最新資料，把 AI 放在資料旁邊。這次選擇 Oracle AI Database。

38-6

設計的思考方式

In-Database AI

在資料所在之處執行 AI 的搜尋與處理

07-2

愛： 文件修改後，就得重新產生它的向量，對吧。

神宮寺： 沒錯。所以向量要在哪裡、怎麼產生很重要。接下來就來想這件事吧。

第2章 嵌入模型放進 DB 內部

決定在哪裡執行嵌入

這一章的對話文字版37-2

第2章

嵌入模型放進 DB 內部

在 DB 中產生向量

08-1

愛： 要把文件轉成向量，需要用什麼？

神宮寺： 用嵌入模型。把文件和問題用同一個模型轉換。

08-2

嵌入模型與向量搜尋

文件與問題

嵌入模型

文件與問題的向量

愛： 搜尋與問題向量接近的文件向量。透過 Oracle AI Database 的 AI Vector Search，就能在 DB 內部進行這個搜尋。

08-4

愛： 嵌入模型要用雲端的 API 嗎？

08-3

神宮寺： 也可以使用外部 API，也可以把嵌入模型匯入到 DB 內。

38-3

Oracle AI Database 的功能

匯入嵌入模型

將相容的 ONNX 格式模型匯入 DB，無需把文件送出即可向量化

32-1

執行嵌入模型的位置

DB 內部

雲端等外部 API

神宮寺： 使用外部 API 時，所有搜尋對象文件都必須送到外部模型去轉成向量。

09-2

愛： 如果是用來回答的摘錄，可以送到外部 LLM。不過，為了準備搜尋，把所有內部文件都送出去還是想避免。

09-3

神宮寺： 如果在 DB 內部向量化，就不必把全部文件送到外面。

神宮寺： 要檢證轉換速度、DB 負載與同時執行數。

10-1

嵌入模型在 DB 內部、回答生成 LLM 在雲端 API

處理地點 傳遞的資料 向量轉換 DB 內部 文件與問題 回答生成 雲端 API 問題與必要的文件摘錄

10-2

愛： 嵌入在 DB 內部，回答生成交給雲端的 LLM。依照角色分工使用。

11-3

multilingual-e5-large

神宮寺： 可以試試看支援日文的知名 OSS 嵌入模型 multilingual-e5-large。

神宮寺： 只要轉成 ONNX 格式並匯入 DB，就能在 SQL 的 VECTOR_EMBEDDING 中使用。

11-1

嵌入模型匯入

必要檔案一式

Object Storage（雲端檔案存放區）

載入到 DB

神宮寺： 準備好驗證與權限，從 Object Storage 載入模型吧。

11-2

愛： 這樣就解決了搜尋與問題語句相似文件的問題了嗎？

神宮寺： 搜尋的準備是完成了。不過，找到相似文件後，就能直接拿來做引導嗎？

第3章 保護客戶範圍的搜尋

從相似文件，走向可供引導的文件

這一章的對話文字版37-3

第3章

保護客戶範圍的搜尋

依據案件的客戶與機種縮小範圍進行向量搜尋

12-1

設計的驗證案例：只靠語意搜尋

愛： 如果是和「管理畫面打不開」意思相近的文章，看起來應該能找到候選。

12-2

雖然相似，但不能直接使用

別的機種：BX-200

已廢止的文件

愛： 啊，是別的機種。而且已廢止。這不能拿來做引導。

33-1

神宮寺： 不只是別的機種或已廢止文件，別的客戶專用文件也不能混進來。

33-1b

愛： 即使是同一機種、相似症狀，若引導到別的客戶專用步驟，也會很麻煩。

33-2

神宮寺： 這次是對案件 SR001、客戶 C001 的回應。別把其他客戶的機器或契約混進來。

33-2b

愛： 就算工程師能處理其他客戶，單次回答也只能限於正在處理的客戶。

33-3

從處理中的案件決定搜尋對象

SR001：處理中的案件

C001：詢問來源客戶

DEV001：該客戶的機器

AX-100：機器機種

33-4

愛： 先依這位客戶可引導的文件範圍、機種、公開狀態縮小，再依語意相近程度搜尋呢。

33-5

愛： 如果在 SQL 裡忘了加客戶條件，要怎麼防止？

神宮寺： 使用只回傳處理中客戶的檢視表。之後若要讓 AI 產生 SQL，也很有幫助。

33-6

愛： 那麼，這個「處理中的客戶」要怎麼傳給 DB 呢？

神宮寺： 把從案件查出的客戶 ID 保存在這個 DB 連線中。

33-7

神宮寺： 檢視表會將連線中保存的客戶 ID，與表中每一列的客戶 ID 透過 WHERE 進行比較。

神宮寺： 因此只會回傳正在處理的客戶資料列。

33-8

使用保存的客戶 ID 作為 WHERE 條件

候選：C001 / DEV001

候選：C002 / DEV009

回傳：C001 / DEV001

CREATE VIEW OJ41_VISIBLE_DEVICES 
AS 
SELECT d.* 
FROM OJ41_DEVICES d 
WHERE d.customer_id = 
OJ41_CASE_CTX.customer_id();

打開 SR001 時，這個連線會保存 C001。

customer_id() 會回傳 C001。

透過 WHERE 只回傳 C001 的資料列。

33-9

愛： 那如果不先打開案件就搜尋呢？

神宮寺： 連線中的客戶 ID 一開始就先清掉。若未設定，就不會有符合的資料列，結果會是 0 筆。會往安全的一側傾斜。

33-10

愛： 文件也只限制在正在處理的客戶能使用的範圍嗎？

神宮寺： 只限於已公開的共通文件，以及該客戶專用文件。搜尋時也要指定機種。

33-11

文件可用於回答的範圍

已公開：共通文件、C001 專用文件

排除：C002 專用、內部限定、草稿、已廢止

案件未設定則為 0 筆

將剩下的候選依機種縮小，並比較向量距離

33-12

愛： 如果用檢視表，AI 就算忘了客戶條件也沒關係嗎？

神宮寺： 沒問題。不過要把 DB 權限定在這個檢視表。若原始表仍可直接讀取，就無法保護。

33-14

愛： 如果契約過期了，文件也不提供嗎？

神宮寺： 已被允許的技術文件還是可以引導。這和是否能現場維護是不同的。

33-16

愛： 測試時，會確認工程師的授權，以及別客戶、未設定的案例。

愛： 連線中保留的客戶資訊，不論成功或失敗都會清除。

15-3

愛： 文件搜尋的設計已完成。接下來要把它變成工程師可用的回答。

第4章 以檢視表守護 RAG

以檢視表選出被允許的文件，並以其本文作為根據來組成回答。

原文出處：https://qiita.com/yuji-arakawa/items/1c6d0ae4400ca2b4bae3