회사에서 프로덕트에 대한 챗봇을 만드는 프로젝트에 참여한 적이 있다.
다만 내가 RAG를 직접 구축했다고 말하기는 어렵다. 엔지니어분들이 뒷단의 대부분을 만들었고, 내가 맡은 일은 답변 품질을 검증하고, 예외 케이스에 어떻게 대응할지 정하고, 지식 베이스를 정리하는 일이었다.
그때도 RAG가 무엇인지는 알고 있었다. 하지만 정보가 어떤 방식으로 나뉘고, 질문과 가까운 자료를 어떻게 찾으며, 찾은 자료가 실제 답변으로 이어지는지는 제대로 알지 못했다.
그래서 이번에는 직접 RAG를 구축해봤다.
AI를 잘 활용한다고 말하려면 적어도 그 시작점에 있는 RAG가 어떤 방식으로 돌아가는지는 알고 있어야 하지 않을까라는 생각에서 출발했다.
RAG는 답변보다 검색에서 시작한다
RAG는 Retrieval-Augmented Generation의 줄임말이다. 우리말로는 검색 증강 생성이라고 한다.
쉽게 말하면 AI가 자신이 학습한 내용만으로 답하는 대신, 먼저 별도의 지식 베이스에서 질문과 관련된 정보를 찾고 그 자료를 바탕으로 답변을 만드는 방식이다. OpenAI의 Retrieval 가이드에서도 입력과 의미가 가까운 데이터를 벡터 저장소에서 검색하고, 그 결과를 모델의 응답에 활용하는 구조를 설명한다.
겉으로 보면 데이터베이스의 정보를 찾아 AI에게 전달하는 일처럼 보인다. 그런데 직접 구축해보니 고민해야 할 부분은 그보다 많았다.
문서를 어느 정도 크기로 나눌 것인가, 비슷한 내용이 여러 문서에 있다면 어떤 자료를 먼저 보여줄 것인가, 질문과 어느 정도 관련이 있어야 검색 결과로 인정할 것인가, 근거를 찾지 못했을 때는 답변을 거절할 것인가.
그리고 가장 중요한 질문이 남는다.
검색된 정보가 맞는지는 누가 확인할 것인가?
RAG를 붙였다고 답변이 곧바로 정확해지는 것은 아니다. 잘못된 문서를 검색할 수도 있고, 오래된 정보를 가져올 수도 있으며, 관련 자료를 찾고도 AI가 그 의미를 다르게 해석할 수 있다. 결국 지식 베이스를 관리하고 답변 품질을 확인하는 일이 필요하다.
돌아보면 회사에서 내가 맡았던 품질 검증, 예외 케이스 대응과 지식 베이스 정리는 RAG의 주변 업무가 아니었다. 오히려 RAG가 실제 프로덕트가 되기 위해 꼭 필요한 일이었다.
비용이 우선인가, 품질이 우선인가
처음 RAG를 설계할 때는 비용을 먼저 생각했다.
얼마나 저렴한 모델을 사용할 수 있는지, 검색 결과를 얼마나 적게 전달할 수 있는지, 불필요한 호출을 어떻게 줄일지를 고민했다. 지식 베이스의 크기도 그리 크지 않았기 때문에 굳이 복잡한 구조까지 만들어야 하나라는 생각도 있었다.
지금에 와서는 품질이 조금 더 우선이라는 생각이 든다.
비용을 줄이는 것은 중요하다. 하지만 사용자가 몇 번 질문하지 않는 서비스라면 한 번의 잘못된 답변이 훨씬 크게 느껴질 수 있다. 근거가 없는 내용을 자신 있게 말하거나, 실제로 있는 정보를 찾지 못한다면 RAG를 붙인 이유 자체가 사라진다.
그렇다고 항상 RAG가 필요한 것은 아니다.
지식 베이스가 많지 않고 내용도 자주 바뀌지 않는다면 RAG는 과한 선택일 수 있다. 몇 개의 문서를 프롬프트에 직접 넣거나, 정해진 답변을 제공하는 방식이 더 단순하고 안정적일 수도 있다.
중요한 것은 RAG를 구축했다는 사실이 아니라, 왜 RAG가 필요한지를 설명할 수 있는가다.
문서를 모으는 것과 기억하는 것은 다르다
GeekNews에 소개된 Cerebras의 사내 지식 베이스 사례를 보면 Slack, 코드 저장소와 문서를 한곳에 복사하는 대신 정보가 만들어지는 장소를 연결하고, 검색·권한·감사·분석을 나누어 관리한다. 검색 범위도 회사 전체가 아니라 프로젝트 단위로 좁혔다.
이 사례를 보며 회사의 기억은 문서의 개수로 결정되지 않는다는 생각이 들었다.
문서가 최신인지 알 수 없고, 누가 작성했는지 모르며, 어떤 사람에게 공개해도 되는지 구분되지 않는다면 아무리 많은 데이터를 모아도 믿고 사용할 수 없다. 누군가 잘못된 답변을 발견했는데 지식 베이스를 고치는 경로가 없다면 같은 오류가 계속 반복된다.
결국 회사의 기억에는 정보만 필요한 것이 아니다.
그 정보가 어디에서 왔는지, 지금도 유효한지, 누가 볼 수 있는지, 틀렸을 때 누가 고칠 것인지가 함께 있어야 한다. 그래야 담당자가 바뀌더라도 업무의 맥락이 완전히 사라지지 않는다.