2026-06-17 Godot RAG 판별기 기반 데이터 생성 구조 메모

구조 이미지

핵심 아이디어

이 구조의 핵심은 LLM에게 최종 라벨 결정을 맡기지 않는 것이다. LLM은 수정 코드, 설명, SFT 질문/답변, DPO 나쁜 답변, patch 초안 같은 생성 보조 역할을 맡고, 실제 라벨과 최종 JSONL 조립/검증은 로컬 시스템 파이프라인이 결정한다.

정리하면 다음 원칙이다.

LLM은 생성 보조
라벨은 시스템이 결정
최종 JSONL은 파이프라인이 조립/검증

전체 흐름

문서 준비
-> 로컬 DB 구축
-> GitHub 원천 데이터 입력
-> 심볼 추출
-> 룰/벡터/키워드 검색
-> 라벨 스코어링 및 결정
-> LLM 생성 보조
-> 최종 JSONL 생성

이 구조는 Godot 3/4 분류, API 매핑, migration fix, instruction SFT, DPO preference, repo explorer, patch generation, metadata verification 데이터를 한 파이프라인에서 만들기 위한 초안이다.

1. 문서 준비

오프라인 단계에서 Godot 공식 문서를 수집하고 정제한다.

• Godot 공식 문서 수집
• 불필요한 문구 제거
• 문서 타입 분류
• 구조 기반 파싱
• 문서 청크 생성
• 임베딩 및 인덱스 구축

생성되는 기본 산출물:

docs_chunks.jsonl

2. 구축되는 3가지 핵심 DB

API 매핑 DB

Godot 3 API와 Godot 4 API의 변경 관계를 저장한다.

예시:

KinematicBody2D -> CharacterBody2D
yield -> await
export var -> @export
move_and_slide(v) -> move_and_slide()

저장 파일:

api_mapping.jsonl

공식문서 벡터 DB

문서 청크를 임베딩해서 근거 검색용 벡터 DB를 만든다.

용도:

• 관련 공식 문서 chunk 검색
• 변환 근거 제공
• API 변경 이유 설명
• hallucination 감소

라벨 프로토타입 DB

라벨 후보와 유사도 검색을 위한 프로토타입을 저장한다.

예시 라벨:

godot3_code
godot4_code
mixed_code
broken_code

저장 파일:

label_prototypes.jsonl

3. 검색/라벨 결정

GitHub에서 수집한 원천 데이터가 들어오면 먼저 코드와 문서를 시스템이 분석한다.

입력 예시:

repo: owner/repo
file_path: scripts/Player.gd
content: ...
repo_tree: ...

시스템은 심볼을 추출한다.

예시:

KinematicBody2D
move_and_slide(velocity)
export var
yield

이후 다음 검색을 수행한다.

• API 매핑 DB 조회
• 공식문서 벡터 DB 검색
• 라벨 프로토타입 DB 검색

최종 라벨은 LLM이 아니라 시스템 스코어링으로 결정한다.

예시:

label: godot3
confidence: 0.93
bad_apis:
  - KinematicBody2D
  - move_and_slide(v)
  - export var
replacement_apis:
  - CharacterBody2D
  - move_and_slide()
  - @export

4. LLM 생성 보조

LLM은 라벨을 직접 결정하지 않고, 시스템이 결정한 라벨과 근거를 입력으로 받아 생성 작업을 보조한다.

가능한 생성 작업:

• 수정 코드 생성
• 설명/근거 생성
• SFT 질문/답변 생성
• DPO 나쁜 답변 생성
• 파일 탐색 정답 생성
• patch 생성 보조
• 검증/문제점 분석

중요한 점은 다음이다.

LLM 생성 결과는 초안이다.
라벨, 최종 스키마, confidence, 검증 여부는 시스템이 관리한다.

5. 최종 JSONL 생성

파이프라인은 시스템 결과와 LLM 생성 결과를 하나의 JSON 객체로 조립한다.

검증 단계에서는 다음을 확인한다.

• 필수 필드 존재 여부
• 라벨 일관성
• 잘못된 API 잔존 여부
• confidence 재계산
• 문서 근거와 출력의 연결성

생성되는 8가지 데이터셋

1. 버전 분류 데이터

파일:

version_classification.jsonl

내용:

• Godot 3/4/mixed/broken 분류
• valid_for_godot4 판단
• bad_apis 추출

2. API 매핑 데이터

파일:

api_mapping.jsonl

내용:

• old_api -> new_api 매핑
• change_type, category 등

3. 변환/수정 정답 데이터

파일:

migration_fix.jsonl

내용:

• before/after 코드
• 변경 이유
• 설정 목록

4. 질문/답변 SFT 데이터

파일:

instruction_sft.jsonl

내용:

• instruction/input/output
• 다양한 패턴의 샘플

5. DPO 선호 데이터

파일:

dpo_preference.jsonl

내용:

• chosen
• rejected
• 이유/조건

6. Repo Explorer 데이터

파일:

repo_explorer.jsonl

내용:

• 작업/오류 해결을 위해 읽어야 할 파일 예측
• 읽어야 하는 이유

7. Patch 데이터

파일:

patch_generation.jsonl

내용:

• before/after
• unified diff / patch
• 적용 이유

8. 메타/검증 정보

파일:

metadata_verification.jsonl

내용:

• confidence
• 점수
• 근거
• 출처 문서 chunk id
• 품질/위험 정보

실행 요약 흐름

GitHub 원천 데이터
-> 심볼 추출
-> 룰/DB 검색
-> 라벨 스코어링
-> LLM 생성 보조
-> 최종 JSON 조립 및 저장

핵심 원칙

• 라벨은 시스템이 결정한다.
• LLM은 생성 보조 역할만 담당한다.
• 최종 JSONL은 파이프라인이 조립하고 검증한다.
• 근거 문서, 스코어, confidence, 출처 정보를 함께 저장한다.
• 잘못된 Godot 3 API가 남아 있는지 반드시 검사한다.