Why human insight is a strategic advantage for building better agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

전문가의 판단을 전체 대화 맥락과 함께 기록하고 평가 데이터로 재사용하면, 에이전트의 품질 기준을 구체화하고 자동 평가와 지속적인 개선을 뒷받침할 수 있다.

📌 핵심 요약

• 에이전트 트레이스는 한 번의 시도에서 발생한 사용자 메시지, 모델 응답, 도구 호출, 중간 단계를 기록한다. 엔지니어나 온라인 평가기가 이상 징후를 표시하면, 사람 검토자가 주석 큐에서 문제의 이유와 적절한 행동을 판단한다.
• 도메인 전문가는 업무와 사용자 의도에 맞는 품질 기준을 제시하며, 에이전트의 오류뿐 아니라 자동 평가가 잘못된 행동을 채점하거나 평가 기준에 빈틈이 있는 문제도 발견할 수 있다.
• 여러 턴에 걸친 에이전트는 이전 메시지와 도구 호출을 포함한 전체 대화인 thread를 검토해야 맥락에 맞게 평가할 수 있다. LangSmith의 주석 큐는 개별 단계인 run과 전체 세션인 thread를 검토 항목으로 지원한다.
• 사람이 평가 기준에 따라 남긴 구조화된 점수와 판단 근거는 LLM judge 보정, 온라인 평가기 개선, golden dataset 구축에 활용할 수 있다. 이 피드백을 해당 run이나 thread에 연결하면 전문가의 지식을 반복 평가에 재사용할 수 있다.
• Fetch Rewards는 AI Rewards Assistant의 개별 입출력을 검토하면서 도구 호출과 결과, 상품 이미지, 사용자에게 제공되는 오퍼까지 확인한다. 검토자는 모호한 사례의 근거와 불확실성을 기록하고, 엔지니어는 이를 활용해 자동 평가기의 판단 논리를 조정한다.

🧩 주요 포인트

1. 전문가가 정답 여부와 이유를 함께 설명함 → 에이전트 수정뿐 아니라 품질 기준과 자동 평가 자체의 결함을 개선할 근거가 생긴다.
2. 여러 턴의 오류가 마지막 응답에서 드러날 수 있음 → 개별 run의 점검을 넘어 전체 thread를 평가 단위로 삼는 것이 중요해진다.
3. 사람의 점수와 판단 근거를 평가 데이터로 축적함 → LLM judge, 온라인 평가기, golden dataset이 같은 품질 정의를 따르도록 개선하는 순환 구조를 만들 수 있다.

🧠 상세 정리

1. 복잡한 에이전트 평가의 출발점인 트레이스

에이전트가 더 길고 복잡한 작업을 맡게 되면서, 성능 평가는 최종 생성 답변만 확인하는 수준을 넘어야 한다는 것이 글의 출발점이다. 에이전트 트레이스는 한 번의 시도에서 발생한 사용자 메시지, 모델 응답, 도구 호출과 중간 단계를 기록하며, 개발팀은 이를 행동 디버깅과 품질 채점, 수정 대상 판단에 활용한다. 엔지니어나 온라인 평가기가 이상해 보이는 트레이스에 표시를 남길 수 있지만, 그 표시는 문제의 신호일 뿐 원인이나 수정 방법까지 설명하지는 않는다. 표시된 상호작용은 주석 큐로 들어가고, 사람 검토자는 에이전트가 적절하게 행동했는지와 그 이유를 기록한다. 이 흐름에서 자동화는 검토할 대상을 고르고, 사람은 개발자가 실제 개선에 활용할 수 있는 판단을 제공한다.

2. 전문가의 판단으로 품질 기준을 구체화하기

첫 번째 원칙은 사람이 가진 도메인 지식이 좋은 에이전트의 기준을 정의한다는 것이다. 검토자는 해당 업무에서 무엇이 좋은 결과인지, 사용자가 무엇을 하려 했는지, 에이전트가 어떻게 행동했어야 하는지를 해석하며, 이런 전문성은 회사와 역할, 개인의 경험에 따라 구체적인 차이를 갖는다. 전문가 검토의 중요한 가치는 결과의 정오 판정뿐 아니라, 왜 맞거나 틀렸는지와 바람직한 행동이 무엇인지 설명하는 데 있다. 검토자는 자동 평가가 놓친 오류뿐 아니라 잘못된 행동을 채점하는 평가기나 불완전한 평가 기준도 발견할 수 있어, 하나의 의견이 평가 체계의 더 큰 문제를 드러낼 수 있다. LangSmith의 주석 큐는 이러한 관점을 run이나 thread에 점수와 판단 근거로 저장해, 다음 개발 과정에서 품질의 정의를 더 명확하게 만드는 데 활용하도록 한다.

3. 전체 대화 맥락이 있어야 성립하는 평가

두 번째 원칙은 검토자의 판단이 제공된 상호작용의 범위에 영향을 받으므로, 여러 턴으로 이어진 작업에서는 전체 대화 맥락이 필요하다는 것이다. 한 단계만 보면 최종 답변을 설명하는 이전 메시지와 도구 호출, 중간 결정을 놓칠 수 있고, 단독으로는 적절해 보이는 답변도 사용자가 앞서 말한 내용과 충돌할 수 있다. 오류 자체는 여러 턴 전에 발생했지만 마지막 메시지에서야 분명해지는 경우도 있어, 작업이 길어지고 단계가 늘수록 빠진 이력을 사람이 찾아 진단하기 어려워진다. 주석 큐의 thread는 전체 세션을 하나의 검토 항목으로 제시해, 사용자의 목적과 에이전트가 답에 도달한 과정, 답변의 타당성을 함께 살피게 한다. 따라서 글은 여러 턴을 수행하는 에이전트의 검토 단위를 대화로 삼아, 검토자가 조각난 기록을 직접 조립하는 부담을 줄여야 한다고 주장한다.

4. 전문가의 기준을 점수와 설명으로 기록하기

세 번째 원칙은 전문가의 판단을 시스템이 다시 사용할 수 있는 고품질 평가 데이터로 바꾸는 것이다. 분야별 전문가인 SME는 좋은 성능의 기준을 제공하며, 글은 개발자가 자동 지표만으로 그 기준을 충분히 얻기는 어렵다고 설명한다. 실제 검토에서는 사람이 주석 큐의 run이나 thread를 열고 통과·실패, 1~5점, 공감, 올바른 도구 사용 등 정해진 평가 기준에 따라 채점하며, 그 이유를 짧은 설명으로 덧붙일 수 있다. 이렇게 라벨이 붙은 사례는 해당 상호작용의 기준 정답 역할을 하면서, 단순히 나쁘다는 판정을 넘어 어떤 차원에서 실패했고 좋은 행동은 무엇이었는지 담는다. 점수와 설명을 원래 상호작용에 연결해 두면, 개발자는 평가 결과의 의미를 구체적인 대화와 행동에 근거해 해석할 수 있다.

5. 평가 데이터를 재사용하는 세 가지 경로

사람이 남긴 라벨을 활용하는 첫 번째 경로는 같은 트레이스에 대한 사람과 LLM judge의 점수를 비교하고, 불일치가 나타나는 부분의 평가 프롬프트나 기준을 수정해 판단이 더 자주 일치하도록 보정하는 것이다. 두 번째는 사람이 같은 유형의 누락을 반복해서 발견할 때 이를 잡아야 할 온라인 평가기를 고치고, 새로운 트래픽에 다시 실행하는 방식이다. 세 번째는 사람이 라벨링한 좋은 사례를 golden dataset으로 선별해, 에이전트나 프롬프트가 바뀔 때 오프라인 실험에 활용하는 것이다. 이 과정에서 개발자는 실패 유형을 식별하고 평가 기준과 데이터셋을 개선하며, 다음 평가가 전문가 검토에서 나온 품질 정의를 따르도록 할 수 있다. 글은 이를 특정 thread에 대한 전문가 판단이 구조화된 점수와 설명, 개선된 평가기와 데이터셋, 반복 가능한 평가로 이어지는 피드백 순환으로 설명한다.

6. LangSmith가 thread와 trajectory를 제공하는 이유

LangSmith가 주석 큐에 thread를 도입한 이유는 검토자가 자신의 전문성을 활용하려면 전체 상호작용과 개발자가 쓸 수 있는 피드백 수단이 함께 필요하기 때문이다. 에이전트가 여러 턴과 도구에 걸쳐 작동할 때, 분리된 단계만으로는 판단에 필요한 대화 맥락을 충분히 파악하기 어렵다는 문제의식이 바탕에 있다. trajectory는 메시지와 도구 호출을 발생 순서대로 보여주면서 중첩된 run 트리와 중복 정보를 제거한, 읽기 쉬운 대화 보기다. 판단 대상은 대화이므로 주석 큐의 항목은 여전히 thread이며, 검토자는 trajectory를 읽으면서 해당 thread에 평가를 남긴다. 이 설계는 도메인 전문가가 트레이스 트리의 구조를 먼저 익히기보다 실제 사용자와 에이전트 사이의 대화 내용에 집중하도록 돕는 데 목적이 있다.

7. Fetch Rewards가 확인하는 답변의 실제 근거

Fetch Rewards는 주석 큐를 활용해 사람의 판단을 자동 평가기의 기준점으로 만들며, 검토자는 AI Rewards Assistant의 개별 턴에 해당하는 입력과 출력을 평가한다. 다만 대화 기록은 검토의 시작일 뿐이며, 유창한 답변도 실제 데이터에 근거하지 않으면 틀릴 수 있어 트레이스 메타데이터에서 도구 호출과 반환 결과를 추가로 확인한다. 사용자가 오퍼를 물으면 어시스턴트가 실제로 오퍼를 검색했는지, 답변이 검색된 오퍼를 정확히 반영하는지 확인한다. 상품 카드 이미지도 대상 상품과 대조하며, 예를 들어 20 oz Coca-Cola 카드에 2리터 병 이미지가 표시되지 않았는지 살핀다. 추천은 받는 사람이 실제로 이용할 수 있어야 유용하므로, 검토자는 사용자의 오퍼를 조회해 제안된 혜택이 그 사용자에게 제공되는지도 확인한다.

8. 모호한 사례의 판단 근거를 개발 과정에 반영하기

Fetch Rewards 사례에는 이미지가 거의 맞지만 완전히 일치하지 않거나, 오퍼가 형식적으로 유효해도 도움이 되지 않거나, 답변이 정확해도 사용자 의도를 놓치는 모호한 상황이 포함된다. 이런 경우 검토자는 근거를 종합하고, 무엇을 확인했으며 무엇이 여전히 불명확한지, 각 점수를 왜 부여했는지를 주석 큐의 의견으로 기록한다. 엔지니어는 이 설명을 통해 자동 평가기의 논리가 사람의 검토와 어디서 달라지는지 파악하고 그에 맞게 조정한다. 글은 이러한 사례를 바탕으로 사람의 검토를 에이전트 개발 생애주기에 포함하는 것이 중요하다는 입장을 제시하며, LangSmith를 통해 이를 작업 흐름에 도입하기 쉽게 만들고 있다고 설명한다. 마지막에는 사람이 에이전트 트레이스를 직접 검토하면서 새로운 통찰과 유용한 데이터를 발견해 보도록 권하며, 전문가의 판단을 개발 개선에 연결한다는 전체 논지를 마무리한다.

🧾 핵심 주장 / 시사점

• 사람의 검토는 에이전트의 답변을 평가하는 동시에 자동 평가기의 품질을 점검하는 역할도 한다. 반복되는 판단 차이는 에이전트뿐 아니라 평가 기준이나 평가기 논리를 수정할 근거가 될 수 있다.
• 전체 thread와 읽기 쉬운 trajectory는 전문가가 판단에 필요한 맥락에 접근하도록 돕는다. 검토 화면의 구성은 전문 지식을 평가에 활용하는 과정과 연결된다.
• Fetch Rewards 사례는 유창함과 사실적 근거, 사용자에게 실제로 유용한지가 서로 다른 평가 차원임을 보여준다. 모호한 사례에서는 점수와 함께 확인한 증거와 남은 불확실성을 기록하는 것이 자동 평가기 조정에 도움이 된다.

✅ 액션 아이템

• 도메인 전문가의 검토에서 품질 기준과 정오 판단의 이유를 함께 기록하고, 자동 평가의 누락이나 기준의 빈틈을 개선에 반영.
• 여러 턴에 걸친 에이전트의 평가에는 이전 메시지와 도구 호출을 포함한 전체 thread를 검토 단위로 활용.
• 사람의 구조화된 점수와 판단 근거를 LLM judge 보정, 온라인 평가기 개선, golden dataset 구축에 재사용.

❓ 열린 질문

• 도메인 전문가가 정의한 품질 기준과 자동 평가의 판단은 어떤 지점에서 어긋나는가?
• 전체 thread를 검토할 때 개별 run만으로는 드러나지 않는 오류의 원인은 무엇인가?
• 사람의 점수와 판단 근거를 반영한 LLM judge와 온라인 평가기는 같은 품질 정의를 얼마나 일관되게 따르는가?