wandergo/docs/ai-eval/README.md

AI 코스 생성 평가셋 v2 (대구, 초안)

WanderGo AI 코스 생성이 조건을 지키는지, 없는 정보를 지어내지 않는지 확인하는 평가용 예시입니다. 모델·프롬프트를 바꿀 때마다 같은 예시로 돌려 점수를 비교합니다. 흐름과 규칙은 AI 코스 생성 설계 §2–§3·§9 를 따릅니다.

• course-eval-v2.jsonl — 대구판 62개. 2026-11-05 초안이며 검토 후 확정합니다.
• course-eval-v1.jsonl — 2026-10-29 초안(서울·부산·제주 등). 장소 DB 가 대구만 있어 지금은 쓰지 않고, 지역을 넓힐 때 다시 씁니다.

구성 (62개)

분류	개수	보는 것
데이트	14	분위기 요청·식사 순서·영업시간·월요일 휴관·날짜 범위 끝(30일)
축제·행사	8	그날 열리는 행사인지·행사 시간·마지막 날·없는 축제를 지어내지 않기
반려동물	10	동반 조건 엄격 적용·미확인 표시·실내 동반 장소가 없을 때 정직하게
가족	8	걷는 양·쉬는 곳·아이/어르신·접근성 정보를 단정하지 않기
외국인	6	영어 응답·한국어 장소명·식이 정보를 지어내지 않기
날씨·시간	6	예보 활용·예보 없는 날짜·이른/늦은 시간·짧은 시간
경계	10	불가능·범위 밖·위험 요청·다시 만들기·프롬프트 주입

조건 해석에서 끝나는 사례가 8개(F04·P05·W04·W06·X02·X06·X07·X10), 생성까지 가는 사례가 54개입니다.

필드

• request — 사용자가 입력하는 문장 그대로
• context — 시스템이 아는 값
  • today·now 를 고정해 결과를 재현한다(2026-11-05 목요일 10:00). 기본값은 이 시각으로 계산한다
  • baseArea — 앱의 기준 위치(동네 또는 현재 위치 좌표)
  • weather — 그 날짜·지역의 강수확률. 예보가 나오지 않는 날짜(11-09 이후)는 null
  • previousStops — 다시 만들기일 때 이전 코스의 장소 이름(X03)
• conditions — 사용자가 화면에서 확인한 조건 = 생성 API 입력(CourseConditions, 설계 §2)
  • 장소형 지역은 placeId 대신 placeName 으로 적는다. 실행기가 스냅샷에서 id 로 바꾼다
  • 조건 해석에서 끝나는 사례는 문장에서 뽑을 항목만 적는다
• inferred — 문장에서 뽑아야 하는 항목. 여기 없는 항목은 기본값이거나 사용자가 화면에서 고른 값이다
• issues — 조건 해석이 내야 하는 되묻기(설계 §2: unsupported_area · past_date · date_out_of_range · multi_day · too_short · past_midnight · unclear_request)
• expected_behavior
  • course — 코스를 만든다
  • partial_with_notice — 조건을 다 채울 수 없으면 적게 만들고 이유를 말한다
  • no_course — 요청의 핵심을 맞출 후보가 없어 만들지 않는다(AI_003 + 이유)
  • refuse_part — 위험하거나 부적절한 부분은 거절하고 나머지는 만든다
  • ask_clarification — 조건 해석에서 issues 로 되묻는다(생성하지 않는다)
  • decline_out_of_scope — 지원 범위 밖이라고 안내한다(생성하지 않는다)
• checks — 코드로 자동 채점하는 조건(조건 해석에서 끝나는 사례는 null)
  • open_at_arrival 도착부터 떠날 때까지 영업 중 · within_window 시간 안에 끝남
  • stops 장소 수 범위 · max_leg_min 장소 사이 최대 이동 시간(분, 기본 걸어서 15 · 대중교통 30 · 자동차 30)
  • pet_policy: strict 동반이 확인된 곳만 동반 가능으로 표시하고 실내는 확인된 곳만 넣는다(미확인 야외는 경고)
  • indoor_ratio_min 실내 비율 하한(비 40% 이상이면 0.5) · category_min 서로 다른 분류 수
  • meals 그 끼니 시간대(점심 11:30–14:00 · 저녁 17:30–20:30)에 도착하는 식당이 있음
  • must_include / must_exclude 꼭 넣을·뺄 것(아래 표)
• judge_focus — 사람·AI 채점자가 중점으로 볼 것
• requires — 이 장소가 AI 후보여야 돌릴 수 있는 사례(큐레이션이 필요하다). 후보에 없으면 '데이터 준비 안 됨'으로 따로 센다
• note — 기대 결과가 기대는 데이터 사정

must_include / must_exclude	뜻
cafe · food · culture · nature · attraction · leisure	그 분류의 장소. cafe>=2 는 2곳 이상. culture 는 전시 행사도 센다
event · exhibition	그날 열리는 행사 · 그중 전시
food_first · food_last · food_or_cafe_first	첫(마지막) 장소가 식당(또는 카페)
market	전통시장(관광공사 분류 SH060100·SH060200)
place:이름	그 장소
previous	이전 코스의 장소(context.previousStops)

채점

1. 조건 해석(코드) — 모든 사례. inferred 항목이 conditions 와 같은지, issues 가 같은지 본다. 시각은 ±60분까지 맞은 것으로 본다. 시간 표현의 기준값은 아래 표다.
2. 자동 채점(코드) — 생성 사례. 장소가 모두 후보 목록에 있는지, checks 를 모두 지켰는지. 하나라도 어기면 실패. 설계 §3.6 검증과 같은 함수를 쓴다
3. AI 채점자 — 요청에 맞는지, 한국어(영어)가 자연스러운지, 이유·알림이 데이터와 맞는지 1–5점
4. 사람 검토 — 매 버전 무작위 10개를 직접 본다

표현	시작	끝
오전 · 오후 · 저녁 · 밤 · 퇴근 후	10:00 · 14:00 · 18:00 · 20:00 · 19:00	시작 + 6시간(22시까지)
하루 종일	10:00	20:00
반나절 · N시간만	기본 시작	시작 + 4시간 · 시작 + N시간
저녁까지 · 늦게까지 · 오전에만	—	21:00 · 23:00 · 12:00
말이 없을 때	오늘이면 다음 정시, 아니면 13:00	시작 + 6시간(22시까지)

목표(초안): 자동 채점 통과율 95% 이상, pet_policy 위반 0건, 지어낸 정보(영업시간·동반 여부·가격) 0건.

만들면서 확인한 데이터 사정 (2026-11-05)

기대 결과는 이날 개발 DB 를 기준으로 정했습니다. 첫 실행 때 후보 스냅샷을 만들면서 다시 확인합니다.

• 반려 동반이 확인된 실내 장소가 없다. AI 후보 721곳 중 동반 정보가 있는 곳은 12곳이고 모두 공원·관광지·케이블카다. 그래서 반려동물 사례 대부분이 partial_with_notice·no_course 다. 큐레이션으로 동반 카페·식당을 확인하면 기대 결과를 다시 본다.
• 전통시장은 AI 후보가 아니다. 쇼핑 분류라 큐레이션에서 추천(O)·확인해야 후보가 된다(장소 DB §3). 서문시장 야시장 사례(F05·G02)는 requires 로 표시했다.
• 11월 대구에 축제가 없다. 행사는 수성국제비엔날레(수성못, 10-27~11-22)와 전시뿐이다. 축제를 찾는 F01 은 '없다고 말하기'를 본다.
• 계절별 시간표는 미확인이다. 하절기·동절기로 나뉜 곳(수창청춘맨숀·대구예술발전소·향촌문화관 등 23곳)은 지금 영업시간 미확인이라 문화시설이면 후보에서 빠진다. 구현 2단계에서 날짜로 고르게 고친다(설계 §3.3).
• 생성 사례는 모두 거른 뒤 후보가 8곳 이상 남는다(설계 §3.2–3.3 규칙으로 근사 계산).

정답 코스는 적지 않았습니다. 평가는 장소 DB 스냅샷 위에서 돌리므로, 정답은 "조건을 지켰는가"로 판단합니다.

검토할 때 봐 주세요

• 대구에 사는 사람이 실제로 할 법한 요청인지, 빠진 상황이 있는지
• checks 기준값(이동 시간, 장소 수, 끼니)이 너무 빡빡하거나 느슨하지 않은지
• expected_behavior 가 의도한 서비스 정책과 맞는지 (특히 반려동물 P01–P10 과 경계 X01–X10)