ファインチューニングとは｜種類・やり方4ステップとRAGとの違い

引っ越しのとき、電動ドライバーを買いました。棚を組むためです。

10本ほどネジを締めて、残りは手で回しました。 電動のほうが速いはずなのに、持ち替えて、先端を替えて、充電を確認する時間のほうが長かったからです。

ネジ1本には、手のドライバーのほうが速い。

道具の性能の話ではありませんでした。1回あたりの仕事が小さいときは、立ち上がりの重さが全部になるという話です。

先に一行だけ置きます。ファインチューニングとは、学習済みのモデルに自社のデータを追加学習させて、特定の用途に合わせることです。

題材は、AIの出力を検査する仕組みです。モデルが返した文章や、ファイルへの書き込みを、外に出す前に一度検査します。機密が漏れていないかを見る役割です。

前置きはさておき、本題に入ります。

今日は、この検査役を作るときに大きいモデルを賢くしようとしてやめた話をしていこうと思います。

① 教科書どおりに、生成モデルを賢くしようとする

ファインチューニングとは

ファインチューニングとは、すでに学習済みのモデルに、追加のデータを与えて微調整することです。ゼロから学習させるのではなく、一般的な能力を持ったモデルを土台にして、特定の用途に寄せます。

「賢くする」というより「寄せる」と理解したほうが実務に合います。一般的な知識が増えるのではなく、与えたデータに近い答え方をするようになる、というのが起きていることです。

ファインチューニングの仕組み

モデルの中身は、大量の数値（パラメータ／重み）です。事前学習でこの数値が決まっており、ファインチューニングでは、追加データに合うように数値を少しずつ更新します。

更新する範囲は手法によって違います。全部を更新する方法もあれば、ごく一部だけを更新する方法もあります。この「どこまで更新するか」が、費用と、失うものの量を決めます。

事前学習（プレトレーニング）との違い

	使うデータ	目的	費用の規模
事前学習	大量の一般的な文章	言語そのものを扱えるようにする	非常に大きい
ファインチューニング	少量の目的別データ	特定の用途に寄せる	比較にならないほど小さい

事前学習をやり直す選択肢は、ほとんどの企業にありません。検討の俎上に載るのは、ファインチューニングか、あるいはモデルに触らない方法（後述）のどちらかです。

転移学習との違い

転移学習は、ある領域で学んだ知識を別の領域へ持ち込む考え方全体を指します。ファインチューニングは、その転移学習を実現する具体的な手法の1つです。

用語としては転移学習のほうが広く、「出力側だけを付け替える」形も転移学習に含まれます。モデルの本体を触らずに済むぶん、費用も、壊すものも少なくなります。

RAG（検索拡張生成）との違い

	何を変えるか	知識を更新するとき	向いていること
ファインチューニング	モデルそのもの	学習をやり直す	答え方の形式・様式・口調をそろえる
RAG	モデルの外にある資料	資料を差し替えるだけ	社内の事実を、根拠つきで答えさせる

「社内の情報を覚えさせたい」という相談は、ほとんどがRAG側の話です。ファインチューニングで知識を入れると、更新のたびに学習をやり直すことになり、しかもどこから来た情報かを回答で示せません。

プロンプトエンジニアリングとの違いと、試す順番

プロンプトの工夫は、モデルを変えずに指示だけで寄せる方法です。費用がかからず、やり直しも効きます。

• 1. プロンプトを直す — 例を数件見せる（Few-shot）だけで届くことがある
• 2. RAGを足す — 事実が足りないなら、資料を渡す
• 3. ファインチューニングする — 形式が安定しない場合に、ここでようやく検討する

この順番を飛ばすと、費用をかけたのに直らない、という結果になりやすくなります。ファインチューニングは、「プロンプトでは形がそろわない」と確かめてから選ぶ手段です。

種類1｜完全（フル）ファインチューニング

モデルのパラメータを全部更新します。寄せる力はいちばん強い代わりに、計算資源と時間が最もかかります。

あわせて、もともとできていたことが劣化することがあります（破滅的忘却と呼ばれます）。狭い用途に強く寄せるほど、それ以外の質問への答えは弱くなります。

種類2｜PEFT（パラメータ効率のよいファインチューニング）

モデル本体はほぼ凍結したまま、ごく一部の数値だけを更新する手法の総称です。代表的なものにLoRAがあります。

やり方	中身
アダプター	層のあいだに小さな追加部品を挟み、そこだけ学習させる
再パラメータ化（LoRAなど）	更新分を小さな行列で表し、元の重みに足す形にする
部分的な更新	既存のパラメータのうち、一部だけを選んで更新する

実務ではまずPEFTを検討します。費用が桁で違ううえ、元のモデルを壊さないので、うまくいかなかったときに戻せます。

種類3｜追加的ファインチューニング

既存の層はそのままにして、新しい層やパラメータを足し、足したところだけを学習させる方法です。

用途ごとに足した部分を差し替えられるため、1つの土台で複数の用途を持たせたいときに向きます。用途ごとにモデルを丸ごと持つより、運用が軽くなります。

種類4｜指示チューニングとRLHF

指示チューニングは、「指示 → 望ましい応答」の組を大量に学習させ、指示に従う振る舞いそのものを身につけさせる方法です。

RLHF（人間のフィードバックからの強化学習）は、複数の出力に人が優劣を付け、その評価を報酬として学習させます。どちらもモデル提供側が行う工程で、利用企業が自前で回すことは多くありません。「何が行われた結果のモデルか」を知るために押さえておく用語です。

モデルに何を学習させるのか — 知識か、形式か

学習させる内容は、大きく2つに分かれます。

学習させるもの	向く手段	理由
事実・知識（社内の数値、規程の中身）	RAG	更新が頻繁で、根拠の提示が要る
形式・様式・言い回し（帳票の書式、社内用語、判定のラベル）	ファインチューニング	毎回同じ形で返ってほしい

この切り分けを先にやってください。学習させるものが知識だった場合、ファインチューニングは費用に見合いません。

メリット1｜特定の用途で精度が上がる

一般的なモデルが苦手な、専門用語や社内固有の表現を扱えるようになります。用途を狭く決めるほど、効果は出やすくなります。

効果を測る対象を、先に決めてください。「全体的に賢くなったか」では判定できません。判定したい項目を並べた評価データを、学習データとは別に用意します。

メリット2｜開発の手間と時間を抑えられる

ゼロから学習させる場合と比べて、必要なデータ量も計算資源も、桁で小さくなります。

ただし「小さくなる」のは学習の工程だけです。データを作る工程は小さくなりません。ここが、見積もりで最もずれる場所です。

メリット3｜自社固有の様式や表現を反映できる

報告書の書式、社内の言い回し、判定に使うラベルの体系。毎回同じ形で返ってほしいものほど、効きます。

逆に、毎回違ってよいもの（要約や案出し）には向きません。そろえる価値があるかどうかを、先に確かめてください。

デメリット1｜学習データの準備がいちばん重い

学習の実行自体は、手順どおりに進めれば終わります。重いのは、その手前でデータを作る工程です。

入力と、望ましい出力の組を用意します。望ましい出力は、人が判断して書くしかありません。既存の資料から自動で作れると考えていると、着手してから予定が伸びます。

デメリット2｜過学習（オーバーフィッティング）

与えたデータに合わせすぎて、少しでも形の違う入力に対応できなくなる状態です。データが少なく、内容が偏っているときに起きます。

防ぐには、学習に使わないデータを最初から取り分けておいて、そちらで測ることです。学習に使ったデータで測ると、必ず良い数字が出ます。

デメリット3｜計算資源と費用がかかる

完全ファインチューニングでは、GPUの時間が必要になります。学習は1回では終わらず、条件を変えて何度か回すのが普通です。

費用を抑えるなら、まずPEFTで試してください。更新する範囲が小さいぶん、必要な資源も時間も小さくなります。

デメリット4｜土台のモデルが変わると、やり直しになる

ファインチューニングした結果は、土台にしたモデルに紐づきます。提供側が新しいモデルに移行すると、作り直しになります。

この作り直しの費用を、最初の見積もりに入れておいてください。入れていないと、モデルが更新されるたびに「予定外の費用」が発生し続けることになります。

ファインチューニングのやり方（4ステップ）

	やること	終わったと言える状態
1. データと土台のモデルを用意する	入力と望ましい出力の組を作り、ベースモデルを決める	評価用のデータが、学習用と分けて取ってある
2. データを整えて登録する	形式をそろえ、学習の設定（回数など）を決める	形式のエラーが無い
3. 学習を実行して様子を見る	損失の推移を見ながら回す	過学習の兆候が出ていないか確認できている
4. 評価して、本番に出す	取り分けたデータで測り、元のモデルと比べる	数字で前後を比べられる

1で評価用データを分けていないと、4で判定できません。全部を学習に使ってしまってから「効果があったか」を測ろうとしても、比べる相手がありません。

学習データの例と、必要な件数の考え方

よく使われるのは次の3種類です。

• 社内にある非公開のデータ — 業務マニュアル、過去の対応履歴
• 専門性が高い分野のデータ — 医療、法務、金融、製造の基準
• モデルが知らない新しい情報 — 学習時点より後に決まった規程

件数は用途で変わりますが、件数より、ばらつきの網羅のほうが効きます。同じ形の例を1,000件そろえるより、起こりうる形を一通り含んだ数百件のほうが、実務では安定します。

効果の測り方

測るのは3つです。

• 正解率 — 取り分けた評価データに対して、何割合っているか
• 元のモデルとの差 — チューニング前と比べて上がったか
• 崩れていないか — 対象外の入力に、おかしな答えを返していないか

3つ目を見落とすと、狭い用途では良くなったのに全体では使えない、という状態に気づけません。

ファインチューニングとRAG、どちらを選ぶか

困っていること	先に試すもの
答えの中身が事実として間違っている	RAG
どこに書いてあったかを示せない	RAG
答えの形式・様式が毎回変わる	プロンプト → 直らなければファインチューニング
社内の用語や言い回しにならない	ファインチューニング
対応できる範囲を広げたい	どちらでもない（用途の切り分けを先に）

組み合わせて使うこともできます。事実はRAGで渡し、答え方はファインチューニングでそろえる、という形です。ただし両方を同時に始めると、どちらが効いたか分からなくなります。順番に入れて、都度測ってください。

ファインチューニングのよくある質問

Q. ファインチューニングとRAGは、どちらを選べばよいですか。
事実を正しく答えさせたいならRAG、答え方の形式をそろえたいならファインチューニングです。社内の情報を覚えさせたいという相談は、ほとんどがRAG側の話になります。

Q. 学習データは何件くらい必要ですか。
用途によりますが、件数より「起こりうる形を一通り含んでいるか」が効きます。同じ形を大量に集めるより、ばらつきを網羅した数百件のほうが安定します。

Q. ファインチューニングをすると、元の能力は失われますか。
完全ファインチューニングでは、もともとできていたことが劣化することがあります（破滅的忘却）。PEFT（LoRAなど）は本体をほぼ凍結するため、この影響が小さく、戻すこともできます。

Q. 費用はどのくらいかかりますか。
学習そのものより、データを作る工程のほうが重くなります。あわせて、土台のモデルが更新されたときの作り直しの費用を、最初の見積もりに入れておいてください。

Q. プロンプトの工夫で済むかどうかは、どう判断しますか。
例を数件見せる（Few-shot）だけで形がそろうなら、そこで止めてください。プロンプトを変えても形がそろわないと確かめてから、ファインチューニングを検討するのが順番です。

最初の発想は、素直でした。賢いモデルに検査させればいい。

→ 出力をモデルに読ませる
→ 問題があるかを判定させる
→ 判定の精度が足りなければ、ファインチューニングする

教科書どおりです。精度が足りないならチューニングする。 そう書いてあります。

そして、動きはします。

ここまでは、教科書どおりです。

ここまでが、ファインチューニングの教科書どおりの整理です。手段を並べ、試す順番を決め、データを作り、測る。判断の材料としては、これで揃っています。

この記事の後半で扱うのは、この順番どおりに進めた1件で、何を確かめる前に手を動かしていたかです。選び方の手前に、確かめていなかった問いがありました。

② そのとおりに進めて、遅さで詰まる

ところが、運用に載せる段になって詰まりました。遅いのです。

検査は、毎回必ず通る処理です。出力のたび、書き込みのたびに走ります。そこに1秒かかると、全部の作業に1秒乗ります。

そして、もうひとつ。常駐できませんでした。

手元の環境はMacの16GBメモリです。検査のためだけに大きなモデルを載せ続けると、他が動かなくなります。

電動ドライバーと同じでした。 性能は高い。ただ、1回あたりの仕事が小さすぎて、立ち上がりが全部になる。

③ そして、これは生成ではなく分類だと気づく

要件を書き出して、はっきりしました。

この仕事の出力は、文章ではありません。

→ 入力：出力しようとしている文章
→ 出力：問題があるか、ないか

答えは1つです。 説明も、言い換えも要りません。分類でした。

生成モデルを使っていたのは、手元にそれしかなかったからです。仕事の性質から選んだわけではありませんでした。

④ 原因は「賢くする」と「判定させる」を混同していたこと

原因を一つに絞ると、これでした。

精度が足りないときに、賢いモデルを持ってくる癖がついていました。

賢さは、難しい問いに効きます。 ところが今回の問いは難しくありません。「この文章に機密が含まれるか」だけです。

難しくない問いに賢さを持ってくると、賢さの代金だけを払うことになります。 遅さとメモリが、その代金でした。

⑤ 直してみる — エンコーダー型を選び、100件を目視で作る

やったことは3つです。

1. モデルを、用途で選び直した。

候補は2つでした。エンコーダー型のMM-BERTと、デコーダー型のQwen-0.6Bです。

性質はこう分かれました。

→ MM-BERT — 高速で、精度も高い
→ Qwen-0.6B — 精度は良いが、処理が遅い

選定基準は、Macの16GBで常駐できることと、速いこと。 その2つで、MM-BERTにしました。

「精度が高いほう」ではありません。「常駐できて速いほう」です。

2. データセットを、100件の目視から始めた。

いきなり大量に作りませんでした。まず100件程度の基準となるデータを、目視で確認して修正します。

そのうえで、GPTとClaudeを併用してデータ拡張をかけ、最終的に6000件以上にしました。

テストデータで高い精度が出たあと、振り返って言えることはこれでした。初期の目視確認が効いていた。

3. 検査の守備範囲を、実測で確認した。

→ 言い換えや翻訳された文章 — 100%ブロック
→ 抽象化された要約 — 70〜80%ブロック

完全ではありません。 元の情報が薄まるほど、判定は難しくなります。止まらなかったものをどう扱うかは、別に決めています。

⑥ あとで知った — 選び方は、2018年の設計思想どおりだった

素朴な選定のつもりでしたが、調べるとこの分岐は、モデルの設計そのものに由来していました。

2018年6月にOpenAIがGPTを、その4か月後にGoogleがBERTを出しています。 同じ年に、違う形で。

→ GPT — デコーダー型。自然言語の生成のために設計された
→ BERT — エンコーダー型。自然言語の理解のために設計された

構造の違いも明快です。エンコーダー型は、入力の全部の語を見られます。 だから、文全体の理解が要る仕事——文や語の分類、抜き出し型の質問応答——に向きます。

一方のデコーダー型は、過去の語だけを見ます。 次の語を予測する形なので、生成に向きます。

そして決定的なのが、これです。エンコーダー型は、自己回帰的に1語ずつ出力しません。 入力を理解して、ラベルのような答えを返します。

私が欲しかったのは、まさにラベルでした。

7年前に、理解のための形と、生成のための形が、別々に用意されていたわけです。私は生成のための形を持ってきて、理解の仕事をさせようとしていました。

手でネジを回せば済む場面で、電動ドライバーを充電していたのと同じです。

新しい理屈は、ひとつも要りませんでした。
選定の記録にはこう残っています。「MM-BERTは高速で精度も高い」「Qwenは精度は良いが処理が遅い」。ところで、選定基準として書かれていたのは「Macの16GBメモリで常駐可能かつ高速な処理が可能なモデル」でした。ただし、精度の比較は基準の中に入っていません。実は、そこが判断の要点です。データセットについても「まず100個程度の基準となるデータを目視で確認・修正した」と記録があり、拡張は6000件以上に及びました。

あとで知った — 数字が、はっきり出ていた

分類なら小さいモデルでよい、という判断は感触で決めていました。あとから、比較の数字が出ているのを知りました。

ModernBERT という、生成をしない分類向けのモデル系統があります。ここで報告されている数字が具体的です。

“`
ModernBERT-large（3億9500万パラメータ） 84.72%
Claude 3.7 86.81%
Gemini Flash 2.0 86.11%
“`

2ポイント差です。 パラメータ数は桁で違います。

さらに、ModernBERT-Large-Instruct は、同程度の大きさの生成モデルを上回ったという報告があり、Llama3-1B の成績の93%を、60%少ないパラメータで達成しています。速度も、従来の同種モデルに対して2倍から4倍と報告されています。

つまり、分類という仕事に限れば、大きくすることで得られる差は2ポイント前後で、その2ポイントのために桁違いの計算資源と待ち時間を払うことになります。

大きいモデルを賢くする前に、それは分類ではないかを疑う。 この順番は、感触ではなく数字で裏が取れていました。

⑦ 何が変わったか

検討の順番が、逆になりました。

“`
前：精度が足りない → 賢いモデルを探す → 遅くて載らない
後：これは生成か分類か → 分類なら小さい型 → 常駐して速い
“`

「賢いモデルを探す」の前に、1つ問いが増えただけです。
増やした問いは1つですが、結果は大きく動きました。常駐メモリは16GB中の数百MBに収まり、1件あたりの判定は数十ミリ秒です。生成モデルに投げていたときは、この2つが両方とも桁違いでした。

項目	生成モデル	エンコーダー型
常駐	できない	できる
1件の判定	秒単位	ミリ秒単位
外部送信	必要	不要

導入後の共有には、こう書かれています。「従来のキーワード判定からGeminiへ、という構成から、キーワード判定、オンデバイス分類器、Geminiという構成になります」。そして「分類器は信頼度も出力するので、信頼度が閾値より低い場合にGeminiにルーティングする仕組みです」。

実測も添えられていました。「今設定している閾値では自分の観測ではルーティング精度が99%あった」。ただし但し書きが付いています。「意地悪な問題を多く用意したデータセットでも約8割」。

ところで、この2つの数字の差が要点です。素直な入力では99%、意地悪な入力では8割。 平均を出しても意味がありません。閾値を下回ったものだけ大きいモデルへ回すという構成にしているから、8割でも回ります。

⑧ 現場で使うなら、この2枚

表1：仕事の性質から、型を決める

仕事	出力	型	ファインチューニング
機密が含まれるか判定	ラベル	エンコーダー型	する（小さく）
問い合わせの振り分け	ラベル	エンコーダー型	する
文章を書く	文章	デコーダー型	通常は不要
社内知識を答える	文章	デコーダー型＋RAG	しない。RAGで足りる

出力欄が「ラベル」なら、生成モデルは要りません。

表2：データセットの作り方

順	やること	なぜ
1	100件を目視で確認・修正	ここが全体の基準になる
2	AIで拡張して数千件へ	量は後から足せる
3	テストデータで精度確認	—
—	いきなり大量に作らない	間違った基準がそのまま増える

補：選定の基準（精度で選ばない）

見るもの	理由
常駐できるか	毎回起動していたら速さが消える
1回あたりの速さ	必ず通る処理は、遅さが全部に乗る
精度	上の2つを満たした中で比べる

補2：ファインチューニングを見送ってよい場合

状況	代わりにやること
知識を参照させたいだけ	RAG。学習は不要
口調を揃えたいだけ	指示文で足りることが多い
判定基準が週単位で変わる	学習し直しが追いつかない。ルールで書く
学習データが100件も作れない	まず100件を目視で作れるかを確かめる

4行目が実務では効きます。 100件を目視で作れないテーマは、そもそも基準が定まっていません。基準が無いまま6000件へ拡張すると、揺れたまま増えます。

⑨ この考え方が効き続ける理由

モデルは、これからも大きく賢くなります。それでも、この判断は残ります。 賢さが上がっても、必ず通る処理の遅さは体験を壊すからです。

→ 検査は毎回通る → 1回の遅さが全体に乗る
→ 常駐できない → 毎回立ち上げる
→ 立ち上げが重い → 速いモデルより遅くなる

1回あたりの仕事が小さい処理ほど、モデルは小さくてよくなります。

そして、この判断には副産物がありました。外に出さずに済むようになりました。 手元で常駐できる大きさなので、検査のために文章をどこかへ送る必要がありません。 機密を見る役が機密を送っていたら、意味がない。

ただし、正直に書いておきます。抽象化された要約は70〜80%しか止まりません。 元の情報が薄まると、機密かどうかの手がかりも薄まるからです。残りの20〜30%をどうするかは、まだ人の目に頼っています。

置き換えたあとの実測です。常駐に必要なメモリは数百MB、1件あたりの判定は数十ミリ秒。 生成モデルに投げていたときは、判定に数秒かかり、常駐そのものができませんでした。検査は1日に数千回通るので、この差がそのまま体験に出ます。

判定の実測も言葉で残しています。「言い換えや翻訳された文章は100%ブロック可能」「抽象化された要約は70〜80%ブロック可能」。ところで、この差が意味するのは「元の情報が薄まるほど手がかりも薄まる」ということです。ただし、そこは分類器の限界ではなく、情報量の限界だと考えています。

関連して、ローカルLLMを自社の中に置く判断話と、LLMに自分の出力を検証させてはいけない話を別に書いています。チャットボットはまず分類器から作る話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、生成AIの実装のページに整理しています。

---

大は小を兼ねる、といえば、Lサイズのシャツばかり買っていた時期があります。

全部、袖が余っていました。大きくしても、合っていないものは合いません。

以上です。

▶ この記事のテーマを実務で相談する: 生成AIコンサルティング

ファインチューニングのよくある質問（まとめ）

ファインチューニングとRAGは、どちらを選べばよいですか？

事実を正しく答えさせたいならRAG、答え方の形式や様式をそろえたいならファインチューニングです。RAGはモデルの外にある資料を差し替えるだけで知識を更新でき、どこに書いてあったかも示せます。ファインチューニングで知識を入れると、更新のたびに学習をやり直すことになり、根拠も示せません。社内の情報を覚えさせたいという相談は、ほとんどがRAG側の話になります。

ファインチューニングの学習データは、何件くらい必要ですか？

用途によって変わりますが、件数より「起こりうる形を一通り含んでいるか」のほうが効きます。同じ形の例を1,000件そろえるより、ばらつきを網羅した数百件のほうが実務では安定します。あわせて、学習に使わない評価用のデータを最初に取り分けてください。学習に使ったデータで測ると必ず良い数字が出ます。

ファインチューニングをすると、元の能力は失われますか？

完全（フル）ファインチューニングでは、もともとできていたことが劣化することがあります。破滅的忘却と呼ばれる現象で、狭い用途に強く寄せるほど起きやすくなります。PEFT（LoRAなどのパラメータ効率のよい手法）はモデル本体をほぼ凍結して一部だけを更新するため影響が小さく、うまくいかなかったときに戻せます。

ファインチューニングの費用は、どこにかかりますか？

学習の実行そのものより、入力と望ましい出力の組を作るデータ準備の工程が重くなります。望ましい出力は人が判断して書くしかないためです。あわせて、土台にしたモデルが提供側で更新されると作り直しになるので、その費用を最初の見積もりに入れておいてください。

プロンプトの工夫で済むかどうかは、どう判断すればよいですか？

試す順番は、プロンプトを直す → RAGを足す → ファインチューニング、です。例を数件見せる（Few-shot）だけで形がそろうなら、そこで止めてください。ファインチューニングは、プロンプトを変えても形がそろわないと確かめてから選ぶ手段です。この順番を飛ばすと、費用をかけたのに直らないという結果になりやすくなります。

ファインチューニングとは何ですか？

学習済みのモデルに自社のデータを追加で学習させ、特定の用途に合わせることです。ゼロから学習させるのに比べて、必要なデータも計算資源もはるかに少なくて済みます。ただし、そもそもその仕事にファインチューニングが要るかどうかを先に判定する必要があります。

ファインチューニングとRAGは、どちらを選ぶべきですか？

仕事の種類で決まります。知識を参照させたいならRAG、振る舞いや判定の基準を覚えさせたいならファインチューニングです。さらに手前で、その仕事が生成なのか分類なのかを見極めてください。分類なら生成モデル自体が不要な場合があります。

どのモデルを選べばいいですか？

用途で変わります。分類のように入力全体を理解して答えを1つ返す仕事は、エンコーダー型が向いています。文章を作る仕事はデコーダー型です。実際の選定では、常駐できるかと速さを基準に、エンコーダー型を選びました。精度の高さだけで選ぶと、遅くて使われない仕組みになります。

データセットは何件くらい必要ですか？

件数より作り方が効きます。実際には、まず100件程度の基準となるデータを目視で確認・修正し、そのあとAIに拡張させて6000件以上にしました。最初の100件の質が全体を決めます。量から作り始めると、間違った基準がそのまま拡張されます。

分類器で、どの程度まで検査できますか？

対象によって差が出ます。言い換えや翻訳された文章は100%止まりました。一方、抽象化された要約は70〜80%です。元の情報が薄まるほど判定が難しくなります。完全ではないので、止まらなかったものをどう扱うかまで設計に含める必要があります。