역량-신뢰성 간극
처음으로 실제 사용자에게 AI를 출시하는 거의 모든 사람을 데이는 패턴이 여기 있습니다:
모델이 당신의 테스트에서는 완벽하게 그 일을 해낸다. 그런데 프로덕션에서 실패한다. 당신은 그것이 작동하는 것을 봤기 때문에 혼란스럽다.
당신이 부딪힌 것은 역량-신뢰성 간극입니다.
역량은 모델이 어떤 작업을 할 수 있다는 뜻입니다 — 어떤 조건 하에서 적어도 한 번은 올바른 출력을 만들어 냅니다.
신뢰성은 모델이 그 작업을 일관되게 올바르게 해낸다는 뜻입니다 — 다양한 입력에 걸쳐, 반복 실행에 걸쳐, 표현이나 컨텍스트의 약간의 변화에 걸쳐.
데모는 역량을 증명합니다. 프로덕션은 신뢰성을 요구합니다. 이것들은 서로 다른 속성이고, 대부분의 가이드는 둘을 혼동합니다.
데모가 거짓말하는 이유
프롬프트를 테스트할 때, 당신은 보통:
- 당신이 직접 설계한 입력으로 그것을 실행합니다
- 몇 번 실행합니다
- 좋아 보이는 출력을 골라냅니다
- 옳아 보일 때까지 프롬프트를 손봅니다
이 과정은 역량을 최적화합니다. 이제 프롬프트는 당신의 예시에서 작동합니다. 당신은 올바른 출력을 봤습니다. 그것을 출시합니다.
문제는 프로덕션에서의 사용자 입력이 당신의 예시가 아니라는 것입니다. 그것들은 더 지저분하고, 더 다양하며, 당신이 예상하지 못한 방식으로 표현됩니다. 모델은 그것들로 테스트된 적이 없습니다. 당신은 그것들에서 모델이 어떻게 동작하는지 전혀 모릅니다.
단 하나의 좋은 출력은 성능 추정치가 아닙니다. 그것은 일화입니다.
분산이 숨은 변수다
LLM은 확률적입니다. 같은 프롬프트를 두 번 실행하면 종종 다른 출력을 얻습니다. 이 분산은 정상이고 보통은 괜찮습니다. 하지만 그것은 관련 있는 질문이 "작동했는가?"가 아니라 — "몇 퍼센트의 경우에 작동하는가?"라는 뜻입니다.
모델이 95%의 경우에 성공하는 작업은 데모에서는 훌륭해 보이지만 대략 스무 명 중 한 명의 사용자에게서 깨집니다. 60%의 경우에 성공하는 작업은 당신이 직접 실행할 때는 괜찮아 보입니다. 이것들은 매우 다른 상황이고, 측정하지 않고서는 둘을 구별할 수 없습니다.
실전에서의 역량-신뢰성 스펙트럼
| 차원 | 역량은 있으나 신뢰성 없음 | 신뢰성 있음 |
|---|---|---|
| 테스트한 입력 | 작성자가 설계한 예시 | 다양한 실제 사용자 입력 |
| 표본 크기 | 몇 번의 실행 | 많은 예시에 대한 반복 실행 |
| 실패 양상의 가시성 | 테스트에서는 드물고, 프로덕션에서는 흔한 실패 | 측정되고 이해된 실패 |
| 깨졌다는 것을 알게 되는 경로 | 사용자 불만 | 당신의 eval 스위트 |
| 개선하는 방법 | 프롬프트를 찍어보고 확인 | 통과율 추적, 실패를 체계적으로 디버깅 |
| 배포 자신감 | 느낌 기반 | 증거 기반 |
eval이야말로 진짜 해자다
더 나은 프롬프트는 역량을 높일 수 있습니다. 신뢰성을 높였는지 알려줄 수 있는 것은 오직 eval뿐입니다.
eval은 구조화된 테스트입니다. 입력 집합, 기대 출력 또는 평가 기준, 그리고 통과율을 측정하는 방법. 당신은 입력에 대해 모델을 실행하고, 출력을 채점하여, 숫자를 얻습니다. 그런 다음 무언가를 바꾸고 — 프롬프트, 모델, 온도 — 다시 실행합니다. 이제 당신에게는 신호가 있습니다.
이것은 화려하지 않습니다. 대부분의 튜토리얼이 통째로 건너뛰는, AI 제품 작업의 한 부분입니다. 하지만 출시할 때 실제로 중요한 질문에 답하는 유일한 방법입니다: "내가 본 적 없는 입력에서 이것이 얼마나 자주 작동하는가?"
시작하는 간단한 방법
시작하는 데 인프라는 필요 없습니다. 최소한의 실행 가능한 eval 루프가 여기 있습니다:
-
골든 세트를 만들어라. 20–50개의 실제 또는 현실적인 입력을 모으세요. 각각에 대해 올바른 출력이 어떤 모습인지(또는 그것을 판단할 기준)를 적으세요. 이것들이 당신의 골든 예시입니다.
-
N번 실행하라. 각 예시에 대해 프롬프트를 여러 번 실행하세요. 실행 간 분산은 프롬프트 안정성을, 예시 간 분산은 커버리지를 알려줍니다.
-
통과율을 추적하라. 각 (입력, 실행) 쌍에 대해 통과 또는 실패를 기록하세요. 전체 비율을 계산하세요. 이 숫자가 신뢰성 그림의 시작입니다.
-
회귀 테스트로 만들어라. 프롬프트를 바꿀 때마다 eval을 다시 실행하세요. 통과율이 떨어지면 무언가를 망가뜨린 것입니다. 올라가면 진짜 개선을 이룬 것입니다.
그게 전부입니다. 스프레드시트로도 됩니다. 도구보다 규율이 더 중요합니다.
이것이 프롬프팅 문제가 아니라 엔지니어링 문제인 이유
모델이 실패할 때의 본능은 프롬프트를 다시 쓰는 것입니다. 때로는 그게 옳습니다. 하지만 종종 그것은 당신이 본 실패 사례에 맞춰 최적화하면서, 확인하지 않은 사례에서 퇴보하는 대가를 치르는 방식입니다.
AI를 위한 신뢰성 엔지니어링은 이렇게 생겼습니다:
- 무엇이든 실행하기 전에 "올바름"이 무엇을 의미하는지 정의하기
- 대표성 있는 입력 분포에 대비해 측정하기
- 일관된 방법론으로 시간에 따른 변화를 추적하기
- "이 모델은 이 작업을 할 수 없다"와 "이 작업이 명세가 부족하다"를 구별하기
프롬프트 엔지니어링은 그 과정 안의 도구입니다. 그것을 대체하는 것이 아닙니다.
정직한 틀
대부분의 AI 역량은 진짜입니다. 모델은 정말로 놀라운 일을 할 수 있습니다. 역량-신뢰성 간극은 그 역량이 가짜라는 주장이 아닙니다 — 그것이 존재한다는 것을 아는 것만으로는 충분하지 않다는 주장입니다.
어떤 작업이 95%의 경우에 작동해야 한다면, 그것이 95%의 경우에 작동한다는 증거가 필요합니다. 그 증거는 데모에 대한 자신감이 아니라 구조화된 테스트를 실행하는 데서 나옵니다.
내구성 있는 AI 제품을 만드는 엔지니어가 반드시 최고의 프롬프트를 쓰는 사람인 것은 아닙니다. 그들은 출시하기 전에 "작동함"이 무엇을 의미하는지 알고, 그것이 사실인지 알려주는 측정값을 가진 사람들입니다.