왜 Fine-Tune (vs. Prompt, vs. RAG)

도구 서랍의 노브 셋

Fine-tune 전에 해야 할지 물어봐. 결정 트리:

프롬프트 엔지니어링 — 시스템 프롬프트, 챗 template, few-shot example 조정. 비용: 시간 단위. 해결: 동작 steering, 단순 포맷 요구사항, persona, 스타일.
RAG (retrieval-augmented generation) — 인퍼런스 타임에 vector store 에서 관련 컨텍스트 pull. 비용: 일 단위. 해결: 도메인 지식, freshness, 인용, 큰 지식 베이스.
Fine-tuning — 태스크별 데이터로 가중치 수정. 비용: 주 단위 (데이터 + 컴퓨트 + eval). 해결: 깊은 스타일/도메인 mastery, latency 감소 (모델이 X 를 재설명 없이 앎), vocabulary adaptation.

Fine-tune trigger 조건

너 eval 셋의 prompt-only 솔루션이 여러 번 iterate 후에도 unreliable.
RAG 컨텍스트 윈도우가 너 latency 예산 폭파.
고품질 example 1k+ 이상 (보이는 품질 점프엔 종종 10k+).
학습 + ongoing eval 위한 GPU 예산.

“모델에 사실 가르치려고” fine-tune 하면 거의 항상 RAG 문제 disguise. Fine-tuning 이 동작 가르치지, 사실 X.

Code

Fine-tune vs prompt vs RAG: pseudo-결정·python

def choose_strategy(eval_score_with_prompt, latency_budget_ms, has_facts_to_inject, num_examples):
    if eval_score_with_prompt >= target_score:
        return "stay with prompt engineering"
    if has_facts_to_inject and latency_budget_ms > 500:
        return "RAG"
    if num_examples >= 1000 and gpu_budget_available:
        return "fine-tune (start with LoRA)"
    return "collect more data, retry"

왜 Fine-Tune (vs. Prompt, vs. RAG)

도구 서랍의 노브 셋

Fine-tune trigger 조건

Code

External links

Exercise

Progress

댓글 0