생명과학 분야의 수많은 RAG 배포 사례가 동일한 계층에서 실패를 겪습니다. 임베딩 모델 때문도 아니고, 벡터 데이터베이스 때문도 아니며, LLM 때문도 아닙니다. 실패의 원인은 바로 청킹(Chunking) 단계, 즉 40페이지 분량의 SOP(표준작업지침서)나 120페이지에 달하는 배치 제조 기록서가 검색 가능한 조각으로 잘리는 바로 그 지점에 있습니다.

기본적인 접근 방식은 대개 다음과 같습니다:

PDF → Split every 500 tokens → Embed → Vector DB

이 방식은 위키피디아 같은 일반 텍스트 문서에는 잘 작동합니다. 그러나 GMP 규제 문서에 적용하는 순간 규제적 재앙을 초래합니다.

고정 크기 청킹이 GxP 문서를 파괴하는 이유

전형적인 SOP 구조를 살펴보겠습니다:

1.0 Purpose
2.0 Scope
3.0 Responsibilities
4.0 Materials
5.0 Procedure
    5.1 Preparation
    5.2 Cleaning
    5.3 Verification
6.0 Deviations
7.0 References

500토큰 기준 분할기는 섹션 4.0의 중간 어딘가를 자르게 됩니다. 청크 1은 “Responsibilities — Operators shall…”(책임 — 작업자는…)로 끝나고, 청크 2는 “5.2 Cleaning — Spray IPA…”(5.2 세척 — IPA를 분사하여…)로 시작됩니다.

이때 사용자가 다음과 같이 질문한다면 어떻게 될까요?

“세척 검증은 누가 승인하나요?”

검색기(Retriever)는 세척 절차 단계가 담긴 청크 2를 반환합니다. 하지만 승인 권한자는 청크 1의 ‘책임(Responsibilities)’ 섹션에 정의되어 있었습니다. 결국 올바른 답을 찾을 수 없게 됩니다. 이는 LLM이 환각(Hallucination)을 일으켰기 때문이 아니라, 청킹 전략이 전후 맥락(Context)을 끊어버렸기 때문입니다.

이것이 바로 **의미적 파편화(Semantic Fragmentation)**이며, 규제 대상 문서에 일반적인 RAG 파이프라인을 그대로 적용할 때 발생하는 가장 흔한 기본 실패 유형입니다.

배치 제조 기록서(Batch Record)의 경우 문제는 더욱 심각해집니다. 단순한 텍스트 분할기는 “배치 번호: 12345”를 한 청크에 넣고 “제조일자: 2024-01-15”를 다른 청크로 분리해 버립니다. 규격 테이블의 중간 행을 잘라 “온도”와 “15–20°C”를 서로 다른 청크로 쪼개기도 합니다. 또한 “버전 1 — 오탈자 수정”과 같은 개정 이력 항목을 핵심 공정 파라미터(Critical Process Parameters)와 나란히 임베딩하여 벡터 공간을 오염시킵니다.

핵심 통찰: 문서 유형마다 서로 다른 청킹이 필요합니다

생명과학 RAG를 구축할 때 가장 중요한 깨달음은 단 하나의 청킹 방식으로는 모든 문서 유형을 처리할 수 없다는 점입니다. SOP는 계층 구조를 갖추고 있습니다. 일탈(Deviation) 보고서는 서사적 조사 기록입니다. 배치 제조 기록서는 서명이 포함된 구조화된 데이터입니다. CAPA(시정 및 예방조치)는 근본 원인과 연결된 조치 항목 추적표입니다. 작업 지침서(Work Instructions)는 순차적인 단계별 목록입니다.

각 문서 유형은 저마다 다른 전략을 요구합니다:

문서 유형 고유 구조 최적의 청킹 단위
SOP 계층적 번호 매기기 섹션 상위 헤딩 브레드크럼을 포함한 섹션 또는 하위 섹션
작업 지침서 (Work Instruction) 순차적인 세부 단계 개별 단계 또는 2–3개 단계 묶음
일탈 (Deviation) 구조화된 메타데이터 + 서술형 필드 필드당 하나의 청크 (발생 사건, 근본 원인, 영향, 조치/처리)
CAPA 조치 테이블 + 근본 원인 서술 조치 항목당 하나의 청크, 근본 원인 분석(RCA) 서술용 별도 청크
배치 제조 기록서 (Batch Record) 표 형태, 양식 기반, 시계열 순서 컬럼 헤더가 반복 포함된 행 그룹

SOP 청킹: 구조 인식이 필수적인 최저 기준

SOP는 이미 뛰어난 계층 구조를 갖추고 있습니다. 번호가 매겨진 섹션 구조는 단순한 외양 꾸미기가 아니라, 문서의 의미론적 골격(Semantic Skeleton)입니다. 청킹 전략은 이를 적극적으로 활용해야 합니다.

전략: 토큰 수가 아닌, 제목 계층(Heading Hierarchy)을 기준으로 분할합니다.

문서를 파싱하여 섹션 헤더(H1, H2, H3 또는 1.0, 1.1, 1.1.1)를 감지합니다. 각 섹션은 후보 청크가 됩니다. 특정 섹션이 목표 청크 크기를 초과하는 경우, 계층 구조를 준수하면서 하위 섹션 경계, 문단 경계, 문장 경계 순서로 분할을 진행합니다.

모든 청크는 메타데이터로 전체 브레드크럼(Breadcrumb) 경로를 반드시 포함해야 합니다:

Section: 5.0 Procedure > 5.2 Cleaning > 5.2.1 Pre-Cleaning Inspection

이는 LLM 호출 비용 없이 얻을 수 있는 무료 문맥 보강(Contextual Enrichment)입니다. 문서 작성자가 이미 제공한 제목 계층 구조가 각 청크를 독립적으로도 이해 가능하게 만드는 핵심 맥락이 됩니다.

청크 크기: 절차 내용의 경우 400–800토큰이 적합합니다. SOP는 정보 밀도가 높기 때문에, 메타데이터 브레드크럼이 맥락을 제공해 주는 한 청크 크기를 작게 유지할수록 의미 손실 없이 검색 정확도를 향상시킬 수 있습니다.

제외해야 할 항목: 개정 이력 항목(“버전 3 — 섹션 4.2 서식 수정” 등)은 구조화된 메타데이터로 저장해야 하며, 청크 벡터 공간에 절대 임베딩해서는 안 됩니다. 세척 절차를 검색하는 사용자에게 “오탈자 수정”이라는 결과가 노출되어서는 안 되기 때문입니다.

작업 지침서: 원자적 단계 수준 청킹

작업 지침서(Work Instructions, WI)는 SOP를 현장 작업자 수준에 맞게 세분화한 문서입니다. 각 번호가 매겨진 지침 항목은 그 자체로 독립된 청크가 될 수 있지만, 다음과 같은 중요한 보강이 수반되어야 합니다:

  • 모든 청크 앞에 컨텍스트 윈도우 헤더를 추가합니다: [WI-998 | v2.1 | Effective: 2023-10-01 | Step 4 of 12]
  • 안전 경고 사항을 지속적으로 전파합니다. 예를 들어 1단계에 “주의: 개인보호장구(PPE)를 착용할 것”이라는 문구가 있다면, 이 경고는 최초 등장한 단계뿐 아니라 해당 섹션 내의 모든 청크 앞단에 함께 포함되어야 합니다.
  • 단계 간 종속성을 보존합니다. 쿼리 시점에 맥락을 확장할 수 있도록 ±2단계 윈도우를 갖는 문장 윈도우 검색(Sentence-Window Retrieval)을 사용합니다. 검색기는 4단계를 찾아내지만, LLM은 실행 맥락을 완벽히 파악할 수 있도록 3–5단계를 함께 전달받습니다.

청크 크기: 100–300토큰이 적합합니다. 작업 지침서는 본질적으로 간결하게 작성됩니다. 여기서는 맥락의 폭(Breadth)보다 정확도(Precision)가 훨씬 중요합니다.

일탈 보고서: 단계 기반 시맨틱 청킹

일탈 보고서(Deviation Reports)는 조사 문서로서 자연스러운 단계적(Phase-based) 구조를 지닙니다:

  1. 사건 설명 (Event Description) — 무슨 일이 언제 일어났는지, 어떤 배치/제품이 영향을 받았는지
  2. 즉각적 영향 (Immediate Impact) — 제품에 대한 격리 또는 출하 조치
  3. 조사 및 근본 원인 (Investigation / Root Cause) — 5-Why 분석, 어골도(Fishbone diagram), 시험실 결과
  4. CAPA 연계 (CAPA Linkage) — 유발된 시정 및 예방조치
  5. 처리 및 종결 (Disposition and Closure) — 최종 결정 및 QA 승인

각 단계는 독립된 청크로 분리되어야 합니다. 이는 자의적인 구분이 아니라, 실제 조사관들이 시스템에 질의하는 방식과 정확히 일치합니다:

  • “B-4521 배치에 어떤 사건이 발생했는가?” → 사건 설명 청크 검색
  • “근본 원인은 무엇이었는가?” → 조사 및 근본 원인 청크 검색
  • “어떤 시정 조치가 취해졌는가?” → CAPA 연계 청크 검색

분량이 긴 조사 서술문의 경우, 해당 단계 내부에서 **시맨틱 청킹(Semantic Chunking)**을 적용합니다. 연속된 문장들을 임베딩하여 코사인 유사도를 측정하고, 주제가 전환되는 지점에 청크 경계를 설정합니다. 이를 통해 조사의 핵심 맥락이 중간에 끊어지는 것을 방지하면서도 청크의 집중도를 높일 수 있습니다.

청크 크기: 구조화된 필드는 300–600토큰, 조사 서술문은 500–800토큰이 적합합니다.

청크당 필수 메타데이터: 일탈 ID, 배치/로트 번호, 제품 코드, 심각도(Severity) 등급, 관련 CAPA 번호 등이 포함됩니다. 이들은 주요 쿼리 앵커(Query Anchor)로 작용합니다. “스프링 압력 불일치와 관련된 일탈은 무엇인가?“를 검색하는 사용자는 의미적 근사치가 아닌 정확한 메타데이터 매칭 결과를 필요로 합니다.

CAPA: 조치 항목 중심 청킹

CAPA는 개별 조치 항목(Action Items)으로 자연스럽게 분해됩니다. 각각의 시정 조치, 예방 조치, 유효성 평가(Effectiveness Check)는 서로 구별되는 독립적 의미 단위입니다.

전략:

  • CAPA 헤더(문제 정의, 범위, 촉발 원인 사건)는 독립된 청크로 분리합니다.
  • 개별 조치 항목들은 별도의 청크로 나눕니다 — “조치 1: SOP-402에 대한 작업자 재교육”과 “조치 2: SOP-402 섹션 5.1 개정”은 한데 합쳐져서는 안 됩니다.
  • 유효성 평가는 별도 청크로 구성하되, 메타데이터를 통해 원인이 된 조치 항목들과 다시 연결합니다.

조치 항목을 분리해야 하는 이유: 사용자가 “작업자 교육과 관련된 CAPA를 보여줘”라고 질문했을 때, 모든 조치를 하나의 청크로 뭉뚱그리면 임베딩에 심각한 노이즈가 발생합니다. 청크를 분리해야 정밀한 매칭이 가능합니다.

그래프 통합 (Graph Integration): CAPA는 고도로 관계 중심적인 문서입니다. 조치 항목 2(“SOP-123 개정”)는 일탈(“DEV-444”)과 연결되고, 이는 다시 배치 제조 기록서(“BR-555”)와 연결됩니다. CAPA 청킹은 이러한 LINKS_TO 관계를 매핑하는 교차 참조 그래프(Cross-Reference Graph)와 반드시 결합되어야 합니다. 순수한 벡터 검색만으로는 이러한 연결 고리를 파악할 수 없습니다.

청크 크기: 조치 항목당 200–400토큰, 상위 CAPA 요약본은 800–1,200토큰이 적합합니다.

배치 제조 기록서: 테이블 인식 구조적 청킹

배치 제조 기록서는 RAG에서 다루기 가장 까다로운 문서입니다. 분량이 방대하며(대개 100페이지 이상), 반복성이 매우 높고, 서명이 포함되어 있으며, 대부분 빈 양식에 몇 가지 수치만 기입된 형태입니다. 표준 텍스트 청킹 방식을 적용하면 치명적인 실패를 겪게 됩니다.

전략: 배치 기록서를 서술형 줄글이 아닌 구조화된 데이터로 취급합니다.

고급 문서 레이아웃 분석 도구(Azure Document Intelligence, Unstructured.io의 hi_res 전략, AWS Textract 등)를 활용하여 텍스트를 단순 평탄화(Flattening)하지 않고 키-값 쌍(Key-Value Pair)으로 추출합니다.

공정 단계 테이블의 경우: 5–10개 행 단위의 단계 그룹별로 청킹하되, 모든 청크에 컬럼 헤더를 항상 반복 포함시킵니다. "pH Reading | Date | Operator | Result"라는 헤더가 없다면, "6.85 | 2024-03-15 | J. Smith | PASS"라는 데이터 청크는 아무런 의미를 갖지 못합니다.

구조화된 필드의 경우: JSON과 유사한 의미 단위를 생성합니다:

{
  "batch_number": "B-2024-0847",
  "product": "DrugX 50mg",
  "step": "Granulation",
  "parameter": "Temperature",
  "specification": "37°C ± 2°C",
  "actual": "36.8°C",
  "result": "PASS",
  "operator": "J. Doe",
  "timestamp": "2024-03-15T08:00:00Z"
}

이는 수치 쿼리에 대한 검색 정확도를 비약적으로 끌어올립니다. RAG 텍스트 청크와 병행하여 파라미터 조회를 위한 **병렬 구조화 데이터 저장소(Parallel Structured Data Store)**를 유지하는 방안을 고려하십시오. 서술적/절차적 맥락 이해에는 RAG를 사용하고, 수치 조회 질의는 구조화 저장소로 라우팅하는 방식입니다.

서명 (Signatures): 메타데이터(verified_by: "J. Doe", timestamp: "2024-03-15T08:23:00Z")로 추출합니다. 서명 이미지의 픽셀 데이터를 벡터 공간에 임베딩해서는 안 됩니다. 이는 벡터 공간에 노이즈만 가중시킬 뿐 검색에 아무런 도움이 되지 않습니다.

청크 크기: 제조 이벤트당 100–400토큰, 레코드 그룹당 400–800토큰이 적합합니다.

메타데이터 스키마: 임베딩보다 더 중요한 요소

생명과학 RAG에서는 메타데이터가 청크 본문 내용만큼이나 중요합니다. 문서 버전이나 유효 일자로 필터링할 수 없는 검색 시스템은 컴플라이언스 측면에서 중대한 결함 요인이 됩니다.

모든 청크에 필요한 필수 필드

필드명 예시 중요한 이유
document_id SOP-QA-017 원본 문서에 대한 추적성(Traceability) 확보
document_type SOP, deviation, CAPA, WI, batch_record 질의 의도에 따른 범위 지정
version 4.2 폐기/대체된(Superseded) SOP 인용 방지
effective_date 2024-11-15 시간 기반 필터링
status Effective, Superseded, Draft 현재 유효한 문서만 필터링
site Site-A-Boston 사업장/공장별 맞춤 쿼리 수행
section_path 4.0 > 4.3 > 4.3.1 계층적 브레드크럼 제공
page_number 12 감사 추적을 위한 정확한 출처 인용
regulatory_scope GMP, FDA 21 CFR 211 규제 요건별 필터링
cross_references SOP-QC-005, FORM-F-201 문서 간 교차 검색 지원
chunk_type parent, child, proposition, table 검색 전략 라우팅

문서 유형별 추가 메타데이터

SOP: department, referenced_docs, supersedes, training_required

일탈 (Deviation): deviation_id, batch_lot_numbers, severity, related_capa, investigation_lead

CAPA: capa_id, action_type (corrective/preventive), owner, due_date, effectiveness_status

배치 제조 기록서 (Batch Record): batch_number, product_name, equipment_id, manufacturing_date, yield_percent

사전 필터링 검색 (Filter-First Retrieval)

메타데이터 필터링은 벡터 검색 이후가 아니라, 반드시 벡터 검색 이전에 수행되어야 합니다. 유사도 점수를 계산하기 전에 접근 권한 필터, 버전 필터, 문서 유형 필터를 먼저 적용하여 무관한 결과를 사전에 배제해야 합니다.

전형적인 쿼리 분해(Query Decomposition) 흐름은 다음과 같습니다:

사용자 질의: "B-4521 배치의 일탈에 대한 근본 원인은 무엇인가요?"

추출된 필터:
  document_type: DEV
  batch_number: B-4521
  section_type: root_cause

필터링된 데이터셋으로 범위 제한 후 벡터 검색 → 정확한 청크 검색

이러한 사전 필터링 단계가 없다면, 검색기는 전혀 다른 배치의 일탈이나 폐기된 이전 버전 문서의 근본 원인을 가져오는 실수를 범할 수 있습니다.

계층형 아키텍처

단 하나의 기법만으로는 충분하지 않습니다. 프로덕션 환경에서 검증된 스택은 각기 다른 실패 모드를 해결하는 다중 전략을 계층화하여 구성합니다:

계층 구성 요소 해결하는 문제
1 (최저 기준) 구조 인식 분할 (Structure-aware splitting) 작성자의 의도된 섹션 구조 보존, 표 구조 훼손 방지
2 부모-자식 검색 (Parent-child retrieval) 검색 정확도(작은 청크)와 생성 맥락(큰 청크)의 분리
3 10–20% 중첩 (Overlap) 청크 경계면에서의 정보 유실 방지
4 풍부한 메타데이터 + 사전 필터링 유사도 채점 전 무관한 결과 원천 차단
5 문맥 검색 헤더 (Contextual retrieval headers) 문서 전반에서 반복되는 유사 문구 간 모호성 해소
6 하이브리드 검색 (Dense + BM25) 임베딩이 놓치기 쉬운 정확 매칭(배치 번호, SOP ID) 보완
7 교차 참조 그래프 (Cross-reference graph) SOP ↔ 일탈 ↔ CAPA ↔ 배치 기록서 간 관계 연결
8 골든 평가 세트 검증 (Golden eval validation) 검색 품질에 대한 데이터 기반 정량적 측정

부모-자식 검색 (Parent-Child Retrieval)

이는 프로덕션 환경에서 가장 널리 채택되는 패턴입니다. 정밀한 검색을 위해 작은 자식 청크(128–256토큰)를 생성하고, 이를 생성 시 충분한 맥락을 제공할 수 있는 더 큰 부모 청크(512–1,024토큰)와 연결합니다.

검색기가 자식 청크(“보관 시간: 2–8°C에서 24시간”)를 매칭하면, 부모 섹션(“용액 A는 섹션 5.3에 따라 조제된다. 조제 완료 후 보관 시간은 다음을 초과할 수 없다…”)을 가리키는 포인터를 따라가 부모 청크 전체를 LLM에 전달합니다.

이를 통해 사용자는 작은 청크 기반의 정밀한 검색력과 큰 청크 기반의 풍부한 생성 맥락을 동시에 누릴 수 있습니다.

순수 벡터 검색은 의미론적 쿼리를 잘 처리하지만, 정확한 일치가 필요한 고유 명칭에는 취약합니다. “SOP-QA-007”과 “SOP-QA-070”은 임베딩 벡터가 거의 동일하지만, 규제적 관점에서는 완전히 다른 문서입니다. “USP <85>“와 “USP <87>” 역시 높은 코사인 유사도로 오인 매칭될 수 있습니다.

조밀 임베딩(Dense Embeddings)과 BM25 키워드 검색을 결합하고, RRF(Reciprocal Rank Fusion, 상호 순위 융합)를 통해 결과를 병합하십시오. 이를 통해 특정 장비 ID, 배치 번호, 규제 참조 조항이 검색에서 누락되지 않도록 보장합니다.

교차 참조 해결 (Cross-Reference Resolution)

생명과학 문서는 독립된 파일들의 단순 집합이 아니라 복잡한 지식 그래프를 이룹니다. 일탈 보고서에는 “근본 원인은 SOP-QA-032의 조사 방법론에 따라 규명되었다”와 같은 내용이 포함될 수 있습니다. 그러나 해당 SOP 청크는 벡터 저장소의 완전히 다른 영역에 위치합니다.

문서 수집(Ingestion) 과정에서 교차 참조(문서 ID, 섹션 번호)를 추출하여 메타데이터 엣지(Edge)로 저장합니다. 검색 시점에 일탈 청크가 반환되면, 보조 조회를 수행하여 참조된 SOP와 CAPA를 함께 가져옵니다. 이를 통해 순수 벡터 검색으로는 해결하기 어려운 조사 목적의 복합 질의(“이 일탈과 관련된 모든 문서와 절차를 보여줘”)를 효과적으로 지원할 수 있습니다.

표(테이블)를 일급 시민으로 다루기

표(테이블)는 생명과학 문서의 핵심 하중을 지탱하는 기둥입니다. 기준 규격, 원자재 목록, 공정 중 시험(IPC) 결과 등 표의 행이 중간에 잘려 나가면 파라미터와 수치 간의 관계가 완전히 파괴됩니다.

타협할 수 없는 절대 원칙:

  1. 표를 여러 청크 경계에 걸쳐 분할하지 마십시오. 표의 크기가 목표 청크 크기를 초과하는 경우, 전체 표를 단일 청크로 추출하거나 행 그룹 경계에서 분할해야 합니다.
  2. 표에서 파생된 모든 청크에 컬럼 헤더를 반복 포함시키십시오.
  3. 표를 평탄화된 텍스트가 아닌 **구조화된 객체(JSON 또는 Markdown)**로 추출하십시오.
  4. 이중 표현(Dual Representation)을 구성하십시오: 정밀한 데이터 조회를 위한 구조화된 청크와 시맨틱 검색을 위한 자연어 요약 청크를 함께 생성합니다.

수많은 단계에 걸친 공정 중 시험과 같이 긴 배치 기록서 테이블의 경우, 헤더 맥락이 반복된 행 단위 청킹을 적용하면 각 행이 그 자체로 완전하고 독립적으로 검색 가능한 사실 단위가 됩니다.

버전 관리 및 시간적 컨텍스트

현재 유효한 규정이 아닌 폐기된 이전 버전의 SOP를 검색하여 참조하는 것은 명백한 컴플라이언스 위반입니다. 청킹 전략은 이를 반드시 통제할 수 있어야 합니다:

  • 문서의 모든 개정 이력을 저장하고, revision_number와 effective_date를 태깅합니다.
  • 현재 유효한 개정본은 status: Effective로 인덱싱하고, 이전 개정본은 status: Superseded로 아카이빙합니다.
  • 배치 제조 기록서의 경우, 각 청크를 해당 배치가 실제로 제조되던 시점에 유효했던 SOP 개정본과 연결합니다.
  • 사용자가 특정 날짜나 배치 맥락을 명시하지 않는 한, 기본적으로 현재 유효한 최신 개정본을 검색하도록 설정합니다.
  • 문서 개정이 발생하면 기존 청크를 덧대어 수정하지 말고, 항상 전체를 재청킹하고 재임베딩해야 합니다.

이를 통해 “현재 유효한 SOP 규정은 무엇인가?“와 같은 일상적 운영 질의와 “이 배치가 제조되던 당시의 규정 절차는 무엇이었는가?“와 같은 조사 질의를 모두 완벽히 지원할 수 있습니다.

평가: 최적화하기 전에 먼저 측정하십시오

측정할 수 없는 것은 최적화할 수 없습니다. 청킹 전략을 확정하기 전에 반드시 골든 검색 평가 데이터셋(Golden Retrieval Set)을 구축해야 합니다.

테스트 쿼리 범주

각 문서 유형별로 다음 범주에 걸쳐 50–100개의 질의를 구성합니다:

범주 예시 기대 결과
사실 조회 (Factual lookup) “WI-LAB-028에서 규정한 pH 허용 기준은 무엇인가?” 출처가 명시된 정확한 기준 수치
절차 순서 (Procedural sequence) “pH 미터 보정 단계는 어떻게 되는가?” 뒤섞이지 않고 순서가 정렬된 절차 단계
문서 간 교차 (Cross-document) “일탈 DEV-2024-0156에 대해 발행된 CAPA는 무엇인가?” 일탈 내용 + 참조된 CAPA
시간/버전 질의 (Temporal) “2024년 1월 15일 기준 SOP-MFG-042의 유효 버전은 무엇이었는가?” 해당 시점에 유효했던 정확한 SOP 개정본
집계 질의 (Aggregation) “2024년에 pH와 관련된 일탈은 총 몇 건 발생했는가?” 여러 일탈 문서 취합 및 종합 수치 산출

핵심 평가 지표

  • Recall@K: 상위 K개 검색 결과 안에 정답이 포함되어 있는가? (목표치: >80%)
  • 맥락 완전성 (Context completeness): 검색된 맥락에 필요한 모든 정보가 온전히 포함되어 있는가, 아니면 단편화되어 있는가?
  • 버전 정확도 (Version accuracy): 폐기된 버전이 아닌 현재 유효한 버전을 정확히 가져오는가?
  • 표 일관성 (Table coherence): 표의 행이 청크 경계에서 잘려 나간 비율이 0%를 유지하는가?
  • 교차 참조 해결도 (Cross-reference resolution): 청크가 다른 문서를 참조할 때, 검색 파이프라인이 해당 참조 문서를 함께 가져오는가?

반드시 **QA 도메인 전문가(SME)**가 샘플 데이터셋을 직접 평가하도록 하십시오. 자동화된 지표만으로는 규제 감사 지적(Regulatory Finding)으로 이어질 수 있는 미묘한 맥락 유실을 완벽히 감지해낼 수 없습니다.

규제 준수: 통제된 기록으로서의 청크

구축된 RAG 시스템이 품질 의사결정에 직간접적으로 관여한다면, 청킹 및 검색 파이프라인은 회사의 컴퓨터 시스템 밸리데이션/보증(CSV/CSA) 정책의 적용 대상이 됩니다. 모든 청크는 ALCOA+ 원칙을 충족해야 합니다:

  • 기인성 (Attributable): 청크 생성이 특정 파싱 시스템 및 소프트웨어 버전에 명확히 귀속되어야 함
  • 가독성 (Legible): 사람이 읽을 수 있는 형태로 저장되며 표 구조가 온전히 보존되어야 함
  • 동시성 (Contemporaneous): 데이터 수집 시점에 즉시 타임스탬프가 기록되어야 함
  • 원본성 (Original): 출처 계보(Lineage)가 명확한 소스 문서의 진본 사본이어야 함
  • 정확성 (Accurate): 밸리데이션된 파싱 알고리즘과 체크섬 검증을 거쳐야 함

감사 추적(Audit Trail)에는 사용자 ID, 타임스탬프, 모델 버전, 입력 프롬프트, 검색된 청크(문서 ID 및 버전 포함), 최종 생성 결과가 모두 기록되어야 합니다. 이 기록은 회사의 문서 보존 정책에 규정된 기간 동안 안전하게 보관되어야 합니다.

21 CFR Part 11에 따라, GxP 기록을 생성, 수정 또는 보관하는 모든 시스템은 컴퓨터 시스템 밸리데이션, 안전한 감사 추적, 고유한 사용자 ID 식별, 기록과 연동된 전자서명을 필수로 요구합니다. 통제된 규제 문서로부터 답변을 생성하는 RAG 시스템은 명백히 이 규제 범위 내에 포함됩니다.

따라서 밸리데이션 산출물을 초기부터 선제적으로 준비해야 합니다: AI 고유 위험 요소(환각, 폐기된 구버전 인용, 표 데이터 누락 등)를 다루는 위험 평가서, 문서 유형별 골든 쿼리 테스트 세트, 그리고 임베딩 모델이나 청킹 로직 변경 시 재밸리데이션을 트리거하는 변경 통제(Change Control) 절차가 포함되어야 합니다.

안티 패턴

피해야 할 실수들:

모든 문서 유형에 단일 고정 크기 청킹 적용. 모든 것을 하나로 통일하려는 방식은 SOP에서 실패하고, 표를 조각내며, 일탈 조사 서술문의 맥락을 깨뜨립니다.

256토큰 미만의 지나치게 작은 청크. 문맥이 너무 빈약해집니다. 맥락 손실은 환각 발생률을 급증시킵니다. 맥락을 희생하지 않으면서 검색 정밀도를 높이려면 부모-자식 아키텍처를 도입하십시오.

2,048토큰을 초과하는 지나치게 큰 청크. 주의 집중 분산(Attention Dilution)과 “중간 정보 유실(Lost in the Middle)” 현상이 발생합니다. 검색 대상 청크는 1,000토큰 내외로 상한을 두는 것이 좋습니다.

중첩(Overlap) 미적용. 청크 경계면에서의 정보 누락은 실재하는 문제입니다. 동일 섹션 내에서 10–20%의 중첩 구간을 설정하십시오.

검색 후 필터링. 접근이 제한되거나 폐기된 콘텐츠가 순위 산정 로직에 노출될 위험이 있습니다. 반드시 유사도 점수 산정 이전에 필터링을 수행하십시오.

문서 구조 무시. 구조 인식 파싱은 언제나 시스템의 가장 밑바탕이어야 합니다. 문서 작성자가 이미 헤딩과 서식을 통해 경계선을 명시해 두었습니다.

교차 참조 미해결. 생명과학 문서는 거대한 지식 그래프입니다. 청킹 파이프라인은 이들 간의 연결 관계(엣지)를 보존하거나 재구성해야 합니다.

평가 생략. 프로덕션 환경에서 전략을 변경하기 전 정량적 지표 측정이 선행되어야 합니다. 골든 데이터셋 평가는 선택 사항이 아닙니다.

핵심 요약

생명과학 RAG에서 성공을 거두는 접근법은 문서 유형을 명확히 인식하는 계층적 청킹과 풍부한 규제 메타데이터 보강의 결합입니다:

  1. 구조 인식 기반 파싱 — 제목, 표, 양식 구조 보존
  2. 문서 유형별 맞춤 청킹 — SOP는 섹션별, 일탈은 단계별, CAPA는 조치 항목별, 배치 기록서는 레코드 그룹별, 작업 지침서는 단계별
  3. 규제 메타데이터 보강 — 모든 청크에 버전, 유효일자, 상태, 교차 참조 정보 부착
  4. 부모-자식 검색 활용 — 정밀 검색을 위한 작은 청크, 맥락 생성을 위한 큰 부모 청크
  5. 하이브리드 검색 — 의미 파악을 위한 조밀 벡터, 고유 식별자 일치를 위한 BM25
  6. 교차 참조 해결 — 데이터 수집 단계에서 문서 간 관계 그래프 구축
  7. 도메인 특화 골든 쿼리 검증 — 자동화 지표뿐 아니라 QA 도메인 전문가(SME) 직접 평가

가장 큰 성능 개선 효과는 의외로 큰 비용이 들지 않는 기본 작업에서 비롯됩니다. 제목 계층을 무료 컨텍스트 헤더로 보존하고, 10–20%의 중첩을 추가하며, 모든 청크에 버전과 배치 번호를 태깅하고, 검색 전 사전 필터링을 수행하는 것입니다. 레이트 청킹(Late Chunking)이나 LLM 생성 문맥 헤더와 같은 고급 기술은 검색 실패율을 49–67%까지 유의미하게 낮춰주지만, 이는 어디까지나 이러한 탄탄한 기본기가 갖춰진 이후에 적용해야 합니다.

규제 환경에서는 이러한 청킹 아키텍처의 설계 결정들이 임베딩 모델을 다른 것으로 바꾸는 것보다 검색 품질에 훨씬 더 결정적인 차이를 만들어냅니다. 청킹 파이프라인은 단순한 배관 작업(Plumbing)이 아닙니다. 규제 준수 수준의 신뢰할 수 있는 답변을 제공하는 시스템과 규제 위반이라는 대형 사고를 초래하는 시스템을 가르는 본질적인 경계선입니다.

복잡한 SOP 표 추출 및 프롬프트 엔지니어링을 다루는 자매 글은 [[Engineering the RAG Pipeline for Life Sciences SOPs]]를 참조하십시오. JSON Schema, Pydantic v2 구현체 및 프로덕션 파이프라인 아키텍처를 포함한 전체 기술 레퍼런스는 [[RAG Chunking Strategies for Life Science Documentation]]를 참조하십시오.

관련 글