RAG와 파인튜닝 비교: AI 시스템 구축 시 잘못된 질문

한 플랫폼 팀이 회사의 ADR(Architecture Decision Records) 및 내부 문서를 사용하여 개발자의 아키텍처 질문에 답변하는 LLM 기반 어시스턴트를 평가하고 있습니다. 평가 과정 중, 해당 팀 스스로가 이 어시스턴트가 작년에 폐기된 서비스 간 인증 패턴을 추천했으며, 게다가 이미 사용 중단(deprecated)으로 표시된 내부 API의 엔드포인트를 호출하도록 제안했다는 것을 발견했습니다. 답변 자체는 그럴듯했고, 잘 작성되었으며, 일반적인 용어로는 기술적으로 방어가 가능했습니다. 다만, 현재 확립된 결정 사항과 모순되었습니다.

이 실패 사례가 사용자에게 도달하기 전에 포착되었고, 바로 이 점 때문에 이어지는 대화가 중요합니다. 두 가지 제안이 논의 테이블에 놓였습니다. 첫 번째는

그 질문은 보이는 것보다 더 중요합니다. 왜냐하면 같은 구식 권장 사항이라도 매우 다른 출처를 가질 수 있기 때문입니다. 이전 패턴을 대체한 ADR(Architecture Decision Record)이 인덱싱되지 않았을 수도 있습니다. '폐지됨'으로 표시된 오래된 ADR이 새로운 ADR 대신 검색될 수도 있습니다. 두 가지 모두 검색되었지만 모델이 컨텍스트를 무시하고 공개 문서에서 학습한 내용에 기반하여 답변했을 수도 있습니다. 또는 질문 자체가 일반적이었고 시스템 지침(system instruction)에서 최신 결정 사항을 우선순위로 지정하라고 요구하지 않았을 수도 있습니다. 각 원인은 다른 수정 방안을 필요로 하며, 이 중 어느 것도 논쟁에서 승리한 기술만으로는 해결되지 않습니다. 예를 들어, 오늘날의 ADR로 파인튜닝(fine-tuning)하는 것은 내일 결정이 대체되면 도움이 되지 않습니다. 이는 우리 시나리오에만 국한된 것이 아닙니다. RAG 시스템에 대한 엔지니어링 보고서에서는 이러한 종류의 시스템을 구축할 때 일곱 가지의 명확한 실패 지점을 식별했습니다.

우리가 이 논쟁에 어떻게 도달했는지 이해하려면 배경 맥락을 되돌아보는 것이 도움이 됩니다. 2022년 말 ChatGPT가 등장한 이후, 조직들은 LLM(대규모 언어 모델)을 예전에는 위키, 공유 폴더, 운영 문서 등에 존재했던 정보 앞에 배치하려고 노력해 왔으며, 이를 통해 필요한 모든 사람에게 지식을 더 쉽게 접근할 수 있게 하겠다는 약속을 했습니다. 이 과정에서 두 가지 기술이 연구 주제였던 것이 일상적인 어휘가 되었습니다. 하나는 Lewis 등이 2020년에 제안한 검색 증강 생성(RAG: retrieval-augmented generation)이고, 다른 하나는 LoRA와 같은 매개변수 효율적 방법(parameter-efficient methods) 덕분에 실행 비용이 훨씬 저렴해진 파인튜닝입니다. 두 가지 강력한 도구가 함께 등장하여 동일한 명백한 '문제점'을 해결하자, 시장이 이를 정면으로 비교하는 것은 자연스러운 일입니다. 이것이 바로 표준적인 틀, 즉 _RAG 대 파인튜닝_의 탄생 배경입니다.

그러한 틀의 문제는 질문에 합의하기 전에 답을 고르도록 요구한다는 점입니다. 두 접근 방식을 나란히 비교하는 연구가 있으며, 이는 슬로건이 아닌 신중한 독해를 받을 가치가 있습니다. 예를 들어, OpenAI의 정확도 최적화 가이드는 이들을 서로 다른 문제에 대한 답변이자 "상호 배타적이지 않고 상가적인(additive), 아닌" 접근 방식으로 취급합니다. 따라서 질문은 기술에서 시작해서는 안 됩니다. 실패(failure)에서 시작해야 합니다.

Two ways to start the same conversation: starting from the technique, the team picks RAG or fine-tuning and the original failure remains undiagnosed; starting from the failure, the cause is identified before the intervention.
그림 1. 두 대화의 차이점은 선택된 기술 자체가 아니라 건너뛴 단계이다.

본 글은 그러한 역전(inversion)을 주장하며, 시스템이 무엇을 알아야 하는지, 어떻게 행동해야 하는지, 그리고 무엇을 해야 하는지를 분리하여 이를 실용적으로 구현하는 방법을 제안합니다. 이는 AI 시스템이 신뢰할 수 있게 되거나 그렇지 않게 되는, 모델 외부에서 발생하는 결정들에 관한 일련의 글 중 첫 번째 단계입니다.

1. 문제점

아키텍처 어시스턴트로 돌아가 봅시다. 테이블 위에 놓인 두 가지 제안은 공통점이 있습니다. 둘 다 기술에서 시작하여 그 기술이 해결할 문제를 나중에 찾아본다는 것입니다. 이는 대화 내용이 기술적이고 성숙하게 들리기 때문에 미묘한 역전(inversion)입니다. 그러나 엔지니어링의 일반적인 경로는 정반대입니다. 즉, 증상을 관찰하고, 원인에 대한 가설을 세우고, 이를 테스트한 다음 비로소 개입하는 것입니다. LLM 기반 시스템에서 진단은 가장 쉽게 건너뛰어지는 단계인 경향이 있습니다.

왜 건너뛰는가? 제가 직접 관찰한 바로는 여러 가지 이유를 생각해 볼 수 있지만, 세 가지가 가장 그럴듯해 보입니다. 첫째, 기술은 유형적입니다. 도구, 튜토리얼, 예산, 그리고 로드맵에 적을 만한 이름이 있습니다. 둘째, 진단은 작업입니다. 추적(traces)을 열고, 검색된 것과 생성된 것을 분리하고, 실패를 재현하며, 어느 단계에서 기원했는지 이해해야 합니다. 셋째, 'RAG인가 파인튜닝인가?'는 의견으로 답할 수 있는 질문이지만, '이 실패의 원인은 무엇인가?'는 증거로만 답할 수 있습니다.

진단 이전에 기술을 선택하는 비용은 최소 세 가지 방식으로 나타납니다.

원래의 실패는 여전히 존재합니다. 만약 문제가 새로운 ADR 대신 오래된 ADR이 검색되는 것이었다면, 모델을 ADR로 훈련시키는 것은 아무것도 바꾸지 못합니다. 잘못된 콘텐츠가 계속 컨텍스트에 도달하는 것입니다. 만약 문제가 모델이 검색된 컨텍스트를 무시하는 것이었다면, 더 많은 컨텍스트를 검색한다고 해서 해결되지도 않습니다. 개입(intervention)은 배포되고, 팀은 문제를 해결했다고 간주하며, 구식 권장 사항이 다음 평가 라운드에 다시 나타납니다.

개입으로 인해 시스템이 더 나빠질 수 있습니다. OpenAI의 정확도 최적화 가이드에는 RAG가 노이즈를 추가하여 모델을 '혼란스럽게' 만들고 점수를 4점 낮춘 예시가 포함되어 있습니다. 파인튜닝 측면에서는, 외부 검색 없는 질의응답에 대한 통제 연구에서 새로운 지식을 포함하는 예제가 더 느리게 학습되며, 일단 학습되면 모델의 환각(hallucinate) 경향을 증가시킨다는 것이 나타났습니다. 그 결과는 특정 설정에 국한된 것이며 모든 파인튜닝에 확장되어서는 안 됩니다. 그럼에도 불구하고, '하나 더 많은 기술'이 위험 부담 없는 선택은 아니라는 것을 보여줍니다.

복잡성은 사용자에게 전가됩니다. 각 기술은 새로운 유지보수 영역을 가져옵니다. RAG는 인덱싱(indexing), 업데이트, 랭킹(ranking), 권한 제어(permission control)를 필요로 합니다. 파인튜닝(Fine-tuning)은 학습 데이터, 버전 관리(versioning), 기본 모델 변경 시마다 재평가, 그리고 콘텐츠 변화에 대한 계획을 요구합니다. 만약 실제 원인이 모호한 지침이었다면, 팀은 프롬프트 조정만으로 해결할 수 있는 문제를 해결하기 위해 그 비용을 지불했습니다. 우연이 아닙니다. 동일한 OpenAI 가이드는 프롬프트 엔지니어링(prompt engineering)부터 시작할 것을 권장합니다.

이 모든 것이 어느 한쪽 기술이 악당이라는 의미는 아닙니다. 증거는 혼재되어 있으며, 그것 자체가 문제입니다. 지식 주입에 대한 직접적인 비교에서 RAG가 비지도 파인튜닝(unsupervised fine-tuning)보다 우수한 성능을 보였는데, 이는 이전에 본 지식과 새로운 지식 모두에 해당합니다(Ovadia et al., 2023). 최근의 다단계 질문(multi-hop questions) 및 신규 지식 관련 연구에서는 지도 파인튜닝(supervised fine-tuning)으로 가장 높은 전반적인 정확도를 발견했습니다. 둘 다 소규모 또는 합성 벤치마크를 사용한 사전 인쇄본(preprint)이며, 어느 것도 우리 팀의 질문에 답하지 못합니다. 이들은 각 기술이 고유한 영역을 가지고 있으며, 실패가 어떤 영역에 속하는지 알아내는 것이 바로

이것은 결과가 아니라 가설입니다. 이 기사에서는 테스트되지 않았습니다. 이를 테스트하려면 팀이 평가 라운드에서 실패 사례들을 수집하고, 독립적인 검토자들에게 각각의 사례를 분류하도록 요청한 다음, 그들 사이의 일치도를 측정할 수 있습니다. 다음으로, 그들은 각 범주에 대해 제시된 개입(intervention)을 적용하고 그 결과를 대안과 비교할 것입니다. 가설은 검토자 간의 합의도가 낮거나, 대부분의 실패 사례가 세 가지 범주에 맞지 않거나, 모든 사례가 동일한 개입을 요구하는 경우 약화됩니다. 시리즈의 다음 기사들에서 이 실험 설계로 돌아올 예정입니다.

하지만 우리의 시나리오가 제시하는 정제(refinement) 사항이 있고, 이는 보통 논의에서 빠지는 부분입니다. 폐기된 ADR로 돌아가 봅시다. Michael Nygard는 형식에 관한 원래 글에서 역전된 결정(reversed decisions)을 삭제해서는 안 된다고 권장합니다. 그들은 기록으로 남겨지고 '폐기됨(superseded)'으로 표시되어야 하는데, 그 이유는

만약 H2가 사실이라면, 지식 실패에 직면했을 때의 첫 번째 질문은 'RAG인가 파인튜닝인가?'에서 '코퍼스(corpus)를 참조할 수 있는 상태인가?'로 바뀐다. 이러한 의미에서의 큐레이션(Curation)은 모델에 대한 어떤 결정보다 앞서, 지식에 관한 일련의 엔지니어링 결정이다. 비용이 낮은 순서로 네 가지 형태가 있다: