3월의 어느 화요일 아침, 한 최고경영자(CEO)가 답변하는 데 30초도 걸리지 않았어야 할 질문을 던졌습니다: 우리가 100만 달러 미만의 책임 제한(liability cap)에 합의한 적이 있는가?

답변은 존재했습니다. 그것은 기록되어 있었고, 서명되었으며, 보관되었고, 내내 공유 드라이브에 놓여 있었습니다. 그것을 찾는 데는 3일이 걸렸고, 제때 찾지 못한 대가는 4만 달러였습니다.

모든 조직에는 그런 화요일의 버전이 존재합니다. 지식은 실재하며, 살아남아 있고, 수백 가지 형식의 수백만 개 파일에 흩어져 있으며, 그날 서류 보관함과 가장 가까이 있었던 사람에 의해 정리되어 있습니다. 조직은 그 안의 누구보다 더 많은 것을 알고 있습니다. 어려운 점은 그 지식에 도달하는 것입니다.

키워드 검색 (Keyword search)이 실패하는 구체적이고 해결 가능한 이유

명백한 첫 번째 해결책은 모든 단어를 인덱싱(indexing)하고 검색하는 것입니다. "liability cap"을 입력하면 "liability"와 "cap"이 포함된 모든 문서를 가져오는 식입니다. 하지만 이것은 실패하며, 그 실패 방식은 정확하게 명명할 가치가 있을 정도로 다양합니다. 왜냐하면 각 실패 방식이 진정한 해결책이 무엇을 해야 하는지를 가리키기 때문입니다.

계약서에는 "liability cap"이라고 적혀 있지 않습니다. 대신 "limitation of liability"라고 적혀 있습니다. 두 구절은 의미는 같지만, 공유되는 키워드는 하나도 없습니다. 검색 결과는 아무것도 반환하지 않고, 당신은 해당 문서가 존재하지 않는다고 결론 내립니다. 검색창은 "그런 계약서가 없다"와 "계약서는 있지만 다른 단어로 분류되어 있다"의 차이를 구분할 수 없습니다.

단어를 맞추는 것은 의미를 맞추는 것이 아닙니다. 직원 핸드북과 공급업체 계약서 전체에서 "termination"을 검색하면 해고, 계약 만료, 그리고 아마도 소프트웨어 라이선스 종료에 관한 단락 등이 단어 빈도수보다 더 의미 있는 기준 없이 나열될 것입니다.

사람들은 키워드가 아니라 질문을 합니다. 아무도 검색 용어로 생각하지 않습니다. 사람들은 "우리가 100만 달러 미만의 책임 제한에 합의한 적이 있는가?"라고 생각합니다. 키워드 엔진은 이것이 질문이라는 사실은 물론, 그 안의 어떤 단어가 중요한지조차 알지 못합니다.

실제로 격차를 줄이는 방법

해결책은 단어를 비교하는 것을 멈추고 의미를 비교하기 시작하는 것입니다. 이를 위해서는 텍스트를 거리(distance)를 측정할 수 있는 무언가로 변환해야 합니다.

임베딩 모델 (embedding model)은 구절을 읽고 수백 개의 숫자로 이루어진 리스트를 반환하며, 해당 구절을 거리가 의미적 유사성을 뜻하는 공간 안에 배치합니다. 연차 (annual leave)에 관한 구절들은 서로 가까운 곳에 위치합니다. 책임 제한 (liability caps)에 관한 구절들은 완전히 다른 어딘가에 위치합니다. 모델은 어떤 문자를 공유하는지가 아니라, 언어가 실제로 어떻게 사용되는지에 기반하여 그들을 그곳에 배치합니다.

from sentence_transformers import SentenceTransformer

...

이제 흥미로운 부분입니다. "직원들이 첫 해에 며칠의 휴가를 받을 수 있나요?"라는 질문을 동일한 공간에 임베딩 (embed)하면, 연차 (annual leave) 구절과 가장 가까운 곳에 위치하게 됩니다. 해당 구절에는 "휴가 (vacation)"라는 단어가 단 한 번도 포함되어 있지 않습니다. 키워드 검색 (keyword search)이 빠졌던 균열이 바로 이 단계에서 메워지며, 이는 두 표현이 같은 의미를 지니고 있기 때문입니다. 모델이 주의를 기울였던 유일한 요소는 바로 그것뿐입니다.

이 모델의 크기는 80MB입니다. GPU나 API 키 없이도 노트북에서 실행됩니다. 이는 생각보다 훨씬 중요한 의미를 갖습니다. 기업용 AI (enterprise AI)에서 마주하는 첫 번째 진지한 질문은 "어떤 모델이 가장 좋은가"가 아니라, "내 데이터가 어디까지 흘러가도 되는가"이기 때문입니다. 로컬 (locally)에서 실행되는 모델은 그 질문에 "어디로도 가지 않는다"라고 답합니다.

아무도 경고해주지 않는 부분

튜토리얼에서 생략하는 내용이 여기 있습니다. 무엇인가를 임베딩하기 전에 반드시 텍스트를 추출해야 하는데, 아카이브 (archive)는 이에 저항합니다.

PDF는 문서가 아닙니다. 그것은 우연히 글자 모양을 만들어내는 일련의 그리기 명령 집합이며, PDF에 텍스트를 요청하는 것은 거절당할 수도 있는 요청입니다. 스프레드시트 (spreadsheet)는 변장을 하고 있는 데이터베이스 (database)입니다. 이를 문자열 (string)로 평탄화 (flatten)하면, 그것이 무엇을 가리키는지 알 수 없는 숫자 행만 얻게 됩니다. 1994년에 스캔된 계약서는 텍스트 레이어 (text layer)가 전혀 없고 그저 종이를 찍은 사진일 뿐이며, 모든 순진한 파이프라인 (pipeline)은 이에 대해 조용히 빈 문자열을 반환하고 다음으로 넘어가 버립니다. 이것이 바로 귀하의 아카이브에서 가장 중요한 문서가 보이지 않게 되는 방식입니다.

텍스트를 추출한 후에는 이를 조각으로 나누어야 합니다. 단순히 500자 단위로 잘라버린다면, 문장 중간에서 단어가 끊겨 "during thei"와 같이 아무런 답변도 할 수 없는 청크 (chunk)가 생성될 것입니다. 문서 자체의 경계(joints)에 맞춰 자르고, 해당 내용이 속해 있던 헤딩 (heading)을 유지한다면, 동일한 구절이 사서가 분류해 놓은 것처럼 식별 가능한 형태가 됩니다.

이 중 어느 것도 흥미로운 AI 부분은 아닙니다. 하지만 이 모든 과정이 흥미로운 AI 부분이 제대로 작동할지 여부를 결정합니다.

긴 버전을 원하신다면
저는 폴더 안의 단일 PDF 파일에서 시작하여 240명의 직원이 있는 가상의 제조업체를 따라, 한 장씩 단계별로 작동하는 검색 시스템 (retrieval system)을 구축하는 과정을 담은 책을 썼습니다. 책에 인쇄된 모든 코드 라인은 인쇄되기 전에 실제로 실행되었습니다.

Chapter 1은 무료이며, 코드 없이도 문제 전체를 설명합니다: https://leanpub.com/learn2rag