休薬レンズアプリ用に、医療ガイドラインを LLM で抽出してマスタ化した

Last updated at 2026-07-11Posted at 2026-07-10

ハルシネーション対策の 5 層検証パイプラインと月次自動更新システムについて記述します

医療従事者向けの Web アプリ休薬レンズ (KyuyakuLens) を作っています。手術・造影 CT の前に「休薬すべき薬」を服用中の患者を、お薬手帳の OCR から抽出して警告するアシストツールです。判定の根拠になっているのが、学会ガイドライン (以下 GL) 30 本超と PMDA 添付文書、それを 155 剤分に落とし込んだ薬剤マスタです。

手術・造影 CT の前には、抗血小板薬・DOAC・SGLT2 阻害薬・メトホルミンなど、事前に休薬しなければ出血・血栓・造影剤腎症・euDKA・乳酸アシドーシスといった重篤な有害事象を招く薬剤群があります。現場では短い診察時間の中で患者のお薬手帳を目視確認して休薬指示を出しますが、 見落とし事例は全国で恒常的に発生 しており、現場の医療者は強い危機感を抱えています。

見落としの構造的な要因が、チェック対象の物量です。判定対象の一般名 155 剤に対応する販売名は、先発品・後発品・配合錠を合わせると数千種類に及びます。これらを人力でもれなくチェックするのは合理的に不可能で、特に後発品は年 2 回の薬価収載で続々と新規銘柄が追加されるため、医師一人がすべてを記憶するのは現実的でない。 医療安全向上のためのアシストツール が現場から強く熱望されていました。

問題は、この「マスタを作って維持するプロセス」の信頼性です。医療で使う判定ツールの数値が間違っていると、医療者の最終判断が介在するとはいえ、医療事故に直結する可能性があります。「LLM が要約した GL 数値」をそのままマスタに載せる、なんて恐ろしくてできない。でも全 GL を医師が手作業で継続追跡するのも、これはこれで現実的でない。

この記事では、その両者の中間を埋めるために実装した 中間ファイルを介した 5 層検証パイプライン を書き残します。「LLM を一次抽出者として使いつつ、出力をそのまま信じない」ための具体的な 6 種類の検証施策と、月次の自動更新機構、現時点で真の hallucination を累積 0 件に保っている運用実績です。

同じように「LLM を業務で使いたいけど、出力をそのまま信じるのが怖いドメイン」の方の参考になれば幸いです。

1. なぜ「LLM 単独」も「全て人力」も駄目なのか

1.1 LLM の出力をそのまま信じると起きること

LLM (大規模言語モデル) を GL PDF に適用すると、数値抽出は高速で網羅的にできます。しかし実運用で以下の具体的な誤りが発生しました。

(a) 年号の埋め合わせ

LLM が「JSA 2024 改訂第 2 版」と出力したが、 PDF の metadata を確認すると実際は 2026 年発行。学会 GL は年号が critical な一次情報 (旧版と新版で数値が変わる) なので、これはそのまま事故に直結する。

(b) paraphrase による意味 drift

原文の「休薬を提案する (弱く推奨)」が LLM 出力では「休薬すべき」に、「休薬は必須でない」が「休薬不要」に、と微妙に強い/弱い方向に変わる。医療 GL の語尾は推奨強度を表す語彙なので、これも事故直結。

(c) 解説記事と GL 本体の混同

学会サイトには GL 本体と解説記事 (専門誌掲載の解釈記事) が混在。 LLM は形式が似ているため区別せず引用してくる。実際に JCS 2021 心不全 GL で 3 件の誤引用を発見した。本体を primary reference と信じていたら解説だった、という汚染で、LLM 特有といえる。

(d) 旧版 GL の巻き込み

同じ学会が新版 GL を出しても、旧版 PDF がサイト上に残っている場合、 LLM はしばしば旧版を primary として引用する。数値が変わっているのに旧値のままマスタに入る。

1.2 全て人力でやろうとすると起きること

「じゃあ全部医師が読めばいい」の案も、実運用スケールでは破綻します。

学会 GL は数年に 1 回改訂される。 30 本超の GL × 155 剤の継続追跡は手作業では追いつかない
後発品は年 2 回の薬価収載で追加される。新規銘柄を人力で追い続けるのは非現実的
学会サイトが URL・ファイル名を変えずに内容だけ差替えた場合、人力ではほぼ気づけない
継続的な保守が個人の労力に依存すると、担当者の交代・病休で更新が止まる

つまり 「LLM の網羅性・速度」と「人間の判断精度」のどちらも単独では使えない。両者を適切な段階で分業させる必要がある。

1.3 そして「作って終わり」なら信頼性は時間と共に下がっていく

さらに悪いことに、このマスタは 静止したデータではない。学会 GL は数年おきに改訂され、後発品は年 2 回の薬価収載で追加され、学会サイトは URL を変えずに内容だけ差替える。何もしなければマスタは以下のように劣化していく:

6 ヶ月放置: 新規発売の後発品 (数十銘柄) がマスタから抜ける → 「見落とし」発生
1 年放置: いずれかの主要 GL が改訂されている → primary 数値が旧版のまま → 「古い判定」発生
2 年放置: 複数の主要 GL が改訂、廃止・名称変更薬剤が発生 → マスタの数値の一部が誤っている状態に
3 年以上放置: 数値の相当数が現ガイドラインと不整合 → 「使えるが信用できない」段階に到達

医療 domain のアシストツールの信頼性は 時間と共に単調減少する。しかも医療現場でツールが信用を失うのは一瞬で、一度「またこれか」と判断されると二度と使われなくなる。信用の減衰は連続的だが、使われなくなる瞬間は離散的、という非対称性が怖い。

つまり LLM 抽出を医療 domain で使う場合、 「抽出パイプライン」と「更新パイプライン」は車の両輪 であり、抽出だけ作って更新機構を後回しにするのは実質的に「初日から陳腐化するシステムを作った」のと変わらない。更新機構の構築は拡張機能ではなく 必須要件 である、というのがこのプロジェクトを通じて一番強く感じた点です。

以下、層 3-4 の検証補強 (章 5-8) と継続更新機構 (章 9) はこの視点で設計されています。「一度 verified 化したら終わり」ではなく、 verified の有効期限 (次回 GL 改訂まで、あるいは次回独立 LLM 再検証まで) を常に意識する。

2. 5 層パイプラインの骨格

原典 PDF から判定 UI まで、データが通る 5 層をこう組みました。

上図が全体像。以下の ASCII 版はファイル名を追いやすい形で並べたものです。

[ 層 0: 原典 ]                        [ 層 1: 抽出 ]
学会 GL PDF (30 本超) ────────────►  primary.yaml   ┐
PMDA 添付文書                                        │──►
KEGG MEDICUS                          independent.yaml  ┘
_manifest.json (更新監視)
                                                      │
                                                      ▼
                                              [ 層 2: 突合裁定 ]
                                              人間が PDF 原文で 再確認
                                              → <gl_id>.yaml (FINAL)
                                              + reconciliation.md
                                                      │
                                                      ▼
                                              [ 層 3: 自動集約 ]
                                              全 FINAL YAML から
                                              guideline_variations.json 生成
                                                      │
                                                      ▼
                                              [ 層 4: 薬剤マスタ ]
                                              drug_list.json
                                              primary 値 + references (verbatim)
                                              + provisional_* (KEGG 仮登録)
                                                      │
                                                      ▼
                                              [ 層 5: 判定 UI ]
                                              処置別ラジオ + GL 別併記

キーポイントは 3 段の分岐/合流です。

層 1 で 原典 → 2 本の独立抽出 への Y 字分岐
層 2 で 2 本 → 1 本の FINAL への Y 字合流 (人間が裁定)
層 3 で N 本の FINAL YAML → 1 本の variations マトリクス への N → 1 収束

以下、各層で何をどう検証しているか具体的に。

3. 層 1: dual-agent 抽出 — 独立 2 本で LLM の誤りをあぶり出す

同じ GL PDF に対し、 プロンプトと session を分けた 2 つの LLM で別々に抽出 します。出力はそれぞれ primary.yaml と independent.yaml。

たとえばリバーロキサバンの抽出結果 (JSA 2026 kokesen GL):

# primary.yaml (Agent A)
- name: リバーロキサバン
  aliases: [rivaroxaban, イグザレルト, Xarelto]
  drug_class: DOAC (直接第 Xa 因子阻害薬)
  covered: true
  high_risk_days: 3
  high_risk_hours: 72
  resumption_after_catheter_removal: 6 時間
  location_in_source: p.25 表 9 抗凝固薬
  quote: "リバーロキサバン | 3 日 (72 時間) | 6 時間"
  extractor_confidence: high

# independent.yaml (Agent B, 別 session)
- name: リバーロキサバン
  high_risk_days: 3
  high_risk_hours: null           # ← ここが違う
  low_risk_days: 1                # ← 追加してきた
  quote: "リバーロキサバン 3 日"     # ← 抽出情報が薄い
  extractor_confidence: medium

差分箇所:

high_risk_hours を Agent A は 72 で保持、 Agent B は null に落とした
low_risk_days を Agent B は 1 と埋めたが、 Agent A は記載なし
quote の verbatim 度合いも Agent A のほうが厚い

これらの discrepancy が層 2 の突合対象になる。

なぜ 2 本に分けるのか: 単一 LLM はもっともらしく見える誤りを静かに混入させる。単発では「本当か間違いか」を検証する術がない。独立に 2 本走らせて差分をあぶり出すのが、単純だが効く手法。

4. 層 2: 突合裁定 — 差分項目を PDF 原文で再確認

primary.yaml と independent.yaml を突合し、 discrepancy が出た項目を 人間が PDF 原文で再確認して裁定 します。結果を <gl_id>.yaml (FINAL) と <gl_id>.reconciliation.md (裁定ログ) に落とす。

上のリバーロキサバン例では、 PDF 原文 (JSA 2026 表 9) を確認すると:

リバーロキサバン | 3 日 (72 時間) | 6 時間

とあり、 GL 本文が 時間単位まで併記 している。 → Agent A の 72 時間保持が正しい、 Agent B の null 化は情報損失、と裁定。 low_risk_days 1 は表 9 に記載なし → Agent B の hallucination として却下。

FINAL YAML の冒頭には突合サマリが明記されます:

# JSA/JSRA/JSPC 抗血栓療法中の区域麻酔・神経ブロック GL 改訂第 2 版
# 最終確定版 — dual-agent 抽出 + 突合裁定済
guideline_id: jsa_2024_kokesen
extracted_by: dual_agent_reconciled
reconciliation_file: jsa_2024_kokesen.reconciliation.md
discrepancies_resolved: 4

「その数値は単発 LLM 出力か / 二段検証を通過したか」がいつでもトレースできる。数年後に「なぜこの数値を採用したのか」を問われても、 reconciliation ログを辿れば裁定根拠 (原文再確認) まで戻れる。

5. 層 4 補強 1: verbatim quote の強制記録 — CI で「原文に存在しない引用」を検出

各推奨値には 原文の一字一句コピー引用 + ページ番号 + PDF ローカルパスを必ず記録します。 LLM に要約 (paraphrase) させず、コピー引用に徹する。

drug_list.json の references エントリ:

{
  "source": "JSA・JSRA・JSPC",
  "title": "抗血栓療法中の区域麻酔・神経ブロック GL 改訂第 2 版 (2026)",
  "url": "https://www.regional-anesth.jp/.../guideline-kaitei02.pdf",
  "local_path": "backend/data/references/guidelines/JSA-JSRA-JSPC_kokesen_kaitei02.pdf",
  "location_in_source": "p.24 総論 5 Summary Statement + p.25 表 9",
  "quote": "低用量アスピリン (＜200 mg/日) を含む非ステロイド性抗炎症薬 (NSAIDs) の服用患者では、 神経ブロックの実施前の休薬は必須でない。",
  "verification_status": "verified",
  "verified_at": "2026-07-05",
  "verified_by": "manual PDF read (verbatim)"
}

この JSON には オンライン GL 掲載ページへの直 URL (url) と ローカル保存 PDF パス (local_path) の両方が記録されています。 GL PDF は #page=33 形式のフラグメントを付与、 PMDA 添付文書も同様に該当ページの直 URL を持たせているので、 UI の各薬剤カードから 1 タップで原典の該当ページを開ける。現場の医療者が判定の根拠を確認したくなった瞬間に、アプリを閉じずに一次資料へ到達できる。「アプリがこう言っているから」ではなく「原典にこう書いてあるから」で医師が判断できる状態を作る、という意味で信頼性を直接押し上げます。

著作権への配慮: マスタが保持しているのは (1) 該当推奨値の verbatim quote (短い該当 1 文)、 (2) 原典への直 URL、 (3) ローカル PDF パス (KyuyakuLens 内部の検証用参照で、ユーザーに配信するものではない) のみで、 GL 本文の大部分を複製・再配布することは一切していません。引用は「引用の主従関係を満たす短い該当箇所」に限定し、 引用元 (学会名・GL タイトル・年度・ページ番号) を全ての引用に明記 することで、引用要件を明確に満たしています。これは法的な安全性だけでなく、「引用元が全て特定可能」であること自体が読み手による検証可能性を担保するので、信頼性の直接的な支えにもなります。

CI では「引用文字列が 原文 PDF に literally 存在するか」を自動チェック。該当ページの PDF テキスト抽出結果に対して substring 検索し、見つからなければ build hard-fail。

コラム: 日本語 PDF テキスト抽出は pdfplumber で

最初 pypdf を使っていたのですが、日本語 PDF (特に横組み表組みが混在する GL PDF) で文字列が 完全に崩壊 します。「アスピリン」が「アスピリン」だったり「アピスリン」だったりする。これで verbatim 検証をやると 51 件が偽陽性 HALLUCINATION_SUSPECT に。

pdfplumber に切り替えたら偽陽性は一気に 0 件になりました。日本語 GL PDF を扱うなら pdfplumber 一択です。

verification_status の 4 段階明示:

status	意味
`verified`	一次資料 PDF/HTML 本文を実読し `quote` + `location_in_source` を記録
`landing_only`	landing HTML 到達確認のみ、本体未読
`unverified`	URL のみ、到達確認も未実施
`helper_link`	KEGG MEDICUS 検索リンク等の補助 (一次資料ではない)

「verbatim quote 記録済」と「URL 到達確認のみ」を別ラベルで明確に区別する。「verified 化率」が現時点で 155 剤中 117 剤 (約 75%)、という定量的な進捗指標が取れる。

6. 層 4 補強 2: 逆方向監査 — GL 側から drug_list の反映状態を検査

順方向 (drug_list.json → GL PDF) の検証は「マスタに載っている各剤の数値が原典と一致するか」を見る。これだけでは、原典側から見たときの以下 3 種類の抜けが検出できません。

収載漏れ: GL に載っている薬が drug_list に存在しない
数値の古さ: drug_list に存在するが、新版 GL の数値が反映されていない
根拠の更新漏れ: drug_list に存在するが、新版 GL の references エントリが追加されていない (現行値の根拠が旧版 GL や添付文書のまま)

そこで GL 側 (原典側) から出発して drug_list 側を照合する 逆方向監査 を実施します。

手順:

FINAL YAML から GL 収載薬リスト (covered: true の全剤) を抽出
各薬剤について drug_list.json 側で (a) 存在 (name + aliases + brand_names 集合とのマッチ)、 (b) 数値 (high_risk_days / low_risk_days が GL と乖離していないか、乖離があるとしたら保守側か危険側か)、 (c) references (当該 GL の verified ref エントリが追加されているか) をチェック
判定を CRITICAL_ISSUE (収載漏れ、または数値が危険側にずれている) / MINOR_ISSUE (保守側への微差、または新版 GL ref 未追加) / PASS (数値一致 + ref 完備 + note で GL と現行値の関係を説明) の 3 段階で記録

JSA 2026 (改訂第 2 版) 抗血栓 GL 収載の 26 剤について監査を実施した結果:

CRITICAL_ISSUE (収載漏れ、または出血・血栓リスクを増やす方向に数値がずれている): 0 件
MINOR_ISSUE (主因は JSA 2026 の verified references エントリ未追加。数値そのものは他 GL や PMDA 添付文書で実質根拠を確保済、かつ現行値が GL より保守側): 18 件
PASS (数値一致 + JSA 2026 verified ref 追加済 + note で GL と現行値の関係を説明): 8 件

CRITICAL 0 件 を維持できているのが、このパイプラインの目に見える成果指標。 MINOR 18 件はそのまま「JSA 2026 ref 追加 PR」のチケット起点になり、 GL 改訂への追随作業を機械的にリスト化できます。

7. 層 4 補強 3: 独立 LLM による数値再検証

抽出時と 別プロンプト・別 LLM で数値をもう一度抽出 し、元 YAML との差分を集計します。抽出時と同じ LLM だと系統誤差が残る (同じ hallucination を再現する) ため、別 LLM を使うのが肝。

差分が出た項目は人間レビューキューに入る。これで「dual-agent + 突合裁定」を抜けた誤りも、別時期の独立 LLM 走行でもう一度網にかかる。検証を 時期・プロンプト・モデルの 3 軸で冗長化 することで、単一の LLM 系統誤差に飲まれない構造にする。

8. 層 4 補強 4: 新版 GL が出たら旧版は「参考」扱いに降格

新版 GL が出たら、 primary reference (判定の主根拠) を常に最新版に差替え、旧版は「参考」に降格します。例:

JSA 抗血栓 GL: 2016 初版 → 2026 改訂第 2 版に差替え済

改訂第 2 版で数値が大幅に変わっている:

アスピリン: 一律 7 日 → 用量別 (低用量 <200 mg/日は継続 / 高用量 ≥200 mg/日は 3-7 日)
NSAIDs 個別薬剤 (ジクロフェナク・インドメタシン等): 個別収載を撤廃 → class 一律「休薬必須でない」
フォンダパリヌクス: 4 日 → 36 時間 (大幅短縮)
チカグレロル: 初版に無記載 → 5 日 (改訂第 2 版で初収載)

旧版を primary に残したまま「新版が出た」と note で補記するだけの対応だと、 UI に出る数値は旧版のまま。これは単純な事故源。旧版 GL の entry は references[] に「参考」として残すが、数値の primary は必ず新版に。

9. 継続的な更新機構

9.1 GL 改訂の自動検知 (`check_guideline_updates.py`)

学会サイトが「静かに」内容を差替えるパターン (URL 同じ・ファイル名同じ・内容変更) を検出するため、各 GL の PDF ハッシュ (SHA256) と URL を月次監視する。 _manifest.json に監視対象を登録:

{
  "id": "jcr_ra_2024_tebiki_jak",
  "source_organization": "JCR (日本リウマチ学会)",
  "title": "関節リウマチに対するヤヌスキナーゼ阻害薬使用の手引き",
  "local_path": "jcr_ra_2024/tebiki_jak_250430.pdf",
  "url": "https://www.ryumachi-jp.com/pdf/tebiki_jak_250430.pdf",
  "landing_page": "https://www.ryumachi-jp.com/guide/ra/",
  "landing_pdf_link_pattern": "tebiki_jak_\\d{6}\\.pdf",
  "revision_date": "2025-04-30",
  "sha256": "141cd85d1a6ae334e8af1dc0bc393c29d00cd54a78200786842cb2edc0523730",
  "cited_by_drugs": ["トファシチニブ", "バリシチニブ", "ウパダシチニブ"],
  "verification_status": "verified",
  "update_detection_method": "filename_pattern"
}

月次 cron の流れ:

url に HEAD リクエスト → Content-Length / Last-Modified を記録
landing_page HTML を取得 → landing_pdf_link_pattern (regex) で最新 PDF リンクを抽出
マッチしたファイル名がローカルと異なれば 改訂検知 として exit code 1 で通知

なぜ SHA + filename_pattern の二重検知か: PDF 内容だけ差し替え (URL 同じ・ファイル名同じ・内容変更) の GL が実在する。 SHA だけでは URL 変化を見落とし、 filename_pattern だけでは内容変化を見落とす。両方監視して初めて漏れない。

exit 1 のとき開発者にメール通知 → 手動で新 PDF 取得 → dual-agent 抽出 (層 1) を再実行、という流れ。検知は機械で、抽出はパイプライン再走で、承認は医師で、が分業。

9.2 新規後発品の自動発見 (KEGG 月次パイプライン)

後発品は年 2 回の薬価収載で大量に追加されます。これを手動で追う代わりに:

月次 GitHub Actions cron
    │
    ▼
update_kegg_brands.py
    ・KEGG MEDICUS を全対象薬 (155 剤) 検索
    ・drug_list.json の provisional_brand_names /
      provisional_generic_brands /
      provisional_combination_brands に append
    ・kegg_ignore_brands に一致する銘柄は恒久拒否 (交差混入防止)
    │
    ▼
_check_kegg_schema_guard.py (schema 検証)
    │
    ▼
自動 PR (対応方法セクション付き)
    │
    ▼
Merge → API endpoint で本番反映

provisional_* フィールドは 「機械が発見したが人がまだ承認していない」状態の専用エリア。これが層 4 (薬剤マスタ) 内に存在するのが肝で、「判定に使う brand_names 集合」とは物理的に分離されている。判定は本登録 (brand_names / generic_brands) だけを見るので、未承認銘柄が誤って判定に混入することがない。

promote_provisional.py で医師が確認:

--list 現状一覧
--interactive 銘柄ごとに承認/却下
--approve-all 一括昇格
--reject "薬剤名:銘柄名" 却下 = kegg_ignore_brands へ追加

却下すると kegg_ignore_brands (恒久拒否リスト) に入り、次回以降 KEGG が同じ銘柄を検出しても 再検出しても二度と provisional に入らない。これで「一度却下した銘柄が毎月 provisional に再登場する」というアラート疲れも防ぐ。

これで「発売直後の後発品を見落とす」状態を構造的に防ぎつつ、誤登録もフィルタする。過去に non_target 銘柄 33 件が誤って判定対象に紛れ込んでいた事故があり、これも kegg_ignore_brands + 逆方向監査で潰した。

10. 運用結果

これらの検証を経て、現時点で:

一次資料 verified (PDF 実読 + verbatim quote 記録済): 155 剤中 117 剤 (約 75%)
逆方向監査完了 GL: 主要国内 GL 全て
独立 LLM 再検証完了以降、運用で発見された 真の hallucination 累積: 0 件
月次 GL 改訂検知 + KEGG 月次発見が稼働中

「真の hallucination」とは 「一次資料に存在しない数値・記述を LLM が生成し、全ての検証層をすり抜けて実装に混入した」事案。検証パイプライン導入前は 51 件の HALLUCINATION_SUSPECT が検出されたが、精査の結果:

42 件: pypdf の日本語 PDF 崩壊による偽陽性 → pdfplumber 切替で解消
9 件: LLM が微妙に paraphrase した箇所 → verbatim quote に修正

導入後、真の hallucination で本番マスタに混入した数値は 0 件を維持。

11. まとめ: LLM を医療 domain で使う骨格

「LLM は使いたい、でもそのまま信じるのは危険、かといって全て人力は現実的でない」という制約下で、有効だった 4 つの骨格を対策マップで整理します。

骨格	解決する制約	recall (網羅性)	precision (誤りゼロ)
dual-agent 抽出 + 突合裁定	単発 LLM の系統誤差	—	○
verbatim quote + CI での存在確認	paraphrase・要約による意味 drift	—	○
逆方向監査	GL 側から drug_list の存在・数値・references 反映を検査	○	○
provisional エリア + 人間承認	機械発見と人間承認の混在	○	○
_manifest.json + SHA/filename 二重監視	サイレント GL 差替え	○	—
検証深度 4 段階明示	「verified」と「URL 到達確認のみ」の混同	—	○

全体を貫く原則は 「機械的な差分検出 + 人間による承認フロー」の段階化。機械は差分を出すところまで、判断は人間、という分業。医療従事者向けアプリの場合、判断者は医師であり、最終的な数値の採用可否と定期監査は医師が一次資料を実読した上で行う。

「LLM をどこで信じ、どこで信じないか」の線引きを 中間ファイルとして物理的に分離する のが、保守しやすさに直結しました。 primary.yaml / independent.yaml / .yaml / guideline_variations.json / drug_list.json (+ provisional_*)、とファイル単位で「検証深度」が階段状に上がる構造にすると、レビューで「今どの段階の情報を見ているか」が一目でわかる。

そして最後に、このパイプラインの本当の価値は 「一度高い精度で抽出できたこと」ではなく、「その精度を時間経過に抗って維持できる構造にしたこと」 にあると思います。医療 domain の情報は学会 GL 改訂・薬価収載・URL サイレント差替で常に動いており、静的なマスタは作った瞬間から陳腐化が始まる。「作って終わり」の抽出プロジェクトは、完成日が品質のピークで以後は単調減少する運命にある。更新機構を「後回しにできる拡張機能」ではなく「初日から作る必須コンポーネント」として設計に組み込むかどうかで、マスタが数ヶ月で陳腐化するか数年運用できるかが決まる。これは LLM を業務に組み込むあらゆるドメインで同じだと感じています。

同じような「LLM を使いたいけどハルシネーションが怖い」「一度作ったマスタを継続運用したい」ドメインの実装参考になれば幸いです。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up