검색 증강 생성(RAG)

01

AI가 모르는 것을 물어보면

어느 회사가 직원들의 질문에 답해 주는 사내 도우미 챗봇을 만들었습니다. 한 직원이 이렇게 묻습니다.

서울 출장 때 호텔비는 1박에 얼마까지 돼요?

이 회사의 출장 규정에는 "숙박비는 1박 12만 원 이내, 단 서울·부산은 15만 원"이라고 적혀 있습니다. 그런데 챗봇은 "1박 10만 원까지입니다"라고 답합니다. 왜 이런 일이 생길까요?

챗봇 안에는 대규모 언어 모델(LLM)이 들어 있습니다. LLM은 인터넷의 글이나 책처럼 공개된 글을 아주 많이 읽고 학습했습니다. 하지만 두 가지는 알 수 없습니다. 하나는 학습을 마친 뒤에 생긴 일입니다. 모델은 학습이 끝난 시점까지의 글만 봤습니다. 다른 하나는 처음부터 공개된 적이 없는 자료입니다. 이 회사의 출장 규정이 그렇습니다.

모르면 모른다고 하면 좋겠지만, LLM은 앞에 놓인 글을 보고 그다음에 올 법한 말을 이어 쓰는 방식으로 답을 만듭니다. 그래서 모르는 질문에도 그럴듯한 문장을 지어냅니다. 사실이 아닌데 사실처럼 말하는 이런 답을 환각(hallucination)이라고 부릅니다.

해결 방법은 생각보다 단순합니다. 질문을 보낼 때 규정 문서의 해당 조항을 같이 붙여 보내면 됩니다. 책을 펴 놓고 보는 오픈북 시험과 비슷합니다. 모델이 규정을 외우고 있을 필요 없이, 눈앞에 놓인 자료를 읽고 답하면 됩니다.

아래 그림은 이 과정을 보여 줍니다. 왼쪽은 이 회사의 규정 문서들, 가운데 틀은 모델에게 보내는 글, 오른쪽은 AI 모델과 모델이 내놓은 답입니다. 처음에는 질문만 보냅니다. 규정 조항을 같이 보내도록 켜 보세요. 찾은 조항이 보내는 글로 옮겨 가고, 답에서 그 조항까지 출처 선이 이어집니다.

이렇게 찾아서(Retrieval), 보내는 글을 보강하고(Augmented), 그걸 바탕으로 답을 만드는(Generation) 방식을 검색 증강 생성, 줄여서 RAG라고 합니다. 2020년에 발표된 연구에서 이 이름이 붙었습니다.

그런데 "관련 조항을 찾아 붙인다"는 말에는 여러 단계가 숨어 있습니다. 크게 보면 질문이 들어오기 전에 미리 해 두는 일과, 질문이 들어왔을 때 하는 일로 나뉩니다.

첫 단계가 왜 "나누기"일까요? 규정집을 통째로 붙이면 되지 않을까요? 규정집이 수백 쪽이라면 사정이 달라집니다.

02

문서를 조각으로 나누기 (청킹)

모델이 한 번에 읽을 수 있는 글의 양에는 한도가 있습니다. 이 한도를 컨텍스트 윈도우라고 부릅니다. 요즘 모델은 한도가 꽤 넉넉하지만, 보내는 글이 길수록 답이 늦어지고 비용도 늘어납니다. 비용은 보통 보내고 받는 글의 양으로 계산하기 때문입니다.

길게 보낸다고 꼭 잘 읽는 것도 아닙니다. 2023년 Liu 등의 연구에서는 긴 글의 처음과 끝에 있는 정보는 잘 쓰는데, 가운데에 묻힌 정보는 자주 놓친다는 결과가 나왔습니다. 수백 쪽 가운데 한 줄을 찾아야 하는 상황이 딱 그렇습니다.

그래서 문서를 미리 작은 조각으로 나눠 두고, 질문이 오면 관련된 조각 몇 개만 골라 보냅니다. 이 조각을 청크(chunk), 나누는 일을 청킹(chunking)이라고 합니다.

문제는 크기입니다. 아래 그림에서 조각 크기를 바꿔 보세요. 각 크기에서 질문과 가장 가까운 조각 하나를 붙였을 때 답이 어떻게 달라지는지 보여 줍니다.

문장 하나씩 잘게 나누면 "숙박비는 1박 12만 원 이내"와 "단, 서울·부산은 15만 원"이 서로 다른 조각이 됩니다. 검색은 숙박비라는 말이 들어간 앞 조각만 가져오고, 모델은 12만 원이라고 답합니다. 거꾸로 장 전체를 한 조각으로 만들면 필요한 내용은 들어 있지만 식비·교통비 조항까지 같이 딸려 옵니다. 글이 길어져 비싸지고, 다른 금액이 답에 섞이기 쉽습니다.

이 예제에서는 조항 하나를 한 조각으로 나눌 때 가장 좋았습니다. 규칙과 그 예외가 한 조항 안에 같이 있기 때문입니다. 정답은 문서마다 다르지만, 기준은 같습니다. 질문 하나에 답하는 데 필요한 내용이 한 조각 안에 다 들어갈 만큼 크게, 그러면서 상관없는 내용은 최대한 빠질 만큼 작게 나눕니다.

나누는 방법

• 고정 크기: 글자 수나 토큰 수(모델이 글을 읽는 단위)로 일정하게 자릅니다. 가장 간단하지만 문장 중간에서 잘릴 수 있습니다.
• 문서 구조대로: 제목, 조항, 문단처럼 문서에 이미 있는 경계를 따라 자릅니다. 규정이나 매뉴얼처럼 구조가 뚜렷한 문서에 잘 맞습니다.
• 뜻이 바뀌는 곳에서: 앞뒤 문장의 뜻이 크게 달라지는 지점을 찾아 자릅니다. 의미 기반 청킹이라고 부릅니다.

어느 방법이든 조각 경계에 걸린 내용이 잘려 나가지 않도록, 앞 조각의 끝부분 몇 문장을 다음 조각 앞에 다시 넣기도 합니다. 이걸 겹침(overlap)이라고 합니다.

조각이 준비됐습니다. 이제 질문이 오면 수천 개 조각 가운데 어떤 걸 붙일지 골라야 합니다. 그런데 직원은 "호텔비"라고 물었고 규정에는 "숙박비"라고 적혀 있습니다. 같은 글자를 찾는 검색으로는 이 조항을 못 찾습니다.

03

뜻을 좌표로 바꾸기 (임베딩)

지도를 떠올려 보세요. 주소를 위도와 경도 두 숫자로 바꾸면, 두 장소가 얼마나 가까운지 숫자로 잴 수 있습니다. 글에도 같은 일을 할 수 있습니다. 글의 뜻을 숫자 몇 개로 바꿔서 좌표처럼 쓰는 겁니다.

이렇게 글을 숫자 목록으로 바꾸는 것을 임베딩(embedding)이라고 하고, 바뀐 숫자 목록을 벡터라고 부릅니다. 이 일은 임베딩 모델이 합니다. 임베딩 모델은 뜻이 비슷한 글에는 비슷한 숫자가 나오도록 학습되어 있습니다. 그래서 "호텔비"와 "숙박비"처럼 글자는 달라도 뜻이 가까우면 좌표도 가까이 찍힙니다.

아래 그림은 규정 문서의 조각들을 임베딩해서 공간에 찍은 모습입니다. 색은 주제입니다. 출장 조각은 출장 조각끼리, 휴가 조각은 휴가 조각끼리 모여 있습니다. 누가 주제를 알려 준 게 아니라 뜻이 비슷해서 저절로 모인 겁니다. 연두색 점이 질문입니다. 질문을 바꿔 보세요.

실제 임베딩은 숫자 2개나 3개가 아니라 수백에서 수천 개로 이루어집니다. 사람이 그런 공간을 그릴 수는 없으니 그림은 3차원으로 줄여서 보여 준 것입니다. 숫자가 많을수록 뜻의 미묘한 차이까지 담을 수 있습니다.

조각의 임베딩은 질문이 오기 전에 미리 다 계산해서 저장해 둡니다. 이렇게 벡터를 모아 두고 빨리 찾을 수 있게 해 주는 저장소를 벡터 데이터베이스(벡터 저장소)라고 합니다. 질문이 들어오면 질문만 그 자리에서 임베딩합니다.

시험에서 헷갈리기 쉬운 점이 하나 더 있습니다. 임베딩 모델은 글을 만들어 내는 모델이 아닙니다. 글을 서로 비교할 수 있도록 숫자로 바꿔 줄 뿐입니다. 답을 쓰는 건 그다음 단계의 LLM입니다.

이제 모든 조각과 질문이 같은 공간 안의 점이 됐습니다. 남은 일은 질문 점에서 가장 가까운 조각 점을 찾는 것입니다.