사후학습 개요와 일상대화 에이전트

후속 학습도 4단계입니다

에이전트 3형제 — 일상 · 코딩 · 사무업무

• 일상 대화 에이전트: 여러 앱·도구를 연결해 심부름을 처리 (예약 변경, 환불 등)
• 코딩 에이전트: 실제 오픈소스 프로젝트로 버그 수정, 터미널 작업, 화면 제작을 연습
• 사무업무 에이전트: 보고서·엑셀·PPT 등 진짜 회사 업무 산출물을 만드는 연습

'검증자 먼저 만들기'로 데이터 부족을 넘다

• 일상 대화 에이전트는 두 가지 축으로 훈련됩니다: ① 상태를 가진 MCP 환경 위에서 도구를 실행하는 것, ② 살아있는 거래형 도메인(예: 은행) 위에서 정책을 지키며 여러 턴에 걸쳐 대화하는 것
• 여기서 MCP(Model Context Protocol)란, AI가 외부 시스템(은행 서버, 예약 시스템 등)과 표준화된 방식으로 명령을 주고받는 규격이에요
• 가장 큰 난관: 상태를 바꾸는 작업(만들기·수정·삭제, 즉 Create/Update/Delete)은 정답이 있는 훈련 데이터가 거의 존재하지 않았어요
• 해결책은 순서를 거꾸로 뒤집는 검증자 먼저 만들기(verifier-first): 먼저 실제 환경에 변경 작업을 실행해보고, 그 결과로 생기는 예상 상태 변화를 기록 → 이를 근거로 샌드박스 안에서 돌아가는 pytest 기반 검증자를 자동 합성 → 마지막으로 과제 지시문 자체를 일부러 살짝 모호하게 다시 써서, AI가 정답을 그대로 베끼지 않고 스스로 해법 경로를 찾게 만듭니다
• 채점은 3-패스 셀프컨시스턴시(three-pass self-consistency)로: ① 정해진 하드 트레이스 규칙(반드시 지켜야 할 필수 행동 목록) 검사 ② LLM이 대화의 정합성을 판정 ③ 실행 가능한 검증자로 최종 상태를 확인 — 세 관문을 모두 통과해야 정답으로 인정합니다

대화형 시나리오는 어떻게 훈련되나

• 다중 턴 대화 축의 시나리오는 살아있는 거래형 데이터베이스 위에, 은행 업무 규칙 같은 명시적 도메인 정책 문서를 함께 얹어서 만들어집니다
• 고객 역할은 사용자 시뮬레이터가 연기하는데, 자신의 의도를 한 번에 다 밝히지 않고 점진적으로 드러내며, 일부 시나리오에서는 에이전트가 제대로 요청하거나 검증하기 전까지 신원 확인 정보를 일부러 숨겨 실제 고객처럼 행동합니다
• 에이전트가 호출하는 모든 도구는 가짜(mock)가 아니라 실제 데이터베이스에 대해 그대로 실행됩니다
• 합격 판정은 LLM 루브릭(채점 기준표) 심사와, 의미 기반 판정만으로는 놓치기 쉬운 정책 준수 여부를 구조적으로 검사하는 관문을 함께 조합해 이루어집니다