새로 구축한 검색 증강 생성 (Retrieval-Augmented Generation, RAG) 챗봇이 단순히 키워드가 일치한다는 이유만으로 오래된 FAQ 페이지를 자신 있게 답변하는 것을 지켜보는 것은 AI 엔지니어들에게 통과의례와도 같습니다.

얼마 전, 호텔과 해변 리조트를 포함한 여러 환대 산업(hospitality) 비즈니스를 운영하는 고객을 위해 고객 서비스 에이전트를 구축하던 중 특정 실패 모드를 경험했습니다. 우리는 표준 벡터 RAG를 사용할 때, 데이터를 고정된 길이의 텍스트 청크(chunk)로 분할하면 관련 콘텐츠가 완전히 단절된다는 사실을 깨달았습니다. 그 결과, 시스템은 서로 다른 엔티티(entity) 간의 예약 관련 질의를 지속적으로 잘못 매칭했습니다.

이것은 청크 불일치 (Chunk Mismatch) 문제로 알려져 있습니다. 임베딩 모델 (embedding model)의 컨텍스트 윈도우 (context window)에 맞추기 위해 복잡한 문서를 임의의 청크로 자르면, 문서의 논리적 일관성이 파괴됩니다. 만약 엔지니어링 티켓의 상단에는 버그에 대한 설명이 있고 하단에는 배포 솔루션이 있다면, 표준 텍스트 분할 방식은 이 둘을 서로 떨어뜨려 놓습니다.

다음은 GraphRAG와 **엔티티 해상도 (Entity Resolution)**를 사용하여 쓰기 시점(write time)에 구조를 강제함으로써 이 문제를 해결하는 기술적 분석입니다.

1. 쓰기 시점의 데이터 구조화: 이중 레벨 그래프 (Dual-Level Graph)

청크 불일치 문제를 해결하려면 평면적인 텍스트를 청킹하는 것을 멈추고, 검색 단계 이전에 데이터를 구조화하기 시작해야 합니다.

이를 위한 훌륭한 아키텍처 설계도는 LinkedIn의 고객 서비스 엔지니어링 팀으로부터 얻을 수 있습니다. 그들은 평면적인 텍스트 청킹을 포기하고 **이중 레벨 지식 그래프 (dual-level Knowledge Graph)**를 채택했습니다. 그들은 두 개의 별도 계층을 사용하여 과거 이슈 티켓을 구조화했습니다:

이슈 내부 트리 (The Intra-Issue Tree)

티켓을 임의의 텍스트 청크로 나누는 대신, 인제스션 파이프라인 (ingestion pipeline)이 이를 **트리 구조 (tree structure)**로 파싱합니다. 각 노드는 요약 (Summary), 설명 (Description), 또는 _재현 단계 (Steps to Reproduce)_와 같이 티켓의 별개이고 논리적인 섹션을 나타냅니다. 이는 문서의 내부 논리를 보존합니다.

이슈 간 그래프 (The Inter-Issue Graph)

그 다음 시스템은 서로 다른 티켓(ticket)들 사이에 연결망을 생성합니다. 여기에는 명시적 연결 (explicit links) (예: 티켓 A가 티켓 B로부터 CLONED_FROM됨)과 티켓 임베딩 (embedding) 간의 의미론적 유사성 (semantic similarity)에 기반한 **암시적 연결 (implicit links)**이 포함됩니다.

사용자가 쿼리 (query)를 제출하면, 시스템은 엔티티 (entity)와 의도 (intent)를 추출한 다음, 이 고도로 구조화된 그래프를 탐색하여 완전한 답변을 생성하는 데 필요한 정확한 서브그래프 (subgraph)를 검색합니다.

2. 말하지 않아도 필요한 전제 조건: 엔티티 해상도 (Entity Resolution)

최근 한 동료 개발자가 지적했듯이, 시스템에 중복되거나 충돌하는 엔티티 표현이 가득하다면 이러한 상호 연결된 그래프를 구축하는 것은 완전히 무용지물입니다.

이는 **엔티티 해상도 (Entity Resolution)**로 이어지는데, 이는 서로 다른 시스템 전반에 걸쳐 중복되거나 관련된 엔티티 표현을 통합된 정준 노드 (canonical nodes)로 조정하는 기초적인 역량입니다.

만약 인제스션 파이프라인 (ingestion pipeline)이 "Hotel A", "Hotel-A-Booking", 그리고 원시 속성 ID (raw property ID)를 세 개의 고립된 노드로 취급한다면, 어떠한 멀티 홉 탐색 (multi-hop traversal)이나 깊이 쿼리 (depth query)도 즉시 막다른 길에 부딪히거나 유령 경로 (phantom paths)를 생성하게 될 것입니다. 지식 그래프 (knowledge graph)의 품질은 그것이 구축된 정준 엔티티 (canonical entities)의 품질과 동일합니다. LLM이 추론할 수 있는 단일하고 검증 가능한 진실의 원천 (source of truth)을 가질 수 있도록, 반드시 **쓰기 시점 (write time)**에 이러한 관계를 해결해야 합니다.

3. 고급 메커니즘: 문자열 레이블 대신 URI 사용

엔터프라이즈급 시맨틱 레이어 (semantic layers)를 설계하려는 개발자들에게는, 이러한 해상된 엔티티를 어떻게 정의하느냐가 매우 중요합니다.

단순한 레이블 속성 그래프 (Labeled Property Graphs, LPGs)는 노드와 관계를 식별하기 위해 종종 기본적인 문자열 레이블 (string labels)에 의존합니다. 그러나 기본적인 문자열 레이블은 복잡한 데이터 통합에 필요한 풍부하고 모호하지 않은 의미가 부족한 경우가 많습니다.

**Resource Description Framework (RDF)**에 기반한 고급 엔터프라이즈 시맨틱 아키텍처 (Advanced enterprise semantic architectures)는 특정 URI (Uniform Resource Identifiers, 통합 자원 식별자) 및 IRI (Internationalized Resource Identifiers, 국제화된 자원 식별자)를 사용하여 절대적인 의미론적 명확성을 확립함으로써 이 문제를 해결합니다. 단순한 텍스트 문자열 대신 URI를 통해 정체성을 강제함으로써, 데이터의 출처와 관계없이 그래프 탐색 (graph traversal) 시 정확히 어떤 표준 엔티티 (canonical entity)를 참조하고 있는지 보장할 수 있습니다. 이는 LLM을 탈선시키는 유령 경로 (phantom paths)를 제거하고, 정확한 검색 (retrieval)에 필수적인 깊은 문맥 (deep context)을 제공합니다.

마무리하며

LLM의 환각 (hallucinations) 현상에 지쳤고 기본적인 API 래퍼 (API wrappers) 수준을 넘어서고 싶다면, 데이터가 어떻게 수집 (ingested)되는지를 살펴봐야 합니다. 평면적인 텍스트 청크 (flat text chunks)에서 벗어나, 이중 레벨 그래프 (dual-level graphs)를 활용하고, 쓰기 시점 (write time)에 엔티티 해소 (entity resolution)를 엄격하게 강제함으로써, 실제 비즈니스 로직을 이해하는 AI 시스템을 구축할 수 있습니다.

여러분의 RAG 파이프라인에서도 청크 불일치 (chunk mismatch) 문제를 겪은 적이 있나요? 댓글을 통해 여러분은 데이터 구조화를 어떻게 처리했는지 알려주세요!