[5단계] 데이터 컨텍스트 보강 설계 - 100-hours-a-week/KTB4-3rd-wiki GitHub Wiki

[5단계] 데이터/컨텍스트 보강 설계

기능 1,2 - 이미지 판정

  • Visual RAG 사용 안함.

    • 이유 :
      1. Visual RAG는 이미지-텍스트 쌍을 사용하는데, 이 서비스에서는 단순히 이미지가 들어오고, 유사한것을 판정하는게 아닌, 이미지 내부의 정보를 판정하는것이기 때문에 사용하면 안됨.
      2. 지식이 필요한게 아니라 이미지 내부의 정보를 판정하는것이기 때문에, 사용하면 안됨.

  • 보강을 위해 파인튜닝은 고려할만함.

    1. JSON 형식고정 파인튜닝은 진행 예정
    2. 이후 포지셔닝을 학습시키는 파인튜닝은 고려하고 있으나, 데이터 확보와 라벨링에 상당한 시간이 소요되므로, 우선순위가 낮음

  • 양자화는 하지 않을것.

    1. 이미 초경량 모델이라 실측에서 확인한 바로 성능 저하가 심각했음.

기능 3 - 혼잡도 분석

  • RAG 사용 안함.

    • 이유 :
      1. 최근 제보의 의미를 분석하는 기능이라, 판단 근거가 해당 게시글 묶음의 원글·댓글 자체임. 외부에서 검색해 올 지식이 없음.
      2. 과거 제보를 검색해 넣으면 만료된 혼잡 정보가 현재 판정을 오염시킴. 같은 장소의 어제 판정은 지금의 근거가 될 수 없음.

  • 별도의 문맥 캐시나 복원 로직 없이 요청 자체로 문맥을 채움.

    1. 댓글은 단독으로 해석되지 않음. "저도요"만 주면 혼잡도와 무관한 글로 버려지지만, 부모 원글("판교역 지금 사람 너무 많아요")을 같이 주면 HIGH 제보 한 건으로 살아남음.
    2. 게시글 묶음에 변화가 있으면 Spring은 원글과 최근 20분의 현재 댓글 전체를 매 요청에 다시 담아 보냄. 원글이 20분보다 오래됐어도 유효한 댓글이 있으면 함께 보냄. AI는 원문을 따로 보관하지 않아도 새 댓글을 해석할 수 있음.
    3. AI가 보관하는 것은 신호별 판정(혼잡 단계·원인)뿐이고 원문은 보관하지 않음. 판정은 25분간 재사용하며, 이 재사용 기간은 20분 집계 유효 시간과 별개 값임.
    4. 시각(created_at)은 요청 기준 상대 시각으로 변환해 같이 넣음. 위치(spot_name)는 1단계 요청 스키마에 없어 지금은 넣지 못함 — Spring과 협의해 정식 필드로 추가되면 같이 넣음.
    5. 보강 위치는 [4단계]의 게시글 묶음 구성 단계. LLM 호출은 게시글 묶음당 1회 그대로임.

  • AI의 분석 상태 자체를 잃었을 때는 지어내지 않고 다시 받음.

    1. 재시작·재배포로 보관 중인 판정을 잃으면 AI는 해당 요청을 적용하지 않고 409 STATE_RESET을 반환함. 가짜 판정을 만들지 않음.
    2. Spring은 현재 유효한 게시글 묶음 전체를 다시 보내고, AI는 전체 분석에 성공해야 정상 처리로 돌아감. 하나라도 실패하면 503을 반환하고 복구 대기를 유지함.
    3. 즉 상태 유실이 결과를 틀리게 만들지 않고, 전체가 성공할 때까지 한 주기씩 늦어질 뿐임.

  • 보강 효과는 A/B로 검증함.

    • 확인할 것 : 상대 시각을 모델 입력에 추가하는 것이 그만큼 늘어난 입력 토큰값을 하는지. 위치(spot_name)는 1단계에 필드가 생긴 뒤 별도로 검증함.
      1. A는 원글·댓글 본문만, B는 상대 시각 보강. 모델과 프롬프트는 동일.
      2. 이득 - 판정 정확도, 그중에서도 관련 여부(RELEVANT/IRRELEVANT) 혼동이 몇 건 줄어드는지.
      3. 비용 - 게시글 묶음당 입력 토큰 수와 처리 시간. 댓글이 쌓일수록 문맥이 길어지므로 AI 응답 제한 50초와 API 비용에 반영됨.
      4. 이득이 비용을 넘지 못하면 시각 보강도 뺌.

  • LangChain은 우선 도입하지 않음.

    • 이유 :

      1. 지금 하는 보강은 요청에 이미 담긴 원글·댓글에 상대 시각을 붙이는 것뿐이라 체인으로 묶을 단계가 없음.
      2. 검색이나 여러 도구를 조합할 일이 없어서 직접 구성하는 편이 더 단순함.

    • 추후 검토 : 외부 검색이나 여러 단계를 조합해야 하는 보강이 필요해지면 그때 다시 판단함.

  • LLM 파인튜닝은 지금은 안함. 자체 서빙으로 전환할 때 검토함.

    • 지금 안하는 이유 :
      1. 운영 API가 대상이 아님.
      2. 파인튜닝은 정답을 대량으로 보여주는 작업이라, 정답 자체가 흔들리면 흔들린 기준을 학습함. 실제 유용한 정답셋을 충분히 얻을 수 있을지 미지수.
      3. 판정 품질이 부족하면 LoRA SFT 고려해볼 것. SFT 목표는 단계·원인 판정으로 좁힘.

  • 재학습보다 정답셋 확보가 먼저임.

    1. 운영 로그에서 사람이 검토한 정답을 모아 평가셋을 키움.
    2. 혼잡단계와 원인이 객관적인 기준이 있는 것이 아니라 추론 경로만 바꿔도 그 정도가 흔들린 실측이 있음.
    3. 라벨은 신호 단위로 매김. 집계 규칙이 바뀌어도 신호 라벨은 그대로 쓸 수 있지만, 스팟 단위 라벨은 규칙을 바꾸는 순간 무효가 됨.