ScheMatiQ: 대화형 스키마 발견을 통한 연구 질문에서 구조화된 데이터로의 변환

대규모 문서 집합에서 연구에 필요한 구조화된 데이터를 추출하려면 전문가의 수동 스키마 설계와 노동 집약적인 라벨링 작업이 필수적이었다. 이 논문은 LLM을 활용해 연구 질문에 맞는 데이터 구조를 스스로 찾아내고 데이터를 추출하는 과정을 자동화하여 연구 효율성을 극대화한다.

기존의 정보 추출 방식은 미리 정의된 고정된 스키마를 기반으로 텍스트에서 값을 찾아내는 데 집중했다. 하지만 실제 연구 현장에서는 어떤 정보를 추출해야 연구 질문에 답할 수 있을지 결정하는 스키마 설계 단계 자체가 가장 큰 병목 구간이다. ScheMatiQ은 LLM의 추론 능력을 활용해 연구 질문이 요구하는 '관측 단위(Observation Unit)'가 무엇인지 먼저 정의함으로써 이 문제를 해결한다.

먼저 LLM은 연구 질문을 분석하여 데이터베이스의 한 행이 무엇이 되어야 하는지(예: 판사, 단백질 등)를 결정한다. 그 다음, 문서 배치를 순차적으로 읽으며 해당 관측 단위를 설명하는 데 필요한 속성(필드)들을 반복적으로 제안하고 정제한다. 이는 마치 숙련된 연구원이 문서를 훑어보며 '이런 정보들을 표로 정리하면 질문에 답할 수 있겠다'라고 판단하는 과정을 모사한 것이다.

최종적으로 구축된 스키마를 바탕으로 전체 코퍼스에서 데이터를 추출하는데, 이때 '증거 규칙'을 적용한다. 즉, 문서 내에 명시적인 텍스트 근거가 있는 경우에만 값을 추출하고 해당 위치를 사용자에게 보여줌으로써 LLM의 환각 문제를 억제하고 데이터의 투명성을 확보한다.

ScheMatiQ 파이프라인은 세 가지 주요 단계로 구성된다. 첫 번째는 관측 단위 발견(Observation Unit Discovery) 단계로, 연구 질문과 문서 배치를 입력받아 [질문+문서 → LLM 분석 → 관측 단위 명칭 및 정의] 과정을 거쳐 데이터의 기본 단위를 설정한다.

두 번째는 스키마 발견(Schema Discovery) 단계이다. 시스템은 문서 배치를 반복적으로 처리하며 기존 스키마에 새로운 필드를 추가할지 결정한다. [현재 스키마 + 새 문서 배치 → LLM 필드 제안 → 필드명, 정의, 허용 값 범위 생성] 과정을 거치며, 새로운 필드가 더 이상 제안되지 않을 때까지 반복하여 스키마를 수렴시킨다.

세 번째는 구조화된 데이터 추출(Structured Data Extraction) 단계이다. 확정된 스키마를 바탕으로 각 문서에서 관측 단위의 인스턴스를 식별하고 필드 값을 채운다. [문서 텍스트 + 스키마 → LLM 추출 → (추출값, 원문 근거)] 순으로 연산이 수행되며, 한 번에 모든 필드를 채우지 못한 경우 실패한 필드만 모아 재시도하는 폴백(Fallback) 메커니즘을 포함한다.

법률 도메인 실험에서 ScheMatiQ은 전문가가 수동으로 구축한 골드 스키마 필드의 대부분을 성공적으로 복구했다. 특히 ScheMatiQ이 독자적으로 제안한 필드들은 전문가 평가에서 5점 만점에 평균 3.6점의 높은 관련성 점수를 기록하며 연구에 유용한 새로운 관점을 제시했다.

생물학 도메인(NESdb 데이터셋)에서는 관측 단위인 단백질 식별에서 87%의 재현율을 보였으며, 제안된 신규 필드들은 4.2점의 매우 높은 관련성 점수를 받았다. 이는 LLM이 단순한 데이터 추출을 넘어 도메인 전문가에게도 통찰력을 줄 수 있는 스키마 설계 능력이 있음을 시사한다.

비용 효율성 측면에서 Gemini 2.5 Flash 모델을 사용할 경우 100개의 문서당 약 1달러의 비용으로 전체 파이프라인을 실행할 수 있어, 수개월이 걸리는 인간의 수동 작업 대비 압도적인 시간 및 비용 절감 효과를 입증했다.

ScheMatiQ의 아키텍처는 React 기반 프런트엔드, FastAPI 백엔드, 그리고 핵심 로직을 담은 Python 라이브러리로 분리되어 있다. 특히 스키마 발견 과정에서 '증분 발견(Incremental Discovery)' 방식을 채택하여, 대규모 코퍼스 전체를 한 번에 처리하지 않고 배치를 통해 스키마를 점진적으로 확장함으로써 토큰 제한 문제를 해결하고 연산 효율을 높였다.

추출 단계에서는 엄격한 '근거 규칙(Evidence Rule)'을 적용한다. LLM이 값을 출력할 때 반드시 해당 값이 포함된 원문 구절을 함께 출력하도록 프롬프트를 설계했으며, 이를 통해 데이터의 추적 가능성(Traceability)을 확보했다. 또한 Gemini 2.5 Flash와 같은 최신 모델의 긴 컨텍스트 창을 활용하면서도, 복잡한 스키마의 경우 필드를 그룹화하여 다단계로 추출하는 전략을 사용해 정확도를 높였다.

폐쇄형 LLM API(Gemini 등)에 의존하기 때문에 모델 업데이트나 비결정적 생성으로 인해 동일한 입력에 대해서도 결과가 미세하게 달라질 수 있어 완전한 재현성이 어려울 수 있다. 또한 관측 단위가 한 문서 내에 너무 많이 등장하는 고밀도 문서의 경우 식별 누락이 발생할 가능성이 존재한다.