Pneuma-Seeker: A Relational Reification Mechanism to Align AI Agents with Human Work over Relational Data

이 논문은 LLM 기반 에이전트가 자연어 요청을 직접 처리하는 대신 사용자의 정보 요구를 점진적으로 구체화하는 '관계적 재구현 (relational reification)' 스키마로 표현하고 이를 기반으로 정확한 답변을 생성하는 Pneuma-Seeker 시스템을 제안하여, 다양한 도메인에서 기존 기법보다 높은 정확도와 신뢰성을 입증했습니다.

핵심

"페우마-시커 (Pneuma-Seeker)": 데이터 탐험가를 위한 나침반과 지도

이 논문은 **"데이터를 찾아서 답을 구하는 것"**이 얼마나 어려운지, 그리고 인공지능 (LLM) 이 어떻게 그 과정을 혁신할 수 있는지 설명합니다. 특히, **페우마-시커 (Pneuma-Seeker)**라는 새로운 시스템을 소개합니다.

이 복잡한 기술 논문을 일반인이 이해하기 쉽게, **'잃어버린 보물을 찾는 모험'**에 비유하여 설명해 드리겠습니다.

---

1. 문제: "무엇을 찾고 싶은지" 말하기가 어렵다

상상해 보세요. 당신은 보물 지도를 가진 탐험가입니다. 하지만 당신은 **"저기서 보물을 찾아줘"**라고만 말합니다.

• 기존의 AI (LLM) 의 문제점:
  과거의 AI 는 당신의 말만 듣고 "아, 보물이겠지!"라고 추측해서 답을 내놓았습니다. 하지만 당신이 정확히 무엇을 원하는지 (예: '보물'이 금괴인지, 보석인지, 아니면 낡은 동전인지) 말해주지 않으면, AI 는 상상해서 (환각) 엉뚱한 것을 찾아오거나, 가정을 해서 틀린 답을 내놓곤 했습니다.

  • 예시: "위험한 물품이 배송 지연을 많이 일으키나요?"라고 물었을 때, AI 는 '위험한 물품'이 정확히 무엇인지 (방사성 물질인지, 독성 물질인지) 모른 채 임의로 정의해서 엉뚱한 데이터를 분석합니다.

• 현실의 어려움:
  실제로는 데이터가 여러 부서 (구매, 물류, 회계) 에 흩어져 있고, 용어도 다릅니다. 사용자가 처음부터 완벽한 질문을 하는 것은 불가능에 가깝습니다. 질문은 살아있는 것처럼 계속 변하고 구체화됩니다.

2. 해결책: "관계형 구체화 (Relational Reification)"라는 마법

페우마-시커는 AI 가 바로 "답"을 말하게 하지 않습니다. 대신, **사용자와 AI 가 함께 그리는 '보물 지도 (스키마)'**를 먼저 만듭니다.

• 비유: 건축 도면 그리기
  • 기존 방식: "집을 지어줘"라고 하면, AI 가 바로 벽돌을 쌓기 시작하다가 엉망이 됩니다.
  • 페우마-시커 방식: "우선 우리가 지을 **집의 도면 (데이터 모델)**을 그려봅시다."라고 합니다.
    • "이 방은 '위험물' 방이고, 저 방은 '배송 지연' 방이야."
    • "이 두 방을 연결하는 문 (Join Key) 은 무엇일까?"
  • 사용자가 도면을 보고 "아, '위험물'은 방사성 물질만 포함해야 해!"라고 수정하면, AI 는 그 도면을 바탕으로 다시 자료를 찾아옵니다.

이 과정을 **관계형 구체화 (Relational Reification)**라고 합니다. 즉, 막연한 질문을 구체적인 '데이터 테이블 구조'로 바꾸는 것입니다. 이렇게 하면 AI 는 더 이상 추측하지 않고, 명확한 도면대로 일을 합니다.

3. 시스템의 작동 원리: 3 인조 탐험대

페우마-시커는 혼자 일하는 AI 가 아니라, 역할을 나눈 3 인조 팀처럼 작동합니다.

1. 지휘자 (Conductor):

   • 역할: 전체적인 작전을 지휘합니다. "우리가 지금 무엇을 찾고 있지? 도면이 맞나?"라고 확인합니다.
   • 특징: 모든 일을 한 번에 하려 하지 않고, 단계별로 계획을 수정합니다. (마치 탐험가가 지도를 보며 "아, 이 길은 막혔네, 다른 길로 가자"라고 말하는 것처럼요.)

2. 수집가 (Retriever):

   • 역할: 방대한 데이터 도서관에서 필요한 책 (테이블) 을 찾아옵니다.
   • 특징: 단순히 제목만 보고 찾는 게 아니라, 내용까지 훑어보며 정확한 책을 찾아냅니다.

3. 조립공 (Materializer):

   • 역할: 찾아온 책들을 가지고 도면대로 테이블을 조립합니다.
   • 특징: 단순히 책을 나열하는 게 아니라, 데이터를 연결하고 정제하여 실제 분석 가능한 형태로 만듭니다.

4. 핵심 기술: "확실하지 않다면 물어봐!" (Micro Context Management)

이 시스템의 가장 멋진 점은 AI 가 모르는 게 있으면 스스로 확인한다는 것입니다.

• 비유: 현미경으로 보기
  • 일반적인 AI 는 책의 목차 (스키마) 만 보고 내용을 추측합니다.
  • 페우마-시커는 "이 책에 2025 년 데이터가 정말 있을까?"라고 의심하면, 실제로 책장을 넘겨 (데이터베이스 쿼리 실행) 확인합니다.
  • "아, '위험물'이라는 열에 '방사성'과 '독성'이 섞여 있네? 그럼 이걸 분리해서 분석해야겠다!"라고 스스로 깨닫고 도면을 수정합니다.

이 덕분에 AI 는 데이터의 실제 내용을 기반으로 판단하므로, 엉뚱한 답을 내놓는 실수가 크게 줄어듭니다.

5. 왜 이것이 중요한가? (신뢰와 투명성)

• 검증 가능한 과정:
  기존 AI 는 "정답은 100 억 원입니다"라고만 말했지만, 페우마-시커는 **"우리는 A 테이블과 B 테이블을 이렇게 연결했고, C 조건을 적용해서 100 억 원이 나왔습니다"**라고 **과정 (도면과 실행 로그)**을 보여줍니다.

  • 사용자는 AI 가 뭘 잘못 생각했는지, 데이터가 어디서 왔는지 직접 확인할 수 있습니다. 이는 기업에서 AI 를 믿고 쓸 수 있는 가장 중요한 '신뢰'의 기반이 됩니다.

• 실제 효과:
  실험 결과, 페우마-시커는 다른 최신 AI 시스템들보다 정확도가 훨씬 높았습니다. 특히 복잡한 데이터를 여러 개 연결해야 하는 문제에서 빛을 발했습니다.

요약: 한 줄로 정리하면?

페우마-시커는 AI 가 "무작정 답을 맞히려고" 애쓰는 대신, 사용자와 함께 '데이터 지도'를 함께 그리는 파트너가 되어, 막연한 질문을 구체적인 데이터 작업으로 바꾸고, 그 과정을 투명하게 보여줌으로써 정확하고 신뢰할 수 있는 답을 찾아줍니다.

이 시스템은 AI 가 단순히 "지식"을 말하는 것을 넘어, 데이터를 다루는 전문가처럼 행동하게 만드는 중요한 한 걸음입니다.

기술 요약

1. 문제 정의 (Problem Statement)

조직 내에서 데이터 기반 의사결정을 내릴 때, 데이터 분석가나 도메인 전문가들은 종종 다음과 같은 두 가지 주요 병목 현상에 직면합니다.

• 정보 요구사항의 모호성 (Under-specified Information Needs): 사용자는 초기에 자신의 정보 요구사항을 정확하게 표현하지 못합니다. "재배송 (re-shipping) 을 줄이겠다"와 같은 고수준 목표는 구체적인 데이터 스키마로 즉시 변환되기 어렵습니다.
• LLM 의 취약성 (LLM Brittleness): 기존 LLM 기반 시스템은 자연어 요청을 직접 해석하여 답변을 생성하려 하지만, 의도가 명확하지 않을 때 필드 착각 (hallucination), 잘못된 조인 경로 가정, 근거 없는 답변 생성 등의 오류를 범합니다.
• 반복적 조정의 비용: 사용자와 시스템 간의 소통을 통해 요구사항을 구체화하는 과정이 수동적이고 비효율적이며, 이를 위해 팀 간 협업과 데이터 탐색/준비 (discovery & preparation) 에 많은 시간이 소요됩니다.

핵심 문제: 사용자의 모호한 정보 요구사항을 구체적인 데이터 작업으로 변환하는 과정에서, 시스템이 사용자의 의도를 추측하려다 실패하거나, 사용자가 시스템의 추론 과정을 검증할 수 없어 신뢰를 얻기 어렵다는 점입니다.

---

2. 방법론: 관계형 구체화 (Relational Reification)

이 논문은 사용자의 진화하는 정보 요구사항을 **관계형 스키마 (Relational Schema)**로 구체화 (Reification) 하는 것을 핵심 아이디어로 제시합니다.

2.1 핵심 개념: (T, S) 쌍

시스템은 사용자의 질문을 직접 답변하는 대신, 다음과 같은 두 가지 요소로 구성된 명시적인 모델로 변환합니다.

• T (Target Relations): 사용자의 요구사항을 충족할 분석 준비된 테이블들의 집합 (속성, 타입, 의미 포함).
• S (Executable Transformation): T 를 기반으로 최종 답변을 계산할 실행 가능한 변환 로직 (SQL 또는 Python 코드).

이 과정을 통해 "이동하는 목표 (moving target)"인 사용자의 질문을 **검토하고 수정할 수 있는 구체적인 산출물 (concrete artifact)**로 만듭니다.

2.2 시스템 아키텍처 (Pneuma-Seeker)

시스템은 에이전트 (Agentic) 아키텍처를 기반으로 하며, 다음과 같은 구성 요소로 나뉩니다.

1. Conductor (지휘자):
   • 사용자의 입력을 받아 (T, S) 를 계획하고 조정하는 메인 에이전트입니다.
   • 동적 계획 (Dynamic Planning): 고정된 파이프라인이 아닌, 상황에 따라 행동을 선택하는 반복 루프를 수행합니다.
   • 행동 공간: 상황 분석, 데이터 검색 (Retriever), 컨텍스트 추출, (T, S) 수정, 실행, 사용자와의 소통 등을 수행합니다.
2. Materializer (구현자):
   • Conductor 가 정의한 T 와 S 를 실제 데이터로 구현합니다.
   • 구조화된 연산자 우선: 자유로운 코드 생성 대신 조인 (Join), 합집합 (Union), 시맨틱 조인 (Semantic Join) 등 구조화된 연산자를 우선 사용하여 오류를 줄이고 신뢰성을 높입니다.
   • Provenance Graph: 데이터 변환 경로를 DAG(방향성 비순환 그래프) 로 기록하여 추적 가능성을 보장합니다.
3. Retriever (검색기):
   • Pneuma-Retriever 등을 활용하여 관련 테이블을 검색합니다.
   • 단순한 토폴로지 검색을 넘어, 테이블 이름 패턴 매칭 (Regex) 등을 통해 관련 테이블을 확장하여 검색합니다.
4. DBService & LMService:
   • 데이터베이스 (DuckDB) 를 통한 질의 실행과 영구 저장, 그리고 LLM 및 임베딩 모델 접근을 담당합니다.

2.3 컨텍스트 관리 전략

대규모 데이터와 LLM 의 컨텍스트 윈도우 제한을 극복하기 위해 두 가지 전략을 사용합니다.

• 매크로 컨텍스트 관리 (Macro Context Management): 작업을 검색, 구현, 오케스트레이션 등 여러 컴포넌트로 분해하여 각 에이전트가 처리해야 할 컨텍스트를 줄입니다.
• 마이크로 컨텍스트 관리 (Micro Context Management):
  • LLM 이 테이블 내용을 완전히 알지 못할 때, Context Extraction 행동을 통해 실행 가능한 Python 스크립트를 호출하여 데이터베이스에서 특정 값이나 분포를 직접 조회하게 합니다.
  • 이를 통해 LLM 은 추측이 아닌 실제 데이터 증거에 기반하여 (T, S) 를 구체화합니다.

---

3. 주요 기여 (Key Contributions)

1. 정보 요구사항의 관계형 구체화 (Reified Intent): 사용자의 모호한 요구사항을 시스템이 실행 가능한 스키마 (T, S) 로 변환하는 메커니즘을 제안하여, 인간과 기계 간의 협업을 구조화했습니다.
2. 고급 컨텍스트 관리 기술:
   • 매크로 수준: 에이전트 간 작업 분리를 통한 효율성 증대.
   • 마이크로 수준: 데이터베이스 기반의 능동적 컨텍스트 추출 (Context Extraction) 을 통해 LLM 이 대규모 테이블의 세부 사항을 정확히 파악하도록 지원.
3. Pneuma-Seeker 시스템 구현: 재현 가능한 데이터 발견, 준비, 실행을 지원하는 에이전트 시스템 설계 및 구현.
4. 실증 평가 및 배포 경험: 다양한 도메인 (법률, 의료, 환경 등) 에서의 벤치마크 평가와 실제 조직 (시카고 대학교) 내 배포를 통한 신뢰성, 설명 가능성, 반복 비용에 대한 실증적 데이터 제공.

---

4. 평가 결과 (Evaluation Results)

논문의 평가는 KramaBench 벤치마크와 실제 배포 데이터를 기반으로 수행되었습니다.

• 정답률 (Answer Quality):
  • Pneuma-Seeker 는 기존 SOTA 벤치마크 (DS-Guru, smolagents) 보다 전반적으로 높은 정답률을 기록했습니다. 특히 Biomedical 및 Environment 데이터셋에서 약 27~38%p 높은 성능을 보였습니다.
  • Context Extraction과 (T, S) 구체화가 정답률 향상에 결정적인 역할을 함을 증명했습니다. (예: 열 이름의 표면적 형태가 아닌 실제 데이터 분포를 확인하여 필터 조건을 정확히 설정).
• 비용 및 확장성 (Cost & Scalability):
  • 비용 - 품질 트레이드오프: Pneuma-Seeker 는 파레토 최적 (Pareto-optimal) 곡선 상에 위치하여, 높은 품질을 유지하면서 합리적인 LLM 토큰 비용을 소모했습니다.
  • 메모리 효율성: DS-Guru 와 같은 기존 방식이 모든 데이터를 메모리에 로드하는 반면, Pneuma-Seeker 는 데이터베이스 기반 실행을 통해 메모리 사용량을 크게 줄였습니다 (1GB 데이터셋 기준 DS-Guru 는 4.4GB 사용, Pneuma-Seeker 는 135MB 사용).
  • 실행 시간: 추가적인 구조화 처리로 인해 DS-Guru 보다 실행 시간이 다소 길 수 있으나, 메모리 효율성과 정확도 향상이라는 이점을 제공합니다.
• 검색 회수율 (Retrieval Recall):
  • Pneuma-Retriever 는 단순 Top-K 검색을 넘어 정규식 기반 테이블 열거 등을 통해 94~100% 의 높은 회수율을 달성하여, 필요한 모든 데이터 소스를 찾을 가능성을 높였습니다.

---

5. 의의 및 결론 (Significance & Conclusion)

• 신뢰할 수 있는 LLM 기반 데이터 시스템의 새로운 패러다임: 단순히 자연어 질문을 답변하는 것을 넘어, 사용자의 의도를 **검토 가능한 스키마 (Schema)**로 변환함으로써 시스템의 추론 과정을 투명하게 만들고 사용자의 개입 (피드백) 을 용이하게 합니다.
• 설명 가능성과 검증 가능성: 생성된 답변의 근거가 되는 데이터 소스, 변환 로직, 그리고 데이터 계보 (Provenance) 를 명확히 제공하여 사용자가 결과를 신뢰하고 검증할 수 있게 합니다.
• 실무 적용 가능성: 실제 조직 환경에서 복잡한 데이터 발견 및 준비 작업을 자동화하면서도, 사용자의 도메인 지식을 효과적으로 결합하여 고부가가치 질문으로 수렴 (Convergence) 하는 것을 가능하게 합니다.

결론적으로, Pneuma-Seeker 는 LLM 의 추론 능력을 데이터 관리 워크플로우에 통합할 때 발생할 수 있는 불확실성과 오류를 줄이고, 상호작용적, 검증 가능하며, 신뢰할 수 있는 데이터 분석 시스템을 구축하기 위한 실용적인 기반을 제공합니다.