도구 출력은 독립적인 검사가 필요합니다. 성공적인 호출이 증명하는 것은 도구가 응답을 반환했다는 사실뿐이며, 그 결과가 정확하거나 최신이거나 완전하다는 뜻은 아니기 때문입니다.
홈 에이전트는 저장소 도구에서 HTTP 200 응답을 받을 수 있지만, 실제로는 잘못된 폴더를 측정했을 수 있습니다. 또는 물리적 상태가 바뀌기 전에 디바이스 API가 반환한 “잠김” 상태를 그대로 받아들일 수도 있습니다. 같은 호출을 반복하면 동일한 오류가 재현될 수 있습니다. 검증은 반환된 값과 그 값에 의존하는 결정 사이에 별도의 관찰이나 규칙을 추가합니다.
전송 성공과 의미적 성공은 다릅니다
도구 응답에는 전송 상태, 파싱 가능한 구조, 스키마 유효성, 도메인 의미, 관찰된 부작용 등 여러 계층이 있습니다. 각 계층은 통과하면서도 다음 계층에서 실패할 수 있습니다. 예를 들어 여유 공간을 나타내는 숫자 필드는 유효한 JSON일 수 있지만, 오래된 데이터를 사용하거나 잘못된 볼륨을 가리킬 수 있습니다.
실용적인 결과 검증 계층 패턴은 원시 에이전트 출력과 후속 사용 사이에 검증을 배치합니다. 이 패턴은 유창한 출력을 완료로 간주하는 대신 형식 검사, 어설션, 증거 기반 게이트를 구분합니다. 이러한 구분은 이후 가정 내 테스트에서도 계속 드러납니다.
오케스트레이터는 이러한 계층을 별도로 표현해야 합니다. 도구에 연결할 수 있지만 검증되지 않은 상태일 수 있고, 제안된 작업은 유효하지만 아직 실행되지 않았을 수 있으며, 실행 결과가 성공으로 보고된 뒤에도 대상 시스템이 변경된 상태를 확인하기 전일 수 있습니다.
독립적인 검사에는 다른 실패 경로가 필요합니다
유용한 검증은 동일한 구성 요소에 자기 자신을 승인하도록 요청하지 않습니다. 파일 생성은 메타데이터나 해시를 읽어 확인하고, 데이터베이스 쓰기는 권위 있는 저장소에서 읽어 확인하며, 스마트홈 명령은 명령 확인 응답이 아니라 상태 센서로 확인해야 합니다.
검증 가능한 에이전트 상태는 에이전트 시스템을 명시적인 안전 속성을 갖춘 검증 가능한 상태 머신 내부의 비결정적 구성 요소로 모델링합니다. 이 접근 방식은 제약 조건과 런타임 모니터가 자유 형식의 모델 추론 외부에 있는 오케스트레이션 계층에 포함되어야 하는 이유를 보여 줍니다.
가장 강력한 검사는 결과의 영향에 따라 달라집니다. 위험도가 낮은 검색은 스키마와 출처의 존재 여부를 확인하면 되지만, 삭제 작업에는 정확한 대상 확인, 정책 승인, 작업 후 관찰이 필요합니다. 여러 검사가 하나의 손상된 출처를 공유한다면 검사를 더 추가한다고 해서 자동으로 더 나아지는 것은 아닙니다.
검증도 같은 잘못된 가정에 동의할 수 있습니다
동일한 프롬프트, 맥락, 모델을 사용하는 두 번의 LLM 검사는 독립적이지 않고 상관되어 있습니다. 두 번째 API 엔드포인트가 동일한 데이터베이스를 공유할 수도 있습니다. 테스트 역시 사용자의 실제 의도를 놓친 채 구현만 검증할 수 있습니다. 따라서 실패 방식이 다를 때에만 일치가 신뢰도를 높입니다.
독립 검증 루프 워크플로는 구현, 적대적 검증, 수정 역할을 분리합니다. 이 방식의 핵심 가치는 에이전트 수가 아니라 결과를 생성하는 일과 외부 기준에 따라 결과를 테스트하는 일 사이에 의도적인 차이를 두는 데 있습니다.
실패 경계는 독립적으로 관찰 가능한 진실이 없는 중대한 결과입니다. 시스템은 반복적인 추론이나 유사한 모델 간 다수결로 확신을 꾸며 내는 대신 불확실성을 드러내고 사람의 확인을 요청해야 합니다. 자동화가 이어지기 전에 중간 결과를 계속 검사할 수 있어야 합니다.
중대한 도구 하나를 위한 검사 설계
데이터나 디바이스 상태를 변경할 수 있는 도구 하나를 선택합니다. 사전 조건, 예상 응답 스키마, 도메인 불변 조건, 권위 있는 사후 조건, 타임아웃, 롤백 경계, 그리고 테스트를 실행하기 전에 사람의 승인이 필요한 정확한 조건을 작성합니다.
에이전트 검증의 한계에 설명된 자기 검증의 한계를 활용해 에이전트가 검사할 수 있는 주장과 직접 관찰할 수 없는 물리적 결과를 구분합니다. 안전한 테스트 환경에서 잘못된 대상, 오래된 응답, 부분적인 성공, 거짓 확인 응답을 주입합니다.
검증기가 주입된 모든 의미적 실패를 포착하고 종속 작업을 차단할 때만 통과로 간주합니다. 검사가 동일한 출처에 의존하거나 사후 조건을 관찰할 수 없다면 결과를 검증되지 않은 것으로 표시하고 에이전트의 권한을 낮춥니다.
기술 및 AI 허브
더 읽어보기

홈 지식 베이스에서 RAG 인용 정확도를 결정하는 요인은 무엇인가?
관련성 있는 출처라도 잘못된 인용이 될 수 있는 이유와 지원 및 커버리지를 좌우하는 파이프라인 단계, 그리고 가정용 RAG 주장 감사 방법을 알아보세요.

로컬 LLM에서 안정적인 JSON 출력을 가능하게 하는 기능은 무엇인가요?
어떤 기능이 JSON 구문을 강제하고 어떤 기능이 의미적 정확성을 보호하는지 알아보고, 스키마, 프롬프트, 실패 사례 전반에서 로컬 모델을 테스트하는 방법을 확인하세요.

로컬 AI 데이터 계보: 모든 답변에 추적 가능한 출처 경로가 필요한 이유
소스 경로가 로컬 AI 답변을 감사 가능하게 만드는 방식, 인용만으로는 불완전한 이유, 그리고 업데이트와 삭제를 통해 계보를 테스트하는 방법을 알아보세요.

