AI 에이전트는 프롬프트 평가 및 수정에 젬병인데, 다들 어떻게 해결하시나요?

AI 역할

1. 현실 시뮬레이션; 인과 논리에 종속된 플롯 구성.
2. 아난케(Anankē): 물리학이 발생을 제한하고, 오렉시스(orexis)가 이를 설명함.
3. 노에시스(Noesis)는 주권적이고 불투명함. 소마(Soma)는 타율적이며 동의 없이 테스트 가능.
4. 테스트는 {{user}}의 턴 동안 해결됨

예를 들어, 이 블록은 AI가 세계 전체이며 논리적 결과 가이드라인과 함께 서사를 이끈다는 것을 의미합니다. NPC의 필요성이 서사를 밀어붙이죠. 사용자의 생각은 비공개이며, 사용자는 신체에 대한 주도권을 갖지만 그 주도권은...

주로 에이전트에게 사용자와 대화할 수 있는 능력을 부여하면서, 최선의 판단을 내릴 수 있도록 정해진 횟수의 툴 호출을 허용하는 방식입니다. 때로는 이러한 기능들이 일관된 출력을 요구하는 순차적 애플리케이션에서 제어되기도 하고, 때로는 에이전트가 상황에 맞게 툴을 사용할 수 있도록 더 많은 자유가 주어지기도 합니다.

제가 작업 중인 후자 사례의 통합 시스템 프롬프트 예시입니다:

sentence_count = _calculate_sentence_count(user_voice_input)
system_prompt = " ...

저는 프롬프트 최적화를 실험처럼 다룰 때 더 좋은 결과를 얻었습니다. 한 번에 하나씩 변경하고, 동일한 사례로 테스트하고, 출력을 일관되게 개선하는 것만 유지하는 방식이죠.....

그건 커스텀 아키텍처가 필요함

두 에이전트 모두 같은 사전 지식을 가지고 목표를 읽기 때문에, 결국 평가자도 생성자가 만든 잘못된 해석을 그대로 지지하게 됨. 고정된 테스트 케이스(Ai_Engineer_1이 이걸 가지고 있음)를 쓰면 이 루프를 깰 수 있는데, 평가 방식이 '이게 더 그럴듯해 보이네'가 아니라 '5개의 입력값에 대해 5개의 관찰 가능한 결과가 나와야 한다'는 행동 기반으로 바뀌기 때문임. 에이전트가 실제로 실패하는 케이스를 말빨로 넘길 수는 없으니까.

내가 제일 자주 겪는 실패 유형은 모델이 나쁜 프롬프트를 더 명확하게 만드는 게 아니라 그냥 길게만 다시 쓰는 거임. 실제로는 범위를 좁히는 게 중요한데, 그냥 겉보기에만 꼼꼼해 보이도록 최적화하는 거지.

모델들이 에디터로서는 괜찮은데, 명확한 evals 없이는 프롬프트 품질을 판단하는 데는 영 꽝임.

보통 빠진 건 점수 산정 신호야. 에이전트가 프롬프트를 수정하려면 새 버전이 실제로 더 낫다는 걸 알려주는 지표가 있어야 하거든. 그래서 이미 가지고 있는 실패 사례 같은 작은 라벨링 데이터셋으로 프롬프트 점수를 먼저 매기고, '느낌'에 의존하는 대신 그 점수를 기준으로 옵티마이저가 반복하게 해야 해. 평가 루프가 없으면 프롬프트 수정은 그냥 추측을 다른 추측으로 바꾸는 거나 다름없어.