RAG 기반 LLM 데이터 생성 시 발생하는 오류와 해결 방법
RAG란?
ChatGPT와 같이 LLM을 활용한 다양한 서비스가 등장했지만, 환각(Halluciation) 현상은 아직도 풀어나가야 할 과제 중 하나로 남아 있습니다. LLM 환각 현상의 해결법 중 하나로 RAG(Retrieval Agumentated Generation, 검색 증강 생성) 방식이 각광받고 있고, 실제로 RAG를 적용해 챗봇을 구현하거나 데이터를 구축하는 사례가 증가하고 있습니다.
RAG는 외부 지식을 기반으로 관련 정보를 검색하여 질문에 대한 답변을 제공하는 방법으로, 특히 지식 집약적인 작업에서 답변의 정확성을 크게 향상시키고, 모델의 환각을 줄이는 것으로 입증되었습니다.
쉽게 설명하면,
① LLM이 질문을 받았을 때 ‘나만의 저장소(이하 DB)’에 질문의 내용을 토대로 검색한 후
② 내가 DB에 올려놓은 데이터 중 적합한 데이터를 모델에 전달하여
③ 답변하게 만드는 것입니다.
사용자는 DB에서 찾은 출처를 인용함으로써, 답변의 정확성을 검증하고 모델 결과물에 대한 신뢰를 높일 수 있습니다. 또한 RAG를 활용함으로써 지식 업데이트와 도메인별 지식 도입이 용이해집니다.
하지만 RAG를 활용한다고 해서 모델 신뢰도를 떨어뜨리는 환각 현상 등의 오류가 100% 해소된다고 보기는 어렵습니다. RAG만의 오류 또한 존재하기 때문입니다. 이번 글에서는 RAG를 활용하여 데이터를 생성할 때 사전에 오류 발생을 줄이는 방법과 오류 발생 시 대처법을 소개하고자 합니다.
데이터 생성 전 RAG 오류 발생률 낮추기
지식 구조화하기
RAG를 도입한다면, 연결된 DB에 데이터를 넣기만 하면 되는 걸까요? 정답은 ‘아닙니다.’
정돈되지 않은 대량의 데이터를 모델에 바로 연결하는 것은 오류로 직결되는 일이기 때문입니다. RAG가 아닌 일반 학습데이터 구축에서도 그렇듯, 도메인별/데이터별 특성에 맞게 ‘지식 구조화’를 거쳐 목적에 적합한 데이터 형태로 바꾸는 사전 작업이 필요합니다. RAG를 위한 데이터 지식 구조화는 다음의 단계를 거칩니다.
- 적용할 모델 분석하기
모델에 맞는 데이터 수량이나, 오류가 발생하지 않는 적정 글자 수 등을 파악하는 과정입니다. 모델 분석이 선행되지 않는다면 적합하지 않은 자료가 학습에 쓰이게 되어 오류율이 높아집니다. - 학습할 자료 분석하기
모든 자료를 모델에 학습시킬 수는 없습니다. 필요하지 않은 자료일 수도 있고, 학습에 적합하지 않은 형태일 수도 있기 때문입니다. 자료의 형태, 분량, 수량, 핵심 내용 등을 분석해 ‘자료 분류표’를 구성합니다. 이를 토대로 필수 자료만 빠르게 학습시키면 효율도 높아집니다. - 데이터 분류체계 구성하기
가지고 있는 자료로 어떤 데이터를 만들 것인지(데이터 정의), 데이터를 어떤 목적으로 사용할 것인지에 따라 분류 체계는 다르게 구성됩니다. 예를 들어, 아티스트 페르소나 챗봇을 구현한다면 사용자는 아티스트의 신상 정보부터 취미, 지인 관계, 활동 내용 등을 ‘팬’의 입장에서 질문하게 되겠죠. 이런 챗봇을 위해서는 팬이 할 법한 질문과 아티스트가 할 법한 답변을 담은 QA 데이터가 필요합니다. 이때 곧바로 QA 데이터를 구축하는 것이 아니라 질문의 분류 또는 답변의 분류 체계를 만들어 데이터셋에 포함하는 것이 좋습니다. 분류 체계를 만들면 어떤 분류에 대한 수요가 가장 많았는지 추적이 가능하기 때문입니다. 세부적으로는 질문과 답변 데이터의 분량, 문체, 문장부호 사용 여부 등을 모델 학습에 적합한 형태로 확정해야 합니다.
이처럼 데이터의 목적 및 대상과 연관성이 높은 자료들을 바탕으로 사전에 ‘지식 구조화’를 수행한다면 오류 발생을 줄일 수 있습니다. 10대 학생을 대상으로 하는 데이터를 만든다고 가정한다면 적용할 모델을 분석한 후에 ‘학교생활’, ‘아이돌’, ‘SNS’, ‘진로 또는 진학’, ‘교우관계’ 등 10대 학생의 관심도가 높은 내용이 포함된 자료를 분석하여 분류체계를 구성합니다. 질문을 구성할 때 10대 학생들이 자주 쓰는 표현, 줄임말 등 말하기 특징, 대화 패턴 등을 포함한다면 더 자연스러운 답변을 구축할 수 있겠죠.
프로그래밍으로 보완하기
지식 구조화 외에도 데이터 생성 이전에 프로그래밍을 통해 오류를 줄일 수 있습니다. 보통 오류는 모델이 데이터를 잘못 이해했을 때 발생하는 것으로 아래 방식을 도입하면 모델의 데이터 이해도를 높일 수 있습니다.
- Query expansion
LLM을 활용해 데이터 입력 범위를 확장해 오류율을 낮추는 방법입니다. 예를 들어 “뽀로로의 생일은 언제야?”라는 질문을 가정해 봅시다. Query expansion은 “뽀로로의 탄생일은 언제야?”, “뽀로로의 태어난 날은 언제야?”처럼 ‘생일’과 동일한 의미를 가지는 단어셋을 미리 구성하고 생일에 대한 질문을 받았을 때 ‘탄생일’, ‘태어난 날’이 포함된 자료에서 답을 찾을 수 있게 하는 것입니다. 사전에 수요가 많을 것으로 생각되는 단어셋을 구성하여 Query expansion을 적용한다면 모델이 데이터를 잘못 이해하는 경우의 발생을 줄일 수 있습니다. - Query decomposition
여러 키워드가 동시에 입력된 경우 오류율을 낮추는 방식입니다. 입력된 데이터의 핵심 키워드를 ‘분해’하여 인식하게 하는 것인데요. “뽀로로가 태어난 날이랑 태어난 곳 알려줘”처럼 생일과 출생지라는 두 가지 이상의 키워드가 포함된 데이터가 입력되었을 때 “뽀로로의 태어난 날”과 “뽀로로의 태어난 곳” 두 가지를 각각의 개념으로 이해하게 하는 것입니다. 여러 키워드를 포함한 데이터가 입력되더라도 키워드에 대한 답을 각각의 자료에서 찾아낼 수 있으므로 오류율을 낮추는 데 도움이 됩니다.
이외에도 HyDE, Query routing: Step back prompting, Query structuring 등 오류율을 줄이는 프로그래밍 방법들이 존재합니다. 하지만 이런 과정을 거친 후에도 오류가 발생한다면 사후에 유형에 맞게 보정하는 과정을 거쳐야 합니다.
데이터 생성 후 RAG 오류 해결하기
RAG-LLM 오류 유형
- 질문 오류
‘질문 오류’는 RAG로 질문과 답변을 모두 생성한 경우에 발생할 수 있는 오류에 해당합니다. DB 내 자료를 출처로 하여 질문과 답변을 모두 생성했을 경우, 뒤에 소개할 ‘답변 오류’ 유형과 동시에 발생하는 경우가 많습니다. 질문 자체가 잘못 생성되었기 때문에, 답변이 잘못 출력되는 경우가 빈번하게 발생합니다. 세부 내용으로는 다음과 같습니다.
- 오탈자가 포함되어 질문을 이해하기 어려운 경우
- 신뢰도 또는 완성도에 긍정적인 영향을 주지 못할 정도로 내용이 지엽적인 경우
- 명확한 대상, 주체 등이 누락되어 질문의 목적이 모호해진 경우
- 답변 오류
‘답변 오류’는 모델의 신뢰도와 완성도를 낮추는 치명적인 오류 유형입니다. 질문이 올바르게 생성되었어도, 자료 내에서 답변을 잘못 생성한 경우가 이에 해당합니다.
이해하기 쉽게 한 아티스트의 페르소나 챗봇을 RAG 기반 데이터 생성을 통해 학습시켜 구현한다고 가정해 보겠습니다. DB에는 당연히 해당 아티스트의 기본 정보부터 아티스트가 자주 쓰는 말, 표현 등이 같이 저장될 것입니다. 아티스트의 일대기를 담은 A 자료와 아티스트의 어록이 담긴 B 자료를 DB에 위치시킵니다.
A 자료와 B 자료의 작성 주체가 다르거나 작성 맥락이 다르다면 두 자료 간의 정보 차이로 인해 같은 질문을 해도 ‘다른 답변’을 하는 답변 오류 유형이 발생할 수 있습니다. QA 데이터셋을 구축하는 상황 예시를 들어보겠습니다.
총 500쌍의 QA 데이터셋을 만든다면, A 자료를 토대로 생성한 10번째 질문과 B 자료를 토대로 생성한 10번째 질문의 내용은 같을 수 있습니다. 두 자료가 동일한 사건이나 토픽을 다루고 있는 부분이 있을 수 있기 때문입니다. 하지만 같은 내용이라도 자료에 따라 표현이나 내용이 다를 수 있으므로 답변이 달라질 수 있습니다. 다른 표현이라도 해당 내용이 사실이 맞다면 문제가 되지 않겠지만, 틀린 내용이 포함된다면 명백한 오류가 됩니다.
이 유형은 특히 사람의 눈으로 가려내기 어려운 유형입니다. 대부분은 질문과 답변의 맥락이 자연스럽게 이어지기 때문입니다. 아티스트 T가 팬 미팅을 통해 회사 정책 중 C 정책에 반대함을 표했으나, D 정책에는 별다른 의견을 보태지 않은 상황을 가정해 보겠습니다. 아래 표와 같이 질문과 답변을 생성했을 때 질문과 답변의 맥락에는 문제가 없지만, 답변 오류는 발견할 수 있습니다. D 정책에 반대를 표했다는 내용을 자료에서는 찾을 수 없는데, D 정책에 반대했다고 출력되었기 때문입니다. 세부 내용은 다음과 같습니다.
- 답변 내 일부 내용이 출처와 다르게 작성된 경우
- 동일한 질문임에도 출처에 따라 다른 내용이 작성된 경우(DB에 여러 출처가 존재할 때)
- 출처에서 찾아볼 수 없는 내용으로 작성된 경우
- 출처의 내용을 잘못 요약한 경우
- 비연관성 오류
세 번째 유형은 질문과 답변의 흐름이 유려하여, 쉽게 놓칠 수 있는 위험이 있는 ‘비연관성 오류’입니다. 다시 아티스트 T의 챗봇을 RAG 방식으로 구현한다고 가정해 봅니다. 아티스트 T의 정보가 담긴 여러 건의 자료를 저장한 후, 이를 토대로 학습에 필요한 QA 데이터셋을 구축합니다. 이때, 해당 자료에 아티스트 T의 정보 외의 주변 인물의 정보 등이 포함된다면 RAG에서는 주변 인물의 정보 또한 아티스트 T의 정보로 받아들입니다. 이 주변 인물의 정보를 토대로 질문과 답변을 구축할 경우 비연관성 오류가 발생하게 됩니다. 세부 내용은 다음과 같습니다.
- 데이터 생성의 목적과 부합하지 않는 문장을 기반으로 질문과 답변이 작성된 경우(다른 인물, 페르소나와 연관 없는 사건 등)
- 질문-답변 매핑 오류
마지막 유형은 눈에 띄는, 굉장히 단순한 오류인 ‘질문-답변 매핑 오류’입니다. 비연관성 오류에 해당하지 않는 질문이 올바르게 출력되었음에도 질문에 전혀 맞지 않는 엉뚱한 답변이 출력된 경우가 해당합니다. 사람이 봤을 때는 너무나도 맥락이 맞지 않기 때문에 쉽게 찾아낼 수 있는 오류로 볼 수 있습니다. 오류가 생기는 이유는 다양하지만, 질문의 핵심 키워드에 집중하여 답변을 생성하였을 경우에 발생하기도 합니다. 세부 내용은 다음과 같습니다.
- 질문의 의도에 부합하지 않는 답변이 생성된 경우
RAG-LLM 오류 해결 방법
환각 현상을 피하려고 RAG 기반으로 데이터를 생성하더라도 이처럼 다양한 오류가 발생합니다. 그렇다고 RAG 방식을 포기해야 하는 것은 아닙니다. 이러한 오류들은 생성 후 데이터 검수 과정을 통해 해결이 가능하기 때문입니다. RAG 관련 프로젝트를 진행하며 학습한 몇 가지 노하우를 소개합니다.
1. 단계별 검수를 진행한다
‘1차 검수-2차 검수-최종 검수’ 등을 나누어 각 검수 단계에서 확인해야 할 내용을 명확히 하면 도움이 됩니다. 오류 유형마다 집중해서 확인해야 할 내용이 다르기 때문에, 순서를 설정하여 단계별 검수를 진행하는 게 좋습니다. ‘질문-답변 매핑 오류’와 같이 자료를 확인하지 않고, 눈으로 읽는 것만으로도 확인할 수 있는 오류 유형을 1차로 검수하면 시간을 효율적으로 운영할 수 있습니다. 해당 오류 유형이 대다수일 경우에는 학습 자체가 잘못된 것이므로, 다시 학습하는 과정이 필요합니다.
2. 오류 유형을 라벨링 한다
생성된 데이터에 오류 유형을 라벨링 하면 보다 효율적인 검수가 가능합니다. 위에서 언급한 예시를 가져온다면 아래와 같이 오류 유형을 라벨링 할 수 있습니다. 라벨링 후 같은 오류 유형을 묶어 확인하면 작업에 드는 리소스를 줄이면서도 정확한 검수가 가능해집니다.
3. 생성된 데이터의 ‘출처’를 표기한다
만약 여러 건의, 페이지 수가 많은 자료에 RAG를 적용한다면 출처 표기가 없을 경우 검수에 큰 어려움이 있을 것입니다. 해당 데이터셋이 어떤 자료에서 생성되었는지 알 수 없기 때문에, 몇백 페이지가 넘는 자료를 일일이 확인해 가며 검수를 진행해야 할 테니까요. 아래와 같이 답변의 출처를 표기한다면 해당 페이지를 중심으로 사실 여부를 확인할 수 있습니다. 생성할 때부터 답변의 출처가 데이터에 자동으로 입력되게 할 수도 있겠죠.
RAG 기반 LLM, 성공적으로 도입하려면
최근 들어 그 한계에 대한 논의가 확산되며 RAG 종말론도 등장하긴 했지만, LLM의 환각 현상을 해결하기 위해 서비스 수준에서 적용 가능한 방법으로는 아직 RAG가 대세인 듯합니다.
RAG 도입이 만능은 아니지만, 발생할 수 있는 오류를 미리 파악하고 대처한다면 높은 모델 성능을 기대할 수 있습니다. 앞서 소개한 RAG 오류 유형과 대처법 외에도, RAG 기술 자체에 대한 이해를 바탕으로 사전에 꼼꼼한 데이터 기획과 설계를 선행한다면 보다 효율적으로, 사용자가 만족하는 서비스 개발이 가능할 것입니다.
Reference
한국어의 특성을 끝없이 연구하고, 이를 데이터에 반영하는 PM 박다혜입니다.
TEXTNET 소개
지금의 딥러닝을 있게 한 AI Guru 제프리 힌튼의 데이터셋 'ImageNet'에 어원을 둔 TEXTNET은 (주)스피링크가 운영하는 AI/챗봇을 위한 텍스트 데이터 설계 및 구축 서비스입니다.
TEXTNET은 언어학, 심리학, 전산언어학 석·박사를 포함한 전문 인력으로 구성된 언어전문가 그룹으로서, 고객사의 니즈에 부합하는 텍스트 데이터를 설계·가공·구축하고 내부 R&D를 통해 설계 방식을 지속적으로 개선하여 최적의 데이터 설계 방법을 제안합니다. 프로젝트 목적에 따라 적합한 숙련 작업자를 선별하여 투입하고, 체계적이고 효율적으로 고품질의 학습데이터를 생산합니다.
TEXTNET은 삼성, LG, KT, SK 등 유수 대기업의 데이터 구축 파트너로 함께하며 금융, 마케팅, 콘텐츠, 메타버스, 서비스 기획, CS 등 다양한 도메인을 다루고 있습니다.