chunkText를 그대로 입력으로 유지한 상태에서, BM25, PostgreSQL full-text search, embedding, reranker, Qwen direct-evidence validator를 어떻게 조합할지 판단해야 함
처음에는 확정 설계가 아니라, ChatGPT를 통해 얻은 검색 방식별 장단점과 예/아니오 응답 흐름을 판단 재료로 모아둔 상태였음
이후 대안별 시뮬레이션과 종합 비교표를 기준으로 F 전략을 우선 채택하기로 함
F 전략은 BM25 + embedding + reranker + Qwen direct-evidence validator를 연결하는 방식임
즉, chunkText를 그대로 검색 입력으로 두고, BM25와 embedding으로 후보를 넓게 모은 뒤, reranker로 재정렬하고, 마지막에는 Qwen이 검색된 JSONL이 현재 코드 chunk와 직접 맞는 근거인지 검증하는 흐름으로 본다
다음 검증은 Qwen으로 docs_chunks, api_mapping, label_prototypes를 각 테이블마다 50개씩 테스트하는 방식으로 잡음
각 테이블에서 총 50개 수준의 샘플을 관련 있는 케이스와 관련 없는 케이스로 나눠 넣어보고, 예가 나와야 하는 케이스와 아니오가 나와야 하는 케이스의 응답이 어떻게 갈리는지 확인할 예정임
이 테스트는 검색이 잘 되는지만 보는 것이 아니라, 검색된 JSONL을 Qwen direct-evidence validator가 실제 코드 chunk와 직접 맞는 근거로 인정하거나 폐기하는지 확인하는 단계임
수기로 진행하다 보니 실제 테스트할 양이 생각보다 매우 많음
Godot 테스트 항목 50개를 만들었고, 각 항목마다 docs_chunks, api_mapping, label_prototypes 세 테이블을 모두 확인해야 함
공통 함수/문법이면 Godot 코드 chunk를 하나 만들고, docs_chunks 기대 예/기대 아니오 데이터, api_mapping 기대 예/기대 아니오 데이터, label_prototypes 기대 예/기대 아니오 데이터를 만든 뒤, 프롬프트 + 테스트 코드 + 6개 데이터를 넣어 응답 패턴이 어떻게 갈리는지 확인해야 함
공통 함수가 아니면 Godot 3용 코드와 Godot 4용 코드를 따로 만들어야 해서 사실상 작업량이 두 배가 됨
이 결과를 나중에 F1-score 같은 분류 지표로 정리하려면 모든 케이스의 true/false 결과를 수기로 남겨야 함
그래서 50개를 하루 안에 전부 끝내기는 불가능하다고 판단했고, 오늘 목표는 5개로 줄여 진행하기로 함
5개를 채운 뒤에는 단순히 테스트 개수를 더 늘리기보다, 지금까지의 예/아니오 응답 패턴을 먼저 분석하는 방향으로 전환하기로 함
실제로 50개 중 5개를 진행함
5개만 진행했는데도 Godot 3 기준으로 만든 JSONL과 Godot 4 기준으로 만든 JSONL의 응답 흐름이 달라지는 현상이 보였음
특히 버전 차이가 있는 코드에서는 Godot 3 기준 JSONL로 Godot 4 코드를 검사했을 때도 공통 문자열이나 migration 근거 때문에 예가 나올 수 있고, 반대로 Godot 4 기준 JSONL로 Godot 3 코드를 검사했을 때도 source/target 문자열이 섞여 있으면 결과가 애매해질 수 있다고 봄
그래서 다음 테스트부터는 단순히 6개 응답이 예/아니오로 맞는지만 보지 않고, 공통문법인지 버전 차이인지 먼저 나눈 뒤 JSONL 생성 기준 버전과 검사 코드 버전을 분리해서 원시 응답을 기록하는 전략으로 바꿔야 할 것 같음
이 과정에서 단순히 검증 프롬프트만 고치는 문제가 아니라, 프롬프팅 전략과 데이터셋 수집 전략도 같이 바꿔야 할 필요성을 느끼게 됨
앞으로는 JSONL을 만들 때부터 공통문법, Godot 3 전용 근거, Godot 4 전용 근거, migration 양방향 근거가 섞이지 않도록 수집/생성 기준을 더 분리해서 잡아야 할 것 같음
한편 공식문서 Markdown -> JSONL 변환도 계속 진행되어, 오늘 기준으로 전체 1,570개 Markdown 중 약 600개가 JSONL로 변환됨