프롬프트 어휘 민감성(Prompt Lexical Sensitivity)은 뜻이 거의 같은 단어로 바꿨을 뿐인데 LLM의 품질이 크게 흔들리는 현상이다. Xie 등은 13만 2천 개의 프롬프트 변형을 분석해 평균 성능이 높은 과제가 대체로 표현 변경에 더 안정적이라는 스케일링 관계를 제시했다. 프롬프트를 한 번 “잘 쓰는” 것보다, 변형에도 같은 수준으로 작동하게 만드는 일이 운영 환경에서는 더 중요하다.
안정성을 만드는 두 요소
| 요소 | 역할 | 예 |
|---|---|---|
| 도메인 특화 용어 | 해석 범위를 좁혀 의미 경계를 고정 | “빠르게” 대신 “p95 지연 시간” |
| 명시적 행동 지시 | 모델이 따라갈 절차를 구체화 | “분석해” 대신 “원인을 3개로 분류하고 근거를 표로 제시” |
연구는 두 요소가 모델의 해석 공간을 제한해 더 결정적인 생성을 유도한다고 본다. 코드 생성 실험에서는 이런 구조화로 성능 분산을 40.7% 줄였다고 보고한다. 이는 모든 모델·작업에 보장된 수치가 아니라, 자체 업무에서도 변형 테스트가 필요하다는 근거다.
실무 적용법
좋은 프롬프트를 정답 문장 하나로 고정하지 말고, 같은 요구를 표현한 5~10개 변형으로 회귀 테스트한다. 모델·온도·도구 버전을 고정한 뒤 형식 준수, 정답성, 도구 호출 성공률을 비교한다. 특정 표현에서만 잘 되면 우연히 맞춘 프롬프트일 수 있다.
목표: 결제 오류를 조사한다.
행동: 로그에서 오류 코드를 추출하고, 발생 시각·사용자 영향·재현 절차를 표로 만든다.
제약: 근거가 없는 원인은 '추정'으로 표시하고, 고객 정보는 출력하지 않는다.
완료: 각 행에 로그 식별자 또는 확인 불가 사유가 있다.이처럼 대상, 행동, 제약, 완료 기준을 분리하면 모호한 수식어에 의존하는 양을 줄일 수 있다. specification-engineering과 ai-agent-evaluation-tips-roadmap은 이를 태스크 명세와 평가로 확장하는 데 도움이 된다.
관련 문서
- prompt-engineering — 프롬프트 설계의 기본 원칙
- specification-engineering — 검증 가능한 작업 명세를 작성하는 방법
- ai-agent-evaluation-tips-roadmap — 에이전트 품질을 측정하는 로드맵