2026-07-28 Source Flow Debugger 실제 소스 검색 보고서

목적

기존 기록에는 실제 Godot 프로젝트를 134개 청크로 나눠 검색했고 관련 문서가 상위 결과에 포함됐다고만 적혀 있었다. 이 표현만으로는 각 청크에서 무엇이 반환됐는지, 반환된 JSONL이 SQLite에 실제로 존재하는지, 더 직접적인 문서가 SQLite에 있는데 검색 순위에서 밀렸는지 알 수 없었다.

이번 보고서는 다음 세 질문을 분리해 기록한다.

Source Flow Debugger가 청크마다 어떤 JSONL 후보를 반환했는가?
반환된 후보가 커밋된 SQLite의 검증된 원문 JSONL과 정확히 같은가?
SQLite 전체에서 확인한 직접 근거가 상위에 왔는가, 아니면 순위 개선이 필요한가?

Qwen 엔드포인트는 중단된 상태이므로 이번에는 검색과 SQLite 대조만 실행했다. Qwen의 Godot 버전 분류와 후보 승인·거절 결과는 기록하지 않았으며, 검색 후보가 나왔다는 사실을 최종 검증 성공으로 취급하지 않는다.

고정 입력

저장소: godotengine/godot-demo-projects
라이선스: MIT
커밋: cae8dc567a56d3e7936f171bcb85f0ccb9634ad0
프로젝트: 2d/hexagonal_map
입력 파일: project.godot, map.tscn, tileset.tres, tileset_edit.tscn, troll.gd, troll.tscn
입력 파일 수: 6
생성 청크 수: 134
AST 청크: 3
직접 청크: 131

실행에 사용한 SQLite는 outputs/godot-rag-sqlite/godot-rag.sqlite3이며, 실행 당시 docs_chunks 2,265건, api_mapping 1,133건, label_prototypes 2건과 embedding 3,399건을 포함했다.

실행 상태

단계	상태	이번 실행의 의미
SQLite FTS5 + Okapi BM25	실행	134개 청크 모두 검색함
embedding	미실행	쿼리 embedding API 키를 설정하지 않음
reranker	미실행	provider API 키를 설정하지 않음
Qwen validator	미실행	Qwen 엔드포인트가 중단됨

따라서 아래 순위는 전체 F 전략의 최종 순위가 아니라 lexical/BM25 단계의 결과다.

전체 대조 결과

항목	결과
청크	134
청크마다 반환된 BM25 후보	80
SQLite와 대조한 반환 후보	10,720
중복을 제거한 후보	844
SQLite에서 찾을 수 없는 후보	0
provenance가 `verified`가 아닌 후보	0
반환 `raw_json`과 SQLite 원문이 다른 후보	0
`docs_chunks` 반환	10,713
`api_mapping` 반환	7
`label_prototypes` 반환	0

반환 데이터의 정합성은 맞았다. Source Flow Debugger가 표시한 테이블과 ID를 SQLite에서 다시 조회했을 때 10,720건이 모두 존재했고, provenance가 verified였으며, 반환된 레코드와 저장된 raw_json도 같았다.

그러나 검색 품질까지 모두 맞았다는 뜻은 아니다. 134개 청크가 전부 후보 상한인 80건을 채웠기 때문에 lexical 후보가 충분히 좁혀지지 않는 상태다. 또한 파일명 anchor 보호로 BM25 점수가 더 낮은 문서가 1위로 승격된 청크가 9개 있었다.

대표 청크 결과

잘 검색된 사례

청크	입력 요약	반환 결과	SQLite 대조
1	`project.godot` 파일 형식 설명	`Manually editing project.godot` 1위	같은 ID와 원문 확인
13	`TileMapLayer`, `tile_map_data`, `TileSet`	`TileMapLayer` 속성 1위, 메서드 2위, `TileData` 3위	모두 검증된 `docs_chunks`
42	`TileSetAtlasSource`, texture region	`TileSetAtlasSource` 1위, `TileSetSource` 2위	직접 클래스 근거 확인
125	`_physics_process`, `Input.get_axis`, `move_and_slide`	`Physics process` 1위, 2D movement 문서 5~7위, `CharacterBody2D` 8위	이동·물리 관련 문서가 함께 존재
130	`CharacterBody2D` 노드	`CharacterBody2D` 클래스 1위	직접 클래스 근거 확인

청크 1의 1위 문서는 BM25 점수만으로 1위가 된 것이 아니라 project.godot lexical anchor 보호로 유지됐다. 이 경우 파일 형식 설명과 직접 맞으므로 보호가 유효했다.

순위 개선이 필요한 사례

청크 123: `extends CharacterBody2D`

실제 1위: Collision exceptions
CharacterBody2D 클래스 문서: 17위
KinematicBody2D -> CharacterBody2D 매핑: 6위

SQLite에는 정확한 CharacterBody2D 클래스 문서가 있었지만 넓은 충돌·이동 문서보다 뒤에 배치됐다. 데이터 부재가 아니라 순위 문제다. 짧은 선언 청크에서는 완전 일치하는 클래스명과 구조 필드를 일반 문맥 토큰보다 더 강하게 취급할 필요가 있다.

청크 124: `tan(deg_to_rad(30))`

실제 1위: Setting up the spring arm and camera
Evaluating expressions: 2위와 3위

1위 문서에도 deg_to_rad 사용 예가 있어 완전히 무관하지는 않지만, 호출 자체를 설명하는 문서보다 3D 튜토리얼이 앞섰다. 직접 API 설명과 단순 사용 예를 구분하는 재정렬이 필요하다.

Qwen 재검증이 필요한 구조 후보

청크 13: `PackedByteArray`가 포함된 `map.tscn`

PackedByteArray -> byte[] 매핑이 48위에 들어왔다. 저장 JSONL은 C# 컬렉션 마이그레이션을 설명하지만 입력은 GDScript 씬 리소스다. 토큰은 일치하지만 언어와 적용 문맥이 다르므로 검색 단계에서 최종 승인하면 안 된다.

청크 130: 이미 `CharacterBody2D`를 사용하는 노드

KinematicBody2D -> CharacterBody2D 매핑이 3위에 들어왔다. 이 매핑은 버전 판별에는 관련이 있지만 현재 청크에는 이전 API인 KinematicBody2D가 없다. 마이그레이션 경고로 승인할 후보는 아니며, Qwen이 JSONL과 원본 청크를 함께 보고 Godot 4 근거 또는 적용 불필요로 분류해야 한다.

두 사례의 SQLite JSONL 원문은 기계 판독 보고서의 reviewCases에 그대로 보존했다.

`label_prototypes`가 0건인 이유

SQLite의 prototype은 다음 두 건뿐이다.

enum PlaneSemanticLabel
class OpenXRSpatialComponentPlaneSemanticLabelList

hexagonal_map 청크에는 두 입력 패턴이 없었다. 따라서 이번 실행에서 label_prototypes가 0건인 것은 누락이 아니라 직접 구조 근거 필터가 작동한 결과로 판단했다.

현재 결론

반환 후보와 SQLite 원문 사이의 데이터 정합성은 확인됐다.
대표적인 프로젝트 설정, TileSet, TileMapLayer, 이동 함수 검색은 직접 관련 문서를 상위권에 포함했다.
모든 청크가 후보 상한 80건을 채워 후보 축소는 충분하지 않다.
짧은 클래스 선언과 단일 함수 호출에서는 더 직접적인 문서가 뒤로 밀리는 사례가 확인됐다.
구조 매핑은 관련 토큰만으로 후보에 들어올 수 있으므로 Qwen이 꺼진 상태에서 승인 여부를 결론 내릴 수 없다.

다음 재실행 기준

Qwen 엔드포인트가 다시 준비되면 같은 커밋과 같은 134개 청크를 사용해 다음 값을 추가한다.

각 구조 후보의 Godot 3, Godot 4, 관련 없음, 근거 부족 분류
PackedByteArray -> byte[] 같은 언어 문맥 불일치 후보의 거절 여부
이미 target API를 사용하는 청크에서 migration 적용 후보를 거절하는지
관련 없는 negative control JSONL의 거절 여부
embedding과 reranker 적용 전후의 직접 문서 순위 변화

목적