이번에 더 배울 것
레이블 목록만 주는 방식(‘노드: Shipment, Warehouse, Carrier / 관계: STORED_AT, CARRIED_BY’)은 짧지만 관계의 방향과 양 끝 레이블을 알려 주지 않습니다. LLM은 (Warehouse)-[:STORED_AT]->(Shipment)처럼 그럴듯하지만 거꾸로 된 패턴을 만들 수 있습니다. 관계를 패턴 문자열 (:Shipment)-[:STORED_AT]->(:Warehouse)로 적으면 방향과 시작·끝 레이블이 한 줄에 담깁니다.
속성은 이름과 타입을 함께 적고, 값이 몇 가지로 정해진 속성은 실제 값을 나열합니다. status가 ‘in_transit, delayed, delivered’ 중 하나라고 적어 두면, LLM이 질문의 한국어 표현을 그대로 옮겨 ‘지연’이나 ‘Delayed’로 필터해 0행을 받는 일을 줄일 수 있습니다. 날짜 형식, 단위(분·km), 대소문자 규칙도 같은 이유로 적어 둡니다.
스키마가 크면 다 넣는 것이 답이 아닙니다. 레이블이 수백 개면 프롬프트가 길어지고 관련 없는 타입이 혼동을 부릅니다. 질문과 관련된 레이블만 고르는 단계(키워드나 임베딩 매칭)를 앞에 두고, 고른 부분의 관계 패턴·속성·값 예시를 적습니다. 어느 방식이든 생성 뒤의 문법·스키마 검증은 그대로 필요합니다.
작은 예제로 따라가기
방식 A(레이블 목록): ‘노드 Shipment, Warehouse / 관계 STORED_AT’ — 방향 정보가 없습니다.
방식 B(관계 패턴): ‘(:Shipment {id, status})-[:STORED_AT]->(:Warehouse {name})’ — 방향과 양 끝 레이블이 드러납니다.
방식 C(B + 값 예시): ‘status ∈ {in_transit, delayed, delivered}, Warehouse.name 예: 부산센터, 대전센터’ — 필터 값의 표기를 데이터와 맞출 수 있습니다.
같은 질문, 다른 스키마 표현
질문 “부산센터의 지연 배송 수는?”에 대해 각 스키마 표현에서 LLM이 어떤 실수를 할 수 있을지 먼저 예상해 보세요.
STORED_AT의 시작과 끝을 모르면 (w:Warehouse)-[:STORED_AT]->(s)도 그럴듯해 보입니다. 실행은 되지만 0행입니다.
학습을 시작하면 새 문제를 직접 풀고 확인 퀴즈를 마친 뒤 선택한 본과정 회차로 돌아갑니다.