Everyone has an opinion on fine-tuning versus RAG. Scroll through any AI forum and you will find heated threads full of architecture diagrams and benchmark claims. Most of the people writing those comments have never trained a model on their own data or watched a RAG pipeline fail silently in production.

I spent months running experiments. Twelve of them, to be exact. I fine-tuned LLMs. I fine-tuned embedders. I built six different RAG configurations. The domain was financial prediction, specifically trying to forecast noisy market outcomes from messy historical data. I held myself to strict statistical standards because I wanted real answers, not blog post claims.

Most of the experiments failed. Those failures turned out to be far more useful than any lucky success.

The Hard Truth About Signal

Before getting into the weeds, here is the lesson that ties everything together. Fine-tuning and RAG are tools for changing what a model knows or what it sees. They are not magic wands that manufacture signal from thin air. If your underlying data does not contain a real, exploitable pattern, these techniques will not create one. They will just help you build a more convincing story around random noise.

In financial prediction, this trap is especially dangerous. Markets are noisy by design. When you strap a powerful LLM to historical price data and add retrieval or fine-tuning, you do not automatically get an edge. You get a more articulate way of rationalizing coin flips. If the signal is not there, the model becomes very good at lying to you. You need to check that first.

When Bigger Memorizes Instead of Learns

My first major mistake was assuming scale would fix everything. I tested a 14 billion parameter model against a 7 billion parameter model on exactly 777 training examples. The larger model achieved a noticeably better eval_loss. Its perplexity dropped. On paper, it was learning.

Then I looked at the win rate, the actual rate at which the model made correct predictions. The 14B model performed significantly worse than the 7B model. It had memorized the training noise. With fewer than 3,000 examples, the bigger model had enough capacity to overfit on spurious correlations and random wiggles in the data. It essentially built a lookup table of noise.

The 7B model, constrained by its smaller capacity, was forced to learn broader patterns. It could not afford to memorize every idiosyncrasy. If you are working with small datasets, start with smaller models. Scale is not free. It can actively hurt you when the data is thin.

Do Not Trust the Loss Curve

I learned to stop staring at loss curves. A model can improve its token-level cross-entropy while becoming worse at the actual business decision you care about. This happens because language modeling loss rewards predicting the next token accurately. In many domains, especially finance, the correct decision and the most probable next token are not the same thing.

I saw models that reproduced training prose beautifully but chose the wrong directional bet every time. The loss went down. The bankroll went down with it. Pick your evaluation metric based on the real-world task. If you are ranking documents, measure ranking quality. If you are predicting outcomes, measure decision accuracy. Never let eval_loss choose your model for you.

Fine-Tuning Shines Only on Foreign Vocabulary

I ran embedder fine-tuning trials on two different text types. The first used standard financial news and public filings. The fine-tuned embedder and the off-the-shelf version performed identically. The base model already knew this language. I was tuning on familiar ground.

The second dataset was full of private jargon, internal codenames, and domain-specific shorthand that never appeared on the open internet. Here, fine-tuning improved retrieval accuracy by 79 percent. The base model simply did not know what these terms meant. Fine-tuning taught it the local vocabulary.

This reframed the entire exercise for me. Fine-tuning is not about making a model smarter in some general sense. It is about teaching it a new vocabulary, a new format, or a house style. If your data looks like the internet, skip the fine-tune. If your data speaks a language the base model has never seen, fine-tuning becomes essential.

RAG Gives You Certainty, Not Truth

예측 작업을 위해 8가지의 서로 다른 RAG 구성을 테스트했습니다. 전반적으로 검색(retrieval)을 추가했을 때 모델의 결정 중 약 30%가 바뀌었습니다. 영향력이 커 보일 수 있지만, 그렇지 않았습니다. 그 변화들은 순전한 노이즈였습니다. 전체적인 정확도는 향상되지 않았습니다. 변한 것은 모델의 확신(confidence)뿐이었습니다. RAG는 시스템이 더 확신에 찬 것처럼 들리게 하고, 더 많은 출처를 인용하며, 더 긴 근거를 생성하게 만들었습니다. 그러면서도 틀린 결과는 여전히 똑같았습니다.

이러한 과잉 확신은 제품 리스크입니다. 사용자는 인용구를 보고 모델이 충분히 조사했다고 가정합니다. 하지만 실제로는 정교해 보이는 추측을 하고 있었을 뿐입니다.

가장 뼈아픈 교훈은 한 RAG 변형 모델을 백테스팅(backtesting)하는 과정에서 얻었습니다. 그 모델은 연간 11%의 수익을 보여주었습니다. 겉보기에는 승리하는 전략처럼 보입니다. 하지만 분류 능력을 측정하는 지표인 AUC(ROC 곡선 아래 면적)는 0.486이었습니다. 이는 0.500인 동전 던지기보다도 못한 수치입니다. 그 수익은 반복 가능한 우위(edge)가 아니라, 특정 시장 기간이 만들어낸 우연(fluke)이었습니다. 손익(P&L)만을 지표로 사용하는 것은 위험합니다. 시장은 언제나 운 좋은 흐름을 만들어냅니다. 우연과 실력을 구분하기 위해서는 통계적인 숙련도 지표가 필요합니다.

각 도구가 실제로 무엇을 하는지 파악하십시오

그렇다면 우리는 어떤 결론을 내려야 할까요? 모델이 새로운 단어, 특정 형식 또는 독특한 스타일을 배워야 할 때는 fine-tuning을 사용하십시오. 모델이 가중치(weights) 외부에 존재하는 사실, 코드 저장소 또는 조직의 지식(institutional memory)에 접근해야 할 때는 RAG를 사용하십시오. 신호(signal)가 없는 데이터에서 신호를 찾아내기 위해 두 도구 중 어느 것도 사용하지 마십시오. 근본적인 패턴이 존재하지 않는다면, retrieval과 fine-tuning은 그저 노이즈를 더 세련된 옷으로 꾸며줄 뿐입니다.

진짜 병목 구간

fine-tuning과 RAG를 위한 인프라 구축은 그 어느 때보다 쉬워졌습니다. 오후 한나절이면 파이프라인을 구축할 수 있습니다. 이제 기술이 병목이 아닙니다. 평가는 그렇습니다. 대부분의 팀은 까다로운 통계 작업을 건너뛰고 대신 허영 지표(vanity metrics)를 축하합니다. 그들은 똑똑해 보이지만 조용히 실패하는 시스템을 출시합니다.

돈을 쓰기 전에 정직한 테스트를 수행하십시오. 지표에 의문을 제기하십시오. 과적합(overfitting) 여부를 확인하십시오. 모델이 실제로 더 나은지 확인하십시오,