LAN 내 AI 봇의 '거짓(환각)'을 용납하지 않는다: CI/CD로 실행하는 사실 일관성 벤치마크 테스트 자동화 스위트 (TC01~TC10)
요약
LAN 내부 AI 챗봇의 환각 및 사실 일관성 문제를 해결하기 위해 자동화된 벤치마크 테스트 스위트를 제안합니다. 이 프레임워크는 실제 DB의 정답 데이터(Ground Truth)와 비교하여, LLM 답변에 필수 키워드 포함 여부를 CI/CD 환경에서 자동으로 채점하는 것이 핵심입니다.
핵심 포인트
- LLM 애플리케이션은 사실 일관성 검증이 필수적이다.
- 프롬프트 변경 시에도 자동화된 테스트를 반드시 실행해야 한다.
- Ground Truth 기반의 벤치마크 스위트가 필요하다.
- CI/CD 환경에서 '필수 키워드 완전 포함' 방식이 가장 확실하고 저렴하다.
LAN 내부 자산 관리나 정보 시스템 담당자 업무용으로 LLM(챗봇)을 구축하여 현장에 공개했다고 가정해 봅시다.
사용자로부터 “좀 더 정중하게 답변해주세요”, “요약해주세요”와 같은 요청을 받아 시스템 프롬프트(System Prompt)를 약간 수정한 경험이 있으신가요?
바로 그 직후, 끔찍한 비극이 발생합니다.
- “프롬프트를 조금 바꾼 것 때문에 LAN 내부 PC 대수를 거짓으로 답변하게 되었다.”
- “존재하지 않는 IP 주소를 자신만만하게 지어낸다(환각/Hallucination).”
- “교체해야 할 장비 목록을 물었는데, 정상적인 장비를 임의로 고장으로 판정한다.”
웹 애플리케이션 코드라면 Unit Test를 작성하는 것이 당연한 일인데도 불구하고, 어째서인지 LLM의 프롬프트 변경만은 ‘사람이 채팅 화면에서 몇 번 테스트하면 끝!’이라는 식으로 출시되는 경우가 많습니다.
AI의 사실 일관성을 보장하기 위해서는 **‘실제 데이터베이스의 정답 데이터(Ground Truth)와 대조하여, 기대하는 중요 키워드가 답변에 포함되어 있는지 자동으로 채점하는 벤치마크 스위트’**를 CI/CD 환경에서 실행해야 합니다.
본 기사에서는 필자의 프로젝트에서 실제로 운영하고 있는 10가지 항목의 자동 정밀도 평가 프레임워크 설계와 구현 내용을 공개합니다.
테스트 케이스는 사전에 실제 DB의 정답 값(Ground Truth)과 일치하도록 정의합니다.
| 테스트 ID | 테스트 질문 | 검증 내용・정답 키워드 | 판정 기준 |
|---|---|---|---|
| TC01 | “스마트폰은 몇 대 있습니까?” | ['4'] | 장비 목록 내 스마트폰 대수(4대)를 올바르게 카운트 |
| TC02 | “NAS의 제조사명은 무엇입니까?” | ['Synology'] | 스토리지 벤더명을 정확하게 특정 |
| TC03 | “교체해야 할 장비로 판정된 장비의 IP는?” | ['192.168.1.236'] | EoL(End-of-Life) 장비의 IP를 정확히 나열 |
| TC04 | “IP 192.168.1.200의 OS는 무엇입니까?” | ['Ubuntu'] | 대상 호스트의 OS 버전을 답변 |
| TC05 | “복합기의 IP 주소와 제조사명을 알려주세요” | ['192.168.1.233', 'Epson'] | 기기 종류별로 IP와 벤더를 동시에 특정 |
| TC06 | “전체 장비의 총 대수는 몇 대입니까?” | ['20'] | 전체 대수(20대)를 환각 없이 답변 |
| TC07 | “Amazon 장비의 IP 주소는 무엇입니까?” | ['192.168.1.227'] | 벤더명으로부터 IP를 역추적 |
| TC08 | “192.168.1.9의 기기 분류는 무엇입니까?” | ['스마트'] | 스마트 TV 등의 종류를 답변 |
| TC09 | “192.168.1.236의 OS 판정은 어떻게 되어 있습니까?” | ['특정 불가'] | 불분명한 장비를 억지로 추측하지 않고 ‘특정 불가’로 정확히 보류 |
| TC10 | “Synology제 NAS의 전체 IP를 알려주세요” | ['192.168.1.12', '192.168.1.13'] | 여러 개 존재하는 장비의 모든 IP를 빠짐없이 나열 |
특히 **TC09(불분명한 것을 아는 척하지 않고 ‘특정 불가’라고 답변할 수 있는지)**는 환각 억제에 가장 중요한 체크 포인트입니다.
복잡한 LLM-as-a-Judge(판단용 LLM)를 사용하면, 판단 측의 편차나 비용이 발생합니다.
CI/CD 환경에서 빠르고 저렴하게 실행하기 위해서는, 대소문자를 무시하는 ‘필수 키워드 완전 포함(Deterministic Keyword Match)’ 방식이 가장 확실합니다.
# 핵심 구현 로직 (요점 발췌)
import requests
import json
...
AI 애플리케이션 개발에서 가장 위험한 것은 ‘감각적인 튜닝’입니다.
프롬프트 한 줄을 수정했다면, 자동 테스트를 일괄 실행하는10가지 필수 요건이 하나라도 빠지면 풀 리퀘스트(Pull Request) 병합을 막는다환각(거짓)을 CI 환경에서 기계적으로 차단합니다.
이러한 테스트 자동화 스위트를 도입해 놓기만 해도, “프롬프트를 만졌더니 다른 기능이 고장 났다”라는 디그레이데이션(Degrade)을 100% 방지할 수 있으며, 안심하고 운영 환경의 AI를 개선하기 계속할 수 있습니다!
끝까지 읽어주셔서 감사합니다!
본 기사가 조금이라도 “도움이 되었다”, “나중에 시도해보고 싶다”라고 느끼셨다면, 꼭 Qiita의 **“좋아요(♡)”**와 “스택(Stock)”, 그리고 계정 팔로우를 해주시면 향후 검증 및 집필에 큰 힘이 됩니다!
또한, 본 기사보다 더 심층적인 **"심층 아키텍처 해설," "주요 파라미터의 기술적 근거," "현장 안티패턴 및 트러블슈팅 대응표"**는 아래 GitHub 기술 리소스를 통해 공개하고 있습니다.
⭐ 전체 14층, 200패턴의 자립형 인프라 & 온프레미스 AI 레퍼런스 모음(오지상 아루세나)을 순차적으로 공개 중입니다. GitHub 리포지토리 Star (★) 및 X (@OjisanTechnical) 팔로우도 부탁드립니다!
👉 GitHub 레포지토리: ojisantech/ojisan-arsenal
💡
【검증 환경 및 개인 연구(PoC) 관련 주석】
본 기사는 필자 개인의 자택 검증 환경(홈랩/가상 환경)에서 공개 정보 및 OSS(오픈소스 소프트웨어)를 사용하여 독자적으로 구축하고 검증한 개인 연구(PoC) 기록입니다. 특정 기업이나 단체의 실제 환경 또는 업무상의 비공개 정보와는 일절 관련이 없습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기