LLM 설명 시스템, 어떻게 만들었을까?

빠른 정책 수립: 엉성하더라도, 일단 최소한의 기준을 포함하여 빠르게 정책을 작성

Model Steering 시도: 준비된 유저 데이터를 활용하여, 정책 기반 설명 생성 및 결과 평가

Pass/Fail 평가: PM과 Engineer가 각자의 직관에 따라 평가하고, 평가 이유(Critique) 상세 기록

의견 공유 및 합의: 평가 결과를 공유하고, 의견 불일치 샘플을 중심으로 논의하여 정책 개선

빠른 실패: 처음부터 완벽한 정책을 만들 수 없음을 인지하고, 빠르게 결과를 확인하고 실패를 통해 학습

단순한 평가 기준: 5점 척도 대신, Pass/Fail과 같은 이분법적 평가를 통해 의사 결정의 부담 감소

Critique의 중요성: 평가 이유를 언어화하는 과정을 통해, 팀원 각자의 제품 기준을 명확히 정의

팀 전체의 Decision Boundary 구축: 각자의 기준을 공유하고, 팀 차원의 합의된 기준을 만들어 모델에 전달

실시간 서빙: 상용 LLM의 프롬프트 엔지니어링(Prompt Engineering)만으로는 실시간 서빙에 한계가 있어, 작고 빠른 모델 학습 필요

학습 방법: 상용 LLM의 설명 예시 또는 사람이 정책에 기반하여 만든 데이터를 활용하여 작은 모델 학습

LLM Judge의 역할: 학습된 모델의 출력을 평가하기 위해, 정책을 정확히 이해하는 LLM Judge 활용

2부 예고: LLM Judge 설계에 대한 자세한 내용은 2부에서 공개 예정

PM의 역할: LLM의 한계를 명확히 이해하고, 제품을 효과적으로 설계

엔지니어의 역할: 기술적 실패를 빠르게 공유하고, 정책 방향성에 기술적 기여

경계 없는 협업: PM, MLE 등 팀원들이 자신의 기준을 공유하고, 모델 개선에 기여

불확실성 극복: Proactive 문화를 통해, LLM 프로젝트의 불확실성을 줄이고 성공 가능성을 높임