RAG 시스템이 틀렸거나 절반만 맞는 답을 내놓을 때, 대개 그 원인은 모델이 아니다. 청킹이다. 답을 담고 있는 구절이 검색된 컨텍스트에 아예 들어오지 못했다면, 어떤 모델도 그 정보로 답할 수 없다. 프롬프트를 아무리 튜닝해도 바뀌지 않는다. 청킹은 애초에 무엇이 검색될 수 있는지를 결정한다. 그래서 가장 먼저 점검해야 할 것이면서도, 대부분의 팀이 가장 마지막에 들여다보는 것이다.

Amazon Bedrock Knowledge Bases는 데이터 소스를 생성할 때 청킹 전략을 선택하게 한다. 이 단 하나의 선택이 조용히 검색 품질의 상한선을 결정한다. 이걸 잘못 고르면 몇 주 동안 임베딩 모델이나 리랭커, LLM을 탓하며 시간을 쓰게 되는데, 실제 문제는 문서를 어떻게 자르느냐에 있다.

왜 청킹이 핵심 결정인가

검색은 문서가 아니라 청크 단위로 동작한다. 각 청크는 벡터로 임베딩되고, 쿼리 시점에 질문과 가장 가까운 상위 k개의 청크를 가져온다. 청크 크기에서 두 가지 실패 양상이 곧바로 따라온다.

청크가 너무 크면 임베딩이 희석된다. 네 개의 하위 주제를 다루는 2000토큰짜리 청크는 그 네 가지의 평균에 해당하는 벡터 하나를 만들어내고, 결국 모든 것과 약하게 매칭되고 어느 것과도 강하게 매칭되지 않는다. 정답에 가까운 청크가 근접 오답들 아래 묻혀버린다. 반대로 청크가 너무 작으면 맥락이 끊긴다. 예시에서 분리된 정의, 경고에서 분리된 단계는 깔끔하게 검색되지만 그것을 유용하게 만들어주던 주변 텍스트 없이 도착한다. 답이 기술적으로는 존재하지만 실질적으로는 불완전한 상태다.

청킹 전략의 역할은 의미 있는 경계에서 잘라, 각 청크가 하나의 완결된 아이디어가 되도록 만드는 것이다. 답을 하기에 충분히 독립적이면서, 순위를 매기기에 충분히 구체적이어야 한다.

Bedrock이 제공하는 세 가지 전략

고정 크기 청킹

N토큰마다 약간의 오버랩을 두고 자른다. 기본값이자 가장 저렴한 방식이며, 주제 전환이 완만한 균일한 산문형 콘텐츠에는 괜찮다. 반면 구조화된 문서에는 특히 나쁘다. 토큰 카운터가 도달하는 아무 지점에서나 자르기 때문이다: 표 중간, 리스트 중간, 제목과 그 제목이 소개하는 문단 사이 같은 곳들이다. 오버랩이 피해를 완화하지만 없애지는 못한다. 코퍼스가 균질하고 기준선을 원할 때 고정 크기 청킹을 선택하라. 그것이 기본값이라서가 아니라.

시맨틱 청킹

의미 기준으로 자른다. 시맨틱 청킹은 인접한 문장 사이의 임베딩 유사도를 측정해서 주제가 바뀌는 지점에서 새 청크를 시작한다. 그래서 경계가 고정된 토큰 수가 아니라 아이디어 사이에 떨어진다. 이것은 FAQ, 지식 문서, 각 답변이나 개념이 온전히 유지되기를 바라는 혼합형 산문 같은 다양한 콘텐츠에 적합한 기본 선택이다. 청킹하면서 임베딩도 함께 수행하기 때문에 인덱스 구축 비용이 더 들지만, 이질적인 코퍼스에서의 검색 품질 차이가 그 비용을 지불할 이유다.

계층형 청킹

부모와 자식 청크를 만든다. 작은 자식 청크는 임베딩되어 정밀한 검색에 매칭되지만, 실제로 모델에 반환되는 것은 더 큰 부모 청크다. 그래서 구체성 기준으로 순위를 매기고 맥락을 갖춘 상태로 답할 수 있다. 이것은 기술 매뉴얼, 법률 계약서처럼 절과 하위 절이 있는 진짜 구조를 가진 문서에 어울린다. 쿼리는 좁은 조항 하나에 히트하지만 모델이 그것을 올바르게 사용하려면 주변 절이 필요한 경우다. 가장 다루기 까다롭지만, 문서에 활용할 만한 진짜 계층 구조가 있을 때 가장 적합하다.

모델을 탓하기 전에 검색을 평가하라

가장 유용한 습관은 검색의 질문과 생성의 질문을 분리하는 것이다. 프롬프트를 만지거나 모델을 바꾸기 전에 딱 하나만 물어라: 실제 질문 집합에 대해, 답을 담은 청크가 검색된 컨텍스트에 나타났는가?

  • 작은 평가 세트를 만들어라: 실제 질문 30개에서 50개, 각각 답을 담은 원본 구절과 함께.
  • 검색만 실행하라. 각 질문에 대해 정답 구절이 상위 k개 결과에 나타나는지 확인하라. 그 적중률이 여러분의 검색 상한선이다.
  • 정답 구절이 검색되지 않는다면 생성 품질은 무관하다. 고칠 것은 청킹, 임베딩, top-k이지 모델이 아니다.
  • 검색이 안정적으로 올바른 구절을 표면화한 후에야 모델이 그것을 어떻게 활용하는지 작업하는 것이 의미가 있다.

대부분의 팀은 이 단계를 건너뛰고 곧장 프롬프트 엔지니어링으로 뛰어든다. 검색 적중률 측정만 했으면 오후 반나절 만에 찾을 수 있었을 문제에 그렇게 오래 붙잡혀 있는 이유다. 검색이 절반의 확률로 답을 놓친다면, 그것은 모델 탈을 쓴 청킹 문제다.

실전에서 시작하는 방법

일반 지식 콘텐츠는 시맨틱 청킹으로 시작하고, 문서에 명확한 절 구조가 있고 답이 주변 맥락에 의존할 때는 계층형으로 옮겨가라. 속도와 단순함을 원하는 크고 균일한 산문에만 고정 크기를 유지하라. 그런 다음 검색 적중률을 측정하고, 변수 하나를 바꾸고, 다시 측정하라. 청킹은 한 번 설정하고 잊어버릴 수 있는 값이 아니다. 여러분의 RAG 시스템이 쓸 만한지 여부에 가장 큰 영향을 미치는 다이얼이다.

핵심 요약

RAG 품질은 모델이 실행되기 전, 문서를 청크로 자르는 순간에 결정된다. 고정 크기는 기준선이고, 시맨틱은 혼합 콘텐츠에 합리적인 기본값이며, 계층형은 구조가 중요할 때 승리한다. 먼저 실제 질문 세트로 검색 적중률을 측정하라. 답이 애초에 컨텍스트에 들어오지 않았다면, 모델은 처음부터 문제가 아니었기 때문이다.

다음으로 읽을 글

대규모 벡터 검색을 운영하는 스토리지와 인프라 측면은 ercan.cloud의 클라우드 필드 노트에 있고, 허브는 ercanermis.com이다.