요약: RAG 청킹은 콘텐츠를 의미 있는 맥락으로부터 잘라낼 때 실패합니다. 하나의 청크는 제목(headings), 테이블 헤더(table headers), 소스 ID(source IDs), 타임스탬프(timestamps), 화자 레이블(speaker labels), 미디어 속성(media traits) 및 보안 메타데이터(security metadata)를 보존해야 합니다. 좋은 파싱과 청킹은 모델이 내용을 보기 전에 검색된 증거를 이해할 수 있게 만듭니다.

대부분의 RAG 튜토리얼은 청킹에 몇 분을 할애한 후 임베딩(embeddings)으로 넘어갑니다. 하지만 실제 운영 환경에서 청킹이야말로 검색 품질이 결정되거나 실패하는 지점인 경우가 많습니다.

모델은 검색 전에 손상된 증거를 사용할 수 없습니다. 만약 테이블 행이 헤더를 잃거나, 스크립트가 화자를 잃거나, 글머리 기호가 상위 제목을 잃는다면, 리트리버(retriever)는 관련 있어 보이는 텍스트를 찾을 수는 있지만 답변을 뒷받침할 수 없는 텍스트일 수 있습니다.

핵심 요약:

• 청킹은 검색 설계(retrieval design)의 문제입니다. 단순한 정리 작업이 아닙니다.
• 목표는 동일한 크기의 텍스트가 아닙니다. 독립적으로 존재할 수 있는 증거를 확보하는 것이 목표입니다.
• 파싱 품질은 임베딩 품질만큼 중요합니다.

벡터 검색을 사용하는 RAG 애플리케이션이 청킹으로 인해 망가지는 이유는 무엇인가요?

요약: 경계가 의미를 무시할 때 청킹은 RAG를 망가뜨립니다. 고정 크기 청크는 문장을 분리하고, 글머리 기호를 제목에서 분리하며, 테이블을 중간 행에서 자르고, 숫자를 레이블에서 분리할 수 있습니다. 그러면 리트리버는 의미론적으로 가깝지만 불완전한 조각들을 반환합니다.

흔한 실패 사례는 기술적으로 관련성은 있지만 쓸모없는 청크입니다. 예를 들어,

짧은 답변: 검색된 모든 테이블 조각(fragment)에 테이블 헤더(header), 행 레이블(row label), 시트 이름(sheet name), 그리고 단위(unit)를 함께 유지하세요. 하나의 행이 서로 연결되지 않은 숫자들의 목록이 되도록 방치해서는 안 됩니다. 만약 테이블이 답변의 핵심이라면, 텍스트 표현(text representation)과 직접 쿼리할 수 있는 구조화된 필드(structured fields)를 함께 저장하세요.

테이블은 그 의미가 관계적(relational)이기 때문에 다루기 어렵습니다. 값 12는 컬럼 이름(column name), 행 레이블(row label), 단위(unit), 그리고 때로는 앞선 섹션(section) 없이는 아무런 의미가 없습니다.

테이블 전략을 사용하세요:

핵심 요약:

• 테이블 RAG는 종종 텍스트 검색(text retrieval)과 구조화된 쿼리(structured querying)가 모두 필요합니다.
• 헤더를 의도적으로 반복하세요. 근접성(proximity)에만 의존하지 마세요.
• 인용(citation)이 실제 출처를 가리킬 수 있도록 출처(provenance)를 보존하세요.

PDF는 어떻게 파싱(parse)해야 하나요?

짧은 답변: PDF를 깨끗한 문서가 아닌 레이아웃 아티팩트(layout artifact)로 취급하세요. 가능한 경우 텍스트, 헤더(heading), 읽기 순서(reading order), 테이블, 페이지 번호, 그리고 소스 좌표(source coordinates)를 파싱하세요. 임베딩(embedding)하기 전에 파싱 결과물을 테스트하세요. 잘못된 PDF 추출은 모든 후속 검색(retrieval) 방법의 성능을 실제보다 더 나쁘게 보이게 만들 수 있기 때문입니다.

PDF는 다중 컬럼 레이아웃(multi-column layouts), 각주(footnotes), 테이블, 캡션(captions), 스캔된 페이지, 그리고 끊어진 읽기 순서를 가질 수 있습니다. 만약 파싱 과정에서 정책 문서가 뒤섞인 텍스트로 변한다면, 임베딩은 그 엉망인 상태를 충실하게 인덱싱(index)할 것입니다.

프로덕션급 파서(parser)는 다음과 같은 결과물을 생성해야 합니다:

• 깨끗한 텍스트
• 읽기 순서
• 테이블 경계(table boundaries)
• 헤더 및 계층 구조(hierarchy)
• 페이지 참조
• 필요한 경우 이미지 캡션 또는 추출된 설명
• 인용을 위한 소스 ID(source IDs)

핵심 요약:

• 추출 품질이 확인될 때까지는 검색(retrieval) 벤치마크를 수행하지 마세요.
• 인용을 위해 페이지 및 소스 참조를 유지하세요.
• 테이블, 스캔된 페이지, 다중 컬럼 레이아웃이 포함된 챌린지 세트(challenge set)를 사용하세요.

스크립트(transcript)와 미디어 요약은 어떻게 청킹(chunk)해야 하나요?

짧은 답변: 타임스탬프(timestamps), 화자 라벨(speaker labels), 정제된 텍스트(cleaned text), 요약 필드(summary fields), 그리고 원문 참조(raw references)를 함께 유지하세요. 비디오 또는 크리에이터 검색의 경우, 벡터(vectors)를 사용하여 결과를 순위 매기기 전에 추출된 특성(traits)을 구조화된 메타데이터(metadata)로서 평가해야 합니다.

원문 스크립트(Raw transcripts)는 길고 반복적이며 불필요한 말(filler)로 가득 차 있습니다. 요약본만 저장하면 정확한 인용구를 놓치게 됩니다. 실질적인 방법은 두 가지를 모두 사용하는 것입니다: 검색(retrieval)을 위한 정제된 청크(cleaned chunks), 감사를 위한 소스 타임스탬프(source timestamps), 그리고 탐색을 위한 요약(summaries) 또는 주제(topics)를 활용하는 것입니다.

미디어 RAG의 경우, 추출된 특성(extracted traits)을 테스트해야 합니다. 만약 애플리케이션이 "곱슬머리 크리에이터" 또는 "42분 지점의 리스크 논의"를 찾아내야 한다면, 해당 라벨들에 대한 평가 세트(evaluation set)가 필요합니다. 벡터 유사도(Vector similarity)는 예/아니오(yes/no) 방식의 특성 탐지기가 아닙니다.

핵심 요약:

• 화자(Speaker) 및 타임스탬프 메타데이터는 증거의 일부입니다.
• 검색 시 정제된 텍스트를 사용하더라도 원문 참조(raw references)를 저장하세요.
• 해당 특성으로 순위를 매기기 전에 추출된 미디어 특성을 평가하세요.

Oracle AI Database로 이를 어떻게 구현하나요?

짧은 답변: Oracle AI Database를 사용하여 청크(chunks), 임베딩(embeddings), 메타데이터(metadata), 그리고 검색 필터(retrieval filters)를 가깝게 유지하세요. 텍스트 처리 및 청킹 워크플로에는 DBMS_VECTOR_CHAIN을 사용하고, 임베딩 및 유사도 검색(similarity search)에는 Oracle AI Vector Search를 사용하며, 어휘적(lexical) 검색과 의미적(semantic) 검색이 모두 중요할 때는 하이브리드 검색(hybrid search)을 사용하세요.

유용한 문서 및 실행 가능한 자산:

• DBMS_VECTOR_CHAIN
• Oracle AI Vector Search User's Guide
• Understand Hybrid Search
• RAG evaluation notebook: oracle_rag_with_evals.ipynb

핵심 요약:

• 청크 텍스트 (chunk text)와 메타데이터 (metadata)를 동일한 관리된 검색 경로 (governed retrieval path) 내에 유지하세요.
• 검색 결과의 변화를 비교할 수 있도록 청킹 설정 (chunking configuration)을 버전 관리하세요.
• 테이블, PDF, 스크립트 (transcripts), 미디어는 각각 실패하는 양상이 다르므로 별도로 테스트하세요.

다음 단계로 무엇을 해야 하나요?

청크 크기 (chunk size)를 튜닝하기 전에 청킹 평가 세트 (chunking evaluation set)를 구축하세요. 실패한 사용자 질문을 가져와 검색된 청크들을 조사하고, 누락된 증거가 파싱 문제 (parsing problem), 경계 문제 (boundary problem), 메타데이터 문제 (metadata problem), 또는 검색 순위 문제 (retrieval-ranking problem)인지 식별하세요. 그러한 진단은 모델을 변경하고 코퍼스 (corpus)가 개선되기를 바라는 것보다 훨씬 빠릅니다.