안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.
사내 문서를 다루는 AI 서비스의 답이 기대에 못 미치면 RAG를 도입할지, 파인튜닝을 할지 고민하게 되는데, 어느 쪽이 맞는지 판단하려면 답이 왜 틀렸는지부터 가려야 합니다.
계약서 검토를 돕는 AI 비서를 예로 들면, 어떤 답에서는 자동 갱신 조항 자체가 빠지고, 어떤 답에서는 조항은 제대로 담겼는데 사내 시스템에 넘길 때 꼭 있어야 하는 해지 통보 기한 항목이 비어 있습니다. 앞의 답은 조항을 놓쳤고 뒤의 답은 조항을 담고도 필요한 항목을 채우지 못한 것이라, 둘 다 틀린 답이어도 틀린 이유는 다를 수 있습니다. 그래서 검색 성능을 높이거나 파인튜닝에 투자하기 전에 답마다 원인부터 봅니다.
RAG(검색 증강 생성)는 답을 만들 때 필요한 자료를 사내 문서처럼 모델 밖에서 골라 모델에 넣는 방식이고, 파인튜닝은 학습 예시로 모델 자체를 조정하는 방식입니다.
여기에 별도의 검색 단계 없이 관련 자료를 요청에 바로 넣는 문서 직접 입력 방식도 있습니다. 세 방법은 함께 쓸 수도 있지만, 어느 방법을 쓰더라도 무엇이 실패했는지 확인하는 과정은 따로 거쳐야 합니다.
먼저 필요한 근거와 분명한 지시문을 모델에 넣었을 때 그 업무를 처리할 수 있는지부터 시험하고, 다음에 무엇을 시험할지는 이 결과를 보고 정합니다. 원인이 모델에 넣는 데이터 쪽으로 좁혀지면 데이터만 바꿔 따로 비교하는데, 그 데이터가 업무에 맞게 준비된 AI-Ready Data(AI 레디 데이터)인지는 이렇게 확인합니다.
RAG와 파인튜닝, 문서 직접 입력의 차이
세 방법은 모델에 넣는 자료를 바꾸는지, 모델 자체를 바꾸는지부터 다릅니다. 아래 표에 각 방법을 먼저 시험해 볼 만한 상황과 운영하면서 계속 필요한 일을 정리했습니다.
무엇을 먼저 시험할지는 표만 보고 정하기보다 실제로 관찰한 실패 원인을 보고 정하는 편이 정확합니다.
근거가 없었던 실패와 근거를 잘못 쓴 실패
실패 원인은 크게 두 갈래로 나눠 볼 수 있습니다. 하나는 지식 부족으로, 계약 조항이나 최신 제품 사양, 거래처별 계약 조건처럼 업무에 필요한 정보가 모델에 전달되지 않은 경우입니다. 다른 하나는 동작 문제로, 받은 정보에서 필수 항목을 제대로 추출하는지, 요청한 형식을 지키는지처럼 정보를 다루는 방식에서 생깁니다.
다만 한 답에서 두 갈래가 섞여 나타나기도 합니다. 맞는 조항을 넣었는데도 예외를 잘못 해석한 답이 나올 수 있고, 문서를 요약하는 과정에서 예외의 적용 범위와 종료일이 빠진 채 그 요약이 모델에 들어가기도 합니다(관련 사례(영문)). 형식은 시스템이 읽는 JSON 형식에 맞는데 내용에는 근거가 없는 답도 나오므로, 지식 문제인지 동작 문제인지는 처음에는 가설로 두고 하나씩 확인해야 합니다.
추출에 실패한 사례라면 실제로 모델에 들어간 입력과 기대한 결과를 나란히 놓고 비교합니다. 관련 조항과 그 조항에 쓰인 용어의 정의가 입력에 들어 있었는지, 지시문에 필수 항목이 무엇인지와 정보가 없을 때는 어떻게 처리할지가 적혀 있었는지를 확인합니다. 이 두 가지를 보면 학습이 필요한 문제인지, 요청 내용을 고쳐 해결할 수 있는 문제인지 가리기가 쉬워집니다.
큰 문서 모음에서 답을 찾을 때는 RAG
RAG는 모델에 이미 학습된 내용에 기대지 않고, 필요한 자료를 따로 골라 모델에 넣는 구조입니다. 그래서 내용이 자주 바뀌는 문서 모음에서 질문마다 그중 일부만 필요할 때 시험해 볼 만합니다.
Ovadia 연구팀의 비교 연구(EMNLP 2024)에서 평가한 지식 중심 과제에서는 RAG의 성능이 비지도 파인튜닝보다 높았습니다. 비지도 파인튜닝으로도 성능이 어느 정도 올랐지만, 그 방식으로 새로운 사실을 모델에 반영하기는 여전히 어려웠습니다. 여기서 비지도 파인튜닝은 정답을 표시한 예시 없이 문서 본문 자체를 더 학습시키는 방식으로, 뒤에서 다룰 지도 미세 조정과는 다릅니다.
Soudani 연구팀(2024)도 덜 알려진 대상에 관한 질의응답에서 비슷한 결과를 얻었습니다. 파인튜닝으로 성능이 올랐지만 검색을 쓴 쪽의 결과가 더 좋았고, 가장 덜 알려진 사실에서 그 차이가 특히 두드러졌습니다.
두 연구는 전문 지식이 필요한 업무라면 검색 방식을 시험해 볼 근거가 됩니다. 다만 이 결과만으로 파인튜닝으로는 사실을 학습시킬 수 없다거나, 다른 문서 모음에서도 검색이 똑같이 효과적이라고 단정하기는 어렵습니다.
계약서 AI 비서라면 검색 결과에 해당 조항과 그 조항을 해석하는 데 필요한 맥락까지 함께 들어오는지를 시험해야 합니다. 인용한 구절이 질문과 무관하거나, 일부만 담겼거나, 답과 맞지 않을 수도 있으므로 출처를 단 답도 따로 확인합니다. 이때 근거를 제대로 골랐는지와 답이 정확한지는 나눠서 측정합니다.
문서 한 건이 근거일 때는 직접 입력
질문과 함께 근거가 이미 정해져 오는 업무도 있습니다. 사용자가 계약서 한 건을 두고 묻는다면 그 계약서를 요청에 바로 넣는 방식을 기준선으로 삼을 만합니다. 이때 검색 색인을 따로 만들면 일만 늘고, 관찰한 실패는 그대로 남을 수 있습니다.
어느 쪽이 맞는지는 서비스에서 자료를 어떻게 활용하는지에 달려 있습니다. 질문마다 큰 문서 모음에서 작은 구절 하나만 필요한지, 문서 한 건의 상당 부분이 필요한지부터 봅니다. 여기에 선택한 모델로 그 문서를 안정적으로 처리할 수 있는지, 응답 시간과 비용이 팀이 정한 한도 안에 드는지도 함께 따져야 합니다.
Li 연구팀은 긴 컨텍스트와 RAG 비교 평가(2024)에서 질문에 딸린 자료 전체를 검색 없이 모델에 넣는 긴 컨텍스트 방식을 RAG와 비교했는데, 이 방식은 이 글의 문서 직접 입력과 비슷합니다. 연구팀이 쓴 질의응답 시험 문제 전체로 보면 긴 컨텍스트 쪽 결과가 더 좋았고 위키백과 기반 질문에서 그 차이가 특히 뚜렷했지만, 대화 기반 질문과 일반 질의에서는 RAG가 유리했습니다. 검색 방식 가운데 요약을 활용한 방식은 긴 컨텍스트와 비슷한 수준이었습니다. 다만 위키백과 기반 자료는 원래 지문에 관련 없는 글을 덧붙여 길게 만든 시험 자료여서, 실제 업무 문서와는 조건이 다를 수 있습니다.
연구에서 시험한 구성에서 얻은 결과이므로, 다른 업무에 어떤 구조가 맞는지는 따로 판단해야 합니다. 가능하면 대표 사례를 모아 문서 직접 입력과 검색 방식을 같은 조건에서 비교합니다. 비교할 사례에는 바로 옆 조항의 정의가 필요한 질문, 다른 조에 있는 예외를 함께 읽어야 하는 질문, 근거가 문서 곳곳에 흩어진 질문을 꼭 넣습니다. 컨텍스트 창이 문서 전체를 담을 만큼 크더라도, 넣은 내용이 답에 빠짐없이 정확하게 반영된다는 보장은 없습니다.
같은 오류가 반복될 때는 파인튜닝
모델에 필요한 정보를 모두 넣고 분명한 지시문과 예시까지 시험했는데도 같은 실패가 반복된다면 파인튜닝을 검토할 만합니다. 학습에는 원하는 결과를 담은 예시가 필요하고, 학습에 쓰지 않은 사례에서도 개선이 이어지는지 확인할 평가 사례도 따로 준비해야 합니다.
Google Cloud의 지도 미세 조정 안내 문서에는 정답을 표시한 예시로 모델의 동작을 조정하는 방법이 나와 있고, 업무에 맞춘 출력 형식도 조정 대상에 들어갑니다. 그래서 추출 오류나 형식 오류가 반복된다면 지도 미세 조정(지도 파인튜닝)으로 고쳐지는지 시험해 봅니다.
학습을 마친 뒤에도 서비스에서 따로 확인해야 합니다. 학습만으로는 답이 늘 정해진 형식에 맞는다고 보장하기 어려우므로, 답을 다음 시스템에 넘기기 전에 형식(스키마)에 맞는지 검사합니다. 답을 받아 어떤 작업을 실행하는 구조라면, 그 작업을 실행할 권한도 모델의 답과 상관없이 따로 확인합니다.
구조를 정하기 전에 해 볼 작은 실험
계약서에서 갱신일과 해지 통보 기한을 뽑는 AI 비서가 있다고 가정해 보겠습니다. 대상 계약서에는 「계약 만료 1개월 전까지 서면 통지가 없으면 같은 조건으로 1년씩 자동 연장한다」는 조항이 있고, 다른 조에는 「단가 재협의가 성립하지 않으면 연장하지 않는다」는 예외가 있습니다. 검토자가 결과를 확인해 보니 이런 예외를 놓친 답과 꼭 필요한 항목을 빠뜨린 답이 섞여 있었습니다.
먼저 검토를 마친 사례를 모으고, 지금 쓰는 서비스를 기준선으로 둡니다. 그다음 예외를 놓친 사례마다 검토자가 직접 골라 확인한 관련 조항과 용어 정의를 모델에 넣어 봅니다. 모델과 업무 지시문은 바꾸지 않고, 고른 사례 전체에서 같은 비교를 반복합니다. 지금 서비스에서 정답이 나온 사례도 함께 넣어, 근거를 더 넣어도 원래 맞던 답이 유지되는지 확인합니다.
추출 결과가 나아졌다면 서비스에서 근거를 골라 모델에 전달하는 방식부터 살펴봅니다. 다만 검토자가 고른 구절로 결과가 좋아졌다고 해서 자동 검색으로도 같은 효과가 난다고 볼 수는 없으므로, 실제 운영과 비슷한 조건에서 검색이나 문서 직접 입력으로 그만큼 쓸모 있는 자료를 넣을 수 있는지 다시 시험합니다. 근거를 고르고 전달하는 방식을 바로잡더라도 다른 실패는 남아 있을 수 있습니다.
검토한 근거를 넣어도 답이 여전히 틀린다면 지시문과 추출 기준(무엇을 어떤 기준으로 뽑을지)에 모호한 표현이 없는지, 그 모델로 이 추출을 해낼 수 있는지를 점검합니다. 지시문을 더 분명하게 고치고 대표 예시를 넣어 시험한 뒤에도 같은 실패가 계속 나타나고 학습에 쓸 데이터가 있다면, 파인튜닝을 다음 실험 후보로 검토합니다.
평가할 때는 빠뜨린 항목과 틀린 값을 나눠서 셉니다. 형식은 완벽해도 값이 틀린 답이 나온다면 추출 문제는 아직 풀리지 않았습니다. 갱신 조항이 아예 없는 계약서도 평가 사례에 넣어, 답할 근거가 없을 때 날짜를 지어낸 답 대신 「정보 없음」으로 처리되는지도 확인합니다.
비교에서 개선이 확인됐다고 가정하면, 결정 기록은 아래처럼 남길 수 있습니다.
실제 기록에는 무엇을 관찰했는지, 어떤 사례에서 확인했는지, 아직 시험하지 않은 것은 무엇인지를 함께 적어야 합니다.
운영 비용과 다시 검토할 조건
앞의 표에서 본 운영 부담도 첫 실험 결과만큼 중요합니다. 문서 직접 입력이라면 캐시를 지원하는 환경에서 캐시로 입력 비용을 줄일 수 있는지도 살펴볼 만합니다. 어느 방법이 늘 더 저렴하다고 가정하기보다 실제 구성에서 비용을 측정해 보는 편이 안전합니다.
한 업무 안에서 방법을 나눠 쓸 수도 있습니다. 예를 들어 검색으로 최신 조항을 찾아 넣고, 파인튜닝한 모델로 그 조항을 일정한 구조로 추출하는 식입니다. 다만 방법을 하나 더할 때마다 실제로 확인한 문제를 해결하는지, 더 단순한 기준선보다 나은지를 비교해야 합니다.
결정을 다시 검토할 조건도 기록해 둡니다. 문서 모음이 크게 늘거나, 출력 형식 요구가 바뀌거나, 모델을 바꾸면 다시 시험할 이유가 생깁니다. 처음 선택할 때 세운 전제가 지금 업무와 맞지 않게 되면 그 선택도 다시 따져 봐야 합니다.
방법을 고르기 전에 확인할 여섯 가지 질문
- 실패한 답마다 실제로 모델에 들어간 입력과 기대한 결과를 나란히 비교했나요?
- 검토자가 고른 근거를 넣었을 때 결과가 나아지는지 확인했나요?
- 근거를 제대로 골랐는지와 답이 정확한지를 나눠서 측정하고 있나요?
- 빠뜨린 항목과 틀린 값을 따로 세고 있나요?
- 답할 근거가 없는 문서도 평가 사례에 넣었나요?
- 방법을 더하기 전에 더 단순한 기준선과 비교해 결과와 비용을 따져 봤나요?
답하기 어려운 질문이 하나라도 있다면, RAG나 파인튜닝을 정하기 전에 그 부분부터 작은 비교 실험으로 확인해 보세요.
데이터를 고친 효과는 따로 검증
근거를 넣어 결과가 나아졌더라도 원인이 검색 쪽에만 있는 것은 아닐 수 있고, 넣을 문서 자체에서 조항이나 정의가 빠져 있었다면 고칠 곳은 데이터입니다. 이렇게 원인이 데이터로 좁혀지면 데이터를 고친 효과는 되도록 그것만 따로 시험합니다. 문서 구조를 바로잡거나, 용어 정의가 빠지지 않게 하거나, 적용할 계약서 버전을 고르는 변경은 모델과 업무 조건을 비슷하게 맞춘 상태에서 평가해야 하며, 데이터와 모델을 한꺼번에 바꾸면 결과가 좋아져도 무엇 덕분인지 가리기 어렵습니다.
계약서 AI 비서라면 원본 계약서를 넣은 경우와, 관련 조항과 정의가 빠지지 않게 손본 계약서를 넣은 경우를 같은 추출 업무로 비교합니다. 이 비교로 그 데이터 변경을 유지할 가치가 있는지 판단하고, 형식 오류나 모델 쪽 오류는 따로 다룹니다.
Syntitan은 데이터를 정해진 활용 목적에 맞게 준비하고 검증하는 CUBIG의 AI-Ready Data Platform입니다. 모델과 조건은 그대로 두고 준비 전과 후의 데이터만 바꿔 결과를 비교하므로, Syntitan으로 확인하는 것은 「데이터를 고치면 결과가 나아지는가」이고 검색 구조나 모델 학습 여부를 정하는 앞의 실험과는 보는 대상이 다릅니다.
모델에 들어간 자료에서 조항이나 정의가 빠져 실패한 사례가 있다면, 그 자료를 고쳤을 때 업무 결과가 나아지는지부터 시험해 보세요. 준비 전과 후의 데이터를 같은 AI 조건으로 비교하는 방식은 Syntitan 제품 페이지에 정리되어 있습니다.
