나의 LLM 파이프라인은 모든 평가를 통과했다. 그러다 운영 환경에서 사용자들에게 거짓말을 하기 시작했다.

나의 LLM (Large Language Model) 파이프라인은 모든 평가(eval)를 통과했다. 그러다 운영 환경(production)에서 사용자들에게 거짓말을 하기 시작했다.

극적으로 일어난 일은 아니었다. 조용히, 그리고 확신에 찬 채로 틀린 답을 내놓았다.

어떤 일이 있었는지 설명하겠다.

나는 우리 SaaS 제품 중 하나를 위해 RAG (Retrieval-Augmented Generation) 파이프라인을 출시했다. 40개의 문서로 테스트했을 때 응답 품질은 매우 날카로웠고, 나는 진심으로 그것이 자랑스러웠다. 첫 실제 사용자들을 온보딩했다. 하지만 72시간 이내에 시스템은 권위 있게 들리지만 사실은... 꾸며낸 답변들을 반환하기 시작했다. 정책 세부 사항을 환각(Hallucinate)하고, 존재하지 않는 조항 번호를 만들어냈다.

나는 트레이스(traces)를 파헤쳤다. 컨텍스트 윈도우(context window)가 조용히 넘쳐흐르고 있었다. 검색된 청크(chunks)가 제한을 초과했을 때, 모델은 에러를 발생시키지 않았다. 깔끔하게 잘라내지도 않았다. 그저 그 공백을 채우기 위해 말을 지어내기 시작했다. 나의 평가 스위트(eval suite) 중 그 무엇도 이를 잡아내지 못했는데, 그 이유는 나의 테스트 문서들이 작았기 때문이다.

해결하는 데는 45분이 걸렸다. 토큰 카운터(token counter), 하드 리밋(hard limit), 그리고 폴백 메시지(fallback message). 끝났다.

하지만 그 72시간의 시간 동안 초기 사용자들과의 실제 신뢰를 잃었다.

내가 계속해서 다시 배우고 있는 교훈은 이것이다: LLM은 요란하게 실패하지 않는다. 매끄럽게 실패한다. 모델은 항상 무언가를 반환할 것이다. 다만 그것이 때로는 사실로 위장한 허구일 뿐이다. 만약 당신이 호출당하는 트레이싱(per-call tracing)과 검색 시점에 강제되는 토큰 예산(token budget) 없이 LLM 기능을 출시하고 있다면, 당신은 실제로 당신을 해칠 실패 모드(failure mode)를 테스트하고 있는 것이 아니다.

가드레일(guardrails)은 그것이 필요해지기 전에 구축하라. 고객 지원 티켓을 읽으며, 왜 당신의 제품이 누군가에게 확신에 찬 어조로 잘못된 정보를 말했는지 의아해하며 구축하지 말고 말이다.