환각의 연쇄 (The Confabulation Cascade)
내 AI 에이전트가 루프에 빠졌다.
가짜 컬럼 이름으로 SQL 쿼리를 작성하면, 데이터베이스는 에러를 반환했다. 에러 메시지에는 실제 컬럼 목록이 포함되어 있었다. 에이전트는 수정 사항을 읽었다. 그러고 나서, 똑같은 잘못된 컬럼 이름을 다시 작성했다.
나는 이것을 '환각의 연쇄(confabulation cascade)'라고 부른다.
이것은 모델의 문제가 아니다. 도구 설계의 문제다.
루프가 작동하는 방식은 다음과 같다:
- 에이전트가 학습된 내용을 바탕으로 쿼리를 생성한다.
- 쿼리가 실패한다.
- 에러 메시지가 진실을 제공한다.
- 에이전트는 진실을 보지만, 대신 내부 학습 데이터에 의존한다.
- 에이전트가 실수를 반복한다.
에이전트는 두 가지 신호에 직면한다. 하나는 에러 메시지이고, 다른 하나는 모델의 학습 데이터다. 학습 데이터의 영향력이 더 강력한 경우가 많다. 에러 메시지는 단 한 번 나타나지만, 학습 데이터는 모델이 쓰는 모든 단어에 나타나기 때문이다.
프롬프트 엔지니어링으로 이를 해결하려 노력했다. 모델에게 에러에 주의를 기울이라고 지시했다. 하지만 효과가 없었다.
진짜 문제는 내 에이전트가 실패를 통해서만 배울 수 있었다는 점이다. 행동하기 전에 테이블 구조를 확인할 방법이 없었다. 그저 추측해야만 했다.
사람에게 API를 줄 때는 문서를 함께 제공한다. 에러 메시지가 스키마를 가르쳐 줄 때까지 잘못된 요청을 계속 보내게 만들지는 않는다.
나는 선제적인 도구를 구축하여 이 문제를 해결했다. 에러가 발생하기를 기다리는 대신, 이제 에이전트는 먼저 describe_table 도구를 호출한다.
새로운 워크플로우:
- 에이전트가 테이블을 쿼리하려고 한다.
- 에이전트가 실제 컬럼을 확인하기 위해
describe_table을 호출한다. - 에이전트가 정확한 이름과 타입을 가져온다.
- 에이전트가 첫 시도에 올바른 쿼리를 작성한다.
루프가 멈췄다. 모델이 더 똑똑해진 것은 아니다. 에이전트가 그저 추측을 멈췄을 뿐이다.
만약 당신의 에이전트가 데이터베이스나 API를 사용한다면, 스스로에게 물어보라: "에이전트가 행동하기 전에 구조를 확인할 수 있는가? 아니면 실패를 통해서만 배우는가?"
사후적인 에러 힌트는 유용하다. 하지만 그것만으로는 부족하다. 실패를 통해서만 배우는 에이전트는 언제나 환각(hallucination) 한 단계 직전에 놓여 있다.
에이전트가 실수를 저지르기 전에 질문할 수 있는 도구를 만들어라.
Optional learning community: https://t.me/GyaanSetuAi