파인튜닝·검색(RAG)·프롬프트 — 무엇을 고를 것인가

모델이 원하는 대로 하지 않는다. 선택지는 셋이고, 결정은 대개 거꾸로 내려진다 — 누군가 접근법을 먼저 고르고, 그다음에 근거를 짓는다. 파인튜닝이 제일 «본격적»으로 들리므로 가장 자주 제안되고 가장 드물게 작동한다.

믿을 만한 순서는 반대다. 실패를 진단하면, 실패가 기법의 이름을 말해 준다.

실패 셋, 도구 셋

모델 동작에 대한 불만은 거의 전부 셋 중 하나다.

지식 결손. 모델이 «모르는» 것이다 — 우리 상품 목록, 지난주 바뀐 정책, 이 고객의 주문 이력. 학습에도 없었고 프롬프트에도 없으니 알 수가 없다.

동작 결손. 알 만큼은 아는데 «모양»이 틀린다. 너무 길거나, 어조가 틀리거나, 필수 절이 빠지거나, 우리 업계가 안 쓰는 용어를 쓰거나, 거절했어야 할 때 답한다.

기술 결손. 맞는 정보를 앞에 두고 지시도 분명한데 특수한 과제를 못 한다 — 경계가 미묘한 도메인 분류, 틈새 형식 표기법, 공개 웹에 잘 안 나오는 관례에 기대는 판단.

파인튜닝이 지식 결손을 못 푸는 이유

이 분야에서 결과가 가장 큰 오해라, 정확히 적어 둘 만하다.

파인튜닝은 예시 쌍 위에서 가중치를 조정한다. 그 예시에 든 사실이 출력에 나올 확률이 오르는 것은 «사실»이다. 다만 지식 시스템에 필요한 성질은 하나도 따라오지 않는다.

• 무엇이 학습됐는지 열거할 수 없다. 어떤 사실이 들어갔는지 돌려주는 질의가 없다.
• 사실 하나만 고칠 수 없다. 가격 하나를 바로잡으려면 데이터셋을 새로 만들어 다시 학습해야 한다.
• 인용을 못 한다. 추적 가능한 출처 없이 사실을 내놓는다 — 규제나 감사가 걸린 어떤 맥락에서도 못 쓴다.
• 권한을 적용할 수 없다. 전 고객 데이터로 학습한 모델은 누구에게나 전 고객 데이터에 대해 답한다.
• 자신 있는 오류가 «더» 나빠진다. 사실 위의 파인튜닝은 그 도메인에 대한 유창함과 자신감을 정확도보다 빠르게 올리는 경향이 있다. 가능한 조합 중 가장 쓸모없는 조합이다.

검색은 모든 줄에서 정반대 프로필을 갖는다. 문서를 바꾸면 다음 답이 바뀐다. 모든 문단에 id 가 있다. 권한은 모델이 무엇을 보기 «전»에 걸리는 필터다.

프롬프트가 과소평가되는 이유

팀들은 프롬프트를 «진지한 시스템은 졸업하는 초보용 선택지»로 취급하곤 한다. 실무에서는 동작 문제의 상당 부분이 거기서 해결되고, 이유는 약한 프롬프트가 대개 같은 세 방식으로 실패하기 때문이다.

예시가 없다. 원하는 출력 모양을 두세 번 «보여 주는» 것이, 그것을 몇 문단으로 «설명하는» 것보다 낫다. 명세하지 말고 시연하라.

구조가 없다. 산문에 묻힌 지시는 고르게 지켜지지 않는다. 절 나눔, 번호 붙인 제약, 명시적 출력 형식은 훨씬 안정적으로 지켜진다.

거절할 권한이 없다. 답을 모를 때 어떻게 하라는 말이 없는 프롬프트는 «어쨌든 답하라»고 암묵적으로 요구하는 것이다. 한 문장 — "문서에 답이 없으면 없다고 말하고 멈춰라" — 이 지어내기 한 부류를 통째로 없앤다.

프롬프트에는 나머지 둘에 없는 성질도 있다. 몇 초 만에 되돌릴 수 있다. 요구사항이 아직 움직이는 동안 그것은 어떤 효율 이득보다 값지다.

정직한 한계는 비용과 일관성이다. 2,000토큰짜리 시스템 프롬프트는 매 요청마다 청구되고, 아주 긴 지시 집합은 고르게 지켜지지 않는다. 동작이 «확정»되고 물량이 많다면 그것을 가중치로 옮기는 것이 옳은 최적화다 — 다만 그건 동작을 «알고 난 뒤»의 효율 판단이지, 동작이 무엇이어야 하는지를 «알아내는» 방법이 아니다.

파인튜닝이 «진짜로» 쓸 자리

셋은 분명히 정당하다.

물량이 많은 상황에서의 형식·문체 일관성. 모든 응답이 사내 구조를 따라야 하는데 프롬프트로 95%까지 갔다면, 일관된 예시 수백 개로 학습해 훨씬 높은 숫자에 도달하면서 매 요청의 지시 토큰을 없앨 수 있다.

좁은 기술 습득. 경계가 미묘한 도메인 분류, 내부 표기법, 공개 웹에 없는 사내 관례. 셋 중 «시키는 것»이 아니라 «할 수 있는 것»을 바꾸는 유일한 기법이다.

작은 모델을 충분하게 만들기. 경제적으로 가장 흥미로운 경우다. 좁은 과제 하나에서 프런티어 모델과 맞먹는 파인튜닝된 작은 모델은 비용과 지연을 크게 깎고, 실현 가능한 자체호스팅 배포의 배후 장치인 경우가 많다.

파라미터 효율적 방법 — 전체 신경망 대신 작은 어댑터만 학습 — 은 셋 다를 예전보다 훨씬 싸게 만들었다. 계산은 달라졌지만 «진단»은 달라지지 않았다. 틀린 문제에 대한 값싼 해법은 여전히 틀린 해법이다.

견적에서 빠지는 비용

데이터셋 조립. 일관되고 올바른 예시 수백~수천 개. 대개 라벨링 작업을 뜻한다. 모순된 예시는 예시가 없는 것보다 나쁘다 — 일관되지 않게 구는 법을 가르친다.

평가. 홀드아웃 셋과 전후 비교 수단이 없으면, 튜닝된 모델이 «더 나은지» 알 방법이 없다. 가장 자주 건너뛰는 단계이자 차이를 감지 가능하게 만드는 단계다.

베이스 모델 러닝머신. 베이스가 올라갈 때마다 질문이 다시 열린다 — 새 베이스로 재학습할 것인가, 옛것에 남아 개선을 포기할 것인가. 무기한 반복되고, 프롬프트에는 이 문제가 없다. 더 나은 베이스는 그냥 «온다».

회귀 위험. 한 동작을 위한 학습이 다른 동작을 나빠지게 할 수 있다. 넓은 평가셋이 없으면 그것을 사용자가 발견한다.

작동하는 순서

1. 실패를 한 문장으로 적고 분류한다 — 지식·동작·기술.
2. 평가셋을 먼저 만든다. 실제로 실패한 사례에서. 그것 없이는 셋 중 아무것도 판정할 수 없다.
3. 프롬프트를 고친다. 예시·구조·명시적 거절 통로를 넣는다. 측정한다.
4. 사실 문제면 검색을 붙인다. 검색과 생성을 «따로» 확인한다.
5. 파인튜닝은 동작이 확정됐는데 프롬프트로 비싸거나, 3·4 를 거치고도 진짜 기술 결손이 남을 때만.

이 순서를 따르는 팀 대부분은 3단계나 4단계에서 멈춘다. 야심이 부족한 게 아니라 그게 올바른 결말이고, 학습 파이프라인을 짓지 않은 그 몇 달이 진단을 먼저 한 것에 대한 수익이다.