Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 에이전트가 사실을 꾸며내는 '환각(Hallucination)'은 모델 자체의 결함이라기보다 시스템 설계 문제입니다. 작성자는 LLM의 출력을 맹신하지 않고, 모든 주장은 반드시 검증 가능한 실제 출처를 기반으로 하도록 제어 장치(harness)를 구축해야 한다고 주장합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AI 비서가 자신감 있고 아름답게 포맷된 답변을 내놓았는데, 그것이 지어낸 것이라는 것을 처음 깨달았던 것은 재앙 같은 일은 아니었습니다. 전화번호였습니다. 그럴듯해 보였고, 올바른 지역 번호를 가지고 있었지만, 누구에게도 속한 번호가 아니었습니다. 제가 우연히 실제 번호를 알고 있었기에 이를 알아챘습니다. 저를 사로잡았던 부분은 바로 이것이었습니다. 저는 설계 덕분이 아니라 운 덕분에 그것을 잡아냈다는 것입니다. INASNAP에서 저희는 초기에 운(luck)은 통제 수단이 될 수 없다고 결정했습니다. 그래서 저희가 구축하는 에이전트들은 거의 모든 규칙보다 앞서는 하나의 원칙을 따릅니다. 바로 실제 출처로부터 얻지 못한 것은 말하지 않는다는 것입니다.
저는 약 20년 동안 웹사이트와 앱을 구축해 왔고, 사업은 9년간 운영했습니다. 그 시간 동안 저는 가장 비싼 버그가 시스템을 다운시키는 버그가 아니라는 것을 배웠습니다. 그것들은 '정확하게 보이는' 버그들입니다. 페이지가 충돌하면 한 시간 만에 수정됩니다. 하지만 제안서 속의 잘못된 번호, 사례 연구에 포함된 지어낸 고객 인용구, 또는 보도 자료 속의 꾸며낸 통계는 몇 달 동안 조용히 신뢰를 깎아내릴 수 있습니다. 대규모 언어 모델(Large language models)은 그럴듯하게 보이는 것을 생성하는 데 매우 능숙합니다. 이것이 바로 이들이 무엇을 주장할 수 있는지에 대한 규칙이 필요한 정확한 이유입니다.
사람들은 '환각'에 대해 마치 다음 모델 출시에서 수정될 결함인 것처럼 이야기합니다. 모델은 실제로 더 좋아집니다. 하지만 근본적인 행동 양식은 사라지지 않습니다. 왜냐하면 그것은 언어 모델이 무엇인지, 즉 그럴듯한 텍스트를 예측하는 시스템이기 때문입니다. '그럴듯하다'와 '사실이다'는 대부분의 경우 겹치지만, 그렇지 않을 때 모델에는 "지금 추측하고 있다"고 경고하는 내장된 알람 장치가 없습니다.
그래서 저는 모델이 고쳐지기를 기다리는 것을 멈추고, 다른 모든 엔지니어링 문제처럼 다루기 시작했습니다. 웹 양식의 사용자 입력은 신뢰하지 않으므로 검증(validate)합니다. 네트워크 호출이 성공할 것이라고 믿지 않으므로 실패를 처리합니다. 마찬가지로, 모델의 사실적 주장을 맹신하지 않고, 확인할 수 있는 출처에서 나오도록 요구해야 합니다.
이것은 모델의 문제가 아니라 제어 장치(harness)의 문제입니다. 저는 The AI Agent Harness Matters More Than the Model에서 더 광범위한 아이디어에 대해 작성했습니다. 제로 페이커레이션(Zero fabrication, 사실 꾸며내기 없음)은 그 제어 장치 중 가장 실용적인 부분 중 하나입니다.
우리가 운영하는 모든 에이전트에게 다음과 같이 명시합니다:
실제 도구, 파일 또는 출처에서 얻지 못한 숫자, 인용문, 참고 문헌, 출처, 이름 또는 기타 사실을 절대 꾸며내지 마십시오. 데이터가 없다면 그렇게 말하고 그것을 얻는 실제 방법을 제시하십시오.
이것은 당연하게 들립니다. 하지만 실제로 많은 행동 변화를 가져옵니다. 저희의 작업에서 나온 몇 가지 예시입니다:
제가 계속 돌아오는 패턴은 스스로 "출처 제시 또는 침묵(source or silence)"이라고 부르는 것입니다. 에이전트가 만드는 모든 사실적 주장은 다음 세 곳 중 한 곳으로 거슬러 올라가야 합니다:
주장(claim)이 이 세 가지 중 어느 것에도 근거하지 못하면 출력에 포함되지 않습니다. 에이전트는 여전히 추론하고, 제안하며, 초안을 작성할 수 있습니다. 단지 어떤 부분이 사실이고 어떤 부분이 자체적인 제안인지를 명확히 해야 합니다.
이것의 엔지니어링 측면은 들리는 것보다 덜 화려합니다. 주로 다음을 포함합니다:
마지막 것은 제가 '유리집 투명성(glass-house transparency)'이라고 부르는 것과 연결됩니다. 에이전트가 숫자를 보내면, 어디서 가져왔는지 볼 수 있어야 합니다. 그렇지 않다면 추측으로 간주해야 합니다.
여기에는 미묘한 부분이 있습니다. 때로는 정말로 자리 표시자 데이터(placeholder data)가 필요합니다. 데모 대시보드, 보고서 목업(mockup), 기능이 어떻게 보이는지 보여주는 교육 비디오 등. 가짜 데이터는 그곳에서 괜찮습니다. 하지만 라벨 없는 가짜 데이터는 안 됩니다.
우리의 규칙은 다음과 같습니다: 자리 표시자 데이터는 항상 예시 데이터(example data)로 명확하게 표시되어야 합니다. 목업에서는 화면에 그렇게 적혀 있고, 비디오에서는 캡션이 데모라고 말합니다. 스프레드시트 템플릿에서는 열 제목이나 메모에 "샘플 값(sample values)"이라고 적습니다.
왜 그렇게 엄격해야 할까요? 예시 데이터가 새어 나가기 때문입니다. 데모의 스크린샷이 슬라이드 덱에 들어가고, 템플릿의 샘플 수치가 실제 제안서에 복사됩니다. 6개월 후 아무도 그것이 꾸며낸 것임을 기억하지 못하고, 이제는 귀사가 반복해 온 "사실"이 됩니다. 라벨은 비용이 들지 않으며 이러한 표류(drift)를 막아줍니다.
사실 꾸며내기(zero fabrication)가 제대로 작동하면, 에이전트의 답변은 조금 덜 매끄럽지만 훨씬 더 유용해집니다. 다음과 같은 방식 대신:
"당신의 최고 경쟁사는 약 40명의 직원을 보유하고 있으며 작년에 시리즈 A 투자를 유치했습니다."
다음과 같은 답변을 얻게 됩니다:
"그들에 대한 신뢰할 수 있는 인원수나 자금 조달 이력을 찾지 못했습니다. 그들의 사이트에는 12명으로 구성된 팀 페이지가 나와 있지만, 자금 조달에 관한 보도 자료는 찾지 못했습니다. 원하시면 기업 등기부를 확인해 드릴 수도 있고, 아시는 정보를 공유해 주셔도 좋습니다."
두 번째 답변은 언뜻 보기에는 인상적이지 않을 수 있습니다. 하지만 동시에 고객, 파트너 또는 투자자 앞에서 속이 불편하지 않게 제시할 수 있는 답변입니다.
글쓰기에서도 마찬가지입니다. 제가 에이전트에게 이와 같은 기사 초안 작성을 요청했을 때, 임의로 "최근 설문조사"를 인용하여 시작하거나 실제로 말한 적 없는 사람의 인용구를 끌어오는 것은 허용되지 않습니다. 만약 통계 자료가 필요하면 직접 찾아보거나, 아예 그 통계 없이 핵심 내용만 작성합니다. 솔직히 말해서, 대부분의 경우 이렇게 하는 것이 글쓰기에 더 좋습니다. 검증된 경험이 빌려온 숫자보다 낫습니다.
저는 이 말을 자주 듣고 있으며, 그 이유를 이해합니다. 만약 AI의 판매 포인트가 항상 답을 가지고 있다는 것이라면, AI에게 "모르겠다"라고 말하도록 가르치는 것은 후퇴하는 것처럼 느껴집니다.
다르게 말씀드리자면, 항상 답을 아는 비서가 유용한 것은 아닙니다. 그것은 그저 동의하기 쉬운(agreeable) 존재일 뿐입니다. 유용하다는 것은 당신이 행동으로 옮길 수 있는 답변을 주는 비서입니다. 에이전트가 무언가를 꾸며내서 당신이 이를 발견할 때마다, 당신은 그를 조금 덜 신뢰하게 되고 모든 것을 재확인하기 시작하며, 이는 원래 절약하려고 했던 시간을 사라지게 만듭니다. 매번 "그것은 가지고 있지 않지만, 이렇게 얻을 수 있습니다"라고 말할 때마다, 당신은 그를 조금 더 신뢰하게 됩니다.
특히 소규모 비즈니스에게 신뢰는 전부입니다. 대기업은 법무팀, 커뮤니케이션 팀을 갖추고 있으며 AI 초안과 대중 사이에는 세 단계의 검토 과정이 있습니다. 반면 소규모 비즈니스는 오너 한 명과 노트북 하나가 전부일 수 있습니다. 만약 AI가 잘못된 정보를 만들어낸다면, 그 실수와 고객 사이에 아무도 서 있지 않을 수 있습니다. 제가 이 도구들로 도움을 받고 싶은 바로 그런 종류의 비즈니스이며, 이것이 제가 규칙에 대해 매우 신경 쓰는 이유입니다.
이러한 아이디어를 사용하기 위해 맞춤형 에이전트 플랫폼(custom agent platform)이 필요하지 않습니다. 오늘날 사업에서 AI 도구를 사용하고 있다면, 몇 가지 습관만으로도 큰 도움이 됩니다:
INASNAP Labs에서는 사실 꾸며내기 없음(zero fabrication)을 나중에 덧붙이는 기능으로 취급하지 않습니다. 이는 읽기 전용 우선 접근 방식(read-only-first access), 권한 거부 기본값(permission-denied defaults), 그리고 인간의 승인과 함께 우리가 구축하는 모든 에이전트가 작동해야 하는 방식으로 자리 잡고 있습니다. 목표는 똑똑하게 들리는 AI를 만드는 것이 아닙니다. 모를 때는 알려주기 때문에, 실제로 업무를 맡길 수 있는 AI를 만드는 것입니다.
귀하의 비즈니스에서 작동시키고 싶거나 수행하고 싶은 종류의 AI가 바로 이것이라면, 저에게 연락 주십시오. 더 많은 정보는 inasnap.org에서 얻을 수 있으며, 저희와 함께하는 데 관심이 있다면 inasnap.org/apply를 확인해 보십시오.
마이클 페틀러(Michael Petler), 창립자 겸 수석 엔지니어, INASNAP LLC (INASNAP Labs), 펜실베이니아.
원문은 Medium에 게재되었습니다.