결정론의 힘¶
사람과 LLM 심사자는 미묘한 차이를 표현할 수 있지만, 동시에 모호성을 야기하기도 합니다. 프로그램 기반 규칙 평가는 다릅니다. 여기에는 "판단"이 개입되지 않고 오직 논리만 존재합니다.
프로그래밍 규칙은 코드, 정규 표현식 또는 수학을 사용하여 출력을 평가하는 자동화된 검사입니다. 심사위원에게 응답이 "유효한 JSON"인지 물어보면 답변이 모호해질 수 있지만, 프로그래밍 규칙에 물어보면 답변은 이진적입니다. 즉, 구문 분석에 성공하거나 실패하거나 둘 중 하나입니다.
규칙의 주요 강점¶
속도 및 비용: 실행 시간은 밀리초 단위이며 API 크레딧 비용은 사실상 0입니다.
오류 제로: 규칙은 기준을 "잘못 해석"할 수 없습니다. 코드가 올바르면 평가는 매번 100% 정확합니다.
정확성: LLM은 정확한 문자 수를 세거나 복잡한 계산을 수행하는 것과 같은 세밀한 작업에서 어려움을 겪습니다. 규칙 기반 알고리즘은 이러한 “기계적인” 검증에 탁월합니다.
형식과 의미 사이의 상충 관계¶
제한점은 간단합니다. 규칙은 형식만 확인하고 의미 는 확인하지 않습니다 .
규칙은 구조, 길이, 필수 키워드, JSON 스키마 또는 차단된 구문을 확인할 수 있습니다 .
규칙으로는 통찰력, 공감 능력, 도움을 주고자 하는 마음, 또는 글쓰기 품질을 확인할 수 없습니다 .
회귀 테스트의 핵심¶
규칙은 결정론적이기 때문에 테스트 파이프라인에서 완벽한 “1차 방어선” 역할을 합니다.
서점 안내 메시지를 업데이트한다고 상상해 보세요.
규칙 검사: 고가의 LLM 검사기가 출력 결과를 검토하기 전에, 프로그램 규칙에 따라 도구 호출이 여전히 유효한지, ID 형식이 올바른지 확인합니다.
즉각적인 피드백: 프롬프트 변경으로 인해 JSON 구조가 손상될 경우, 규칙이 즉시 이를 감지합니다.
효율성: 규칙을 통해 “명백한” 기계적 오류를 잡아냄으로써, 인력과 LLM(판정자)을 더 어렵고 주관적인 문제에 투입할 수 있습니다.
요약: 평가 코드를 작성해야 하는 시점¶
평가 조건을 간단한 조건문 (if/then) 으로 작성할 수 있다면 , 그것은 프로그래밍 규칙이어야 합니다. 다음과 같은 경우에 사용하세요:
스키마 유효성 검사: 에이전트가 유효한 JSON 또는 Markdown을 출력하는지 확인합니다.
제약 조건 검사: 응답이 특정 문자 수 이하인지 확인합니다.
키워드 존재 여부: 특정 필수 정보(예: 도서의 SKU)가 있는지 확인합니다.
수학/논리: 가격 계산 또는 재고 수량 검증.
프로그래밍 규칙은 언제 사용해야 할까요?¶
결정은 생각보다 간단합니다. 실패 또는 성공을 구체적인 기계적 조건으로 설명할 수 있는 경우라면 프로그래밍 규칙이 적합한 도구입니다. 출력 결과가 어떻게 나와야 하는지(또는 나와서는 안 되는지) 정확히 알고 있다면 LLM 호출을 낭비하지 말고 규칙을 작성하세요.
규칙의 일반적인 사용 사례
형식 준수(스키마 유효성 검사): 이는 운영 시스템에서 가장 중요한 검사입니다. JSON 구문 분석이 제대로 되는지, 필수 필드가 모두 포함되어 있는지 확인해야 합니다.
서점 예시: 담당자가 픽업 주문을 할 때, 출력에 customer_name, contact_info, 및 가 포함되는지 확인하는 규칙이 있습니다 book_details.
길이 및 구조 검사: 응답이 정의된 범위 내에 있습니까?
서점 운영자 예시: 만약 작성 지침에 2~4개의 짧은 단락이 요구된다면, 단어 수 제한 규칙을 통해 너무 긴 답변이나 너무 짧은 “한 문장” 답변을 걸러낼 수 있습니다.
키워드 및 엔티티 검사: 응답에 필수 정보가 포함되어 있습니까?
서점 예시: 에이전트가 책을 추천하는 경우, 부분 문자열 규칙을 사용하여 해당 단어 title와 단어가 author텍스트에 실제로 존재하는지 확인할 수 있습니다.
금지된 콘텐츠(개인 식별 정보 및 보안): 이는 "역방향 검사"입니다. 응답에 포함되어서는 안 되는 내용이 포함되어 있습니까 ?
서점 예시: 정규 표현식 패턴을 사용하여 상담원이 내부 데이터베이스 ID, 고객 이메일 또는 결제 정보를 유출하지 않도록 하세요. 이는 규정 준수 및 보안에 매우 중요합니다.
분류 정확도: 모델이 고정된 레이블 목록(예: Search, Pickup, Store_Info)에서 레이블을 선택하는 경우, 규칙은 해당 레이블이 유효한지 확인합니다.
전문가 팁: “정답” 데이터셋이 있는 경우, 규칙을 통해 모델이 선택한 레이블이 올바른 레이블과 일치하는지 즉시 확인할 수 있습니다.
공통점: 정밀성¶
이 모든 경우에 여러분은 이미 알려진 것들을 다루고 있습니다 . 이러한 지식을 코드로 표현할 수 있으며, 그 코드는 매번 정확히 똑같은 방식으로 실행됩니다. 이러한 기계적인 검사를 프로그래밍 규칙에 맡김으로써, 시스템의 "성격"이나 "공감 능력"에 대해 걱정하기 전에 시스템의 구조적 안정성을 확보할 수 있습니다.
효과적인 프로그램 규칙 설계하기¶
규칙이 무엇인지 아는 것과 오경보를 유발하지 않는 규칙을 작성하는 방법을 아는 것은 다릅니다. 효과적인 규칙은 목표 지향적이고 확장 가능하며 현실에 비추어 검증되어야 합니다 .
1. 고장 모드부터 시작하세요¶
“무엇을 확인할 수 있을까요 ?” 라고 묻지 말고, “어떤 구체적인 오류를 잡아내고 싶나요?” 라고 물으세요. * 프로세스: 프로덕션 로그를 살펴보세요. 서점 담당자가 품절된 도서를 추천하는 경우, 추천 도서 ID와 재고 수량을 대조하는 규칙을 작성하세요.
목표: 쓸모없는 규칙을 수백 개 작성하는 것을 피하십시오. 실제로 발생하거나 위험도가 높은 문제에만 집중하십시오.
2. 이진 규칙 vs. 점수 규칙¶
모든 규칙이 단순히 합격/불합격으로 나뉘는 것은 아닙니다. 평가 기준에 맞는 논리를 선택하세요.
이진 분류(통과/실패): “무관용” 위반에 사용합니다.
예시: 답변 과정에서 고객의 이메일 주소가 유출되었습니까? (예 = 불합격, 아니오 = 합격).
점수 매기기(0-5): 부분적인 성공도 여전히 가치가 있을 때 사용하세요.
예시: 책 추천은 5가지 요소(제목, 저자, 가격, 구매 가능 여부, 설명)를 갖춰야 합니다. 에이전트가 5가지 요소 중 4가지만 충족했다면, 완전히 실패한 것은 아니고 약간의 부족함이 있는 것입니다. 점수는 이러한 미묘한 차이를 포착합니다.
3. 규칙 구성 가능성¶
강력한 평가는 간단한 벽돌을 쌓아 올리는 것과 같습니다. 하나의 거대하고 복잡한 스크립트 대신, 집중적인 검사들을 결합하세요.
규칙 A: JSON이 유효한가?
규칙 B: 필수 입력란이 모두 포함되어 있습니까?
규칙 C: 개인 식별 정보(PII)가 감지되었습니까? 그런 다음 이러한 점수를 평균 내거나 세 가지 모두를 통과하도록 하여 견고한 구조적 평가를 수행할 수 있습니다 .
4. 예외적인 상황에 주의하세요¶
코드는 경계에서 취약합니다. 이메일 주소를 추출하기 위한 정규 표현식이 임의의 “@” 기호가 포함된 문장을 실수로 잘못 판단할 수도 있고, 길이 검사가 공백으로 가득 찬 출력에 속을 수도 있습니다.
해결 방법: 배포하기 전에 알려진 예제를 사용하여 규칙을 테스트해야 합니다.
워크플로: 간단한 "테스트 세트"를 구성하여 코드가 예상대로 작동하는지 확인합니다. 이는 나중에 발생할 수 있는 큰 문제를 예방하는 일회성 비용입니다.
핵심 요점: 프로그램 규칙은 첫 번째 방어선 입니다 . 이러한 규칙은 기계적인 "형식"을 처리하므로 LLM 심사위원과 사람 검토자는 "의미"에 집중할 수 있습니다.평가 피라미드: 3가지 유형 통합¶
지금까지 휴먼 인 더 루프, LLM을 심판으로 활용하는 방식, 그리고 프로그래밍 방식 규칙에 대해 살펴보았습니다. 이제 이 모든 요소들이 어떻게 결합되는지 알아보겠습니다. 프로그래밍 방식 규칙은 결과물이 좋은지 아닌지를 알려주는 것이 아니라, 유효 한지 여부를 알려줍니다 . 그리고 실제 운영 환경에서는 유효성이 품질의 필수 조건입니다.
신뢰성의 계층 구조¶
평가 전략을 피라미드라고 생각해 보세요. 각 층은 바로 아래 층이 처리할 수 없는 부분을 담당합니다.
기초: 프로그램 규칙 (“골격”)
역할: 최전선 방어선. 구조적 오류 및 규정 준수 오류(예: 잘못된 JSON, 개인정보 유출)를 잡아냅니다.
논리: JSON 형식이 잘못되어 애플리케이션이 충돌한다면, AI의 조언이 얼마나 "통찰력"이 뛰어났든 상관없습니다. 구조적 정확성이 항상 최우선입니다.
중간 단계: 판사로서의 LLM (“영혼”)
역할: 유효성이 확인된 후 품질을 평가합니다.
논리: 언어를 이해해야 하는 질문은 다음과 같습니다. 어조가 적절한가? 권고 사항이 관련성이 있는가? 정보가 완전한가?
에이펙스: 인간 참여형 프로세스(“실제 상황”)
역할: 예외적인 상황을 검증하고 "알 수 없는 미지의 것들"을 탐구합니다.
논리: 인간은 LLM 평가 시스템을 조정하여 모델에 “도움이 되는” 것이 사람에게도 “도움이 되는” 것을 의미하도록 합니다. 그들은 아직 자동화되지 않은 새로운 오류 패턴을 찾아냅니다.
신뢰성 루프의 실제 작동 모습¶
이 시스템의 강점은 각 계층 간의 통신 방식에 있습니다. 예를 들어, 서점 담당자가 실수로 내부 데이터베이스 ID를 포함시키는 등 인간 검토자가 새로운 오류를 발견하면 특정 경로를 따라 진행됩니다.
1단계: 담당자가 “데이터베이스 ID” 유출을 발견합니다.
2단계: 해당 오류를 즉시 프로그램 규칙 으로 코드화합니다 .
3단계: 이제 해당 규칙은 향후 모든 출력에 대해 자동으로 실행되어 문제를 밀리초 단위로 감지합니다.
4단계: 이제 사람은 자유롭게 다음 복잡한 실패 패턴을 찾아 나설 수 있습니다 .
요약: 엔지니어링 신뢰성¶
신뢰할 수 있는 AI는 모든 것을 한 번에 완벽하게 만드는 것이 아니라, 발견된 오류를 자동화된 검사로 꾸준히 전환하는 과정을 통해 구축됩니다 . 평가 피라미드를 사용하면 문제가 한 번 발견되면 사용자에게 다시는 발생하지 않도록 보장할 수 있습니다.