파인튜닝 vs RAG: 실제로 파인튜닝이 필요할 때
원하는 행동의 예시로 모델의 학습을 이어 가서, 그 행동이 매 요청마다 요구하는 것이 아니라 기본값이 되게 하는 것. 모델이 무엇을 아는지가 아니라 어떻게 작동하는지를 바꿉니다.
모델이 당신을 위해 하는 일을 바꾸는 방법은 단 세 가지뿐이며, 서로 대체할 수 없습니다. 잘못된 것을 고르면, 몇 달이 지나서야 드러나는 방식으로 비싼 대가를 치릅니다.
| 지렛대 | 무엇을 바꾸나 | 언제 비용이 드나 |
|---|---|---|
| 프롬프팅 | 이번에 모델이 하는 일 | 매 요청마다, 토큰으로 — 그리고 긴 지침은 대화가 길어질수록 덜 안정적으로 지켜집니다 |
| 검색(Retrieval) | 모델이 지금 아는 것 | 요청마다, 검색 작업으로. 사실은 모델 밖에 살기에 항상 최신입니다 |
| 파인튜닝 | 모델이 기본적으로 하는 일 | 한 번, 선행 비용으로. 요청 시점에는 무료 — 행동이 새겨져 있습니다 |
파인튜닝이 실제로 무엇인가
기본 모델을 가져다가 원하는 행동의 예시로 학습을 이어 갑니다: 입력과, 당신 분야의 훌륭한 실무자가 내놓았을 답의 쌍입니다. 모델의 기본값이 이동합니다 — 어떤 단어를 꺼내는지, 답이 어떤 모양을 취하는지, 답하기 전에 무엇을 묻는지.
그것은 데이터베이스가 아닙니다. 아무것도 저장되고 조회되지 않습니다. 예시는 모델의 경향을 움직일 뿐, 모델이 암송할 수 있는 사실이 되지는 않습니다.
실제로는 새 모델이 아니라 어댑터
모든 가중치를 재학습하는 것은 비싸고 좀처럼 필요하지 않습니다. 일반적인 접근 — LoRA, 즉 저순위 적응(low-rank adaptation) — 은 얼어붙은 기본 모델 위에 얹히는 소수의 추가 파라미터를 학습합니다. 그 결과는 수십 기가바이트가 아니라 수십 메가바이트짜리 파일입니다.
그것은 알아 둘 만한 결과를 낳습니다: 하나의 기본 모델이 많은 어댑터를 서비스할 수 있습니다. 단일 기계가 법률 회사, 진료소, 물류 사업자를 위해 같은 기본 가중치를 실행하면서 테넌트별로 작은 어댑터를 교체할 수 있습니다. 업종별 파인튜닝이 업종별로 통째 모델 하나를 의미하지는 않습니다.
실제로 필요할 때
어투가 중요하고 프롬프트가 그것을 유지할 수 없을 때. 일본어 비즈니스 경어, 임상적 표현, 심사역이 말을 아끼는 방식. 프롬프트로 어투를 묘사할 수는 있지만, 긴 대화에서는 모델이 기본값으로 되돌아갑니다. 파인튜닝은 그 기본값을 옮깁니다.
대량에서의 형식 준수. 모든 출력이 특정 구조여야 하고 "대체로 맞음"으로는 충분하지 않다면, 예시가 지침보다 더 안정적으로 그것을 가르칩니다.
지침이 답보다 커졌을 때. 시스템 프롬프트가 그것이 생산하는 것보다 길어지면, 매 요청마다 그 토큰 값을 치르고 있는 것입니다. 파인튜닝은 그 비용을 요청별 경로에서 덜어 내는 방법입니다.
좁은 도메인의 작은 모델. 잘 튜닝된 작은 모델이 하나의 업종 안에서는 훨씬 큰 범용 모델을 이기는 경우가 많습니다 — 이는 품질만큼이나 비용에 관한 결정입니다. 자체 모델 사용하기를 참고하세요.
당신의 언어나 분야에서 기본 모델이 약할 때. 일부 언어와 전문 분야는 공개 학습 데이터가 빈약합니다. 예시가 그것을 고치는 방법입니다.
필요하지 않을 때
사실은 파인튜닝에 속하지 않습니다. 가격, 정책, 재고, 사건 상태 — 화요일에 바뀔 수 있는 무엇이든 지식 베이스에 속하며, 거기서는 그것을 바꾸는 일이 업로드 한 번입니다. 파인튜닝된 모델은 당신의 가격표가 바뀔 때 갱신되지 않으며, 학습한 것을 자신 있게 계속 답할 것입니다.
- 아직 더 나은 프롬프트를 시도해 보지 않았을 때. "커스텀 모델이 필요하다"는 문제의 대부분은 프롬프트 문제입니다. 파인튜닝은 비싼 답이니, 먼저 그럴 자격을 얻으세요.
- 예시가 한 줌뿐일 때. 수십 개로는 모델이 움직이지 않습니다. 수백 개의 좋은 예시라면 움직일 수 있습니다. 품질이 양을 이기고, 나쁜 예시는 나쁜 습관을 충실히 학습시킵니다.
- 원하는 것이 자주 바뀔 때. 매주 편집하고 싶을 만한 것은 새겨 넣어서는 안 됩니다.
제대로 하려면 무엇이 드는가
예시. 수백에서 낮은 수천 개, 실제 업무에서 뽑아 그 분야를 아는 사람이 검토한 것. 이것이 고객이 과소평가하는 부분입니다 — 데이터 수집이 대개 학습보다 오래 걸립니다.
따로 떼어 둔 평가 세트. 모델이 한 번도 보지 못한 예시로, 전후에 채점합니다. 이것 없이는 파인튜닝이 도움이 됐는지, 해가 됐는지, 아무것도 안 했는지 알 수 없으며 — "느낌이 더 낫다"는 측정이 아닙니다. 이것이 가장 자주 건너뛰는 단계이자, 프로젝트가 할 가치가 있었는지를 결정하는 단계입니다.
기본 모델이 바뀌는 것에 대한 계획. 어댑터는 학습된 기본 모델에 묶여 있습니다. 더 새로운 기본 모델로 옮기면 튜닝을 다시 합니다. 일회성이 아니라 유지보수로 예산을 잡으세요.
설계로 대비해야 할 실패
하나의 좁은 스타일에 너무 강하게 튜닝된 모델은 다른 모든 것에서 나빠집니다 — 다른 어투가 필요한 질문에도 당신의 사내 목소리로 답하고, 배운 적 없는 것에 대해 자신 있게 유창해집니다. 이것이 평가 세트가 중요한 이유이며, 분별 있는 목표가 대개 한 가지만 할 수 있는 모델이 아니라 기본값의 완만한 이동인 이유입니다.
에이전트가 누구인지에 대한 상시적 서술 — 그 성격, 어조, 타협 불가능한 원칙 — 으로, 그것이 마침 하고 있는 일과는 별도로 보관됩니다.
에이전트가 근거로 답할 수 있는 문서들. agent4.io는 두 종류 — 당신 회사의 검증된 자료와, 각 고객 자신의 파일 — 를 함께 검색하지만 결코 서로 혼동하지 않고 보관합니다.
이름이 붙은 능력 묶음 — 언제 사용하는지에 대한 짧은 설명, 더 상세한 지침, 그리고 그것이 열어 주는 도구들 — 으로, 에이전트는 관련이 있을 때만 이를 불러옵니다.
Model Context Protocol — 에이전트를 외부 도구 및 데이터에 연결하기 위한 개방형 표준으로, 시스템이 AI 제품마다 한 번씩이 아니라 자신의 능력을 한 번만 노출하게 합니다.
하나로 혼동되곤 하는 세 가지 서로 다른 일 — 지식 베이스는 사실을 담고, MCP 도구는 모델이 즉흥적으로 처리하게 둘 수 없는 계산을 수행하며, Skill은 그중 무엇을 꺼낼지 결정하는 절차입니다.