ファインチューニングかRAGかについては、誰もが意見を持っている。AIフォーラムをスクロールすれば、アーキテクチャ図やベンチマークの主張で溢れかえった熱い議論がいくらでも見つかるだろう。そうしたコメントを書いている人のほとんどは、自分のデータでモデルを訓練したことも、本番環境でRAGパイプラインが静かに失敗する様子を見たこともない。

私は数ヶ月かけて実験を繰り返した。正確には12個だ。LLMのファインチューニング、エンベッダーのファインチューニング、そして6つの異なるRAG構成の構築。ドメインは金融予測、具体的には、乱雑な履歴データからノイズの多い市場の結果を予測することだった。私はブログ記事のような主張ではなく、真の答えを求めていたため、厳格な統計基準を自分に課した。

ほとんどの実験は失敗に終わった。しかし、それらの失敗は、たまたま成功した時よりもはるかに有用であることがわかった。

シグナルに関する厳しい真実

詳細に入る前に、すべてを貫く教訓を伝えよう。ファインチューニングとRAGは、モデルが「知っていること」や「見ているもの」を変えるためのツールだ。それらは、何もないところからシグナルを生成する魔法の杖ではない。もし基盤となるデータに、利用可能な真のパターンが含まれていないのであれば、これらの手法を使ってもパターンは生まれない。ただ、ランダムなノイズに対して、より説得力のある物語を構築する手助けをしてしまうだけだ。

金融予測において、この罠は特に危険だ。市場は設計上、ノイズが多い。強力なLLMに過去の価格データを結びつけ、検索やファインチューニングを追加したからといって、自動的に優位性（エッジ）が得られるわけではない。得られるのは、コイン投げの結果を正当化するための、より流暢な言い回しだ。シグナルが存在しない場合、モデルはあなたに対して非常に上手く嘘をつくようになる。まずそれを確認する必要がある。

スケールが学習ではなく記憶をもたらすとき

私の最初の大きな間違いは、スケール（規模）ですべてが解決すると想定したことだった。私は、ちょうど777個のトレーニング例を用いて、140億パラメータのモデルと70億パラメータのモデルを比較テストした。より大きなモデルは、明らかに優れた eval_loss を達成した。パープレキシティも低下した。書類上では、それは学習しているように見えた。

しかし、モデルが正しい予測を行った実際の割合である「勝率」を見たとき、事態は変わった。14Bモデルは、7Bモデルよりも著しくパフォーマンスが悪かったのだ。それはトレーニングデータのノイズを記憶してしまっていた。3,000例に満たないデータセットでは、大きなモデルには、データの偽相関やランダムな揺らぎに対して過学習するための十分な容量（キャパシティ）があった。本質的に、ノイズのルックアップテーブルを構築してしまったのだ。

容量の制限があった7Bモデルは、より広範なパターンを学習せざるを得なかった。あらゆる特異性を記憶する余裕はなかったのだ。小さなデータセットを扱うなら、小さなモデルから始めるべきだ。スケールは無料ではない。データが希薄なとき、スケールは積極的に害を及ぼす可能性がある。

損失曲線（Loss Curve）を信じるな

私は、損失曲線を凝視するのをやめることを学んだ。モデルは、トークンレベルのクロスエントロピーを改善しながら、あなたが重視する実際のビジネス上の意思決定においては悪化していくことがある。これは、言語モデルの損失が「次のトークンを正確に予測すること」に報酬を与えるために起こる。多くのドメイン、特に金融においては、正しい意思決定と、最も確率の高い次のトークンは同一ではない。

トレーニング時の文章を美しく再現しながらも、予測の方向性については毎回間違った賭けをするモデルを私は見てきた。損失は下がっていった。そして、それと共に資金（バンクロール）も減っていった。評価指標は、現実世界のタスクに基づいて選択すべきだ。ドキュメントのランキングを行っているなら、ランキングの質を測定せよ。結果を予測しているなら、意思決定の精度を測定せよ。eval_loss にモデル選びを任せてはならない。

ファインチューニングが輝くのは「未知の語彙」に対してのみ

私は2種類の異なるテキストタイプで、エンベッダーのファインチューニング試験を行った。1つ目は、標準的な金融ニュースと公開書類を使用したものだ。ファインチューニングしたエンベッダーと、既存の製品版は全く同じパフォーマンスを示した。ベースモデルはすでにこの言語を知っていた。私は慣れ親しんだ領域でチューニングを行っていたのだ。

2つ目のデータセットは、公開されたインターネット上には決して現れない、独自の専門用語、社内コードネーム、ドメイン特有の略語で満ちていた。ここでは、ファインチューニングによって検索精度が79パーセント向上した。ベースモデルは、これらの用語の意味を全く知らなかったのだ。ファインチューニングによって、モデルにローカルな語彙を教え込むことができた。

この結果、私の中で演習の定義が完全に書き換えられた。ファインチューニングとは、モデルを一般的な意味で賢くすることではない。新しい語彙、新しいフォーマット、あるいは特定の執筆スタイルを教え込むことなのだ。もしあなたのデータがインターネット上のものと似ているなら、ファインチューニングはスキップしてよい。もしあなたのデータが、ベースモデルが一度も見たことのない言語を話しているなら、ファインチューニングは不可欠となる。

RAGが与えるのは確信であり、真実ではない

I tested eight separate RAG configurations for prediction tasks. Across the board, adding retrieval changed roughly 30 percent of the model's decisions. That sounds impactful. It was not. Those changes were pure noise. The overall accuracy did not improve. What did change was the model's confidence. RAG made the system sound more certain, cite more sources, and produce longer justifications. All while being just as wrong.

This overconfidence is a product risk. A user sees citations and assumes the model has done its homework. In reality, it was doing sophisticated-looking guesswork.

The most painful lesson came from backtesting one RAG variant. It showed an 11 percent annual profit. On the surface, that looks like a winning strategy. But its AUC, the area under the ROC curve and a measure of classification skill, was 0.486. That is worse than a coin flip, which sits at 0.500. The profit was a fluke of the specific market period, not a repeatable edge. Using P&L alone as a metric is dangerous. Markets hand out lucky streaks all the time. You need statistical skill metrics to separate flukes from competence.

Know What Each Tool Actually Does

So where does this leave us? Use fine-tuning when the model needs to learn new words, specific formats, or a distinctive style. Use RAG when the model needs access to facts, code repositories, or institutional memory that lives outside its weights. Do not use either tool to discover signal in data that has none. If the underlying pattern is not there, retrieval and fine-tuning will only help you dress up the noise in a sharper suit.

The Real Bottleneck

The infrastructure for fine-tuning and RAG has never been easier to set up. You can spin up a pipeline in an afternoon. The technique is no longer the bottleneck. Evaluation is. Most teams skip the hard statistical work and celebrate vanity metrics instead. They ship systems that sound smart but fail silently.

Run honest tests before you spend money. Question your metrics. Check for overfitting. Make sure the model is actually better,