4.2 AIエンリッチメントの影響: 実例

これらの実例を通して、スキーマのエンリッチがLLMの有効性にどのように直接的に影響するかを確認してください。

例1: 医療イベント - 追跡スキーマ

この例では、医療イベントを追跡するために設計されたスキーマを使用し、医師の活動と、患者のイベント中に実施される具体的な処置に焦点を当てています。

スキーマは、次の3つの表で構成されます:
  • Practitioner表: 医師の名前、専門およびステータスなどの情報を格納します。
  • Event表: 予約の日時および場所、担当医師などの患者の予約に関する概要を記録します。
  • EventDetail表: イベント中に実施された個々の処置(手術など)を記録し、処置の説明、正確なタイムスタンプおよび期間を収集します。 
CREATE TABLE Practitioner (
    practitioner_id NUMBER PRIMARY KEY,
    nm VARCHAR2(80),
    speciality VARCHAR2(40),    -- This represents 'department'
    status VARCHAR2(20)         -- e.g., 'Active', 'Inactive'
);

CREATE TABLE Event (
    event_id NUMBER PRIMARY KEY,
    dt DATE,                    -- Date or time of the overall event
    practitioner_id NUMBER,
    location VARCHAR2(40)       -- e.g., 'OR1', 'ER', 'ICU'
);

CREATE TABLE EventDetail (
    event_id NUMBER,
    act_desc VARCHAR2(200),
    act_time TIMESTAMP,
    duration_minutes NUMBER,    -- Duration of this action or procedure
    CONSTRAINT FK_EVENT_ID FOREIGN KEY (event_id) REFERENCES Event(event_id)
);
スキーマ解釈に関するノート
  • practitionerという用語は、医師と同義です。
  • speciality列は、医師の診療科を表します。
  • EventDetail表のact_desc列には、実施された処置(手術など)が記録されます。
  • EventDetail表のact_time列には、処置を時間ベースでフィルタ処理するためのタイムスタンプが示されます。

ビジネス問合せ

病院の管理者がLLMに次の質問をするとします:

"For each doctor, display their name, department, and the count of surgeries performed after 8 PM within the last six months."

AIエンリッチメントなし

注釈なしの場合、LLMはRAWスキーマを解釈する必要があります。これにより、次のような不備のある問合せになる可能性があります:

SELECT
    PRAC.nm,
    PRAC.speciality,
    COUNT(EVT.event_id) AS surgery_count
FROM
    Practitioner PRAC
JOIN
    Event EVT 
    ON PRAC.practitioner_id = EVT.practitioner_id
WHERE
    EVT.dt >= ADD_MONTHS(SYSDATE, -6)
    AND EXTRACT(HOUR FROM EVT.dt) >= 20
GROUP BY
    PRAC.nm,
    PRAC.speciality;
この問合せにはクリティカル・エラーがいくつかあります:
  • EVT.event_idをカウントしているため、手術のみではなく、午後8時以降のすべての予約が誤って集計されています。
  • EVT.dtでフィルタ処理していますが、これは予約の開始時間であり、具体的な処置の開始時間ではありません。午後1時の予約に午後9時の手術が含まれている可能性がありますが、この問合せではそれが検出されません。
  • EventDetail表との必要な結合が欠落しています。

AIエンリッチメントあり

次の注釈を適用することで、必要なセマンティック・コンテキストをLLMに提供できます。
  • ALIAS注釈をPractitioner表に追加し、doctorとして指定します。
  • ALIAS注釈をPractitioner.speciality列に追加し、departmentとして指定します。
  • DESCRIPTIONおよびSAMPLE VALUES注釈をEventDetail.act_desc列に追加して、手術や診察などのイベント時に実行される特定の処置が含まれていることを明確にします。

このエンリッチされたコンテキストにより、LLMははるかに正確で信頼性の高い問合せを生成できます:

SELECT
    PRAC.nm,
    PRAC.speciality,
    COUNT(*) AS surgery_count
FROM
    Practitioner PRAC
JOIN
    Event EVT 
    ON PRAC.practitioner_id = EVT.practitioner_id
JOIN
    EventDetail ED 
    ON EVT.event_id = ED.event_id
WHERE
    ED.act_desc = 'Surgery'
    AND ED.act_time >= ADD_MONTHS(SYSDATE, -6)
    AND EXTRACT(HOUR FROM ED.act_time) >= 20
GROUP BY
    PRAC.nm,
    PRAC.speciality;
注釈により、問合せは著しく改善されます:
  • EventDetail表への必要な結合が実行されるようになります。これは、特定の処置を検出するために不可欠です。
  • ED.act_desc = 'Surgery'でフィルタ処理され、注釈から手術が処置の一種であることが正しく理解されます。
  • 正しいタイムスタンプED.act_timeが使用され、午後8時以降に実際に行われた手術が検出されます。

この例に示すように、注釈はビジネス用語と物理スキーマ間のギャップを埋めて、LLMがデータの関係を理解し、正しいSQLを生成するように導きます。

例2: 人事管理スキーマ

この例では、salary_convとhire_dtという2つの新しい列をEMPLOYEES表に追加して、HRサンプル・スキーマを拡張します。

スキーマ解釈に関するノート

EMPLOYEES表:

  • salary列は、現地通貨での従業員報酬を表します。
  • salary_conv列は、米ドル(USD)に換算された従業員報酬を表します。
  • hire_date列は、従業員の正式な勤務開始日を表します。
  • hire_dt列は、システム入力日(レコードが最初に作成された時点のタイムスタンプ)を表します。

ビジネス問合せ

ビジネス・アナリストがLLMに次の質問をしたとします:

List each department and the average salary in USD of employees hired after 2020. Order the result by average salary, highest first.

AIエンリッチメントなし

注釈なしの場合、LLMはスキーマ内のRAW表および列名しか読み取ることができません。名前と結合で推測され、不備のある問合せが返される場合があります:

SELECT 
    d.department_name, 
    AVG(e.salary) AS avg_salary 
FROM 
    EMPLOYEES e 
JOIN 
    DEPARTMENTS d 
    ON e.manager_id = d.manager_id
WHERE 
    e.hire_dt > DATE '2020-01-01' 
GROUP BY 
    d.department_name
ORDER BY 
    avg_salary DESC;
この問合せには問題がいくつかあります:
  • salaryおよびhire_dtを選択しているので、必要な列ではなく、曖昧なデータ(現地通貨やシステム・タイムスタンプなど)を誤って取得しています。
  • この特定の関係の正しいキーではないmanager_idで結合しています。そのため、論理的な不一致が発生しています。

AIエンリッチメントあり

次の注釈を適用することで、必要なセマンティック・コンテキストをLLMに提供できます。
  • UNITS注釈をsalary_conv列に追加し、通貨タイプをUSDとして指定します。
  • JOIN COLUMN注釈をd.department_id列に追加し、優先結合パートナをe.department_id列として指定します。
  • DESCRIPTION注釈をhire_date列に追加し、その列を正式採用日フィールドとして明示的に指定します。

これらの注釈を指定すると、生成される問合せがより正確になります:

SELECT 
    d.department_name, 
    AVG(e.salary_conv) AS avg_salary_conv
FROM 
    EMPLOYEES e
JOIN 
    DEPARTMENTS d 
    ON e.department_id = d.department_id
WHERE 
    e.hire_date > DATE '2020-01-01'
GROUP BY 
    d.department_name
ORDER BY 
    avg_salary_conv DESC;

ここでの改善点は重要です:

  • このモデルでは、UNITS注釈に導かれて、salaryフィールドのかわりにsalary_conv列が使用されます。
  • JOIN COLUMN注釈で指定したとおり、正しい結合列(department_id)が選択されます。
  • システム・タイムスタンプが回避されて、日付述語に対して正しい列(hire_date)が選択されます。

重要なポイント

これらの例に示すように、注釈は、正しい結合列の選択、適切な単位の適用、有効な述語の使用、オブジェクト名の解読などをLLMが実行するよう導くことで、問合せの精度を高めます。

注釈を一貫して適用すると、データに関する質問のターンアラウンドが速くなり、誤った結合が少なくなり、不正なSQLによる本番環境の不具合が減少します。LLMの場合、各注釈により、実行可能な問合せ計画の検索領域が縮小され、意図したとおりのパターンに焦点を絞ることができます。

厳格なコンプライアンス・ルールを持つ組織の場合、注釈を使用すると、管理者はLLMと共有される正確なコンテキスト情報を制御することもできるため、自由形式の列コメントに存在する可能性のある機密データの意図しない開示を削減できます。