제 웹사이트에서 디지털 트윈을 운영하고 있습니다. 이 모델은 제 삶과 기술에 관한 질문에 답합니다. 저는 모델에게 한 가지 엄격한 규칙을 주었습니다. 절대 지어내지 말 것. 만약 제가 갖지 못한 기술에 대해 질문하면, 모른다고 인정해야 합니다. 몇 달 동안 저는 시스템이 잘 작동하고 있다고 믿었습니다. 여기저기서 수동으로 테스트해 보았고, 답변들은 견고해 보였습니다. 그러다 제대로 된 평가 하네스(evaluation harness)를 구축했습니다. 결과는 충격적이었습니다. 35개의 질문 중 9개는 명백한 거짓말이었습니다. 답변할 수 없도록 설계된 8개의 질문 중 모델은 단 4개만 거절했습니다. 저의 할루시네이션 방지 프롬프트는 약 4분의 1의 확률로 실패했습니다. 저는 사용자에게 거짓말을 하는 제품을 출시하고 있었던 것입니다.
매우 단순한 검색 설정
저는 Pinecone이나 무거운 벡터 데이터베이스를 구축하지 않았습니다. 전체 설정은 단순한 JSON 파일 하나로 이루어져 있습니다. 제 코드는 프로필을 개별 섹션으로 나눕니다. 질문이 들어오면 시스템은 쿼리와 각 텍스트 청크(chunk) 사이의 코사인 유사도를 계산하여, 가장 유사한 항목을 선택한 뒤 이를 컨텍스트로서 프롬프트에 집어넣습니다. 그러면 모델은 해당 윈도우에 보이는 내용에만 엄격히 기반하여 답변을 생성합니다.
좁은 범위의 사실만을 다루는 소규모 개인 사이트의 경우, 이 방식은 빠르고 비용이 거의 들지 않습니다. 원격 벡터 저장소로의 네트워크 왕복도 없고, 인덱싱 오버헤드도 없으며, 복잡한 오케스트레이션도 필요 없습니다. 파일을 읽고, 청크의 점수를 매기고, 프롬프트를 만들면 끝입니다. 하지만 백엔드의 단순함이 출력의 정직성을 보장하지는 않습니다. 모델이 즉흥적으로 행동하기로 결정하면, 가벼운 파이프라인이라도 심각한 문제를 일으킬 수 있습니다. "여기 컨텍스트가 있습니다"와 "그것에 대해 이렇게 말하겠습니다" 사이의 간극, 바로 그곳에 할루시네이션이 존재합니다. 모델에게 귀하의 경력에 관한 단락을 건네주더라도, 귀하가 한 번도 다뤄본 적 없는 프로그래밍 언어에 대해 자신만만하게 꾸며낸 이야기를 들을 수 있습니다.
신뢰를 무너뜨린 숫자들
몇 달 동안 저는 수동으로 부분 점검을 하는 것만으로도 충분하다고 생각했습니다. 채팅창을 열고 이미 답을 알고 있는 질문을 던진 뒤, 답변이 맞으면 고개를 끄덕였습니다. 그것이 저의 테스트 전략이었습니다. 제가 직접 인터페이스를 사용하고 있었기에 철저하다고 느꼈습니다. 하지만 그렇지 않았습니다.
마침내 체계적으로 실행할 수 있는 평가 하네스를 작성했을 때, 상황은 바뀌었습니다. 테스트 스위트가 디지털 트윈에 35개의 질문을 던졌습니다. 9개의 답변에는 거짓이 포함되어 있었습니다. 또한 제 프로필 어디에도 답이 없는 8개의 질문도 포함했습니다. 모델은 이 질문들을 모두 거절했어야 했습니다. 하지만 단 4개만 거절했습니다. 절대 지어내지 말라는 단호한 표현을 포함하여 정성스럽게 만든 저의 할루시네이션 방지 프롬프트는 약 25%의 확률로 실패했습니다. 4번 중 1번꼴입니다. 이것은 단순한 오차가 아닙니다. 망가진 제품입니다.
친절한 질문으로 테스트하는 것을 멈추십시오
단순히 자신의 제품을 사용하는 것만으로는 버그를 찾을 수 없습니다. 제품을 망가뜨리려고 시도해야 버그를 찾을 수 있습니다. 저의 수동 테스트는 너무 친절했습니다. 저는 정확한 답을 알고 있는 질문만 던졌고, 이는 무의식적으로 모델을 안전한 영역으로 유도했음을 의미합니다. 저는 한 번도 경계선을 탐색하지 않았습니다. 제가 가졌으면 하는 기술이나, 결코 일어나지 않은 경험에 대해서는 묻지 않았습니다.
진정한 테스트에는 적대적 의도(adversarial intent)가 필요합니다. AI를 실패하게 만들도록 설계된 질문을 만들어내야 합니다. 방문자 앞에서 실수하지 않도록 실험실에서 미리 실수하게 만들어야 합니다. 이미 믿고 있는 사실만을 확인해 주는 테스트 스위트는 그저 그럴싸하게 꾸며진 데모에 불과합니다. 에지 케이스와 함정 질문을 적극적으로 만들어내지 않는다면, 그것은 테스트가 아닙니다. 그저 희망 사항일 뿐입니다.
중요했던 두 가지 실수
프롬프팅은 보장이 아닙니다. AI에게 할루시네이션을 하지 말라고 지시하는 길고 상세한 명령은, 명령의 탈을 쓴 제안에 불과합니다. 모델은 대부분의 경우 그 지시를 따르겠지만, 통계적 압력이 다른 방향으로 모델을 밀어붙이는 순간 그 지시를 무시할 것입니다. 온도(Temperature), 토큰 확률, 그리고 학습 데이터의 형태는 시스템 프롬프트의 문장 한 줄보다 더 강력한 무게를 가집니다. 순종 여부는 희망이 아니라 데이터로 측정해야 합니다. 강력한 지시는 검증된 사실이 아닙니다. 그것은 요청일 뿐이며, 요청은 거절될 수 있습니다. 만약 귀하의 전체 안전 전략이 프롬프트를 단호하게 작성하는 것에만 의존하고 있다면, 귀하는 휴지로 가드레일을 만든 것과 다름없습니다. 모델이 얼마나 자주 복종하는지, 어떤 조건에서 복종하는지, 그리고 실패할 때는 왜 실패하는지를 측정하는 평가 하네스가 필요합니다. 숫자는 귀하의 말투에 개의치 않습니다.
평가 루프에 결함이 있었습니다. 저를 거의 함정에 빠뜨릴 뻔했던 미묘한 문제가 하나 있습니다. 제가 처음에 만든 테스트 도구는 검색(retrieval) 프로세스를 두 번 실행했습니다. 첫 번째 실행에서는 정답(ground truth)과 대조할 컨텍스트를 가져왔습니다. 두 번째 실행에서는 실제 답변 생성을 위한 컨텍스트를 가져왔습니다. 실제로 이는 평가자(judge)가 본 청크(chunks)가 모델이 본 청크와 다를 수 있음을 의미했습니다. 평가자는 AI가 전혀 받지 못했을 수도 있는 데이터를 기준으로 답변을 채점하고 있었던 것입니다. 잘못된 입력을 기준으로 채점하는 평가는 아예 평가를 하지 않는 것보다 더 나쁩니다. 이는 잘못된 안도감을 줍니다. 점수를 보고 높은 통과율을 확인하며 안심하게 됩니다. 그동안 사용자들은