대안 E: Qwen query profile 생성

흐름

raw chunkText
  -> Qwen에게 검색용 JSON 생성 요청
  -> 생성된 JSON으로 BM25/vector 검색
  -> JSONL 후보 반환

예시 출력

Qwen이 잘 뽑으면 다음처럼 검색 profile을 만들 수 있다.

{
  "search_intent": "Godot 4 2D player movement tutorial",
  "important_literals": [
    "Input.is_action_pressed",
    "Vector2.ZERO",
    "AnimatedSprite2D",
    "position.clamp",
    "screen_size"
  ],
  "likely_doc_topics": [
    "first 2D game",
    "coding the player",
    "player movement",
    "clamp position to screen",
    "play and stop AnimatedSprite2D"
  ],
  "migration_signals": []
}

장점

하드코딩을 줄일 수 있다.
복잡한 chunk에서 의도를 요약할 수 있다.
검색어를 사람이 읽기 좋게 만들 수 있다.
Godot 문맥 추론을 Qwen에게 맡길 수 있다.

단점

느리다.
비용이 든다.
검색 전 단계부터 hallucination이 들어갈 수 있다.
Qwen이 없는 단서를 만들어낼 수 있다.
잘못된 migration intent를 만들어 api_mapping을 잘못 끌고 올 수 있다.

실패 예시

기준 chunk에는 AnimatedSprite2D가 있지만, Qwen이 다음처럼 잘못 요약하면 위험하다.

{
  "migration_intent": "Godot 3 to Godot 4 migration",
  "important_terms": ["AnimatedSprite", "AnimatedSprite2D"]
}

이 경우 정상 Godot 4 코드인데 migration mapping을 잘못 끌고 올 수 있다.

PoC 시뮬레이션

기준 chunk를 Qwen에게 먼저 넘겨 검색 profile을 만들게 한다.

입력:

SOURCE_CODE:
func _process(delta):
  ...
  $AnimatedSprite2D.play()
  position = position.clamp(Vector2.ZERO, screen_size)

성공 profile:

{
  "search_intent": "Godot 4 2D player movement tutorial",
  "important_literals": [
    "Input.is_action_pressed",
    "Vector2.ZERO",
    "AnimatedSprite2D",
    "position.clamp",
    "screen_size"
  ],
  "migration_signals": []
}

이 profile로 검색하면 기대되는 후보는 다음이다.

docs_chunks:
  first_2d_game / coding_the_player
  first_2d_game / clamp and screen bounds section

api_mapping:
  거의 없음 또는 낮음

label_prototypes:
  거의 없음 또는 낮음

실패 profile:

{
  "search_intent": "Godot 3 to Godot 4 migration",
  "important_literals": [
    "AnimatedSprite",
    "AnimatedSprite2D",
    "KinematicBody2D"
  ],
  "migration_signals": ["AnimatedSprite to AnimatedSprite2D"]
}

실패 profile이 위험한 이유:

SOURCE_CODE에는 AnimatedSprite가 없다.
SOURCE_CODE에는 KinematicBody2D가 없다.
SOURCE_CODE는 Godot 4 정상 코드일 수 있다.
그런데 Qwen이 migration intent를 만들면 api_mapping/label_prototypes를 잘못 검색할 수 있다.

PoC에서 확인할 로그

Qwen query profile 방식은 검색 전에 LLM이 개입하므로, 다음 로그가 반드시 필요하다.

1. raw chunkText
2. Qwen이 만든 query profile JSON
3. profile 안의 important_literals가 SOURCE_CODE에 실제 존재하는지
4. profile 안의 migration_signals가 SOURCE_CODE에 실제 존재하는지
5. profile로 검색한 후보
6. raw chunkText로 검색한 후보와의 차이

눈에 보이는 결론:

Qwen profile이 잘 나오면 검색어가 보기 좋아진다.
하지만 없는 단서를 만들어내면 검색 전 단계에서 결과가 오염된다.
그래서 Qwen은 검색 전보다 검색 후 validator로 쓰는 편이 안전하다.

판정

검색 품질 실험용으로는 좋음
프로덕션 1차 검색기로는 신중

원문 메모의 판단은 Qwen을 검색 전 query 생성기보다 검색 후 direct-evidence validator로 쓰는 편이 더 안전하다는 쪽이다.