정족수의 가면: 에이전트 검증에 결함 주입(Fault Injection)이 필요한 이유
당신의 AI 에이전트는 자신의 정확도에 대해 거짓말을 하고 있을지도 모릅니다.
최근 저는 AI 파트너가 세 번 연속으로 실패하는 것을 목격했습니다. 서로 다른 환경에서 동일한 진실성 문제를 놓쳤습니다. 잘못된 어조로 글을 썼습니다. 리뷰어 모델은 동일한 오류를 읽을 때마다 더 높은 점수를 주었습니다. 심지어 사실 왜곡(fact drift)에 관한 사실 관계조차 잘못 계산했습니다.
제가 루프(loop) 밖에 있었기에 이 오류들을 잡아낼 수 있었습니다.
이는 에이전트 스택의 거대한 문제를 드러냅니다. 대부분의 검증 시스템은 독립성을 가정합니다. 멀티 에이전트 투표, maker/checker 패턴, 또는 앙상블 프롬프트를 사용합니다. 이들은 서로 다른 경로가 서로 다른 것을 볼 것이라고 가정합니다.
하지만 종종 이러한 경로들은 동일한 소스를 공유합니다.
리뷰어가 작성자와 동일한 소스를 읽는다면, 그것은 두 개의 관점이 아닙니다. 두 개의 서로 다른 모자를 쓴 하나의 관점일 뿐입니다. 이것은 정족수의 가면을 쓴 단일 장애점(single point of failure)입니다.
만약 경로들이 상류(upstream)를 공유한다면, 그들은 동일한 잘못된 사실이나 동일한 환각(hallucination)에 동의하게 될 것입니다. 출력값이 다양해 보이기 때문에 시스템은 건강해 보이지만, 소스가 거짓을 말할 때마다 시스템은 실패합니다.
이를 해결하려면 결함 주입(fault injection)을 사용해야 합니다.
단순히 에이전트들이 의견을 달리하는지 측정하지 마십시오. 시스템의 일부를 고장 냄으로써 그들이 의견을 달리하도록 강제할 수 있는지 측정하십시오.
스택을 테스트하는 방법은 다음과 같습니다:
- 잘못된 메모리 주입: 하나의 검색 경로에 가짜 사실을 심습니다. 두 경로 모두 가짜 사실을 반환한다면, 경로들이 결합(coupled)되어 있는 것입니다.
- 규칙 변형: 오프라인에서 규칙을 변경합니다. maker와 checker가 불일치를 알리지 않고 모두 새로운 규칙을 따른다면, 그들은 캐시를 공유하고 있는 것입니다.
- 잘못된 텔레메트리 심기: 가짜 모델 ID를 로그에 남깁니다. 검증이 통과된다면, 검증기(verifier)가 작성자와 동일한 레코드를 읽고 있는 것입니다.
분산 시스템은 이미 수년 전에 이 문제를 해결했습니다. 그들은 카오스 엔지니어링(chaos engineering)과 파티션 테스트를 사용합니다. 그들은 시스템이 잘 작동하는 것을 지켜봄으로써 신뢰하지 않습니다. 실패를 유도함으로써 신뢰합니다.
에이전트 아키텍처도 이러한 규율을 채택해야 합니다.
독립성은 한 번 설정하면 끝나는 속성이 아닙니다. 끊임없이 재검증해야 하는 속성입니다. 공유 캐시나 모델 업데이트가 하룻밤 사이에 당신의 독립성을 무너뜨릴 수 있습니다.
만장일치 투표를 신뢰하는 것을 멈추고, 결함 주입을 시작하십시오.
Source: https://dev.to/jugeni/a-quorum-costume-why-agent-verification-needs-fault-injection-kbh
Optional learning community: https://t.me/GyaanSetuAi