Executive Summary

주요 수치

앞의 세 숫자는 질문이 오기 전에 값을 뽑아 둔 대가로 얻은 것이고, 마지막 숫자는 그 스키마가 맞는지 확인하는 데 실제로 쓰인 표본의 크기입니다.

출처: arXiv:2608.13384 표 1, §VI-B·VI-D

논문이 드는 예시 질문은 평범합니다. NBA에서 우승을 다섯 번 넘게 한 팀의 현역 선수들은 평균 몇 살인가. 사람에게는 한 문장이지만 시스템에는 조건 필터와 집계와 문서 사이의 조인이 한꺼번에 걸린 요구입니다. 저자들은 이런 질문에서 기존 방식이 두 지점에서 무너진다고 정리합니다.

첫 번째는 문서를 찾는 단계입니다. 문서와 질문을 벡터로 바꿔 가까운 것부터 K개를 돌려주는 방식은 주제가 가까운지를 재지, 조건을 만족하는지를 재지 않습니다. 출생 연도가 1985년보다 앞선다는 조건을 걸어도 주제만 비슷하고 연도는 어긋난 문서가 딸려 오고, 조건에는 맞지만 그 사실이 문서에서 두드러지지 않은 문서는 빠집니다. 이때 빠진 문서는 뒤 단계에서 되살아나지 않습니다. 그래서 실제 시스템은 가져온 문서를 다시 LLM에 넣어 조건을 하나씩 확인하고, 비용은 가져온 문서 수에 비례해 늘어납니다.

두 번째는 계산하는 단계입니다. 평균과 비교와 조인은 값이 열로 정리돼 있어야 성립하는 연산입니다. 벡터 검색이 돌려주는 것은 순서도 스키마도 없는 텍스트 조각 묶음이라 이런 연산을 걸 자리가 없습니다. 지식 그래프는 엔티티와 관계를 미리 뽑아 두지만 경로를 따라가는 탐색기에 가까워서, 걸러 낸 집합에 평균을 내거나 간선이 없는 두 집합을 잇는 작업은 결국 부분 그래프를 통째로 LLM에 넘겨야 합니다.

두 실패를 관통하는 문제로 논문이 지목하는 것은 정확도가 아니라 비용의 구조입니다. 두 방식 모두 속성을 뽑는 비용을 질의 실행에서 떼어 내지 못합니다. 같은 코퍼스에 열 번 물으면 열 번 다시 뽑고, 백 번 물으면 백 번 다시 뽑습니다. 비용이 질의 수에 비례하는 한 대규모 분석 작업에는 올려 두기 어렵다는 것이 이 논문의 출발점입니다.

AnnoIndex의 답은 일을 앞으로 당기는 것입니다. 질문을 받고 문서를 뒤지는 대신, 질문이 오기 전에 코퍼스를 훑어 어떤 필드를 뽑아 둘지 정하고 값을 채워 넣습니다. 이렇게 만들어진 표를 논문은 주석 인덱스라고 부릅니다. 출생 연도가 1985년보다 앞선다는 조건은 이 인덱스 위에서 숫자 비교 한 번으로 끝나고, LLM은 한 번도 불리지 않습니다.

그 스키마를 만드는 모듈이 SchemaLoop입니다. 구조는 관계형 데이터베이스를 그대로 본떴습니다. 데이터셋 층이 코퍼스를 논리적인 데이터베이스로 나누고, 테이블 층이 문서를 엔티티 유형으로 묶고, 문서 층이 문서마다 뽑을 세부 필드를 정합니다. 위층이 아래층의 검색 범위를 먼저 잘라 내도록 설계돼 있어서, 문서 층의 필터가 걸릴 무렵이면 후보는 이미 크게 줄어 있습니다.

누가 스키마를 정하는지는 층마다 다릅니다. 데이터셋 층은 사람이 미리 정의합니다. 테이블 층과 문서 층은 GPT-4o가 그룹당 한 번씩 불려 후보를 만듭니다. 코퍼스의 최상위 경계만 사람이 긋고 그 안의 세부 필드는 모델이 채우는 분업입니다. 완전 자동도 아니고 완전 수동도 아니라는 점이 이 시스템의 성격을 규정합니다.

값을 뽑고 나면 표현을 고르는 작업이 이어집니다. 날짜는 ISO 8601 같은 한 가지 형식으로 통일하고, 숫자는 단위와 소수 표기를 맞추고, 범주형 문자열은 공백과 표기를 정리합니다. 통일할 형식은 코퍼스에서 자주 나타난 값의 모양에서 뽑아내고, 그 규칙 자체도 스키마와 같은 피드백 루프를 돌며 다듬어집니다. 후보 스키마 사이에 뜻이 같은 필드가 섞여 나오면 동의어 대조와 임베딩 유사도로 묶어 하나만 남깁니다. 데이터 팀이 손으로 하던 정규화와 중복 제거가 인덱스를 만드는 과정 안으로 들어와 있는 셈입니다.

이 준비 작업에 얼마나 드는지도 논문은 따로 셉니다. 데이터셋 층은 모델을 부르지 않고, 테이블 층과 문서 층은 문서 그룹마다 GPT-4o를 한 번씩만 부릅니다. 값을 실제로 뽑아 보는 검증 단계는 경량 모델이 맡고, 문서 층의 마지막 검증에서만 필요하면 큰 모델이 불려 옵니다. 그렇게 세운 인덱스는 질의가 훑어야 할 문서 수를 보통 100분의 1에서 1000분의 1까지 줄이고, 문서 1,600건 규모의 코퍼스에서 스키마 유도와 인덱스 구축을 합친 비용은 온라인 질의 한두 번 분량에 그쳤습니다. 질문이 오기 전에 준비해 두는 쪽이 싸다는 주장은 이 계산 위에 서 있습니다.

자동으로 만든 스키마를 그대로 쓰지는 않습니다. SchemaLoop은 후보가 나올 때마다 검증 단계를 거칩니다. 문서 그룹에서 무작위로 다섯 건을 골라 Mistral-7B로 모든 필드의 값을 뽑아 본 뒤, 두 지표로 채점합니다. 하나는 추출 성공률로, 뽑으려던 값 가운데 비어 있지 않게 채워진 비율입니다. 다른 하나는 필터링 효율로, 이 스키마로 문서를 나눴을 때 한 칸에 얼마나 쏠리는지를 뒤집은 값입니다. 임계값은 각각 0.6과 0.3입니다.

둘 중 하나라도 임계값에 못 미치면 실패한 지점을 모델에 되돌려 주고 필드를 합치거나 쪼개거나 다시 정의하게 합니다. 반복은 두 지표가 안정될 때까지 이어지되 최대 다섯 라운드이며, 문서 층은 보통 서너 번 안에 수렴한다고 저자들은 적었습니다.

0.6과 0.3이라는 숫자는 세 데이터셋에 똑같이 쓰였습니다. 문서 하나가 6,000토큰을 넘는 법률 조문에도, 같은 틀이 반복되는 웹 페이지에도 같은 기준이 걸립니다. 코퍼스 성격에 따라 이 값을 달리 잡으면 결과가 어떻게 달라지는지를 살핀 실험은 논문에 없습니다.

추출 성공률은 값이 채워졌는지를 재고, 필터링 효율은 문서가 고르게 나뉘는지를 잽니다. 값이 실제로 맞는지는 어느 쪽도 재지 않습니다. 정답과 맞춰 보는 작업은 논문의 실험 평가에서만 등장합니다. 저자들은 GPT-4o로 후보 속성을 뽑은 뒤 대학원생 여덟 명이 값을 일일이 검수해 gold standard를 만들었는데, 그것은 성능을 채점하기 위한 별도 자산이지 시스템이 돌아가며 참조하는 장치가 아닙니다.

그러니 다섯 건에서 값이 잘 채워지고 문서가 고르게 갈라지기만 하면, 그 필드가 엉뚱한 값을 뽑고 있어도 검증은 통과로 끝납니다. 통과한 스키마는 코퍼스 전체에 적용되고, 그 위에서 이후의 모든 질의가 답을 얻습니다. 자동 생성 스키마의 오류는 인덱스에 그대로 새겨진 채 조용히 재사용됩니다.

인덱스가 서면 질의는 SQL을 닮은 실행 계획으로 컴파일됩니다. 인덱스에 있는 필드로 걸 수 있는 조건은 먼저 걸러 냅니다. 이 단계에는 모델 호출이 없습니다. 인덱스에 없는 조건은 EXTRACT라는 연산자로 처리하는데, 값싼 도구부터 순서대로 붙입니다. 정규식으로 되는 것은 정규식으로, 안 되면 경량 모델인 Mistral-7B로, 그래도 남으면 GPT-4o로 넘어갑니다.

논문이 실행 계획을 통째로 보여 주는 예시는 1985년 이전에 태어났고 지금도 뛰고 있는 야구 선수를 찾는 질의입니다. 계획은 먼저 테이블 필드로 야구 선수 문서만 남기고, 다음으로 출생 연도 필드에 1985보다 작다는 조건을 겁니다. 여기까지는 인덱스 위의 비교라 모델이 한 번도 불리지 않습니다. 현역인지는 인덱스에 없는 값이라 마지막에 EXTRACT로 넘어가는데, 그 시점에 남아 있는 문서는 몇 건뿐이라 GPT-4o가 읽어야 할 분량도 그만큼 줄어 있습니다. 벡터 검색이 지키지 못하던 조건이 여기서는 WHERE 절 한 줄이 됩니다.

법률 코퍼스에서 상위법과 충돌하는 조문을 찾는 질의가 이 순서를 잘 보여 줍니다. 미리 뽑아 둔 충돌 유형 필드로 1,600건이 120건으로 줄고, 경량 모델이 환경 관련 키워드를 뽑아 35건으로 좁힌 뒤, GPT-4o는 그 35건에서 충돌 설명을 뽑는 일만 맡습니다. 같은 질의에서 F1은 0.79로, 조건을 걸어 둔 QUEST의 0.61보다 높습니다. QUEST가 LLM 호출을 풀면 정확도는 올라가지만 토큰이 20만 개를 넘어갑니다.

실행기가 쓰는 요령은 몇 가지 더 있습니다. 조건을 확인하는 순서는 문서마다 다시 정해지고, 하나라도 어긋나면 나머지는 보지 않고 그 문서를 버립니다. 조인은 한쪽에서 조건을 만족하는 값을 먼저 뽑아 IN 필터로 바꿔 반대쪽 호출을 줄입니다. 질의 하나가 부를 수 있는 LLM 호출에는 상한이 걸려 있어서 계획이 어긋나도 비용이 한없이 늘지는 않습니다. 세 테이블을 잇는 질의에서는 실행 계획이 방향성 비순환 그래프로 짜여 단계마다 필요한 속성만 뽑는데, 조인 순서가 한쪽으로 고정된 QUEST와 갈리는 지점이 여기입니다.

EXTRACT가 뽑아낸 값은 버려지지 않고 인덱스로 되돌아갑니다. 처음에는 확장 영역의 가상 필드로 저장되고, 같은 필드가 열 번 넘게 불리면 정식 스키마 필드로 승격돼 SchemaLoop 쪽으로 다시 넘어갑니다. 저자들의 표현을 빌리면 값을 뽑는 비용을 질의마다 무는 구조에서 그 값이 처음 필요해질 때 한 번만 무는 구조로 옮기는 장치입니다. 승격 기준 역시 값이 맞는지가 아니라 몇 번 불렸는지입니다. 자주 쓰이는 필드가 좋은 필드라는 가정 위에 서 있는 장치입니다.

효과는 반복 질의에서 드러납니다. 질의 100개짜리 배치를 다섯 번 연달아 돌리자 LLM 호출을 부르는 추출 횟수가 경제 모드에서 48회에서 13회로, 성능 모드에서 72회에서 15회로 줄었습니다. 다섯 배치를 합치면 각각 128회와 177회로, 재사용이 없을 때 예상되는 300회 안팎과 비교됩니다. 같은 질문이 반복될수록 한계비용이 내려가는 구조입니다.

실험 대상은 성격이 다른 세 코퍼스입니다. 문서당 6,000토큰이 넘는 법률 조문 1,600건, 열 개 분야에 걸친 위키백과 문서 219건, 템플릿이 있는 웹 페이지 1,050건입니다. 데이터셋마다 500개 질의를 만들고 단순 조건 검색부터 3중 조인과 다단계 추론까지 난이도를 나눠 배치했습니다. 답이 맞았는지는 튜플의 모든 속성 값이 정확히 일치할 때만 정답으로 셉니다.

표에서 가장 크게 벌어지는 칸은 법률 조문입니다. 벡터DB와 RAG를 붙인 구성이 0.34에 머무는 동안 AnnoIndex의 성능 모드는 0.81을 냅니다. 문서 하나가 6,000토큰을 넘어가고 조건이 조문 안쪽에 묻혀 있는 코퍼스에서, 주제가 비슷한 문서를 찾아 오는 방식과 값을 미리 뽑아 열로 세워 두는 방식의 차이가 그대로 드러납니다. 3중 조인 질의만 따로 보면 AnnoIndex가 0.86, QUEST가 0.74이고, 문서를 통째로 GPT-4o에 넣는 방식은 0.35로 사실상 답을 내지 못했습니다. 이 복합 질의 평가는 2중 조인 30개와 3중 조인 및 다단계 추론 20개, 법률 충돌 분석 25개를 따로 모아 진행한 것입니다.

베이스라인의 순위가 데이터셋마다 바뀌는 것도 표를 읽는 단서입니다. 문서를 통째로 모델에 읽히는 Lotus는 웹 페이지에서 0.95를 내지만 법률 조문에서는 0.46으로 내려앉습니다. 길고 촘촘한 조문을 한꺼번에 밀어 넣으면 모델이 그 안에 묻힌다는 뜻입니다. 웹 페이지는 같은 틀이 반복되는 자료라 값이 놓인 자리가 거의 고정돼 있어 상위 방법 셋이 모두 0.94를 넘깁니다. 그러니 방법 사이의 차이를 보려면 법률 조문 열을 봐야 합니다.

논문은 구성 요소를 하나씩 떼어 낸 실험도 함께 실었습니다. 도메인 전문가가 문서 20건을 읽고 손으로 정의한 스키마로 바꾸면 위키백과 F1이 0.87에서 0.72로 내려가고 토큰은 26.8K에서 51.8K로 늡니다. 사람이 만든 스키마가 중요한 속성을 빠뜨리거나 쓸모없는 속성을 넣기 때문입니다. 반대로 검증 단계를 빼면 정확도는 그대로인데 토큰만 38.7K로 늘어납니다. 걸러지지 않은 스키마에 남은 중복 필드가 불필요한 추출을 부릅니다. 자동 유도와 그 검증이 정확도와 비용 양쪽에 붙어 있다는 뜻입니다.

세 번째 변형은 스키마를 그대로 두고 구조화 질의 엔진만 걷어 냈습니다. 순수 벡터 검색으로 바꾸자 F1이 0.64까지 떨어집니다. 이때 토큰은 32.5K로 성능 모드와 크게 다르지 않습니다. 값을 미리 뽑아 둔 인덱스가 있어도 그 위에서 조건을 걸고 테이블을 잇고 순서대로 실행하는 쪽이 없으면 정확도가 무너진다는 뜻이고, 그 손실이 토큰을 아끼다 생긴 것이 아니라는 뜻이기도 합니다. 스키마를 먼저 세우는 설계는 인덱스 하나로 완성되지 않고 그것을 읽어 내는 실행기와 짝을 이룰 때 성립합니다.

논문이 말하는 질의당 토큰은 오프라인 인덱싱에 든 토큰과 온라인 질의에 든 토큰을 더해 질의 수로 나눈 값입니다. 데이터셋마다 질의가 500개이고 구축비는 그 가운데 한두 번 분량이라, 질의가 늘어날수록 이 값은 온라인 한계비용 쪽으로 내려갑니다. 값싼 추출기부터 붙이는 경제 모드는 질의당 15.7K 토큰으로 F1 0.83을 냅니다. 뒤집어 말하면 같은 코퍼스에 몇 번만 묻고 마는 상황에서는 이 계산이 성립하지 않습니다.

수치를 읽을 때 함께 붙여 둘 조건도 있습니다. 세 데이터셋은 모두 저자들이 고른 것이고 gold standard도 저자들이 만들었습니다. 스키마의 최상위 층은 사람이 미리 정의했으니, 완전 자동으로 세운 인덱스의 성적은 아닙니다. 무엇보다 스키마가 틀렸을 때 그 사실이 어디서 드러나는지에 대한 장치가 아직 없습니다. 인덱스는 한 번 잘못 서면 그 위의 모든 질의가 같은 방향으로 틀립니다. 질의마다 다시 뽑는 방식이 비싼 대신 매번 새로 판단한다는 점을 생각하면, 이 설계가 옮겨 놓은 것은 비용만이 아니라 오류의 지속 시간이기도 합니다.

그래서 이 논문을 지금 파이프라인에 붙일 도구로 읽기보다, 문서 자산을 다루는 팀이 다음 세 가지를 점검하는 계기로 읽는 편이 실용적입니다.

• 지금 문서에 묻는 질문 가운데 몇 퍼센트가 매번 같은 필드를 다시 뽑고 있습니까. 반복되는 필드는 질의가 아니라 인덱스로 옮길 후보입니다.
• 그 필드를 누가 정했는지 답할 수 있습니까. 사람이 정한 경계와 모델이 채운 필드가 섞여 있다면 어디까지가 사람의 결정인지 기록해 둘 필요가 있습니다.
• 자동으로 만든 스키마가 틀렸다는 사실을 알려 줄 통로가 있습니까. 추출이 됐는지만 보는 점검은 값이 틀린 경우를 통과시킵니다.

같은 축의 이전 글로는 문서 근거를 거버넌스 데이터로 옮기는 흐름을 다룬 데이터브릭스 지니, 값만 보고 열의 의미를 복원하는 로제타, 그리고 준비도의 조건을 정리한 AI-Ready Data의 조건이 있습니다. 논문 원문은 arXiv:2608.13384에서 전문을 볼 수 있습니다.

• 1.Lin, T., Luo, Y., Tang, N. (2026). "Structure then Query: Enabling Precise Analytical Queries over Unstructured Documents." arXiv:2608.13384.
• 2.Sun, Z. et al. (2025). "QUEST: Query Optimization in Unstructured Document Analysis." Proc. VLDB Endowment, 18(11).
• 3.Lin, T., Luo, Y., Tang, N. (2026). "AnnoRetrieve: Efficient Structured Retrieval for Unstructured Document Analysis." arXiv:2604.02690.
• 4.Edge, D. et al. (2024). "From Local to Global: A Graph RAG Approach to Query-Focused Summarization." arXiv:2404.16130.