AI의 유스케이스는 비교적 간단하게 설명할 수 있습니다.

• RAG로 사내 문서에 답변하기
• Agent로 문의 대응을 자동화하기
• 계약서나 매뉴얼을 검색할 수 있게 하기

하지만 이것만으로는 AI 애플리케이션의 설계가 결정되지 않습니다.

예를 들어 「PDF를 RAG에 등록하여 질문에 답변한다」라는 요구사항이 있다고 가정해 봅시다.

여기서 정말로 확인해야 할 것은 RAG를 사용할지 여부가 아닙니다.

어떠한 데이터가 있고, 어떠한 질문에 답해야 하는가입니다.

AI 애플리케이션을 설계할 때는 다음 순서로 생각하는 것이 안정적입니다.

유스케이스를 결정한다
↓
실제 데이터를 확인한다
...

RAG는 검색 대상이 되는 외부 지식과 생성 모델(Generative Model)을 결합하는 메커니즘입니다. 즉, 모델뿐만 아니라 검색 가능한 형태로 지식을 준비할 수 있는지가 전제 조건이 됩니다. (arXiv)

중요한 것은 처음부터 「Chunk Size는 500」, 「Overlap은 100」이라고 결정하는 것이 아닙니다.

데이터와 질문을 보고 나서, Chunk의 경계를 결정하는 것입니다.

「PDF를 지원한다」라는 요구사항만으로는 불충분합니다.

PDF에는 다음과 같은 차이가 있습니다.

PDF를 단순히 텍스트화하면 표의 열 관계, 그림의 화살표, 본문과 주석의 대응 등이 유실될 수 있습니다.

문서의 구조적 요소를 이용한 Chunking은 단순한 단락 분할보다 재무 문서의 RAG 성능을 개선할 수 있다고 보고되었습니다.

또한, Microsoft의 공식 자료에서도 문서 레이아웃을 이용하여 제목, 단락, 표 등의 구조를 추출하고, 구조를 고려하여 Chunk를 만드는 방식을 설명하고 있습니다. (Microsoft Learn)

즉, 처음에 확인해야 할 질문은,

PDF를 지원할 수 있습니까?

가 아니라,

이 PDF 안에서 답변에 필요한 정보는 어떻게 표현되어 있습니까?

입니다.

Excel도 마찬가지입니다.

다음 두 가지는 모두 .xlsx 파일이지만, RAG에서의 취급은 다릅니다.

Excel A
└─ Sheet1: 제품 목록
Excel B
...

확인해야 할 것은 단순히 Excel을 읽어들일 수 있는지 여부가 아닙니다.

• 여러 개의 Sheet가 있는가
• Sheet 간에 참조 관계가 있는가
• 첫 번째 행이 Header라고 단정할 수 없는가
• 병합된 셀이나 수식이 있는가
• 숨겨진 Sheet를 검색 대상으로 할 것인가
• 하나의 질문으로 여러 Sheet를 참조하는가

표 형식의 데이터를 단순한 문자열로 분할하면 열 이름과 값의 관계가 끊어지기 쉽습니다.

표의 행이나 Key-Value 구조를 유지한 Chunking은 고정 길이(Fixed-length) 또는 재귀적 Chunking(Recursive Chunking)보다 검색 성능을 개선할 수 있다는 연구 결과도 있습니다. (arXiv)

Excel에서는 글자 수보다 먼저 다음 단위를 생각해야 합니다.

Workbook
↓
Sheet
...

어디까지를 하나의 「검색 가능한 증거」로 볼 것인가가 중요합니다.

Chunking을 생각할 때는 실제로 답변하고 싶은 질문을 확인합니다.

서비스를 재시작하는 명령어는 무엇입니까?

필요한 정보가 하나의 절차나 코드 블록 안에 포함되어 있을 가능성이 있습니다.

이 경우에는 명령어와 설명을 동일한 Chunk에 남겨두어, 완전 일치 검색(Exact Match Search)이나 키워드 검색(Keyword Search)도 이용할 수 있도록 합니다.

경비 신청이 거절되는 조건과 예외 승인 절차를 알려주세요.

「거절 조건」과 「예외 승인」이 서로 다른 장에 존재할 경우, 하나의 Chunk만으로는 답변할 수 없습니다.

여러 증거를 검색하고 관계를 판단해야 합니다.

APAC 지역에서 매출이 감소한 제품에 대해, 제품 마스터상의 담당 부서도 알려주세요.

이 질문에서는 매출 Sheet와 제품 마스터를 결합해야 답변할 수 있습니다.

이는 단순한 유사도 검색이 아니라, 여러 정보를 단계적으로 취득하는 Multi-hop Question Answering에 가까운 문제입니다. 기존의 RAG는 여러 증거를 취득하여 추론하는 질문을 어려워한다고 보고되고 있습니다. (ar5iv)

또한, 취득한 정보를 모두 긴 Context에 넣는다고 해서 해결되는 것도 아닙니다. 관련 정보가 긴 Context의 중앙에 위치하면 모델의 성능이 저하되는 「Lost in the Middle」 현상도 확인되었습니다. (arXiv)

즉, Chunking은 문서를 기계적으로 분할하는 작업이 아닙니다.

질문에 답하기 위한 증거를 검색 가능한 단위로 변환하는 설계입니다.

RAG를 만들기 시작하기 전에, 최소한 다음과 같은 대응표를 작성합니다.

이 표를 만들면 필요한 기술이 보입니다.

OCR이 필요한가
Layout Parser가 필요한가
표 구조를 유지할 것인가
...

Agent에 대해서도 마찬가지입니다.

"Agent로 조사를 자동화한다"라는 유스케이스만으로는 사용할 Tool (도구), 권한, 정지 조건, 실패 시 처리, 평가 방법을 결정할 수 없습니다.

Anthropic도 처음부터 복잡한 Agent 프레임워크를 도입하는 것이 아니라, 단순하고 조합 가능한 패턴부터 시작할 것을 권장하고 있습니다. (Anthropic)

AI의 유스케이스는 짧은 문장으로 설명할 수 있습니다.

RAG로 문서에 답변하기
Agent로 업무를 자동화하기

하지만 AI 애플리케이션의 어려움은 그 이후에 있습니다.

확인해야 할 사항은 다음과 같습니다.

• 어떤 파일이 있는가
• 파일 안에 무엇이 포함되어 있는가
• 어떤 질문에 답변할 것인가
• 하나의 답변에 몇 개의 증거가 필요한가
• 그 증거를 어떤 단위로 검색할 것인가

RAG의 설계는 Vector Database (벡터 데이터베이스)를 선택하는 것부터 시작하지 않습니다.

실제 데이터와 실제 질문을 확인하는 것부터 시작합니다.

• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv)
• Yepes et al., Financial Report Chunking for Effective Retrieval Augmented Generation
• Liu et al., Lost in the Middle: How Language Models Use Long Contexts (arXiv)
• Tang et al., MultiHop-RAG: Benchmarking Retrieval-Augmented Generation for Multi-Hop Queries (ar5iv)
• Microsoft Learn, Chunk and Vectorize by Document Layout
• Anthropic, Building Effective Agents