Skip to content

개인화 모델의 마지막 병목은 RAG와 하네스였다 ​

LoRA를 붙이고 나면 한동안 모든 문제가 해결된 것처럼 보인다.

커밋 제목이 내 스타일에 가까워지고, PR 목차가 자연스러워지고, Jira 템플릿도 일정한 모양을 갖춘다. 그런데 실제 업무에 써보면 곧 한계가 나온다.

내 말투는 배웠지만 오늘의 사실은 모른다.

개인화와 최신성은 다른 문제였다 ​

최근 변경된 코드나 지금 진행 중인 Jira 상태를 모델이 알고 있어야 답할 수 있는 질문이 있다. 이것은 LoRA로 해결할 수 없다. 학습 시점의 기록을 더 강하게 외우게 만들 뿐, 다음 날 바뀐 내용까지 반영해주지는 않는다.

text
LoRA
  → 표현 방식과 반복되는 업무 패턴

RAG
  → 현재 확인할 근거와 원문

그래서 검색 결과를 prompt에 넣었다. 그런데 검색이 된다고 답이 좋아지는 것은 아니었다.

검색 결과가 너무 많으면 중요한 기록이 묻혔고, 너무 적으면 앞뒤 맥락이 사라졌다. 비슷한 커밋과 Jira가 함께 나오면 모델이 서로 다른 시점의 사실을 합쳐버리기도 했다.

하네스가 모델보다 먼저 판단해야 했다 ​

처음에는 검색 결과를 그대로 모델에 넘겼다.

곧 하네스가 필요해졌다. 여기서 하네스는 단순한 prompt 문자열 조립기가 아니었다.

text
요청 해석
  → 필요한 source와 visibility 결정
  → 검색
  → 시점·작성자·프로젝트 필터
  → 근거 충돌 검사
  → 모델 호출
  → 형식·근거·권한 검증

예를 들어 전역 채널의 메시지를 참고해 DM 초안을 만드는 것과, DM 내용을 전역 공지로 바꾸는 것은 완전히 다른 일이다. 모델이 자연스럽게 써줬다는 이유만으로 두 번째 작업을 허용하면 안 된다.

모델에게 판단을 맡기기 전에 하네스가 할 수 있는 검사를 먼저 했다.

근거가 없으면 그럴듯하게 실패해야 했다 ​

개인화 모델은 내 말투로 틀린 답을 만들어서 더 위험했다.

일반적인 틀린 답은 어색함이 드러날 수 있다. 하지만 익숙한 문체로 작성된 잘못된 Jira 요약이나 PR 설명은 실제 기록처럼 보인다.

그래서 다음 조건을 평가에 넣었다.

text
근거 없는 사실을 추가하지 않는다.
서로 다른 시점의 상태를 섞지 않는다.
권한 밖의 기록을 인용하지 않는다.
확신할 수 없으면 모른다고 표시한다.

“답변이 자연스러운가”보다 먼저 “이 답변을 어떤 근거로 만들었는가”를 보게 된 이유다.

하네스도 실패한다 ​

검색 시스템을 붙였다고 끝나지 않았다.

  • 검색 인덱스가 최신 상태가 아님
  • embedding과 reranker의 결과가 다름
  • 검색은 성공했지만 필요한 문서가 없음
  • 모델 provider가 timeout됨
  • 출력이 요구한 JSON이나 템플릿을 지키지 않음

이 각각을 하나의 성공으로 처리하면, 실패가 조용히 답변 속에 섞인다.

그래서 상태를 나눴다.

text
RETRIEVAL_EMPTY
EVIDENCE_CONFLICT
MODEL_TIMEOUT
OUTPUT_SCHEMA_INVALID
COMPLETED_WITH_EVIDENCE

실패를 숨기고 자연스러운 문장을 만드는 것보다, 어떤 단계에서 확신을 잃었는지 남기는 편이 운영하기 쉬웠다.

평가도 golden set 하나로 끝나지 않았다 ​

5천 개 골든셋은 중요한 기반이었다. 하지만 모델 출력만 평가하면 부족했다.

같은 요청에 대해 검색된 문서가 달라졌는지, 잘못된 visibility filter가 적용되지 않았는지, 근거 없는 PASS가 만들어지지 않았는지도 봐야 했다.

그래서 평가를 세 층으로 나눴다.

text
1. Retrieval
   필요한 근거를 찾았는가

2. Generation
   형식과 문체를 지켰는가

3. Harness
   권한·근거·실패 계약을 지켰는가

모델 점수가 좋아졌는데 하네스 결과가 나빠지는 실험도 있었다. 그 실험은 성공이 아니었다.

결국 여러 모델보다 경계가 중요했다 ​

처음에는 문서 형식과 판단 역할별 dense 모델 여러 개를 만들었다. 그다음에는 LoRA를 붙였고, dense와 MoE 차이를 공부했다. 모델 구조와 하이퍼파라미터를 바꾸면 더 좋은 결과가 나올 것 같았다.

하지만 마지막에 남은 문제는 모델 밖에 있었다.

text
무슨 작업인가
누가 읽는가
어떤 역할의 검토가 필요한가
어떤 근거가 필요한가
어디까지 공개할 수 있는가
실패하면 무엇을 반환할 것인가

이 경계를 먼저 정하지 않으면 dense도 MoE도, LoRA도 RAG도 그럴듯한 출력을 만드는 도구에 머문다.

개인화의 목표를 “내 말투 복제”로 잡았을 때는 모델을 더 많이 학습시키면 된다고 생각했다.

지금은 목표를 조금 바꿨다.

내가 어떤 상황에서 어떤 근거를 확인하고, 누구에게 어떤 형식으로 말하는지를 재현하는 것.

그 일을 하려면 모델 하나가 아니라 데이터 계약, 검색, 하네스, 평가, 실패 상태가 함께 필요하다.

그래서 이 이야기는 LoRA에서 끝나지 않았다. 오히려 LoRA가 끝난 뒤에 진짜 시스템 설계가 시작됐다.

마지막 수정:

Boundary · Execution · Verification · Operation