질문의 종류를 먼저 읽는다
데이터 요청인지, 시스템 설명인지, 불만·피드백인지 구분하고 데이터 요청이면 그래프·표·차트·지도 중 적절한 표현을 결정한다.
Chapter Thesis · 356-357
이 장이 바꾸는 것: 답변 생성에서 질의 구성으로
제14장은 일반적인 RAG를 조금 더 꾸미는 장이 아니다. 질문에 관련된 문단을 찾아 LLM에게 넘기는 방식에서 벗어나, 도메인 전문가가 그래프를 탐색할 때 거치는 사고 절차를 시스템 구성요소로 분해한다.
도메인의 지도를 건넨다
기술적 DB 스키마를 그대로 넣지 않고, 핵심 개체·관계·속성만 남긴 개념 스키마와 도메인 주석을 제공한다.
질의하고, 실행하고, 해설한다
자연어를 Cypher로 변환하고 실행 오류를 다시 입력으로 활용한다. 결과는 시각화와 텍스트 요약의 이중 출력으로 제공한다.
설계 원칙 — “전문가라면 무엇을 먼저 확인하는가?”를 묻고, 그 행동을 작은 분류·변환·검증 단계로 구현한다. 이 원리는 법집행뿐 아니라 의료, 금융, 과학 연구에도 그대로 이전된다.
14.1 · 357-358
법집행의 현장: 데이터는 많고, 맥락은 사람에게 있다
사건 보고서 하나는 면담, 증거 수집, 차량 조회, 위치 분석, 조직 관계 탐색으로 번진다. 각 단계가 데이터를 만들고 또 소비한다. 지식그래프는 이 흩어진 조각을 한데 묶는 단일 진실 공급원이지만, 그 가치를 현실의 판단으로 바꾸는 사람은 도메인 전문가다.
현장 경찰
사건에 대응하고 현장의 관찰과 초기 증거를 수집한다.
수사관
인물·사건·차량·장소 사이의 연결을 추적해 사건의 구조를 복원한다.
감식 전문가
물적 증거를 분석하고 관찰을 검증 가능한 사실로 변환한다.
정보 분석가
여러 출처의 패턴과 추세를 읽어 다음 조사 방향을 제시한다.
도메인 전문가가 KG를 직접 질문해야 하는 열 가지 이유
| 가치 | 현장에서의 의미 | 조직적 효과 |
|---|---|---|
| 전문성 활용 | 미묘한 맥락을 반영한 질문을 직접 만든다. | 검색 정확도와 관련성이 높아진다. |
| 신속한 판단 | 기술팀의 질의 작성 대기 시간을 제거한다. | 긴급 사건의 의사결정 지연을 줄인다. |
| 기술 장벽 제거 | Cypher를 몰라도 자연어로 탐색한다. | KG의 사용자 기반이 넓어진다. |
| 자원 효율 | IT·데이터 과학자는 반복 질의 지원에서 벗어난다. | 고난도 기술 과제에 집중할 수 있다. |
| 역할 전문화 | 분석가는 수사 맥락에, 개발자는 플랫폼에 집중한다. | 업무 경계가 선명해진다. |
| 새로운 관점 | 현장 경험에서 나온 탐색 경로가 열린다. | 기술 사용자만으로는 놓칠 통찰을 발견한다. |
| 문제 해결 강화 | 결과를 보며 즉시 질문을 수정한다. | 탐색과 가설 검증의 순환이 빨라진다. |
| 투자 수익 극대화 | 구축된 KG가 실제 업무에서 반복 사용된다. | 플랫폼 투자 가치가 현실화된다. |
| 부서 간 협업 | 기술·비기술 인력이 같은 그래프를 본다. | 공통 언어와 협업 기반이 생긴다. |
| 공유된 이해 | 사건과 데이터 구조를 동일한 관점에서 논의한다. | 조직 전체의 분석 정렬이 강화된다. |
14.2.1 · 358-361
RAG가 잘 작동하는 순간: 필요한 증거가 모두 들어왔을 때
“CASE123의 목격자 진술을 요약하라”는 요청은 모델의 학습 기억만으로 답할 수 없다. 그러나 관련 진술이 완전하게 검색되어 맥락으로 주어지면, 문제는 LLM이 잘하는 요약·비교 작업으로 바뀐다.
왼손잡이 가능성이 다소 높다
목격자 C의 왼손 전화 사용이 강한 단서로 작용한다. 다만 지갑과 가방을 오른손으로 사용한 진술도 있어 단정할 수 없다.
왼손 단서 1 · 오른손 단서 2 · 맥락상 가중치 적용
같은 모델도 어떤 증거가 들어왔는지에 따라 전혀 다른 결론을 낸다. RAG의 지능은 생성기만의 성능이 아니라 검색된 맥락의 완전성에 의해 결정된다.
완전한 맥락에서 LLM이 수행한 일
세부사항 압축
외형, 행동, 현장 증거를 항목별로 정리해 긴 진술을 빠르게 읽게 한다.
상충 단서 비교
오른손 지갑·가방과 왼손 전화 사용을 함께 보고 가능성을 비교한다.
불확실성 유지
양손잡이, 부상, 습관 차이 가능성을 남겨 추가 수사의 필요성을 제시한다.
14.2.2 · 361-363
검색 누락의 역설: 증거 하나가 빠지자 결론이 뒤집혔다
목격자 C의 진술이 검색되지 않으면 같은 질문에 대한 판단은 “오른손잡이일 가능성이 높다”로 바뀐다. 생성 모델은 주어진 문맥 안에서는 일관되고 자신감 있게 추론하지만, 보지 못한 문서를 스스로 복원할 수 없다.
독립 passage 가정
RAG는 답이 작은 독립 문단에 담길수록 잘 작동한다. 실제 답은 여러 문서와 관계에 걸쳐 있는 경우가 많다.
분절된 문맥
각 문서는 부분 단서만 제공한다. 필요한 조각이 모두 검색되지 않으면 맥락은 불완전해진다.
그럴듯한 보완
LLM은 빈틈을 질문의 상식과 관찰된 패턴으로 메우며, 잘못된 가정을 자연스러운 문장으로 포장할 수 있다.
14.3 · 363-366
전문가는 문단을 고르기 전에, 구조를 읽는다
전문가에게 열두 문서를 주고 관련 문단만 남긴 뒤 나머지를 잊으라고 하면 전문성은 오히려 약해진다. 전문가는 먼저 그래프의 청사진인 스키마를 이해하고, 질문을 개체·관계·제약조건으로 해체한다.
Red Camaro 질의 빌더
스키마의 개체·관계·제약조건이 질의로 합쳐지는 과정을 확인한다.
14.4 · 366-367
전문가 모사형 QA의 여섯 구성요소
핵심 전환은 “어떤 답을 생성할까?”에서 “어떤 형식의 질문을 그래프에 실행할까?”로 초점을 옮기는 데 있다. 자연어 질문과 사용자 선택이 입력되고, 스키마가 별도로 공급되며, 실행 오류는 질의 생성 단계로 되돌아간다.
요청 유형과 출력 방식을 분류한다.
기술 스키마를 LLM이 읽을 형식으로 변환한다.
질문·스키마·의도를 Cypher로 통합한다.
질의를 실행하고 오류와 결과를 반환한다.
그래프·표·차트·지도로 결과를 보여 준다.
질문에 필요한 사실과 통찰을 추려 서술한다.
두 종류의 사용자 맥락
질문은 원하는 정보를 서술하고, 선택 상태는 사용자가 화면에서 고른 노드·관계를 가리킨다. “선택한 사람의 형제를 보여 달라” 같은 표현은 선택 상태 없이는 해석할 수 없다.
실행 오류를 다음 질의의 재료로
잘못된 속성명·문법·방향 오류가 발생하면 DB 오류 메시지를 선택적 정보 필드로 다시 넣어 후속 시도에서 질의를 수정한다.
14.5 · 367-376
질문은 내용만이 아니라, 기대하는 표현을 품고 있다
빨간 Camaro의 결과를 수사 보드처럼 그래프로 볼지, 번호판·카메라·시간을 표로 볼지, 위치를 지도에 표시할지는 질문의 의도와 사용자의 업무에 따라 달라진다. 따라서 의도 탐지는 파이프라인의 첫 관문이다.
광의의 요청 분류
Data-Related, System-Related, Feedback/Complaints로 나눈다. 시스템 질문은 다시 문서 설명과 스키마 설명으로 구분된다.
데이터 표현 분류
데이터 요청이면 Graph, Table, Chart, Map 중 적절한 결과 형식을 선택한다. 분류 집합은 운영 경험에 따라 합치거나 확장한다.
좋은 분류 프롬프트의 여섯 조건
명확한 지시
무엇을 분류하는지 첫 문장에서 선언한다.
정의된 클래스
범주와 경계의 의미를 구체적으로 기술한다.
예시
few-shot으로 기대 패턴을 보여 준다.
경계 사례
여러 클래스로 해석될 질문을 포함한다.
출력 형식
JSON 필드와 허용값을 고정한다.
Fallback
애매한 요청을 억지로 분류하지 않을 길을 둔다.
의도 분류 실험실
교재의 범주 체계를 단순 규칙으로 체험하는 설명용 도구다.
분류 결과
Data-Related
Map
질문이 장소 표시를 직접 요청하므로 지도 표현이 적합하다.
작은 모델의 경계 오류 — “KG는 얼마나 자주 갱신되는가?”를 데이터의 타임스탬프로 답하려 하면 실제 운영 주기가 아니라 데이터 입력 습관을 측정할 수 있다. 교재는 이를 System-Related / Documentation-Related로 분류해야 한다고 본다.
reason 필드는 오분류 원인을 추적하는 디버깅 창구가 된다.단일 프롬프트인가, 다단계 분류인가
| 설계 | 장점 | 주의점 | 적합한 상황 |
|---|---|---|---|
| 단일 광의 프롬프트 | 구현과 유지가 단순하고 빠르다. | 복잡한 경계 사례에서 정확도가 낮아질 수 있다. | 초기 배포, 클래스 수가 적고 성능이 충분한 경우 |
| 다단계 분류 | 각 단계별 통제와 수정이 쉽고 세밀하다. | 구성·평가·운영 지점이 늘어난다. | 정확성이 중요하고 분류 체계가 자주 변하는 경우 |
14.6 · 376-383
기술 스키마를 그대로 주지 말라: 개념의 골격만 남겨라
apoc.meta.schema는 현재 그래프에서 라벨·속성·관계를 추출하지만, 보조 노드·관리용 속성·중복 라벨·사용하지 않는 관계까지 포함한 기술적 DB 스키마다. LLM이 필요한 것은 도메인 전문가가 사고할 때 쓰는 개념 스키마다.
Technical Schema
DB 운영과 구현 세부를 포함한다.
- 관리·보조 라벨
- 기술 메타데이터
- 미사용 속성·관계
- 중복 타입
→
Conceptual Schema
도메인의 핵심 개체와 연결만 남긴다.
- Vehicle, Person, CameraEvent
- OWNED_BY, PLATE_READ
- 질의에 쓰이는 속성
- 관계 방향
→
LLM-ready Description
일관된 텍스트 문법과 주석으로 표현한다.
- 타입이 명시된 속성
- 관계 패턴
- 약어·값 예시
- 도메인 의미
왜 개념 스키마가 필요한가
인간 추론과 정렬
전문가가 실제로 쓰는 개체·관계·속성을 중심으로 질문을 매핑한다.
LLM 인지 부하 감소
불필요한 토큰을 줄여 핵심 구조에 집중시킨다.
질의 오류 감소
구현 전용 요소와 중복 라벨로 인한 잘못된 질의를 막는다.
해석 가능성 향상
사람과 모델이 같은 도메인 구조를 읽고 검토할 수 있다.
스키마 표현 방식 비교
Listing 14.3-14.5가 보여 주는 세 단계의 차이를 전환해 본다.
Vehicle 노드는 차량을 나타낸다. 속성으로 color, make, model, style, plate_number가 있다.\n예: Toyota Camry 세단, 번호판 XYZ123.\nOWNED_BY는 차량과 소유자를 연결하며 소유 시작일을 가질 수 있다.
사람에게 친절하지만 대규모 스키마에서는 장황하고 형식이 불균일해진다.
Nodes:\n(:Vehicle { color: STRING, make: STRING, model: STRING, style: STRING, plate_number: STRING })\n\nRelationships:\n(:Vehicle)-[:OWNED_BY { since: DATE }]->(:Person)
개체·속성 타입·관계 방향을 짧고 규칙적인 문법으로 표현한다.
(:Vehicle /* 사건·소유 관계에 등장하는 차량 */ {\n color: STRING, /* BLK, GRY, SIL, WHI ... */\n make: STRING, /* BMW, BUIC, CADI, CHEV ... */\n model: STRING, /* IMP, ALT, SON, CIV ... */\n plate_number: STRING /* 차량 번호판 */\n})\n(:Vehicle)-[:OWNED_BY {since: DATE /* ISO 날짜 */}]->(:Person)
간결한 구조에 도메인 치트시트를 결합한다. “black”이 DB에는 “BLK”로 저장된다는 사실 같은 함정을 방지한다.
YAML을 이용한 실무적 관리
불필요한 요소 제거
schema:\n skip:\n classes: [AuditEvent]\n relationships: [TECH_LINK]\n properties: [internal_id]
클래스·관계·속성별로 개념 스키마에서 제외할 요소를 중앙 설정한다.
도메인 의미 추가
descriptions:\n classes:\n Vehicle: "사건 또는 소유 관계의 차량"\n properties:\n Vehicle:\n color: "BLK, GRY, WHI 등 약어"
스키마가 진화해도 사람이 읽고 수정할 수 있는 설명 계층을 유지한다.
장점 — 사용자 맞춤성, 중앙화된 유지보수, 스키마 확장에 대한 확장성을 동시에 확보한다. 구조와 설명을 분리해 핵심 프롬프트를 재사용할 수 있다.
14.7-14.7.1 · 383-386
순서가 결과를 바꾼다: 먼저 결론을 쓰면, 뒤의 설명은 변호가 된다
LLM은 토큰을 순차적으로 생성한다. 처음 내놓은 답은 이후 문맥의 일부가 되어 모델을 그 방향으로 끌고 간다. 초기 오류는 뒤의 토큰으로 전파되고, 설명은 결론을 검토하기보다 정당화하는 문장이 되기 쉽다.
답 먼저
고속도로 X→고속도로 Y→초기 결론
- 첫 경로에 일찍 고정된다.
- 공사·거리 문제를 알면서도 신뢰성이라는 사후 이유를 붙인다.
- 대안 경로의 거리를 체계적으로 비교하지 않는다.
계획 먼저
후보 나열→거리·조건 비교→결론
- 고속도로·간선도로·지역도로를 모두 후보로 둔다.
- 거리와 교통 조건을 비교한다.
- 지역도로가 최단이라는 결론과 실용적 대안을 함께 제시한다.
교재의 메시지 — 복잡한 질의 생성에서는 관계 후보와 계획을 먼저 구성하고 최종 Cypher를 나중에 생성한다. 다만 분류 과제에서는 정답 뒤의 이유가 오분류 원인을 분석하는 디버깅 정보로 유용할 수 있다.
이 페이지는 모델의 비공개 내부 사고과정을 공개하려는 것이 아니라, 출력 구조가 오류 전파와 일관성 편향에 미치는 설계 효과를 설명한다. 운영 시스템에서는 검증 가능한 계획 요약과 구조화된 중간 산출물을 사용하는 편이 안전하다.
14.7.2-14.7.3 · 386-392
Text-to-Cypher 프롬프트의 아홉 칸
자연어 질문, 주석이 붙은 스키마, 선택된 노드를 세 입력으로 받고, 입력 처리·맥락 구성·최종 지침의 세 단계에 걸쳐 프롬프트를 구성한다. 출력은 관계 목록, 계획 요약, Cypher, 성공 플래그를 가진 JSON이다.
출력 필드 순서가 하는 일
relationships
사용할 관계를 먼저 명시해 스키마에 없는 관계의 환각을 줄인다. 모델 성향에 따라 “잠재적 관계”로 완화할 수 있다.
reasoning / plan
개체·관계·제약조건과 질의 계획을 먼저 정리해 결론에 성급히 고정되는 것을 완화한다.
query
앞서 선택한 관계와 계획에 일관된 유효 Cypher 문자열을 생성한다.
success
제공된 스키마로 질의를 만들 수 있는지 명시하고, 선택 누락 같은 실패를 프로그램이 처리하게 한다.
{
"relationships": ["PLATE_READ", "HAS_EVENT"],
"reasoning": "Vehicle과 CameraEvent를 시간·색상 조건으로 제한하고 ANPR 위치를 결합한다.",
"query": "MATCH path=... WHERE ... RETURN path",
"success": true
}
각 구성요소의 실무적 이유
| 구성요소 | 설계 의도 | 실패 방지 |
|---|---|---|
| HTML-like 태그 | 질문·스키마·결과의 경계를 분명히 한다. | 지시와 데이터가 섞이는 문제 |
| 의도별 요구 | 그래프는 경로 전체, 표는 열로 쓸 속성을 반환한다. | 프론트엔드와 맞지 않는 결과 |
| 관계 방향 강제 | 스키마에 정의된 방향만 사용한다. | 실행 불가능한 패턴 |
| 현재 선택 | “선택한 사람” 같은 지시어를 해석한다. | 비어 있는 선택에 대한 허위 질의 |
| 질문 반복 | 긴 스키마 뒤에서 핵심 의도를 다시 강조한다. | 중간 컨텍스트에 의한 초점 상실 |
| 오류 정보 | 이전 실행 실패를 다음 시도의 입력으로 사용한다. | 동일 오류 반복 |
| 예시 형식 일치 | few-shot도 실제 JSON 출력 구조를 따른다. | 예시가 출력 규칙을 무너뜨리는 문제 |
14.8 · 392-396
마지막 단계는 번역이 아니라 해설이다
요약기는 파이프라인에서 실제 질의 결과를 처음으로 보는 LLM 구성요소다. 앞 단계가 “무엇을 물어야 하는가”를 다뤘다면, 이 단계는 원시 그래프 결과를 사용자가 이해할 수 있는 사실과 통찰로 바꾼다.
results_analysis: false
텍스트 요약
빨간 Camaro 2대가 지정 구역의 ANPR 카메라에서 포착되었다. 가장 최근 포착은 21:14이며, 두 차량의 번호판과 카메라 위치가 그래프에 연결되어 있다.
요약 프롬프트의 입력 사슬
원래 질문
사용자가 무엇을 알고 싶었는지 기준점을 제공한다.
실행 Cypher
시스템이 질문을 어떻게 해석했는지 보여 준다.
원시 레코드
그래프·노드 속성·관계 등 사실적 근거다.
현재 선택
사용자가 화면에서 가리킨 문맥을 유지한다.
시각화의 보완재 — 그래프를 문장으로 반복해서는 안 된다. 시각적으로 잘 보이지 않는 노드 속성, 질문에 직접 관련된 수치, 여러 경로에서 드러나는 패턴을 강조해야 한다. 완전한 경로 반환 때문에 함께 온 무관한 데이터는 걸러낸다.
results_analysis
질문이 명시적·암묵적으로 분석을 요구하는지 먼저 판정한다.
reasoning / plan
요약 범위와 필요한 분석을 정리해 출력 일관성을 높인다.
summary
기본 Markdown을 활용한 사실적이고 의미 있는 최종 문장을 반환한다.
Source Map
제14장의 도표와 Listing 전체 지도
Figures 14.1-14.12
중요 문서 검색 누락으로 잘못된 답을 내는 RAG 흐름.
Red Camaro 자연어를 스키마 매핑과 Cypher로 바꾸는 세 단계.
의도·스키마·질의·실행·시각화·요약의 전체 아키텍처.
파이프라인에서 Intent Detection이 담당하는 위치.
데이터 질문을 graph·chart·table·map으로 분류하는 구조.
데이터·시스템·불만 및 문서·스키마 하위분류.
Schema Extraction 단계의 위치와 역할.
Technical → Conceptual → LLM-friendly schema 변환.
의도·스키마·실행 오류가 모이는 Query Generation 단계.
답 먼저와 계획 먼저의 경로 선택 결과 비교.
Text-to-Cypher 프롬프트의 9개 구성요소와 JSON 출력.
질의 결과를 시각화와 요약으로 나누는 이중 출력 단계.
Listings 14.1-14.8
RAG 맥락으로 쓰는 다섯 목격자 진술. 완전·불완전 검색 비교의 실험 재료다.
apoc.meta.schema의 라벨·속성·관계 응답 구조.
Vehicle과 OWNED_BY를 자연어와 예시로 풀어 쓴 서술형 스키마.
노드·속성 타입·관계 패턴만 남긴 간결한 LLM-friendly 형식.
값 약어와 관계 의미를 인라인 주석으로 보강한 스키마.
제외할 클래스·관계·속성을 정의하는 YAML skip 섹션.
클래스·관계·속성 설명을 관리하는 YAML descriptions 섹션.
필터와 설명이 적용된 최종 Graph Schema Overview 예시.
Chapter Summary · 395-396
제14장이 남기는 여섯 문장
전문성은 절차로 옮길 수 있다
“전문가라면 무엇을 하는가?”를 묻고, 스키마 확인·의도 파악·제약 순회 같은 행동을 구현 가능한 단계로 나눈다.
Intent Detection은 두 겹이다
먼저 데이터·시스템·피드백을 가르고, 데이터 질문이면 결과 표현 방식을 다시 분류한다.
DB 스키마와 사고의 스키마는 다르다
기술적 노이즈를 제거하고 도메인 주석을 더해야 LLM이 정확한 질의를 만든다.
출력 순서는 곧 계산 순서다
관계 후보와 계획을 먼저 생성하고 질의를 나중에 생성하면 성급한 고정과 환각을 줄일 수 있다.
Text-to-Cypher에는 전체 맥락이 필요하다
스키마, 선택 상태, 의도별 요구, 예시, KG별 주석, 오류 피드백이 함께 작동해야 한다.
요약은 시각화와 경쟁하지 않는다
그래프에 보이지 않는 속성과 패턴을 짚어, 원시 결과를 사용 가능한 통찰로 바꾼다.
지식그래프에 자연어 창을 단다는 것은 Cypher 문법을 감추는 일이 아니다. 전문가가 그래프를 읽는 질서를 보존한 채, 그 질서를 누구나 사용할 수 있는 인터페이스로 옮기는 일이다.
범위와 근거 — 이 웹페이지는 첨부 도서 제14장 356-396쪽의 개념, 사례, 도표, Listing과 장 요약만을 바탕으로 재구성했다. 제15장의 LangGraph·Streamlit 구현 세부는 포함하지 않았다.