대회 개요와 목표

• KDD Cup 2026은 ACM SIGKDD 연례 학회에서 개최되는 데이터 마이닝/AI 대회의 일부로, 2026년 8월 제주에서 발표된다. 이번 대회의 한 트랙인 “Data Agents” 챌린지는 다양한 데이터 소스와 도구를 활용하여 복잡한 분석 질문을 스스로 분해·계획·수행할 수 있는 자율 데이터 에이전트를 구축하는 것이다. 이는 단순한 질문‑응답 시스템을 넘어, 이종 데이터 패키지를 이해하고, 여러 도구를 사용하며, 멀티 스텝으로 추론·계산을 수행하는 “데이터 중심 에이전트” 연구를 자극하려는 목적이다 .
• 대회 기간은 **2026‑03‑15 (AoE) \~ 2026‑08‑09 (AoE)**로, 3월에 예제 데이터와 Starter Kit이 공개되고 4월부터 Phase 1이 진행된다 .
• 공식 홈은 dataagent.top이며, 대회 규칙·타임라인·등록·데이터 설명 등이 제공된다. 대회에 참가하려면 **팀 등록(최대 3명+지도자 1명)**을 하고 KDD Cup 참가 규정을 준수해야 한다 .

데이터 및 DataAgent‑Bench

데이터 구조

• 대회에서 사용하는 DataAgent‑Bench는 여러 작업(task)으로 구성되며 각 작업은 고유 식별자 task_<id>를 가진다. 입력 데이터는 /input/task_<id>/ 경로 아래 제공된다 .
• 각 작업 폴더에는
  • task.json : 작업의 메타데이터(작업 ID, 난이도, 질문)를 포함 .
  • context/ 디렉터리 : 작업 수행에 필요한 이종 데이터 소스들을 포함. 각 작업별로 존재하는 하위 디렉터리가 다를 수 있으며 csv/ (구조적 테이블), db/ (SQLITE DB), json/ (semi‑structured JSON), doc/ (문서), knowledge.md (배경 지식) 등이 있다 .
  • prediction.csv : 참가자가 작성하여 /output/task_<id>/에 저장해야 하는 결과 파일 .

난이도 및 데이터 모달리티

• Easy : CSV/JSON + knowledge 문서로 구성되며, Python 코드 생성을 통해 간단한 데이터 분석 워크플로를 수행한다 .
• Medium : CSV/JSON + 데이터베이스 + knowledge 문서가 포함되어 Text‑to‑SQL 및 다중 소스 분석이 필요 .
• Hard : 위 자료들에 10 K\~128 K 토큰 규모의 데이터 문서가 추가된다 .
• Extreme : Hard와 같은 모달리티에 문맥 길이가 128 K 토큰을 초과하는 데이터 문서가 제공되어, 초장문 컨텍스트 관리와 메모리 효율성 문제가 핵심 과제로 제시된다 .

에이전트의 수행

• 에이전트는 고수준 질문을 여러 단계로 분해하고, 각 단계에서 적절한 도구(예: SQL, Python, 이미지 분석)를 호출하며, 최종적으로 prediction.csv를 작성해야 한다 .
• 예를 들어, 특정 지역의 최고 성장률을 PDF 보고서에서 읽어낸 뒤, 데이터베이스에서 해당 지역의 매출을 SQL로 질의하고, 차트 이미지에서 목표 매출을 추출한 후 Python으로 퍼센트 차이를 계산하는 식이다 .
• 이러한 프로세스는 분기·병합·반복 루프를 포함하는 DAG 형태의 추론 그래프를 형성한다 .

Starter Kit 및 베이스라인

• 주최측은 ReAct 프롬프트 기반의 기본 에이전트가 포함된 Starter Kit를 제공한다. Python uv 패키지를 이용해 종속성을 설치하고, uv run dabench run-benchmark 명령으로 베이스라인을 실행할 수 있다 .
• 에이전트는 다음과 같은 도구들을 사용할 수 있다 :
  • list_context: 컨텍스트 디렉터리 탐색
  • read_csv, read_json, read_doc: CSV/JSON/문서 미리 보기
  • inspect_sqlite_schema 및 execute_context_sql: 데이터베이스 구조 확인 및 SQL 실행
  • execute_python: Python 코드를 실행해 계산과 데이터 가공 수행
  • answer: 최종 결과 테이블 제출
• 각 도구 호출은 JSON 형식으로 전달되며, Qwen LLM은 툴 호출 선택을 자동으로 처리할 수 있다 .
• 베이스라인은 ReAct(Retrieve–Act) 패턴을 따르는데, 시스템 프롬프트, 질문 프롬프트, 관찰 프롬프트가 정의되어 있고 각 단계에서 LLM이 다음 액션(도구 선택/실행)을 결정한다 .

평가 및 채점 방식

자동 채점 (Leaderboard Track)

• 각 작업에 대한 prediction.csv와 숨겨진 gold.csv를 비교한다. 컬럼 이름은 무시하고 각 컬럼의 값 벡터(정렬된 형태)를 기준으로 매칭한다 .
• 완벽히 일치하는 골드 컬럼을 모두 포함하면 점수 1을 부여하고, 컬럼을 누락하거나 값이 다른 경우 0점이 주어진다 .
• 더 일반적인 평가는 리콜 지향 점수에 소량의 과잉 컬럼 패널티를 적용하여 Score = Recall − λ · (Extra Columns / Predicted Columns)로 계산한다 .
• 모든 작업의 평균 점수가 총점이며, 동점일 경우 제출 시간이 빠른 팀이 상위에 랭크된다 .

크리에이티브 트랙 평가 (Phase 2)

• Phase 2에서는 자동 평가 외에 시스템 설계, 인터페이스 사용성, 투명성 등을 종합적으로 평가하는 Creative Track이 있다 .
• 해당 트랙에서는 주최측 및 스폰서가 제출된 시스템을 직접 평가하며, 사용자 경험, 혁신성, 설명 가능성 등이 중시된다 .

일정 및 전반적인 요구 사항

제출 및 도커 요구 사항

• 제출 형식은 도커 이미지 하나뿐이다. 참가자는 에이전트 프로그램과 모든 의존성을 포함한 도커 이미지(teamID:vN)를 만들고, 이를 tar.gz 아카이브(teamID_vN.tar.gz)로 내보내 Google Drive 링크를 이메일로 보내야 한다 .
• 이미지는 10 GB를 넘지 않아야 하며, ENTRYPOINT/CMD로 실행될 수 있어야 한다 .
• 평가 시 컨테이너에는 16 CPU, 64 GB RAM이 제공되며, 총 실행 시간은 12 시간이다. GPU는 제공되지 않으며, 모델 추론은 주최측에서 일괄 처리한다 .
• 컨테이너는 /input(읽기 전용)에 모든 작업을, /output(쓰기) 디렉터리에 결과를 작성해야 하며, 모든 작업을 자동으로 순회하여 prediction.csv를 생성해야 한다 .
• 인터넷 접근은 전면 차단된다. LLM 호출은 주최측이 주입한 MODEL_API_URL과 MODEL_API_KEY 환경 변수만을 사용해야 하며, 자체 LLM을 주요 추론 엔진으로 실행하는 것은 금지된다 .
• 팀당 하루 1회 제출, Phase 1 전체 기간 동안 최대 30회 제출이 허용된다 .

성공 전략

1. 에이전트 설계 전략

1. 복잡한 계획 수립 – 질문을 분해하여 데이터 탐색, 필터링, 요약, 집계, 계산 등의 세부 단계로 계획해야 한다. ReAct 패턴을 활용하여 “생각–도구 사용–관찰” 루프를 반복하며, 오답을 수정하거나 추가 정보를 탐색하는 branch/merge/loop 구조를 구현한다.
2. 툴 선택 자동화 – Qwen3.5‑35B‑A3B 모델은 OpenAI‑Style Tool Calling을 지원한다 . 이 기능을 적극 활용하려면 각 도구의 schema와 role을 명확히 정의하고, 프롬프트에 도구 설명과 사용 예시를 포함하여 모델이 적절한 도구를 선택할 수 있도록 해야 한다.
3. 하이브리드 접근 – 모델에게 모든 작업을 맡기지 않고, Python 코드에서 데이터 탐색·필터링·통계 계산 등은 직접 수행하도록 한다. 예를 들어, 단순 집계는 execute_context_sql 또는 execute_python에서 구현하고, 복잡한 자연어 질의 해석이나 추상적 reasoning은 LLM에 맡긴다.
4. 메모리 및 컨텍스트 관리 – Hard/Extreme 난이도에서는 10 K\~128 K 이상 길이의 문서가 제공된다 . 긴 문서를 슬라이딩 윈도우/요약 기법으로 분할하여 필요한 부분만 LLM에 전달하거나, embedding 기반 검색을 이용해 관련 부분을 찾은 후 요약하도록 한다.
5. 오류 검출 및 자기‑반성 – 단계별 결과를 검증하는 절차를 삽입한다. 예를 들어, SQL 실행 결과의 행 수와 스키마를 확인하거나, 문서 추출 결과가 질문의 맥락과 일치하는지 검사한다. 문제 발견 시 이전 단계를 반복하거나 대안을 시도한다.
6. 대화 프롬프트 최적화 – Qwen3.5‑35B‑A3B의 문맥 길이(약 262 K 토큰)와 툴 콜 파서 규칙 을 고려하여, 시스템 프롬프트에 역할 및 규칙을 명확히 서술하고, user 프롬프트에는 간결하면서도 핵심 정보를 담는다.
7. 병렬 처리와 타임아웃 – 제출된 컨테이너는 400개 내외의 숨겨진 작업을 12시간 안에 처리해야 한다 . max_workers를 적절히 설정하여 여러 작업을 병렬로 처리하고, 각 작업별 시간 제한을 두어 전체 타임라인을 초과하지 않도록 한다.

2. 개발 및 평가 준비

1. Demo 데이터셋을 통한 실험 – 공개된 Phase 1 Demo 데이터셋을 다운로드하여 에이전트 로직을 테스트하고, 다양한 난이도별 데이터를 탐색한다. 베이스라인을 실행하여 출력 형식과 expected behavior를 파악한다 .
2. 로컬 LLM 활용 – 개발 단계에서는 자체 LLM(OpenAI, Claude 등)을 사용할 수 있다 . 단, 코드에서는 환경 변수로 base URL과 API 키를 읽어야 하므로, 로컬 테스트 시 자신의 서비스 주소와 키를 설정한다.
3. 컨테이너 테스트 – 로컬에서 Docker 컨테이너를 빌드하고 /input과 /output 구조를 모의하여 전체 파이프라인을 점검한다. 특히 파일 권한(read‑only vs read‑write)을 준수하고, 컨테이너 내에서 외부 네트워크가 차단되는 상황을 재현하여 테스트한다.
4. 로깅 및 디버깅 – stdout과 stderr를 /logs/runtime.log로 redirect하여 실행 도중 발생하는 오류를 기록하고, 코드가 예외 상황에서 로그를 남기도록 구현한다 . 이는 주최측이 디버깅 지원을 제공하는 데 중요하다.
5. 모듈화 및 버전 관리 – Agent 설계와 도구 구현을 모듈화하고, 실험 설정(프롬프트, 툴 구성, 하이퍼파라미터)을 YAML 또는 JSON으로 관리하여 다양한 구성을 쉽게 시험할 수 있도록 한다.

3. Phase 2 Creative Track 준비

• 리더보드 트랙뿐만 아니라 Creative Track에서는 사용자 인터페이스, 시스템의 투명성, 의사결정 과정 설명 등이 중요한 평가 요소이다 .
• 이 트랙에 대비하여 웹/GUI 기반 시스템을 설계해 데이터 패키지를 업로드하고 자연어 질문을 입력하면 에이전트가 실행되는 과정을 시각적으로 보여주는 기능을 구현해볼 수 있다.
• 또한, 도구 호출과 intermediate 결과를 로그에 기록하여 사용자에게 설명 가능한 reasoning 과정을 제공하는 것이 좋다.
• 팀의 연구 아이디어를 잘 설명하고, 결과의 정확성뿐만 아니라 사용성, 확장성, 인사이트 제공 능력을 강조한다.

요약

KDD Cup 2026 “Data Agents” 챌린지는 복잡한 분석 질문을 자율적으로 계획하고 실행하는 에이전트 개발을 목표로 한다. 참가자는 이종 데이터가 제공되는 여러 작업을 해결하기 위해 Agent를 설계하고, 도구를 통한 멀티 스텝 추론을 구현해야 한다. 공개된 Starter Kit과 Phase 1 Demo 데이터를 활용하여 모델을 개발하고, **제출 이미지(Docker)**를 통해 주최측 모델과 환경에서 평가된다.
핵심 성공 전략은 철저한 계획 수립, 도구 활용 최적화, 긴 문서에 대한 메모리 관리, 병렬 처리 및 시간 관리, 로깅/디버깅이다. Phase 2의 Creative Track에 진출하려면 시스템의 사용성·투명성도 크게 개선해야 한다. 이를 통해 상위권에 입상하고, KDD Cup 워크숍에서 결과를 발표할 기회를 얻을 수 있다.