당신이 계속해서 최고의 소프트웨어를 출시하고, 멋진 콘텐츠를 쓰고, 엄청난 이미지를 생성하는 사람들이 있는 데는 이유가 있습니다…
그들은 평가 루프(eval loop)를 채택한 반면, 당신은…
더 나은 프롬프트를 시도해보고, 더 비싼 모델로 바꿔보고, 더 긴 지시문을 작성해보고, 메모리를 켜고, 소설만한 크기의 컨텍스트 파일을 만들었지만, 여전히 슬롭(slop)이 나옵니다…
슬롭이 계속 나오는 이유는 당신이 전혀 문제가 되지 않았던 계층을 계속 고치고 있기 때문입니다
슬롭은 프롬프트 문제가 아니라 시스템 문제입니다. 불량품을 출하하는 공장에 직원 문제가 있는 것이 아니라 품질 관리 문제가 있는 것과 같습니다. 아무도 제품이 공장을 떠나기 전에 출력을 확인하지 않습니다
그래서 이번에는 실제로 구축해보겠습니다. 이 글을 다 읽고 나면 오픈소스 에이전트인 hermes 안에서 작동하는 평가 루프를 갖게 될 것입니다. 이 루프는 모든 출력을 당신의 기준에 따라 점수를 매겨 출시 전에 검사하고, 출시 후에는 실시간 출력을 모니터링하며, 모든 실패를 새로운 테스트로 변환하여 품질 기준이 스스로 상승하게 만듭니다.
함께 하나씩 구축해 나가며, 그 결과는 명확합니다. 자정에 다시 읽지 않아도 신뢰할 수 있는 깨끗한 출력, 실제로 확인할 수 있는 품질 점수, 그리고 청중이 아니라 출구에서 걸러지는 슬롭입니다.
이 글을 통해 얻을 수 있는 것은 다음과 같습니다:
- 더 나은 프롬프트, 더 큰 모델, 메모리가 왜 슬롭을 영원히 없애지 못하는지, 그리고 실제로 작동하는 유일한 계층은 무엇인지
- 슬롭이 작업에 숨어 있는 두 곳 — 콘텐츠 출력과 제품 출력 — 그리고 두 경우 모두 해결책이 동일한 이유
- 평가 루프가 무엇인지 평범한 영어로 설명, 거의 매일 사용하는 사람이 없는 품질 계층, 그리고 아무도 왜 구축하라고 말하지 않았는지
- 이번 주 안에 세울 수 있는 품질 벤치마크 — 콘텐츠와 제품 모두에 대해 — 정확히 무엇을 측정해야 하고, "좋은" 것이 화면에서 읽을 수 있는 숫자로 어떻게 보이는지
- 정확한 구축 방법, 단계별로 — hermes가 이미 제공하는 조각들(스킬, 메모리, 크론, 승인 버튼)을 사용해 전체 루프를 연결하여 게이트가 당신 없이도 작동하게 하는 방법
만약 "AI 슬롭을 고치는 5가지 프롬프트"를 찾으러 왔다면, 이 글은 그런 글이 아닙니다. 그런 글들은 존재하지만 작동하지 않으며, 이 글은 실제로 작동하는 버전입니다.
당신은 한 가지를 제외한 모든 것을 시도해봤습니다
당신이 이미 시도한 것들을 간단히 살펴보겠습니다:
프롬프트를 세 번, 네 번 다시 썼습니다. 예제를 추가하고, 페르소나를 추가하고, 엄청나게 긴 "하지 마라" 목록을 추가했습니다.
프론티어 모델로 업그레이드하고, 토큰당 5배를 지불했으며, 출력은 더 일반적이지 않으면서 더 자신감 있어졌습니다.
메모리를 켜고, 컨텍스트 파일을 만들고, 브랜드 보이스, 과거 작업, 스타일 가이드를 입력했습니다.
그리고 그 모든 움직임은 몇 가지 좋은 생성 결과를 얻는 데 그쳤고, 다시 슬롭이 스며들었습니다.
그 모든 것은 입력 측 수정입니다. 잡아내야 할 것을 무시하면서 생성하는 것만 계속 갈고 닦는 것입니다. 어둠 속에서 발사된 더 좋은 총은 여전히 아무것도 맞히지 못합니다.
슬롭은 출력 측 문제입니다. 모델이 좋은 작업을 생성할 수 없는 것이 아니라, 중요한 사람에게 도달하기 전에 좋은 작업과 나쁜 작업을 구분할 방법이 없는 것입니다.
평가 루프가 없고, 품질 벤치마크가 없고, 점수판이 없습니다. 그래서 당신은 맹목적으로 튜닝하고 있습니다. 프롬프트를 바꾸고 느낌상 좋아졌다고 생각하지만, 느낌은 측정이 아니며, 느낌은 다음 50개 생성 결과에 숨어 있는 나쁜 실행을 잡아내지 못합니다.
그래서 당신은 자신을 탓하거나, 프롬프트를 탓하거나, 에이전트 설정을 탓하거나, 컨텍스트 엔지니어링을 탓합니다. 하지만 빠진 조각은 AI와 함께 작업할 때 보여주지 않았던 완전한 계층이며, 이 글을 다 읽으면 그 계층이 당신의 컴퓨터에서 hermes 안에서 실행될 것입니다.
더 나은 프롬프트가 왜 이 문제를 해결할 수 없는가 (그리고 왜 모두가 계속 시도하는가)
프롬프트는 가설이고, 출력은 결과이며, 평가는 둘 사이의 루프를 닫는 유일한 것입니다.
루프가 없으면 당신은 영원히 추측합니다. 가설을 조정하고, 결과 하나를 대충 보고, 승리를 선언하며, 동일한 프롬프트가 30%의 경우에 쓰레기를 생성한다는 사실을 절대 알지 못합니다. 당신이 눈앞의 출력 하나만 보았기 때문입니다.
모델은 비결정적입니다. 동일한 프롬프트를 두 번 실행하면 두 개의 다른 답변이 나옵니다. 즉, 완벽한 프롬프트조차도 일부 실행에서 슬롭을 생성하며, 클라이언트나 사용자가 그것을 볼 때까지 어느 실행인지 알 수 없습니다.
따라서 완벽한 프롬프트는 품질 보장이 아니라 약간 더 나은 동전 던지기이며, 당신은 모든 던지기를 출시하고 있습니다.
모두가 계속 프롬프트에 의존하는 이유는 간단합니다. 프롬프트는 당신이 실제로 볼 수 있는 유일한 레버이기 때문입니다. 편집할 수 있고, 편집하는 것이 통제하는 느낌을 줍니다.
측정은 보이지 않습니다. 아무도 그것에 대한 강좌를 팔지 않으며, "내 출력을 10배 향상시킨 평가 스위트"라는 바이럴 스레드를 올리는 사람도 없습니다. 그래서 전체 대화는 스스로 문제를 해결할 수 없는 하나의 레버에 갇혀 있습니다.
AI 출력이 지속적으로 깨끗한 사람들은 당신보다 프롬프팅에 더 능숙한 것이 아닙니다. 그들은 당신이 없는 두 번째 레버를 가지고 있을 뿐입니다. 그들은 모든 출력을 출시 전에 기준에 대해 측정하며, 그 측정이 그들의 프롬프팅을 마법처럼 보이게 만듭니다.
슬롭이 사는 두 곳
슬롭은 정확히 두 곳에 숨어 있으며, 거의 모든 사람이 그 중 하나만 보고 있습니다.
장소 1: 콘텐츠 출력
트윗, 기사, 이메일, 랜딩 페이지, 게시물 — AI로 생성하고 당신의 이름으로 게시하는 모든 것.
여기서의 슬롭은 기술적으로는 괜찮지만 완전히 공허한 작업처럼 보입니다. 타임라인의 다른 모든 AI 계정처럼 들리며, 겉은 정확하지만 속은 비어 있습니다.
공개적으로 실패하며, 왜 그런지 설명할 수 없습니다. 각각의 개별 조각이 보낼 때 괜찮아 보였기 때문입니다.
장소 2: 제품 출력
당신이 출시한 AI 기능, 에이전트, 챗봇, 고객 응답기, 추출 파이프라인 — 사용자가 실제로 만지는 것.
여기서의 슬롭은 완전한 자신감으로 전달된 잘못된 답변, 환각된 숫자, 깨진 JSON 페이로드, 브랜드에 어울리지 않는 톤, 데모에서는 훌륭했지만 세 번의 배포 후 조용히 성능이 저하된 출력처럼 보입니다.
공개적으로 실패하지 않고 조용히 확장됩니다. 모든 사용자는 약간 더 나쁜 경험을 하며, 대부분은 당신에게 말하지 않고 그냥 떠납니다.
이것들은 같은 치료법을 가진 같은 질병입니다.
콘텐츠 슬롭과 제품 슬롭은 모두 측정되지 않은 AI 출력이 중간 게이트 없이 직접 청중에게 가는 것입니다.
유일한 차이는 중요성과 가시성입니다. 콘텐츠 슬롭은 당신을 큰 소리로 당황시키고, 제품 슬롭은 조용히 당신을 피를 빼냅니다. 우리가 hermes에서 구축할 루프는 둘 다 같은 스킬로 평가하므로, 생성하는 모든 것에 대해 두 개가 아닌 하나의 품질 시스템을 운영하게 됩니다.
평가 루프가 실제로 무엇인가
평가 루프는 반복 가능한 테스트로, AI 출력을 기준에 대해 자동으로, 매번, 출시 전과 후에 점수를 매깁니다.
그게 전부입니다. 그리고 이것은 AI로 구축하는 거의 모든 사람이 가지고 있지 않은 계층입니다.
출력을 생성한다
정의한 벤치마크에 대해 점수를 매긴다
기준선 아래로 떨어진 실행을 잡아낸다
실패하는 부분을 고친다
다시 점수를 매기고, 통과한 출력만 통과시킨다
소프트웨어 엔지니어들은 이것을 영원히 가지고 있었습니다. 그것은 테스팅이라고 불립니다. 코드를 테스트 없이 출시하고 프로덕션에서 작동하기를 바라지 않을 것입니다. 그러나 이것이 바로 현재 전체 업계가 AI 출력을 출시하는 방식입니다. 모델에서 사용자로, 느낌과 기도에 의존하여 직접 전달합니다.
거의 아무도 평가 루프를 가지고 있지 않은 이유는 인구통계학적입니다. 오늘날 AI로 구축하는 사람들은 엔지니어링이 아니라 콘텐츠, 영업, 제품, 창업 출신입니다. 따라서 "출력에 대한 테스트를 작성하라"는 도구 상자에 없었습니다. 평가는 "진짜" 엔지니어를 위한 인프라로 읽히며, 가장 필요로 하는 사람들은 그것을 원할 자격이 없다고 생각합니다.
비결정적 요소에 대한 단위 테스트라고 생각하십시오. 코드가 실행되는지 테스트하는 것이 아니라 출력이 좋은지 테스트하는 것이며, 하나의 나쁜 실행이 숨을 수 없을 만큼 충분한 케이스에 대해 테스트합니다.
평가 루프는 세 곳에서 실행되며, 앞으로 구축할 내용은 그것을 세 곳 모두에 배치합니다:
- 출시 전: 새로운 프롬프트나 모델을 저장된 케이스 세트에 대해 실행하고 더 나빠지지 않았는지 확인합니다. 이것은 회귀 테스트입니다. 한 가지를 고치고 조용히 세 가지를 망가뜨리는 변경을 막는 방법입니다.
- 런타임: 출력이 생성될 때 점수를 매기고 조건부 로직이 사용자에게 도달하기 전에 실패를 잡아냅니다. 이것이 가드레일입니다.
- 프로덕션: 실제 실행 샘플을 지속적으로 점수 매겨 품질이 저하되기 시작한 날을 알 수 있게 합니다. 클라이언트가 불평하는 주가 아니라.
첫 번째는 스프레드시트로 세울 수 있지만, 세 가지 모두를 두 번째 직업으로 변하지 않게 지속적으로 운영하는 것이 바로 이 모든 것을 에이전트 안에 넣는 이유입니다.
품질이 숫자가 되는 순간, 슬롭은 계속 느끼는 감정에서 고칠 수 있는 버그로 바뀝니다. 느낌은 디버깅할 수 없지만, 0.82에서 0.61로 떨어진 점수는 디버깅할 수 있습니다.
벤치마크: 당신이 곧 구축할 세 부분
벤치마크는 세 부분으로 구성되며, 콘텐츠를 평가하든 제품을 평가하든 동일합니다:
테스트 케이스: 좋은 출력이 무엇인지에 대한 실제 입력과 쌍 (당신의 기준 데이터)
메트릭: 출력을 점수로 변환하는 방법, 이상적으로는 0~1
임계값: 그 아래로는 아무것도 출시되지 않는 선
이 세 가지를 구축하면 품질 게이트가 생깁니다. 하나라도 건너뛰면 소원만 남습니다. 나머지 섹션에서는 각 부분에 무엇이 들어가는지 설명하고, 그런 다음 세 가지를 모두 hermes에 연결합니다.
콘텐츠의 경우, 테스트 케이스는 당신의 금본위입니다
당신의 최고의 작품 20~50개를 가져오세요. 북마크된 게시물, 당신의 전체 이름을 걸고 싶은 기사들. 이것이 "좋은" 것이 무엇인지입니다. 기준을 발명하는 것이 아니라 당신이 최고의 날에 이미 달성했던 기준을 추출하는 것입니다.
콘텐츠의 경우, 메트릭은 루브릭입니다
점수는 그 뒤에 있는 루브릭만큼만 좋습니다. 따라서 당신이 실제로 작업을 좋게 만드는 것을 인코딩하십시오. 콘텐츠의 경우 나는 모든 작품을 네 가지 기준으로 평가합니다:
- 구체적인 작업을 수행하는 방법을 설명합니다. 분위기가 아니라 독자가 내일 취할 수 있는 행동입니다.
- 청중의 누구나 따라할 수 있습니다. 전문 용어 장벽이 없고, 내부자 이야기가 없습니다.
- 구조화되어 있고, 반복 가능하며, 단계별입니다. 단지 영감을 주는 것이 아닙니다.
- 참신합니다. 독자가 이런 일을 할 수 있다는 것을 전혀 몰랐습니다.
네 가지 위에 있는 메타 기준은: 누군가가 이것을 북마크하고 나중에 구현하러 돌아올 것인가? 대답이 '아니오'라면, 아무리 문장이 깨끗해도 슬롭입니다.
비결은 루브릭입니다. 모호한 루브릭("이것이 좋고 매력적인가")은 모호한 점수를 생성합니다. 구체적인 루브릭("이것이 적어도 하나의 복사-붙여넣기 가능한 템플릿이나 플레이북을 포함하는가")은 신뢰할 수 있는 점수를 생성합니다. 심판은 당신이 실제로 당신의 취향을 적어야만 당신의 취향을 물려받습니다.
제품의 경우, 테스트 케이스는 로그에서 가져옵니다
당신의 기능이 실제로 보는 입력을 로그에서 가져오세요. 실제 사용자 세션에서, 출시일에 테스트한 세 가지 해피 패스 예제가 아닙니다. 당신을 망가뜨리는 경우는 이상한 경우이며, 이상한 경우는 로그에 있습니다.
제품의 경우, 메트릭은 작업과 일치합니다
각 입력에 대해 올바른 출력이 무엇인지 정의하십시오. 그런 다음 메트릭을 작업과 일치시키십시오. 하나의 올바른 레이블이 있을 때는 정확 일치, 구조가 유지되어야 할 때는 검증기, 출력이 개방형일 때는 의미적 유사성에 심판을 더합니다. 메트릭은 숫자를 반환하기만 하면 됩니다. 숫자만이 임계값을 설정할 수 있기 때문입니다.
둘 다의 경우, 임계값은 당신이 지키는 선입니다
0.7은 시작하기에 합리적인 값입니다. 0.7 미만의 모든 것은 출시 전에 재작업되거나 폐기됩니다. 예외 없음. 임계값은 당신이 마음에 들어서 0.6을 통과시키지 않을 때만 작동합니다. 요점은 늦은 밤의 자존심을 결정에서 빼는 것입니다.
이것이 벤치마크입니다. 이제 그것이 스스로 실행되게 만듭니다.
hermes 내부에 루프 구축하기
hermes는 평가 버튼을 제공하지 않습니다. "슬롭 보호 켜기"를 클릭하는 품질 대시보드가 없습니다.
hermes가 대신 제공하는 것은 더 좋습니다. 평가 루프의 원시 조각들을 프리미티브로 제공하여 한 번 조립하면 소유하게 됩니다:
스스로 작성하고 재사용하는 스킬, 세션을 넘어 성장하는 지속적 메모리, 모든 플랫폼에 전달하는 내장 크론, Slack의 승인 버튼, 그리고 코어에 내장된 자기 개선 습관.
hermes는 스스로를 "당신과 함께 성장하는 에이전트"라고 부르며, 그 성장이 바로 우리가 구축하는 루프입니다.
자, 이제 연결해 보겠습니다. 여섯 가지 동작입니다.
동작 1: hermes를 당신이 도달할 수 있는 곳에 세우기
설치하고 Telegram에 연결하십시오. 이것은 생각보다 중요합니다. 게이트는 당신을 방해할 수 있을 때만 작동하기 때문입니다. hermes는 20개 이상의 채널에서 실행되며 Slack과 Telegram에 네이티브 승인 버튼을 제공하므로, 에이전트가 백그라운드에서 작업하고 결정이 필요할 때 당신의 어깨를 두드릴 수 있습니다.
동작 2: 금본위를 메모리에 로드하기
hermes는 세션을 넘어 성장하는 지속적 메모리를 가지고 있으며, 완전한 교차 세션 검색이 가능합니다. 따라서 벤치마크의 20~50개 최고 작품을 한 번 넣으면 영원히 남습니다. 이것은 일반적으로 스크린샷과 오래된 초안에 흩어져 있는 부분입니다. 여기서는 에이전트의 장기 메모리이며, 질의 가능하고, 점수가 측정되는 기준 데이터입니다.
동작 3: 루브릭을 심판 스킬로 전환하기
이것이 핵심입니다. 당신은 hermes에게 한 번, 평범한 영어로, 출력과 루브릭을 받아 각 기준에 대해 0~1 점수와 한 줄 이유를 반환하는 스킬을 만들라고 말합니다. 이것이 LLM-as-a-judge입니다. 에이전트가 당신의 LLM을 평가하는 것입니다. 날카로운 루브릭을 가진 모델은 당신보다 더 일관된 비평가입니다. 그 작품에 대한 자존심이 없고, 당신이 은근히 자랑스러워하는 한 문장에 집착하지 않기 때문입니다.
이것이 일회성 프롬프트가 아니라 스킬로 사는 이유는 hermes 스킬이 절차적 메모리이기 때문입니다. 에이전트가 스킬을 작성하고, 보관하고, 재사용합니다. 당신은 당신의 취향을 한 번 인코딩하고, 그것은 모든 출력을 영원히 평가합니다. 그리고 스킬은 복리 효과를 냅니다. nous는 20개 이상의 자체 생성 스킬을 가진 에이전트가 유사한 작업을 40% 더 빠르게 완료한다는 것을 발견했습니다. 그들은 과정을 다시 발견하지 않기 때문입니다. 당신의 심판은 실행될수록 더 날카로워집니다.
동작 4: 스위트를 스킬로 만들기, 스프레드시트가 아니라
당신의 테스트 케이스와 메트릭 함수는 hermes가 보유하고 버전 관리하는 스킬이 됩니다. 메트릭 라이브러리는 작업에 필요한 모든 것입니다. 분류를 위한 정확 일치, 추출을 위한 정규식, 구조를 위한 JSON 및 키-값 검증기, 생성적 출력을 위한 의미적 유사성.
개방형 작업을 위한 당신의 심판 스킬. hermes는 스스로 점수 코드를 작성합니다. 당신이 작업을 설명하면 에이전트가 메트릭을 구축합니다. 이 모든 것이 에이전트가 소유하는 한 곳에 위치하며, 당신이 잃어버릴 스프레드시트가 아닙니다.
동작 5: 회귀 테스트와 승인 버튼으로 출시 게이트 설정하기
이것은 전체 시스템에서 가장 레버리지가 높은 습관이며, 아무도 수동으로 계속하지 않는 것입니다. 따라서 에이전트에 넘깁니다. 모든 변경(새 프롬프트, 모델 교체, 파이프라인 조정)이 스위트를 트리거하도록 연결하십시오. hermes는 모든 케이스를 다시 실행하고, 기준선에 대한 점수 델타를 계산하며, 조용히 출시하는 대신 Slack에서 당신을 핑합니다: "점수가 0.81에서 0.74로 떨어졌습니다. 두 케이스가 회귀했습니다. 승인하시겠습니까?" 그리고 당신이 버튼을 누를 때만 진행됩니다.
/goal로 해당 작업에 고정할 수 있습니다. 이는 에이전트를 턴 전반에 걸쳐 목표에 유지시킵니다. 더 큰 작업의 경우 멀티 에이전트 칸반이 실행을 분해하고, 병렬로 점수를 매기고, 스케줄링할 수 있습니다. 따라서 게이트는 상시 프로세스가 되며, 당신이 실행해야 한다고 기억하는 것이 아닙니다.
동작 6: 크론으로 프로덕션을 모니터링하고 루프를 닫기
hermes는 모든 플랫폼에 전달하는 내장 크론을 가지고 있습니다. 따라서 실제 실행을 샘플링하고, 동일한 심판 스킬로 점수를 매기고, 라인이 떨어지는 순간 DM을 보내는 작업을 스케줄하십시오. 당신은 품질 저하가 시작된 날을 잡아냅니다. 클라이언트가 불평하는 주가 아니라.
그런 다음 전체 시스템이 복리 효과를 내는 부분입니다. Slack에서 엄지손가락 내리기로 나쁜 출력을 표시하면, hermes는 그것을 스킬 스위트에 새로운 테스트 케이스로 다시 씁니다. 그 실패한 실행은 영구적인 검사가 됩니다. 자기 개선이 hermes의 본질이기 때문에(옆에 덧붙인 기능이 아니라), 스위트는 매주 스스로 강화됩니다. 당신이 자는 동안 기준선이 상승합니다.
이것이 실행되면 좋은 것이 어떻게 보이는지, 구체적으로: 루브릭에서 0.7 미만의 콘텐츠 작품은 절대 출시되지 않습니다. 기준선 아래로 메트릭을 떨어뜨리는 제품 변경은 당신이 승인할 때까지 배포를 차단합니다. 그리고 프로덕션 점수 라인은 평평하게 유지되거나 상승합니다. 라인이 떨어지는 날은 hermes가 당신을 핑하는 날이며, 이탈이 나타나는 주가 아닙니다.
아무도 듣고 싶어하지 않는 부분
당신의 AI 출력이 일관적이지 않은 이유는 당신이 프롬프팅을 못하기 때문이 아니며, 모델이 아직 충분히 똑똑하지 않기 때문도 아닙니다.
그것은 당신이 품질 단계 없이 생성 단계만 실행하고 있기 때문입니다. 당신은 절반의 시스템을 구축하고, 작동하는 절반을 비난해 왔습니다.
해결책은 더 나은 프롬프트가 아니라, 빠진 계층입니다: 좋은 것이 무엇인지 정의하고, 그것을 숫자로 바꾸고, 모든 출력을 그것에 대해 점수 매기고, 기준선 아래로 떨어지는 모든 것을 게이트로 차단하고, 루프를 닫아 기준선이 매주 상승하게 하십시오. 그리고 이제 그 계층은 언젠가의 프로젝트가 아니라, 당신의 컴퓨터에서 실행되는 에이전트 안의 여섯 가지 동작입니다.
그렇게 하면 슬롭은 당신에게 무작위로 발생하는 일이 아니라, 당신이 출구에서 매번 잡아내는 일이 됩니다. 진짜 공장이 결함이 고객에게 도달하기 전에 잡아내는 것과 같은 방식입니다.
프롬프트는 결코 시스템이 아니었습니다.
평가 루프가 시스템이며, hermes가 그것이 실행되는 곳입니다. 이제 당신은 그것을 가지고 있습니다.
