TL;DR

  • LiteLLM Lens는 수천 건의 에이전트 실행 기록을 검토해 반복되는 실패를 찾고, 원본 기록을 대조해 후보 패턴을 검증함.
  • 각 실행 기록에 검토 에이전트를 배정해 병렬로 살펴보며, 도구 응답과 하위 에이전트 호출을 포함한 과정과 결과를 함께 조사함.
  • 검토 에이전트는 Python으로 기록을 검색·계산하고, 문맥 창보다 큰 기록도 조각별로 분석함.
  • 그룹화 에이전트는 검사 항목과 추정 원인에 따라 관찰 내용을 묶고, 조사 에이전트는 원본 기록과 반례를 확인해 패턴을 검증함.
  • 실제 세션과 통제 데이터셋에서 문제를 찾아냈으며, 25건의 조사·3,752개 세션·99,797개 구간으로 구성된 실험 데이터셋에서 예상된 실패 패턴 11개를 모두 찾아 100% 재현율을 기록함.

실행 기록 검토

  • 각 실행 기록에 전담 검토 에이전트를 배정해 병렬로 실행함. 초반의 도구 응답이 수백 단계 뒤의 오답을 설명할 수 있으므로, 에이전트마다 전체 실행 기록을 제공함.
  • 검토 에이전트는 무엇을 읽을지 결정하고 도구 결과와 하위 에이전트 간 전달을 따라가며, 반환할 관찰 내용을 확보할 때까지 조사함. 비교가 필요하면 선택한 다른 실행 기록도 열어볼 수 있음.
  • 웹 조사 예시에서 페이지가 문장 중간에 끝나고 최종 답변에 반환된 텍스트로 뒷받침되지 않는 주장이 있으면, 검토 에이전트가 이를 인용 근거와 함께 기록하되 원인은 확정하지 않음.
  • 결과뿐 아니라 실행 과정도 검토함. 예를 들어 에이전트가 호환되지 않는 grep 도구를 다섯 차례 시도한 뒤 터미널로 작업을 성공해도, 실패한 시도를 조사 대상으로 남김.

검토 에이전트의 Python 활용

  • 검토 에이전트에 실행 기록과 조사 도구가 담긴 작업 공간을 제공하며, 이는 코드 에이전트가 저장소에서 작업하는 방식과 유사함. 에이전트는 증거를 읽고 검색하거나 계산이 필요한 질문에 답하는 Python 코드를 작성함.
  • 웹 조사 예시에서는 응답 길이를 비교해 같은 지점에서 끝나는 페이지를 찾는 스크립트를 작성할 수 있음. 측정 결과를 바탕으로 열어볼 응답과 확인할 주장을 결정하며, 반복 실패 횟수 계산이나 하위 에이전트 호출 순서 재구성에도 같은 방식을 적용할 수 있음.
  • 실행 기록은 작업 공간에 보관하고, 에이전트는 필요한 구절이나 계산 결과를 모델 문맥으로 가져옴. 기록이 문맥 창보다 커도 검색과 부분 분석으로 처리할 수 있음.
  • Python은 네트워크 접근이 차단된 제한 환경에서 실행됨. 조사가 길어지면 에이전트가 대화를 작업 메모로 압축하고, 필요할 때 앞서 살펴본 증거로 돌아갈 수 있음.

관찰 내용 그룹화

  • 여러 검토 에이전트가 같은 근본 문제를 표시할 수 있으므로, 관찰 내용을 병렬 배치로 묶은 뒤 배치 간 일치 항목을 병합해 조사 에이전트가 사례를 함께 살펴보도록 함.
  • 그룹화 기준은 검사 항목과 추정 원인임. PDF 도구가 없는 문제와 PDF 렌더러가 실패하는 문제는 해결책이 다르므로 별도의 후보로 유지함.
  • 페이지가 잘리는 사례에서는 갑작스러운 페이지 종료와 근거 없는 주장을 나타내는 관찰 내용을 ‘원본 콘텐츠 누락’ 후보로 모음. 조사 에이전트에는 서로 다른 실행 기록의 사례와 증거 링크를 제공해 하나의 설명으로 사례를 설명할 수 있는지 확인하게 함.

후보 조사

  • 후보마다 조사 에이전트를 하나씩 병렬로 실행함. 조사 에이전트는 검토 결과와 원본 실행 기록에 접근하며, 읽기·검색·Python 도구를 동일하게 사용함.
  • 검토 에이전트가 설명을 바꿀 수 있는 문맥을 빠뜨렸을 가능성이 있으므로, 조사 에이전트를 원본 실행 기록으로 돌려보냄. 웹 조사 사례에서는 페이지 응답과 최종 주장을 대조하고, 에이전트가 정보 누락을 인정했거나 원문의 나머지 부분을 가져온 반례도 찾음.
  • 서로 다른 페이지가 반복해서 정확히 8,000자를 반환하면 도구가 고정 제한에서 응답을 자른다는 정황이 됨. 다만 조사 에이전트는 누락된 내용이 거짓 주장과 관련 있는지 확인하고, 증거와 그럴듯한 추측을 구분해야 함.
  • 근거가 약한 후보는 폐기할 수 있음. 결과를 저장하기 전에 작업자가 인용문을 원본과 대조하고, 유효하지 않은 인용은 수정하도록 돌려보냄. 정확한 인용문도 잘못된 해석을 뒷받침할 수 있으므로 평가에서도 이 차이를 확인함.

실제 실행 기록에서 설계 확인

  • 350개 구간(span)으로 구성된 실제 코딩 에이전트 세션에서 검토 에이전트와 조사 에이전트가 Python으로 검증 명령을 살펴봄. tail로 파이프 연결된 검사 명령이 실제 검사 실패에도 성공을 보고하는 문제를 찾아냄.
  • Lens는 문제와 이후 성공한 검사들을 식별했으며, 해당 실패가 전달된 코드에 계속 남아 있다고 주장하지 않음. 발견 내용의 인용문도 원본과 대조함.
  • 해당 세션의 한 검색 결과는 544,000자 이상에 달함. 도구 접근 권한은 에이전트가 읽을 내용을 직접 선택하게 하지만, 지나치게 많은 데이터를 요청할 수 있으므로 도구 사용과 발견 내용의 품질을 함께 점검함.

결과가 Lens에 전달되는 방식

  • 작업자는 진행 상황과 발견 내용을 LiteLLM 게이트웨이에 전송함. 다른 에이전트가 작업 중이어도 완료된 검토 결과가 나타나는 과정을 확인할 수 있으며, 발견 내용은 검토를 위해 원본 단계로 연결됨.
  • 작업자는 사용자 인프라에서 실행되며 작업을 받기 위해 LiteLLM을 폴링함. 증거와 선택한 분석 모델 호출에는 게이트웨이를 사용함. 실행 기록은 ClickHouse에, 조사 상태는 Postgres에 저장됨. 파이프라인과 도구는 오픈 소스임.
  • 아키텍처 실험용 골든 데이터셋은 조사 25건, 세션 3,752개, 구간 99,797개로 구성됨. 통제 사례에는 중첩 에이전트, 긴 도구 결과, 정상 실행, 실패 후 복구가 포함됨.
  • 해당 아키텍처는 예상된 실패 패턴 11개를 모두 찾아 100% 재현율을 기록함.
  • 에이전트에 적용하려면 작업자를 연결하고 조사를 생성하면 됨.