JSONL 근거 매칭 프롬프트 관찰

작성일: 2026년 6월 27일

목적

오늘은 Source Flow Debugger에서 실제 DB 검색을 붙이기 전에, GPT에게 데모용 Godot 코드 chunk와 JSONL 후보를 만들게 하고, LLM이 그 JSONL을 근거로 제대로 관련/무관을 판정하는지 확인했다.

처음 생각은 단순했다.

SOURCE_CODE + JSONL 후보
  -> 이 JSONL이 source code에 해당하는 내용을 담고 있는가?
  -> 예 / 아니오

하지만 실제로는 이 질문만으로는 부족했다. LLM이 JSONL 안의 직접 문자열 근거가 아니라, Godot에 대한 자기 지식이나 넓은 주제 유사성을 이용해 “예”라고 판단하는 현상이 있었다.

데모 데이터 생성

먼저 GPT에게 임의의 Godot chunk와 관련 JSONL, 무관 JSONL을 만들게 했다.

요청 의도는 다음과 같았다.

임의의 Godot chunk와 임의의 JSONL을 만든다.
Godot chunk는 일부러 Godot 3 코드로 만든다.
JSONL은 Godot 4 변환 근거가 담긴 것과 전혀 관련 없는 것을 둘 다 만든다.
LLM에게 던졌을 때 관련 JSONL과 무관 JSONL의 차이가 드러나는지 테스트한다.

캡쳐:

초기 프롬프트 문제

처음에는 다음처럼 물었다.

이거 jsonl이 소스코드에 해당하는 내용이 담겨있어?
답변은 예 / 아니오만

이 방식에서는 관련 JSONL을 넣었을 때도 예가 나오고, 무관 JSONL을 넣었을 때도 예가 나왔다.

관련 JSONL 결과:

무관 JSONL 결과:

문제는 질문이 너무 넓었다는 점이다. “소스코드에 해당하는 내용이 담겼냐”라고만 물으면, LLM은 Godot, Godot3, Godot4, migration, 2D, physics 같은 넓은 단어만 보고도 관련 있다고 판단할 수 있다.

이러면 Retriever가 엉뚱한 JSONL을 가져왔을 때도 LLM이 자기 지식으로 메워서 “예”라고 해버릴 수 있다. 이건 우리가 원하는 검증이 아니다.

수정한 프롬프트

그래서 프롬프트를 근거 매칭 판정기로 바꿨다.

너는 JSONL 근거 매칭 판정기다.

아래 SOURCE_CODE에 대해 아래 JSONL이 직접적인 변환 근거를 포함하는지 판정하라.

판정 기준:
- JSONL의 source_api, source_pattern, match_terms, required_when_seen_in_code, before_code 중 하나가 SOURCE_CODE 안의 실제 문자열 또는 API 호출과 직접 일치해야만 "예"다.
- 단순히 Godot, Godot3, Godot4, migration, 2D, physics 같은 넓은 단어가 같으면 관련 없음이다.
- JSONL에 "does not describe", "not related", "unrelated", "does not apply"처럼 부정적으로 언급된 내용은 관련 근거로 인정하지 않는다.
- JSONL이 다른 API, 다른 노드, 다른 시스템에 대한 내용이면 "아니오"다.
- 네가 알고 있는 Godot 지식은 사용하지 말고, JSONL에 적힌 문자열 근거만 사용하라.
- 답변은 반드시 "예" 또는 "아니오" 하나만 출력하라.

이 프롬프트에서는 판단 기준을 “직접 문자열 근거”로 좁혔다.

특히 다음 필드 중 하나가 SOURCE_CODE의 실제 문자열/API 호출과 직접 맞아야 한다고 제한했다.

source_api
source_pattern
match_terms
required_when_seen_in_code
before_code

또 LLM이 넓은 주제어와 자기 Godot 지식으로 추론하지 못하게 막았다.

수정 후 결과

관련 JSONL은 예로 나왔다.

무관 JSONL은 아니오로 나왔다.

이 결과를 통해, DB 검색 뒤 LLM 검증 단계는 단순한 의미 유사도 판정이 아니라 “검색된 JSONL 안에 현재 chunk와 직접 맞는 문자열 근거가 있는가”를 먼저 확인해야 한다는 점을 다시 확인했다.

오늘 얻은 기준

DB 검색 결과 검증 프롬프트는 다음 기준을 가져야 한다.

• 넓은 주제 유사성은 근거로 인정하지 않는다.
• LLM의 사전 Godot 지식으로 부족한 근거를 메우게 하면 안 된다.
• JSONL 안의 명시 필드가 현재 chunk의 실제 문자열/API 호출과 직접 맞아야 한다.
• 부정적으로 언급된 JSONL 내용은 관련 근거로 인정하지 않는다.
• 관련/무관 1차 판정은 짧고 강하게 예 또는 아니오로 제한하는 편이 낫다.

이 기준은 내일 DB 검색을 붙일 때 중요하다.

docs_chunks, api_mapping, label_prototypes에서 후보 JSONL을 가져온 뒤, Qwen 검증 단계는 다음처럼 동작해야 한다.

chunkText
  -> DB 검색으로 JSONL 후보 수집
  -> prompt + chunkText + retrieved JSONL
  -> JSONL에 직접 문자열 근거가 있는지 판정
  -> 관련 없는 JSONL은 폐기
  -> 관련 있는 JSONL만 이후 설명/마이그레이션 판단 근거로 사용

오늘 실험의 핵심은 “LLM이 맞게 아는가”가 아니라 “LLM이 JSONL에 적힌 근거만 보고 판정하게 만들 수 있는가”였다. 이게 안 되면 Retriever가 가져온 무관 후보도 LLM이 그럴듯하게 이어붙일 수 있다. 그래서 검색 품질뿐 아니라, 검색 결과 검증 프롬프트 자체도 별도로 설계해야 한다.