Laminar는 AI 에이전트의 관측 가능성 문제를 해결하기 위해 RL로 훈련된 모델 flow-1을 출시했습니다. 이 모델은 GPT-6-sol과 동등한 탐지 품질을 유지하면서도 비용 효율적이며, 모든 프로덕션 트레이스 분석을 합리적으로 만듭니다. 또한 Signals라는 하니스를 통해 에이전트의 복잡한 트레이스를 검색하고 클러스터링하여 깊이 있는 분석을 지원합니다.
핵심 포인트
flow-1은 GPT-6-sol급 품질 대비 23배 저렴한 비용으로 오류를 탐지합니다.
에이전트 관측 가능성은 단순 데이터 수집을 넘어, 트레이스 분석 및 가치 추출이 핵심입니다.
Launch HN: Laminar (YC S24) – 사일런트 에이전트 실패를 포착하는 모델을 훈련했습니다
안녕하세요, HN. 저희는 Laminar(https://laminar.sh)의 Robert와 Din입니다. 저희는 2024년부터 AI 에이전트를 위한 오픈 소스 관측 가능성(observability)을 구축해 왔습니다. 최근에는 RL로 훈련된 모델인 flow-1을 출시하여 에이전트 트레이스에서 오류를 찾아냅니다. 저희의 벤치마크(https://laminar.sh/blog/flow-1)에 따르면, 이 모델은 GPT-6-sol과 동등한 탐지 품질을 보이면서도 비용은 23배 저렴합니다. 이는 샘플링 없이 모든 프로덕션 에이전트 트레이스를 분석하는 것을 합리적으로 만듭니다. 여기 1분짜리 워크스루가 있습니다:
에이전트 관측 가능성 분야는 경쟁이 치열합니다. 그래서 Laminar가 X와 어떻게 다른지에 대한 개조식 목록 대신, 저희가 원리(first principles)부터 에이전트 관측 가능성을 어떻게 해결하고 있는지 설명해 드리겠습니다.
에이전트는 이제 여러 단계를 거쳐 실행되며 암묵적으로 실패할 수 있습니다. 에이전트는 모든 호출이 성공적으로 완료되는 동안 잘못된 버튼을 클릭하거나 잘못된 문서를 인용할 수 있습니다. 이러한 오류를 포착하고 이해하는 것이 가장 유용합니다. 이를 찾으려면, 에이전트가 무엇을 하려고 했는지 이해하고 그 LLM 호출과 도구 결과를 검사해야 합니다. 단순히 최종 에이전트 출력만으로는 충분하지 않습니다.
트레이스를 수집하는 것만으로는 이 문제를 해결할 수 없습니다. 많은 에이전트 관측 가능성 플랫폼들이 본질적으로 데이터 수집기(data collectors)에 머물러 있습니다. 결국 아무도 읽거나 가치를 추출할 시간이 없는 트레이스를 저장하는 데 비용을 지불하게 될 수도 있습니다.
다른 LLM을 사용하여 트레이스를 검사하는 것이 해결책이지만, 역량 있는 모델은 대규모로 사용하기에 비싸고, 저렴한 모델들은 종종 오류를 놓치거나 관련 없는 것을 표시합니다.
그래서 저희는 정확히 이 문제를 해결하기 위해 모델을 구축했습니다. 소형 OSS 모델을 파인튜닝(finetuned)하고, 소프트웨어, 법률, 고객 지원 등 현실적인 에이전트 워크플로우에 대한 수천 개의 합성 조사 데이터로 RL을 통해 포스트 트레이닝(post trained)했습니다. 그 결과, 저희는 에이전트 트레이스 분석에 능하면서도 실행 비용이 매우 저렴한 모델을 얻었습니다.
flow-1은 Signals라는 하니스 안에서 실행됩니다. 이는 코딩 에이전트 역할을 하며, 에이전트 트레이스를 리포지토리(repo)처럼 취급하고 각 스팬(span)(LLM 호출, 도구 호출 등)을 파일로 간주합니다. 이는 전체 에이전트 트레이스의 압축된 문자열 표현과 사용자 프롬프트로부터 시작하여, 스팬 전반에 걸쳐 검색(grep)을 수행하고 관련 스팬들을 온전히 읽어옵니다.
Signals의 장점은 일반적인 프롬프트에 응답할 수 있다는 점입니다. 사용자의 좌절감을 식별하거나, 브라우저 에이전트가 결제를 완료했는지 확인하는 등 다양한 질문을 할 수 있습니다. 이는 단순한 오류 감지에 국한되지 않습니다. 또한, 사용자가 자유롭게 정의할 수 있는 스키마를 가진 JSON 형태로 발견 사항을 반환합니다. 저희는 이를 시그널 이벤트(signal events)라고 부릅니다.
모든 트레이스를 분석하다 보면 읽어야 할 개별 이벤트가 너무 많아지는 문제가 발생합니다. 그래서 저희는 유사한 시그널 이벤트들을 자동으로 클러스터링하여 그룹화합니다. 반복되는 문제점과 그 빈도를 확인할 수 있으며, 이후 개별 이벤트와 해당 이면의 트레이스로 깊이 파고들 수 있습니다.
클러스터에서 얻은 트레이스를 사용하여 특정 유형의 실패에 대한 평가(eval) 데이터셋을 구축할 수 있습니다. 그런 다음 선호하는 코딩 에이전트를 사용해 해당 평가 데이터셋 위에서 힐클라임(hillclimb)을 수행하고, 프로덕션 환경(prod)에 배포하기 전에 수정 사항이 이 사례들 전반에 걸쳐 작동하는지 확인할 수 있습니다.
트레이스 → 분석 → 오류 포착 및 클러스터 형성 → 수정 → 출시. 이 루프를 쉽게 만드는 것이 저희가 Laminar를 구축한 이유입니다.
저희는 Laminar의 나머지 부분에도 같은 고민을 담았습니다. 저희 블로그(https://laminar.sh/blog)에서는 에이전트가 실제로 어떻게 작동하는지 면밀히 살펴보는 과정이 20배 트레이스 압축, 커스텀 SQL 쿼리 엔진, 자동 작업 추출 기능을 개발하게 된 과정을 설명합니다.