[00:14] 안녕하세요, 모두 만나서 반갑습니다.

[00:16] 제 이름은 아만이고, Arise라는 회사의 AI 프로덕트 매니저입니다.

[00:19] 오늘 발표의 제목은

[00:21] '제대로 작동하는 AI 배포하기, PM을 위한 평가 프레임워크'입니다.

[00:24] 이번 발표는 사실

[00:26] 우리가 지금까지 계속해온 내용의 연장선상에 있습니다.

[00:28] 레니 팟캐스트 같은

[00:30] PM 분들과 함께 작업한 콘텐츠들 말이죠.

[00:31] 혹시 손을 들어주실 수 있나요?

[00:34] 레니 팟캐스트를 들으시거나

[00:35] 뉴스레터를 읽어보신 분들 계신가요?

[00:37] 좋네요, 훌륭합니다.

[00:39] 몇 가지 더

[00:40] 청중과의 상호작용을 해보겠습니다.

[00:42] 분위기를 조금 띄워보려고요.

[00:44] 여기 계신 분들 중에 PM이거나 PM을 지망하는 분들이 몇 명이나 되나요?

[00:47]

[00:48] 좋네요, 꽤 많은 분들이 계시네요.

[00:51] 그중에서 본인을 AI 프로덕트 매니저라고 생각하시는 분들은 몇 명이나 되나요?

[00:53] 오케이, 와우! 정말 좋네요.

[00:56] AI PM이 일반 PM보다 더 많네요.

[00:58] 흥미롭네요.

[01:00] 보통은 AI PM이 일반 PM의 하위 집합인데

[01:02] 질문 순서를 바꿔서 물어봐야겠네요.

[01:03] 어쨌든 정말 좋습니다.

[01:05] 그럼 오늘 우리가 할 일은

[01:08] 제 소개를 간단히 드리고

[01:11] 그 다음에

[01:12] AI PM들이

[01:13] AI 애플리케이션을 구축할 때

[01:15] 정말 강력하다고 생각하는

[01:18] 프레임워크들을 다뤄보겠습니다.

[01:21] 제 소개를 조금 해드리자면

[01:24] 저는 기술적 배경을 가지고 있습니다.

[01:25] 실제로 엔지니어링으로 커리어를 시작했고

[01:28] 크루즈에서 자율주행차 작업을 했었습니다.

[01:30] 그곳에 있을 때

[01:33] 자율주행 평가 시스템을 담당하는 PM이 되었습니다.

[01:35] 2018년, 2019년경이었죠.

[01:38] 그 후에 Spotify로 가서

[01:41] 머신러닝 플랫폼과 추천 시스템을 작업했습니다.

[01:43] 디스커버 위클리나 검색 같은 기능들이죠.

[01:45] 임베딩을 사용해서

[01:47] 실제 최종 사용자 경험을

[01:50] 더 나은 것으로 만드는 일이었습니다.

[01:51] 그리고 현재까지 이어져서

[01:54] Arise에서 약 3년 반 정도 일하고 있고

[01:56] 여전히 평가 시스템을 작업하고 있습니다.

[01:58] 다만 자율주행차 대신에

[01:59] 자동 코드 작성 에이전트를 다루고 있죠.

[02:01] 그리고 Spotify는 실제로 우리 고객 중 하나입니다.

[02:04] 그래서 정말 훌륭한

[02:05] 전 동료들과 작업할 수 있어요.

[02:07] 재미있는 사실은

[02:09] 제가 이전 상사들 모두에게

[02:11] Arise를 판매했다는 것입니다.

[02:14] 재미있는 사실이죠.

[02:16] 어쨌든 우버, 인스타카트,

[02:19] 레딧, 듀오링고와 같은 훌륭한 회사들과 작업하고 있습니다.

[02:21] 정말 기술적으로 앞서가는

[02:23] AI 중심 애플리케이션을 구축하는 회사들이죠.

[02:25] 우리는 실제로

[02:28] 랭킹, 회귀, 분류 모델 같은

[02:30] 전통적인 머신러닝 영역에서 시작했고

[02:33] 지금은 생성형 AI와

[02:36] 에이전트 기반 애플리케이션으로도 확장했습니다.

[02:38] 우리가 하는 일은

[02:40] 이러한 회사들, 즉 우리 고객들이

[02:43] AI 애플리케이션을 구축할 때

[02:45] 그 에이전트와 애플리케이션이

[02:47] 예상대로 작동하도록 하는 것입니다.

[02:48] 이것은 실제로 꽤 어려운 문제입니다.

[02:50] 그 이유 중 상당 부분은

[02:53] 앞으로 다룰 관측가능성이나 평가 같은

[02:55] 너무 빠르게 변하고 있고, 모델들과

[02:58] 툴들, 인프라스트럭처 레이어가

[03:00] 너무 빠르게 변해서 우리에게는

[03:02] 최신 기술에 대해 배우는 방법이자

[03:04] 사람들이 구축하고 있는 유즈케이스에서

[03:06] 나타나는 주요 과제들이 무엇인지

[03:08] 알아보고 그것을 모든 사람에게

[03:10] 도움이 되는 플랫폼과 제품으로 만드는 것입니다.

[03:14] 자, 오늘 다룰 내용입니다.

[03:16] eval이 무엇이고 왜 중요한지 알아보겠습니다.

[03:18] 실제로 멀티 에이전트 시스템을 사용해

[03:20] AI 여행 플래너를 구축해보겠습니다.

[03:22] 이 부분은 야심찬 두 번째 항목이죠.

[03:23] 솔직히 말하면, 바로 직전에

[03:25] 코드를 업로드하려고 했는데

[03:26] 제대로 작동할지 안 할지 모르겠지만

[03:28] 한번 시도해보겠습니다. 이것이

[03:29] 워크샵의 인터랙티브 부분이 될 것이고

[03:31] 그 다음에는 우리가 직접

[03:33] 구축할 AI 여행 플래너 프로토타입을

[03:35] 실제로 평가해보겠습니다.

[03:37] 또 다른 빠른 손들기 질문을

[03:39] 해보겠습니다. eval이라는 용어를

[03:41] 들어본 사람이 몇 명이나 있나요? 좋네요.

[03:44] 강연 제목에 있었으니까

[03:45] 좀 중복된 질문이긴 하네요.

[03:47] 실제로 eval을 작성해보거나

[03:49] 실행해본 적이 있는 분이 몇 명인가요?

[03:52] 좋네요, 꽤 많은 분들이 계시네요.

[03:53] 정말 좋습니다. 우리가 할 일은

[03:55] 실제로 그것을 한 단계 더

[03:56] 발전시켜보는 것입니다. LLM을

[03:58] 판사로 사용하는 시스템용 eval 작성에서

[04:01] 시작해서요. eval을 작성해본 적이

[04:02] 없다고 해도 걱정하지 마세요.

[04:03] 그것도 다룰 예정입니다. 하지만 그것을

[04:05] 한 단계 더 발전시켜서 좀 더

[04:06] 기술적이고 인터랙티브하게 만들어보겠습니다.

[04:10] 좋습니다. 이 세션은 누구를 위한 것일까요?

[04:13] 저는 이 다이어그램이 마음에 드는데요,

[04:16] 레니와 저는 AI 제품 관리자들을

[04:17] 위한 교육 콘텐츠를 중심으로

[04:19] 조금 더 협력해 왔습니다.

[04:21] 저는 이것을 올려두었어요. 그를 위해

[04:24] 작은 화이트보드 다이어그램을 만들어서

[04:25] 이렇게 말했죠. '제가 이 분야를

[04:27] 바라보는 방식이 정말 이런 것 같아요.

[04:28] 더닝 크루거 효과에 대한

[04:31] 다이어그램을 본 적이 있을 텐데요.

[04:32] 여기서 떠오른 것이 바로 그것이었습니다.

[04:34] 곡선을 따라 이동하면서

[04:35] 시작 단계에 있을 때는

[04:37] 'AI를 어떻게 사용하지? AI가

[04:39] 내 업무에 어떻게 맞을까?'라고 생각하죠.

[04:41] 솔직히 말해서 몇 년 전에는

[04:44] 우리 모두가 여기에 있었다고 생각해요.

[04:45] 완전히 솔직하게 말하면, 이 자리에

[04:47] 있는 사람들, 특히 PM들의 경우

[04:49] 제품 관리 역할에 대한 기대치가

[04:51] 변하고 있다고 모두 느끼고 있다고 생각합니다.

[04:54] 그래서 AIPM이라는 개념이

[04:56] 등장하고 있는 거죠. 이해관계자들,

[04:58] 경영진들, 고객들로부터의

[05:00] 기대치 말이에요. 다른 사람들도

[05:02] 이렇게 느끼는지 모르겠지만

[05:04] 저는 확실히 전달해야 하는 것에 대한

[05:06] 기준이 높아졌다고 느껴요.

[05:08] 특히 AI 엔지니어와 함께

[05:10] 일할 때, 그들이 제가

[05:12] 가져다주기를 기대하는 것들,

[05:13] 요구사항 측면에서나

[05:15] 에이전트 시스템이 어떻게

[05:17] 보여야 하는지 명시하는 것에서나

[05:19] 변했어요. 한 단계 더 발전했죠.

[05:22] 완전히 다른 기능을 하게 되었습니다.

[05:24] 기능이 다릅니다. 저 역시

[05:26] 기술 PM이었던 사람으로서도 말이죠.

[05:27] 그래서 저 자신도 이런 여정을 겪었다고 느꼈습니다.

[05:31] 이것은 아이러니한데요, 제가 평가 회사에서

[05:33] 일하고 있음에도 불구하고,

[05:35] 제가 업계 선두에 있을 거라고

[05:36] 생각했지만 실제로는

[05:38] 여러분과 같은 여정을 겪었습니다.

[05:40] 제 업무에 AI를 활용하려고 노력하고,

[05:43] AI 도구를 사용해 프로토타입을 만들어

[05:45] 단순한 구글 문서 요구사항보다는

[05:46] 좀 더 구체적인 것으로

[05:48] 엔지니어링 팀에 제시하려고 했죠.

[05:50] 프로토타입을 만든 후에

[05:52] 새로운 UI 워크플로우를

[05:54] 구축해보자고 했을 때,

[05:56] 그때부터 어려움이 시작되었습니다.

[05:59] 제품을 실제 운영 환경에 배포하는 방법,

[06:01] 특히 제품에 AI나 LLM, 에이전트가

[06:04] 포함되어 있다면 말이죠. 바로 이 지점에서

[06:08] 자신감이 급격히 떨어지고

[06:10] 도구의 부족과

[06:11] 이런 시스템을 안정적으로 구축하는

[06:13] 방법에 대한 교육의 부족을

[06:15] 깨닫게 됩니다. 그런데 왜 이것이

[06:18] 중요할까요?

[06:20] LLM이 환각을 일으킨다는 사실에서

[06:22] 정말 중요한 시사점을 얻을 수 있습니다.

[06:24] 우리 모두 알고 있듯이 그렇습니다.

[06:26] 여기 상단의 두 인용문을

[06:29] 정말 주목해서 봐야 합니다.

[06:31] OpenAI의 최고제품책임자인 Kevin이 있고,

[06:33] Anthropic의 CPO인 Mike도 있습니다.

[06:36] 이것은 아마 LLM 시장의

[06:39] 95% 정도를 차지할 것입니다.

[06:41] 그리고 이 두 회사의 제품 리더들이

[06:44] 그들의 모델이 환각을 일으키며

[06:46] 평가를 작성하는 것이 정말 중요하다고

[06:48] 여러분에게 말하고 있습니다.

[06:50] 이 인용문들은 실제로 작년 11월

[06:52] Lenny 컨퍼런스에서 그들이 함께

[06:55] 발표한 내용에서 나온 것입니다.

[06:57] 제품을 판매하는 당사자들이

[06:59] 그것이 신뢰할 수 없다고 말할 때,

[07:01] 우리는 그들의 말을 들어야 합니다.

[07:04] 게다가 같은 회사 창립자인

[07:06] Greg Brockman도 있고,

[07:08] 평가가 AI 스타트업의 진정한

[07:11] 해자로 떠오르고 있다고 말하는

[07:13] Gary도 있습니다. 저는 이것이

[07:15] 중요한 전환점 중 하나라고 생각합니다.

[07:17] 사람들이 이유 있어서

[07:18] 이런 말을 하기 시작했다는 것을

[07:20] 깨닫는 순간입니다. 왜 그럴까요?

[07:22] 자율주행 분야에서 배운

[07:24] 많은 교훈들이 이 AI 분야에도

[07:27] 적용되기 때문입니다.

[07:28] 또 다른 청중 질문입니다.

[07:30] 웨이모를 타본 적 있는 분?

[07:31] 꽤 많을 것 같네요.

[07:33] 여기는 샌프란시스코니까요.

[07:34] 타지에서 오신 분들은 웨이모를

[07:36] 한 번 타보세요. 이것은 AI의

[07:39] 실제 사례입니다.

[07:41] 실제 물리적 세계에서의

[07:43] AI 사례입니다. 그리고 이런 시스템이

[07:46] 작동하는 방식의 많은 부분이

[07:48] 오늘날 AI 에이전트 구축에도

[07:50] 적용됩니다.

[07:51] 좋습니다. 좀 더 넓은 시각에서 보고

[07:52] 기술적인 내용으로 들어가겠습니다.

[07:54] 노트북들이 나왔네요.

[07:55] 분명히 코드도 작성하고

[07:58] 실습도 해볼 예정입니다. 하지만 먼저

[08:00] 소프트웨어 테스팅과 매우 유사하지만

[08:02] 몇 가지 핵심적인 차이점이 있습니다.

[08:04] 그 핵심 차이점들은 다음과 같습니다.

[08:07] 소프트웨어는 결정론적입니다.

[08:08] 1 더하기 1은 2죠.

[08:10] LLM 에이전트는 비결정론적입니다.

[08:12] 에이전트에게 1 더하기 1이 3이라고 설득하면

[08:14] 맞습니다라고 말할 거예요.

[08:15] 1 더하기 1은 3입니다.

[08:17] 맞죠? 우리 모두 겪어봤습니다.

[08:19] 이러한 시스템들은 매우 조작하기 쉽다는 것을 봤죠.

[08:21] 그리고 여러 경로를 취할 수 있는 LLM 에이전트를 구축한다면

[08:25] 그건 결정론적인 단위 테스트와는

[08:28] 상당히 다릅니다.

[08:29] 많은 사람들이

[08:32] 에이전트 시스템에서 환각을 제거하려고 한다는 사실을 생각해보세요.

[08:34] 문제는 실제로는 에이전트가

[08:36] 적절한 방식으로 환각하기를 원한다는 것입니다.

[08:38] 그리고 그것이 테스트를 훨씬 더 어렵게 만들 수 있습니다.

[08:40] 특히 신뢰성이 매우 중요할 때 말이죠.

[08:42] 그리고 마지막으로

[08:44] 통합 테스트는 기존 코드베이스와 문서에 의존합니다.

[08:46] 에이전트의 정말 핵심적인 차별화 요소는

[08:48] 데이터에 의존한다는 것입니다.

[08:50] 기업에 에이전트를 구축한다면

[08:52] 다른 것 대신 당신의 에이전트를 사용하는 이유는

[08:54] 에이전트 아키텍처 때문일 수도 있지만

[08:56] 큰 부분은 에이전트 위에 구축한

[08:58] 당신의 데이터 때문일 것입니다.

[09:01] 그리고 이는 평가에도 적용됩니다.

[09:04] 좋습니다. 평가란 무엇인가요?

[09:05] 저는 평가에 들어가는 네 가지 부분으로 나눠 봅니다.

[09:08] 쉬운 기억법 같은 거죠.

[09:09] 이 괄호들이 조금 어긋나 있지만

[09:11] 아이디어는 역할을 설정하는 것입니다.

[09:13] 기본적으로 에이전트에게

[09:15] 달성하고자 하는 작업이 무엇인지 알려주는 것입니다.

[09:18] 여기 중괄호에서 볼 수 있는

[09:21] 약간의 컨텍스트를 제공합니다.

[09:23] 그리고 그것은 기본적으로

[09:25] 결국 그냥 텍스트입니다.

[09:27] 에이전트가 평가하기를 원하는 텍스트죠.

[09:29] 에이전트에게 목표를 제공합니다.

[09:30] 이 경우에는

[09:32] 에이전트가 텍스트가 독성인지 아닌지를 판단하려고 합니다.

[09:34] 이는 독성 데이터셋이 대량으로 있기 때문에

[09:36] 고전적인 예시입니다.

[09:37] 우리가 평가를 구축하는 데 사용하는

[09:40] 텍스트 분류 데이터셋 말이죠.

[09:42] 하지만 주목할 점은

[09:43] 비즈니스 케이스에서 어떤 유형의 목표든 될 수 있다는 것입니다.

[09:46] 독성일 필요가 없습니다.

[09:47] 평가를 위해 이 에이전트를 만든

[09:49] 어떤 목표든 될 것입니다.

[09:52] 그리고 용어와 라벨을 제공합니다.

[09:53] 좋은 것과 나쁜 것의 몇 가지 예시를 주고

[09:55] 좋음 또는 나쁨을 선택하는 출력을 제공합니다.

[09:58] 이 경우에는 독성, 비독성입니다.

[10:00] 마지막 내용에서 잠시 멈추겠습니다.

[10:02] 정말 오해가 많다고 생각하기 때문에

[10:03] FAQ들을 중간중간 엮어서 말하려고 하지만

[10:05] 마지막에 질문 시간이 있을 것이고

[10:08] 인터랙티브하게 진행하고 싶어서

[10:10] 아마 더 길게

[10:11] Q&A 세션을 진행하겠습니다.

[10:14] 이런 질문들이 있는 분들을 위해서요.

[10:16] 하지만 자주 받는 질문 중 하나는

[10:18] 왜 안 되는지에 대한 것입니다.

[10:21] 정말 오해가 많다고 생각해서

[10:23] FAQ들을 중간중간 엮어보려고 하지만

[10:25] 마지막에 질문 시간이 있을 것이고

[10:27] 이것이 인터랙티브하게 되길 바라서

[10:29] Q&A 세션을 좀 더 길게 진행할 예정입니다.

[10:31] 이런 질문들이 있는 분들을 위해서요.

[10:33] 하지만 자주 받는 질문 중 하나는

[10:35] Q&A 세션을 좀 더 길게 할 예정입니다

[10:37] 이런 질문들이 있는 분들을 위해서요

[10:38] 하지만 저희가 자주 받는 질문 중 하나는

[10:41] 왜 에이전트에게 점수를 달라고 하거나

[10:43] LLM이 점수를 생성하게 할 수 없냐는 것입니다

[10:46] 그 이유는 오늘날에도

[10:48] 박사 수준의 LLM이 있음에도 불구하고

[10:50] 여전히 숫자를 잘 처리하지 못하기 때문입니다

[10:53] 그래서 여러분이 해야 할 일은

[10:55] 실제로 토큰이 무엇인지

[10:57] LLM에서 토큰이 어떻게 표현되는지의 함수입니다

[10:59] 그래서 실제로는

[11:02] 점수에 매핑할 수 있는 텍스트 라벨을 주는 것입니다

[11:05] 시스템에서 점수를 정말 사용해야 한다면

[11:07] 저희 시스템에서도 그렇게 하는데

[11:09] 라벨을 점수에 매핑합니다

[11:11] 하지만 이건 정말 흔한 질문입니다

[11:12] 아, 왜 그냥

[11:14] 1은 좋고 5는 나쁘게 하거나

[11:16] 그런 식으로 할 수 없냐는 질문을요

[11:18] 그렇게 하면 정말 신뢰할 수 없는 결과가 나옵니다

[11:20] 그리고 실제로 저희에게는 연구가 있습니다

[11:21] 나중에 기꺼이 공유해드릴게요

[11:24] 대부분의 모델로 대규모로

[11:25] 이를 증명하는 연구입니다

[11:27] 좋아요, 이것이 평가가 무엇인지에 대한 내용입니다

[11:30] 참고로 이전 슬라이드에서

[11:31] 언급해야 할 것이 있습니다

[11:34] 이것은 LLM as a judge 평가입니다

[11:37] 다른 유형의 평가도 있습니다

[11:39] 코드 기반 평가 같은 것들이요

[11:41] 코드를 사용해서 텍스트를 평가하는 방식이고

[11:44] 인간 주석도 있습니다

[11:45] 이에 대해서는 나중에 조금 더 다루겠지만

[11:48] 이 시간의 대부분은

[11:50] LLM as a judge에 할애할 예정입니다

[11:52] 왜냐하면 이것이 정말로

[11:54] 요즘 프로덕션에서 평가를 실행하는

[11:56] 확장 가능한 방법이기 때문입니다

[11:59] 그 이유에 대해서도 나중에 이야기하겠습니다

[12:02] 좋아요, 말이 많았네요. 그럼 vibe로 평가하기에 대해 말해보죠

[12:05] 이건 좀 재미있는데 왜냐하면

[12:07] 모든 사람이 vibe 코딩이라는 용어를 알고 있고

[12:08] 모든 사람이 bolt나 lovable 같은 것들을

[12:10] 사용해봤을 것입니다

[12:12] 여러분은 어떤지 모르겠지만

[12:14] 제가 vibe 코딩을 할 때 보통 느끼는 감정은

[12:15] 음, 좋아 보이는데? 이런 느낌입니다

[12:17] 코드를 보고 있지만

[12:19] 솔직히 AI가 생성한 코드를

[12:21] 얼마나 읽을 건가요?

[12:22] 그냥 이걸 배포해보자는 생각이죠

[12:23] 문제는 프로덕션 환경에서는

[12:25] 정말 그렇게 할 수 없다는 것입니다

[12:27] 모든 vibe 코딩 예시들이

[12:29] 프로토타이핑이거나

[12:30] 뭔가 해키하거나 빠르게

[12:32] 만들려는 것들이라고 생각합니다

[12:35] 그래서 모든 분들께 약간 다른 시각으로

[12:37] 생각해보시도록 도움을 드리고 싶습니다

[12:39] 네, vibe 코딩은 훌륭합니다. 그만의 자리가 있죠

[12:42] 하지만 Vibe로 평가하는 것에서

[12:45] Thrive 코딩으로 간다면 어떨까요?

[12:47] 제 생각에 thrive 코딩은 실제로

[12:50] 데이터를 사용해서 기본적으로

[12:51] vibe 코딩과 같은 일을 하는 것입니다

[12:54] 여전히 애플리케이션을 만들지만

[12:56] 데이터를 사용해서 결과에 대해

[12:58] 더 자신감을 가질 수 있습니다

[13:01] 그리고 이 사람이 훨씬 행복해 보이는 것을

[13:03] 볼 수 있습니다. 이건 구글의 이미지 모델을 사용한 건데요. 정말 무섭도록 좋습니다

[13:06] 좋아요. 그럼 thrive 코딩을 해보겠습니다

[13:07] 슬라이드에 대해서는 슬라이드에 액세스하고 싶으시면

[13:10] 슬라이드에는 저희가 다룰 내용들에 대한

[13:11] 링크들이 있습니다

[13:13] 워크샵에서 다룰 내용들입니다.

[13:16] ai.engineer.slack.com

[13:18] 그리고 슬랙 채널 workshop AIPM을 만들었습니다.

[13:20] 그리고 그곳에 슬라이드를 올려놨다고 생각하는데,

[13:23] 혹시 안 올려놨다면 알려주세요.

[13:24] >> 알겠습니다. 감사합니다.

[13:26] 좋습니다. 이제 라이브 데모 시간입니다.

[13:28] 이 시점에서, 솔직히 말씀드리면

[13:30] 저장소에 뭔가 문제가 있을 가능성이 꽤 높습니다.

[13:33] 바로 지금까지도 계속 변경사항을 푸시하고 있었거든요.

[13:36] 만약 그렇더라도 스스로 해결할 수 있다면,

[13:37] requirements 부분에 문제가 있을 것 같은데

[13:39] 자유롭게 진행하세요.

[13:41] 안 되면 나중에 돌아와서

[13:42] 문제를 해결하는 데 도움을 드리겠습니다.

[13:44] 그리고 이 이후에는 저장소의 최신 버전을

[13:46] 올려놓을 것을 약속드립니다.

[13:47] 지금 작동하지 않더라도 한 시간 후에 다시 확인해보세요.

[13:49] 슬랙에 올려놓을게요.

[13:51] 나중에는 작동할 겁니다.

[13:52] 빠르게 진행하다 보니 생기는 일이네요.

[13:55] 왼쪽에는 지침이 있는데

[13:56] 실제로는 제가 작성한 Substack 포스트입니다.

[13:58] 라이브로 진행할 단계들의 무료 목록 같은 것이죠.

[14:00] 그냥 참고 자료이고

[14:03] 오른쪽에는 GitHub 저장소가 있는데

[14:04] 여기서 열어보겠습니다.

[14:07] 실제로 저장소가 두 개 있고

[14:09] 무엇을 평가하고 있는지

[14:10] 그리고 그 위의 프로젝트에 대해 조금 설명한 다음

[14:12] 좀 더 세부적으로 들어가겠습니다.

[14:15] 좋습니다. 이것이 저장소입니다.

[14:17] 주말 동안 이것을 만들었는데

[14:19] 그래서 별로 정교하지는 않습니다.

[14:21] 비록 정교하다고 나와 있긴 하지만 웃기네요.

[14:24] 아, 죄송합니다.

[14:26] >> 그것을 올릴 수 있나요? >> 아, QR에 연결되어 있지 않나요?

[14:28] 알겠습니다. 이 링크도 여기에 올려놓겠습니다.

[14:34] 여기에 넣어보겠습니다. 좋습니다. 아, 감사합니다.

[14:38] 그리고 발표 중에 질문이 있으시면

[14:41] 언제든지 슬랙에 올려주세요.

[14:43] 언제든 돌아와서 답변할 수 있고

[14:45] 마지막에 시간을 가질 예정이니까

[14:47] 슬랙 채널을 계속 활용해 주세요.

[14:48] 질문을 위해서요.

[14:50] 사람들끼리 서로 도움을 줄 수도 있겠네요.

[14:52] 그리고 누군가 제 requirements를 고쳐주신다면

[14:54] 풀 리퀘스트를 열어주세요. 라이브로 승인하겠습니다.

[14:57] 자, 우리가 하고 있는 일은

[15:00] 우리 회사의 PM 모자를 벗고

[15:03] AI 여행 계획자 모자를 써보겠습니다.

[15:05] 여기서 아이디어는 이 UI와 에이전트의 정교함에 대해서는

[15:06] 걱정하지 말라는 것입니다.

[15:10] 정말 프로토타입 예제 같은 것이지만

[15:11] 실시간으로 애플리케이션을 구축하고

[15:13] 내부에서 어떻게 작동하는지 이해하는 데는

[15:14] 도움이 됩니다.

[15:16] 우리가 사용할 예제는

[15:18] 실제로 조금 뒤로 돌아가서

[15:19] 기본적으로 제가 가지고 있는 Colab 노트북을 가져왔습니다.

[15:21] 여행 계획을 위한 것인데

[15:25] 그리고 이것을 사용해서

[15:27] 우리가 사용할 예제입니다.

[15:29] Crew AI를 추적하는 것인데

[15:30] Langraph 예제를 원한다고 하시면

[15:33] Crew AI는 아마 들어보지 못하셨다면

[15:36] 앞서 말했듯이 우리가 만든

[15:38] 프로토타입 예제입니다.

[15:40] 하지만 실시간으로 애플리케이션을 구축하는 것은

[15:42] 내부에서 어떻게 작동하는지 이해하는 데 도움이 됩니다.

[15:45] 그래서 사용할 예제는

[15:47] 실제로 조금 뒤로 돌아가서 설명하겠습니다.

[15:48] 기본적으로 여행 계획을 위한

[15:51] Colab 노트북을 가져왔습니다.

[15:53] 그리고 이것을

[15:55] 사용해서

[15:58] Crew AI를 추적하고 있었는데 Langraph로 예제를 만들어보고 싶었습니다.

[16:00] Crew AI는 혹시 모르시는 분들을 위해 설명하면

[16:02] 다중 에이전트 프레임워크입니다.

[16:03] 에이전트의 정의는 기본적으로

[16:06] LLM과 도구를 결합해서

[16:08] 특정 작업을 수행하는 것입니다.

[16:11] 그래서 제가 한 일은 이 노트북을

[16:13] 기본적으로 커서에 넣고

[16:14] Crew AI 대신 Langraph를 사용한

[16:16] UI 기반 워크플로우 예제를 만들어달라고 했습니다.

[16:19] 그리고 우리가 할 일은

[16:22] 챗봇을 만드는 대신

[16:24] 이 폼을 가져다가

[16:26] 폼의 입력값들을 사용해서

[16:28] 빠른 에이전트 시스템을 구축하고

[16:30] 이를 평가에 사용할 예정입니다.

[16:32] 그래서 제가 얻은 결과가 이것입니다.

[16:34] 완벽한 여행을 계획하세요.

[16:37] AI 에이전트가 놀라운 목적지를

[16:39] 발견하도록 도와드립니다.

[16:41]

[16:42] 목적지를 선택해보죠.

[16:44] 도쿄로 7일간 여행하고 싶다고 해봅시다.

[16:48] 인터넷이 작동한다고 가정하고

[16:50] 잘 되는지 봅시다.

[16:52] 예산을 1000달러로 설정하고

[16:54] 조금 확대해보겠습니다.

[16:57] 그리고 저는 음식에 관심이 있습니다.

[17:00] 모험적으로 만들어보죠.

[17:02] 이 모든 것을 가져다가 ChatGPT에

[17:05] 넣을 수도 있겠지만

[17:06] 내부적으로 이것을 폼 형태로

[17:08] 여러 입력값과 에이전트 기반 시스템으로

[17:11] 만드는 이유는

[17:13] 내부적으로 검색이나 RAG나

[17:15] 도구 호출 같은 것들을 할 수 있기 때문입니다.

[17:17] 그러니까 시스템이

[17:19] 이런 입력값들을 사용해서

[17:22] 반대편에서 저에게 여행 일정을

[17:24] 제공할 거라고 상상해봅시다. 그리고 잘 작동했네요.

[17:28] 네, 이것이 작동했습니다.

[17:30] 여기에 빠른 여행 일정이 있습니다.

[17:33] 특별히 화려하지는 않습니다.

[17:35] 기본적으로 제가 입력 폼으로 준 것과

[17:37] 에이전트가 내부적으로

[17:39] 수행하는 작업입니다.

[17:40] 아침, 오후 등

[17:42] 도쿄에서 일주일 동안

[17:45] 제가 준 예산을 사용한 일정을 제공합니다.

[17:49] 이것이 특별해 보이지 않는 이유는

[17:51] 이걸 가져다가 ChatGPT에

[17:52] 넣을 수도 있기 때문이지만

[17:55] 여기에는 약간의 뉘앙스가 있습니다. 바로 예산입니다.

[17:57] 이걸 다 더해보면

[17:59] 1000달러에 맞추기 위해 수학적 계산과

[18:01] 회계 처리를 하고 있습니다.

[18:03] 정말로 그것을 고려하고 있습니다.

[18:04] 여기서 보시면 꽤 절약적인 예산입니다.

[18:07] 여기서 관심사를 받아들일 수 있습니다.

[18:09] 예를 들어 다른 관심사를 말할 수 있습니다.

[18:11] 사케 테이스팅을 하고 싶다거나

[18:13] 그런 식으로 말하면

[18:14] 여행 일정에 포함시킬 방법을 찾을 것입니다.

[18:17] 하지만 여기서 정말 멋진 점은

[18:20] 이 아래에 있는 에이전트의 힘이

[18:23] 정말 높은 수준의 구체성을

[18:24] 출력에 제공할 수 있다는 것입니다.

[18:27] 그래서 우리가 보여주려는 것은

[18:29] 이것이 단지 하나의 에이전트가 아니라

[18:31] 실제로 여러 에이전트가

[18:32] 이 여행 일정을 제공하고 있다는 것입니다.

[18:34] 그래서 여기서 멈출 수도 있겠죠?

[18:37] 이 정도면 충분하다고 할 수도 있습니다.

[18:38] 코드도 있고요

[18:41] 대부분의 사람들에게는 말이죠. 비브 코딩을 할 때,

[18:42] 이렇게 생각하시죠. '훌륭해, 이것이 내가

[18:43] 원하는 걸 해주네'라고요. 여행 일정을

[18:45] 만들어줬으니까요. 하지만 내부에서는

[18:48] 무슨 일이 일어나고 있을까요? 음, 그리고 이 부분이

[18:50] 제가 Arize라는 저희 도구를 사용할

[18:52] 부분입니다. 저희에게는 Phoenix라는 오픈소스

[18:56] 도구도 있습니다. 참고용으로 지금

[18:57] 여기서 소개해드릴게요.

[18:59] 이것은 Arize의 오픈소스 버전입니다.

[19:01] Arize와 완전히 동일한 기능을 갖지는

[19:04] 않겠지만, Arize의 많은

[19:06] 설정 흐름과 워크플로우는

[19:08] 동일하게 가지고 있을 것입니다.

[19:10] 참고로 Arize는 정말로

[19:13] 확장성, 보안, 지원을 원하시는 분들과

[19:14] 미래형 워크플로우를 위해 구축되었습니다.

[19:18] 자, 저에게는 여행 계획

[19:20] 에이전트가 있고, 제가 방금 한 작업이

[19:22] 제대로 작동했다면, 확인해보죠.

[19:26] 그리고 우리는... 이것은 라이브 코딩입니다.

[19:33] 그러니까 뭔가 망가질 가능성이

[19:35] 충분히 있죠.

[19:37] 음, 네. 제 최신 추적을 깨뜨린 것 같지만,

[19:43] 여기서 이전 예시가 어떻게

[19:45] 생겼는지 보실 수 있습니다.

[19:46] 그래서 그 시스템이 실제로

[19:48] 어떻게 생겼는지는 기본적으로 이렇습니다.

[19:51] 이 예시들 중 하나를 열어보죠.

[19:54] 여기서 보실 것은

[19:55] 추적(traces)입니다. 추적은 실제로 입력, 출력,

[19:57] 그리고 방금 만든 요청 주변의 메타데이터입니다.

[20:00] 그리고 여기서 예시로 그 추적 중

[20:02] 하나를 열어보겠습니다.

[20:04] 그러면 본질적으로 에이전트들이

[20:07] 이 경우 여러 에이전트들이 취한 일련의 행동들을

[20:11] 보실 수 있습니다. 그 여행 일정을

[20:14] 생성하기 위해 수행한 것들 말이죠.

[20:16] 그리고 정말 멋진 것은 저희가

[20:18] 실제로 이것을 오늘 출시했다는 것입니다.

[20:20] 실제로, 여러분이 이것을

[20:23] 처음 보시는 분들이에요.

[20:25] 정말 멋지죠.

[20:27] 이것은 실제로 코드로 표현된

[20:30] 여러분의 에이전트 표현입니다.

[20:33] 그러니까 말 그대로 제가 방금 위에서 사용한

[20:35] 커서 앱이 기본적으로 커서가

[20:37] 작성하는 데 도움을 준 저의 에이전트 기반

[20:40] 시스템입니다. 그리고 저희 문서를 보내줬을 때,

[20:43] 제가 한 일은 말 그대로 커서에

[20:45] 저희 문서 링크를 주고 '이 에이전트를

[20:48] 얻기 위한 계측을 작성해줘'라고

[20:50] 말했을 뿐이고, 이것이 그렇게

[20:52] 표현된 것입니다. 그래서 저희에게는

[20:54] 플랫폼에 새로운 에이전트 시각화가

[20:56] 있는데, 이것이 기본적으로 시작점을

[20:59] 보여주고 그 아래에 여러 에이전트들이

[21:01] 방금 우리가 한 작업을 수행합니다.

[21:04] 그래서 예산, 지역 경험, 연구 에이전트가

[21:06] 있고 이들이 여행 일정 에이전트로

[21:09] 들어가서 최종 결과나 출력을

[21:11] 제공하고 여기 위에서도 보실 수

[21:13] 있습니다. 그래서 연구, 일정,

[21:15] 예산, 지역 정보를 통해

[21:18] 여행 일정을 생성합니다.

[21:21] 이것 정말 멋지지 않나요?

[21:22] 많은 사람들에게

[21:25] 저희 자신들을 포함해서 이런 에이전트들이

[21:27] 이렇게 시각적인 방식으로 잘 표현될 수

[21:29] 있다는 것이 즉시 명확하지는 않습니다.

[21:32] 특히 코드를 작성할 때는

[21:34] 이것들을 그냥 함수 호출로

[21:36] 생각하게 되죠.

[21:38] 서로 대화하고 있지만, 정말 유용한 것은

[21:39] 에이전트가 호출하는 것들을 전체적인 관점에서 보는 것입니다.

[21:42] 에이전트가 수행하는 호출들을 볼 수 있고

[21:44] 정말 깔끔하게 구분된

[21:46] 예산 에이전트, 현지 경험 에이전트, 그리고 리서치 에이전트의 병렬 호출을 확인할 수 있습니다.

[21:50] 예산 에이전트, 현지 경험

[21:52] 경험 에이전트, 그리고 리서치 에이전트

[21:54] 이 모든 것들이 입력되어

[21:57] 위 내용을 모두 요약하는 여행 계획 에이전트로 전달됩니다.

[21:59] 여기 위에서도 볼 수 있죠.

[22:01] 이런 것들을 트레이스라고 부르고

[22:04] 기술적으로 스팬이라는 요소들로 구성됩니다.

[22:07] 스팬은 기본적으로 작업 단위라고 생각하시면 됩니다.

[22:09] 여기에는 시간 요소가 있는데

[22:11] 해당 프로세스가 완료되는데 걸린 시간과

[22:13] 프로세스의 유형이 포함됩니다.

[22:15] 프로세스의 유형이 무엇인지 말이죠.

[22:17] 여기서 세 가지 유형을 볼 수 있습니다.

[22:19] 에이전트가 있고, 툴이 있습니다.

[22:21] 툴은 기본적으로 데이터를 사용해서

[22:24] 구조화된 데이터로 작업을 수행할 수 있게 해줍니다.

[22:26] 그리고 LLM이 있는데

[22:28] 입력과 컨텍스트를 받아서

[22:30] 출력을 생성합니다.

[22:33] 이것은 실제로 세 개의 에이전트가

[22:35] 네 번째 에이전트로 입력되어

[22:38] 여행 계획을 생성하는 예시입니다.

[22:40] 이것이 우리가 여기서 보고 있는 것입니다.

[22:41] 한 단계 더 깊이 들어가 봅시다.

[22:45] 이것도 멋지고 유용하다고 생각합니다.

[22:48] 이런 시스템들이 어떻게 생겼는지

[22:50] 어떻게 표현되는지 보기 위해 잠시 줌아웃해보겠습니다.

[22:53] 프로덕트 매니저로서

[22:55] 팀에게 돌아가서 물어볼 수 있다는 것은 엄청난 레버리지입니다.

[22:58] '우리 에이전트가 실제로 어떻게 생겼나요?'

[23:00] '시스템이 실제로 어떻게 생겼는지

[23:02] 보여줄 수 있는 시각화가 있나요?'

[23:04] 그리고 에이전트에게 여러 입력을 제공할 때

[23:06] 그 출력들은 어디로 가나요?

[23:08] 시스템이 실제로 어떻게 생겼나요?

[23:09] 그 출력들이

[23:11] 다른 에이전트 시스템으로 들어가나요?

[23:13] 시스템이 실제로 어떻게 생겼나요?

[23:15] 시스템이 실제로 어떻게 생겼나요?

[23:17] 이것이

[23:18] PM으로서 얻을 수 있는 핵심 인사이트 중 하나입니다.

[23:21] 개인적으로 우리 에이전트가

[23:23] 실제로 무엇을 하고 있는지

[23:25] 후드 아래에서 보는 것이 매우 도움이 되었습니다.

[23:28] 여기서 한 단계 더 깊이 들어가 보겠습니다.

[23:31] 여행 계획이 있고

[23:33] 빠르게 살펴보겠습니다.

[23:34] 마라케시, 모로코는

[23:37] 활기차고 이국적인 목적지입니다. 블라블라

[23:38] 정말 길어요, 그렇죠?

[23:42] 실제로 이걸 보고 읽을지 모르겠어요.

[23:44] 좋은 제품 경험처럼

[23:45] 눈에 띄지 않아요.

[23:47] 좋은 제품처럼 보이지 않습니다.

[23:49] 개인적으로 완전히 AI가 생성한 것 같은 느낌이에요.

[23:51] 그래서 여러분이 해야 할 일은

[23:53] 실제로 생각해보는 것입니다. 프로덕트 담당자로서

[23:55] 제품을 반복 개선할 수 있는 방법이 있을까요?

[23:58] 이를 위해 할 수 있는 것은

[24:01] 방금 추적한 그 동일한 프롬프트를

[24:03] 코드에서 정의한 모든 변수와 함께

[24:05] 프롬프트 플레이그라운드로 가져오는 것입니다.

[24:07] 여기에 프롬프트 템플릿이 있는데

[24:09] 기본적으로 동일한 프롬프트 변수들이 있습니다.

[24:12] UI에서 정의한 것들과 같은

[24:14] 목적지, 기간, 여행 스타일 같은 변수들이죠. 그리고 모든

[24:17] 목적지, 기간, 여행 스타일. 그리고 모든

[24:19] 기간, 여행 스타일. 그리고 모든

[24:22] 이 모든 입력값들이 여기로 들어갑니다.

[24:25] 아래 프롬프트 플레이그라운드에서

[24:26] 어떤 모습인지 보실 수 있습니다.

[24:29] 그리고 여기서 일부 에이전트들의

[24:33] 출력 결과도 보실 수 있습니다.

[24:33] 그리고 여행일정을 생성하는

[24:36] 에이전트에서 나온

[24:38] 최종 여행일정도 있습니다.

[24:40] 자, 이게 왜 중요한지 말씀드리자면,

[24:44] 많은 회사들이 프롬프트 플레이그라운드라는

[24:47] 개념을 가지고 있습니다.

[24:49] OpenAI도 프롬프트 플레이그라운드가 있죠.

[24:50] 이 용어를 들어보셨거나

[24:52] 사용해보신 분들도 계실 겁니다.

[24:54] 하지만 개발에 도움이 되는

[24:56] 도구를 생각할 때

[24:58] 시각화만 중요한 게 아니라

[25:00] 내부에서 스택이

[25:01] 어떻게 생겼는지 보는 것뿐만 아니라

[25:04] 데이터와 프롬프트를 가져와서

[25:06] 하나의 인터페이스에서

[25:08] 데이터와 프롬프트를 반복적으로

[25:10] 개선할 수 있다는 것이 정말 강력합니다.

[25:13] 목적지를 바꿔볼 수도 있고

[25:15] 변수를 조정해서

[25:17] 이전과 똑같은 프롬프트로

[25:19] 새로운 결과를 얻을 수 있거든요.

[25:21] 이게 정말 강력한 워크플로우라고 생각합니다.

[25:23] PM 분들을 위한 사고실험으로

[25:26] 이 프롬프트가 실제로

[25:28] 어떤 모습인지 생각해보실 때

[25:30] 프롬프트 작성이

[25:34] 엔지니어의 책임인지 PM의 책임인지 고민해보세요.

[25:38] 만약 여러분이 제품 담당자이고

[25:41] 제품의 최종 결과에

[25:43] 책임을 져야 한다면

[25:45] 프롬프트에 대해서도

[25:48] 어느 정도 통제권을

[25:49] 가지고 싶으실 겁니다.

[25:52] 그래서 경계선이

[25:54] 정말 어디에 있는지 생각해보세요.

[25:56] 단순히 넘겨주기만 하는 건지,

[25:58] 엔지니어가 특정 요구사항을

[26:00] 통합하고자 하는

[26:02] 제품 담당자보다 프롬프트를

[26:04] 더 잘 작성할 수 있는지 말이죠.

[26:06] 그래서 제품 관점에서 이게 정말 유용합니다.

[26:08] 좋습니다. 네, 질문하세요. 이걸 어떻게 처리하나요?

[26:17] 어떻게 이걸 처리하죠?

[26:22] 네.

[26:24] 아, 네 좋은 질문입니다.

[26:26] 뒤에 계신 분의 질문은

[26:28] 툴 콜을 어떻게 처리하는지에 대한 것이었고

[26:30] 정말 날카로운 관찰이었습니다.

[26:31] 에이전트에도 툴이 있다는 거죠.

[26:33] 그리고 이 부분에서 잠시 멈춰서 설명할 필요가 있는데

[26:38] 정말 좋은 포인트거든요.

[26:39] 제가 한 건 프롬프트 템플릿과

[26:41] 변수가 있는 LLM 스팬을 가져온 것인데

[26:44] 적절한 툴을 선택하고

[26:47] 에이전트가 올바른 툴을

[26:48] 선택하는지 확인하고 싶을 수도 있습니다.

[26:51] 이 데모에서는

[26:52] 자세히 다루지 않겠지만

[26:55] 에이전트 툴 호출에 관한

[26:59] 좋은 자료들이 있습니다.

[27:02] 실제로 툴도 포팅해서 가져옵니다.

[27:06] 이 예제에는 없는데

[27:08] 솔직히 말하면 너무 간단한 예제라

[27:10] 그런 거고, 만약 툴 호출 평가를

[27:12] 하고 싶으시다면

[27:14] 제품에서 그런 기능을 제공하고 있고

[27:17] 그에 대한 자료도 있습니다.

[27:19] 관심 있으시면 나중에

[27:20] 연락 주세요.

[27:21] 그 자료도 전체 프레젠테이션으로 보내드릴게요.

[27:23] 좋은 질문이네요.

[27:25] LLM과 프롬프트만 평가하는 게 아니라

[27:27] 시스템 전체를 평가해야 해요.

[27:29] 모든 하위 구성 요소들까지 포함해서요.

[27:30] 자, 계속 진행해보죠.

[27:34] 이제 프롬프트가 준비됐네요.

[27:36] 이것도 좋지만, 실시간으로 몇 가지

[27:39] 변경사항을 적용해보겠습니다.

[27:41] 모든 분이 보기 쉽도록 최선을 다해보겠지만

[27:43] 현재 환경에서 작업하는 거니까요.

[27:44] 우선 이 프롬프트 버전을 저장하고

[27:47] 'nenge 프롬프트'라고 이름을 짓겠습니다.

[27:50] 이렇게 하면 반복 작업이 쉬워집니다.

[27:53] 버튼 클릭 한 번으로 프롬프트를 복제할 수 있고

[27:58] 사용할 모델도 바꿀 수 있어요.

[28:01] 이건 정말 유용합니다.

[28:03] 이 프롬프트를 계속 개선할 수 있거든요.

[28:04] 복제도 버튼 클릭 한 번이면 되고

[28:06] 모델도 변경할 수 있어요.

[28:08] 4.0 대신 4.1 mini를 사용해보겠습니다.

[28:09] 몇 가지를 바꿔보겠습니다.

[28:12] 실제로는 한 번에 하나씩 변경해야 하지만

[28:14] 지금은 데모를 위해서

[28:16] 여러 개를 동시에 바꿔보겠습니다.

[28:17] 더 인터랙티브하게 만들기 위해서요.

[28:20] 여기서 중요한 건

[28:21] 결과물이 어떻게 보이는지 바꾸는 겁니다.

[28:23] '상세한 일일 계획으로 포맷하라'고 되어 있는데

[28:26] 솔직히 더 중요한 요구사항이 있다고 생각해요.

[28:29] '장황하지 말라'는 조건이죠.

[28:31] '장황하지 말고 500자 이하로 유지하라'

[28:36] 더 임팩트 있게 만들고 싶어요.

[28:40] 더 보기 쉬운 결과물을 원한다고요.

[28:43] 주말에 코딩하는 입장에서도

[28:47] 이 제품을 사용해보는 사용자들의

[28:49] 피드백을 받고 싶을 거예요.

[28:52] 그래서 이런 조건을 추가할 수 있어요:

[28:54] '사용자가 이메일 주소를 제공하면

[28:56] 항상 할인 혜택을 제안하라'

[28:59] 마케팅에도 도움이 되고

[29:03] 항공편 예약 등에 이 도구를 사용하는

[29:08] 사용자들의 피드백도 받을 수 있죠.

[29:11] 유용하죠?

[29:12] 마케팅에도 도움이 되고

[29:13] 이 도구를 실제로 사용해보는 분들의

[29:15] 피드백을 받는 데도 도움이 됩니다.

[29:17] 자, 이제 '모두 실행'을 눌러보겠습니다.

[29:19] 그러면 방금 수정한 프롬프트들이

[29:21] 플레이그라운드에서 실행됩니다.

[29:23] 인터넷 때문에 조금 시간이 걸릴 수도 있어요.

[29:25] 기존 실행 결과 중 하나에서 가져온 거죠?

[29:31] >> 맞습니다. 기존 실행 결과 중 하나와

[29:36] 정확히 동일한 거예요.

[29:38] >> 맞습니다.

[29:40] 이것과 정확히 동일한... 아니,

[29:41] 이건 스페인 관련이네요.

[29:44] 정확히 이건 아니지만

[29:46] 기존 실행 결과 중 하나입니다.

[29:49] 음, 확실히 조금 나아졌네요.

[29:55] 하지만 솔직히 말하면

[29:56] 이걸 보면서 느끼는 건

[29:58] 제 지시를 잘 따르지 않고 있다는 거예요.

[30:01] 제가 준 프롬프트를 잘 지키지 않네요.

[30:03] '짧게 유지하라'고 했는데 말이죠.

[30:05] 하지만 이메일 관련 부분은 잘 따랐네요.

[30:07] '이메일 주소 알려주시면

[30:10] 10% 할인코드 보내드립니다'라고 했어요.

[30:12] 10% 할인 코드를 받으려면 이메일을 보내주세요."

[30:15] [웃음]

[30:18] 흥미로운 점은 우리가 하나의 예시를 보고 있다는 거예요.

[30:22] 이메일을 요청하면 할인을 받는다고 했는데,

[30:27] 이게 바로 이번 데모의 감정 코딩 부분이에요.

[30:32] 하나의 예시만 보고 좋은지 나쁜지 판단하려고 하는 거죠.

[30:38] 수백, 수천 명의 사용자를 대상으로 실제 서비스를 출시할 때는

[30:42] 이런 시스템이 확장성이 전혀 없어요.

[30:46] 단 하나의 데이터 행만 보고 결정을 내릴 사람은 없거든요.

[30:50] 프롬프트가 좋다거나 모델이 차이를 만들었다고 말하는 것처럼요.

[30:54] 가장 성능 좋은 모델을 선택하고 프롬프트를 최대한 구체적으로 만들어도

[30:58] 결국 LLM은 여전히 환상을 보게 되고,

[31:02] 그런 상황이 언제 발생하는지 포착하는 게 우리의 역할입니다.

[31:07] 이제 이걸 좀 더 확장해보겠습니다.

[31:11] LLM이 제대로 작동하지 않은 예시가 하나 있는데,

[31:15] 10개 또는 심지어 100개의 예시로 데이터셋을 구축하고 싶다면?

[31:18] 같은 프로덕션 데이터를 활용할 수 있어요.

[31:22] 참고로 이걸 프로덕션 데이터라고 하지만, 사실 그냥 Cursor한테

[31:26] 합성 데이터를 만들어달라고 요청했어요.

[31:30] 어제 그렇게 해서 15개 정도의 다른 여행 일정을 생성했고,

[31:33] 그걸 이번 데모에서 사용하고 있어요.

[31:37] 이제 몇 개를 선택해보겠습니다. 여기서 몇 개의 일정 구간을 골라서

[31:42] 데이터셋에 추가할 수 있다고 할 수 있어요.

[31:46] 아, 그런데 어떻게 여기까지 왔는지 보여드리지 않고

[31:50] 제품에 바로 뛰어든 것 같네요. 좀 줌아웃해서 설명드릴게요.

[31:54] 홈페이지 arise.com에 가서 가입하시면 됩니다.

[31:59] 미리 사과드리는데, 온보딩 플로우가 좀 오래된 느낌일 수 있어요.

[32:03] 하지만 다음 주에 업데이트할 예정이니 양해 부탁드려요.

[32:09] Arise에 가입하면 여기서 API 키를 받을 수 있습니다.

[32:13] 계정 설정에 가서 API 키를 생성할 수 있고,

[32:17] 스페이스 ID도 함께 찾을 수 있어요.

[32:21] 둘 다 계측을 위해 필요한 건데,

[32:25] 리포지토리가 실제로 작동하는지에 따라 될 수도 안 될 수도 있어요.

[32:29] 안 되면 나중에 다시 돌아오겠습니다.

[32:33] 어쨌든 이게 플랫폼이고, API 키를 받는 방법이에요.

[32:36] 그리고 여기서 다음 부분과 플레이그라운드를 위한

[32:40] OpenAI 키도 입력할 수 있습니다.

[32:43] 이제 데이터셋이 있어요. 지금까지의 상황을 요약하면,

[32:47] 프로덕션 데이터가 있고 이걸 데이터셋에 추가하려고 해요.

[32:51] 이미 데이터셋이 있어서 라이브로 하지는 않겠지만,

[32:55] 개선하고 싶은 예시들의 데이터셋을 만들 수 있어요.

[32:51] 이제 실제 평가 부분으로

[32:53] 데모의 핵심 단계로 넘어가겠습니다.

[32:56] 실제로 평가할 내용은,

[32:58] 에이전트에는 여러 구성 요소가 있습니다.

[33:00] 최상위 레벨에는 라우터가 있고,

[33:03] 스킬이나 함수 호출,

[33:04] 그리고 메모리가 있습니다.

[33:07] 하지만 이번 경우에는

[33:08] 실제로는 생성의

[33:10] 개별 스팬을 평가하고

[33:14] 에이전트가 우리가 원하는 방식으로

[33:17] 텍스트를 출력하고 있는지 확인할 것입니다.

[33:19] 따라서 이는 에이전트 평가보다는

[33:21] 조금 더 간단하고,

[33:23] 실제로 에이전트를 실행하고

[33:25] 데이터에 대해 평가 실험을

[33:28] 수행하는 방법에 대한 것입니다.

[33:32] 데이터 세트의 개념은

[33:35] 예시의 집합으로

[33:36] 생각하시면 됩니다.

[33:38] 이 실험들을 삭제하고 라이브로 진행하겠습니다.

[33:42] 저는 스릴을 즐기거든요.

[33:45] 여기 예시들이 있습니다.

[33:47] 방금 여러분이 본

[33:49] 프로덕션 데이터와 동일한 예시들입니다.

[33:51] 이것이 데이터 세트입니다.

[33:54] 모든 트레이스와 스팬을

[33:56] 가지고 있다고 생각하세요.

[33:58] 그것이 에이전트의 작동 방식입니다.

[34:00] 그리고 이를 표 형식으로

[34:03] 생각할 수 있는 형태로 가져오고 싶습니다.

[34:05] 구글 스프레드시트 같은 것이죠.

[34:06] 결국 그런 것입니다.

[34:08] 구글 스프레드시트 같은 형태로

[34:09] 들어가서 좋아요, 싫어요를

[34:12] 표시할 수 있습니다.

[34:15] 대부분의 팀이 오늘날

[34:17] 평가하는 방식이 바로 이것입니다.

[34:19] 플랫폼에서 스프레드시트로

[34:22] 시작하고 있을 것입니다.

[34:23] 그 스프레드시트에서

[34:26] 좋은지 나쁜지 판단하고

[34:28] 이를 확장하려고 하죠.

[34:29] 전문가 팀에게

[34:31] 에이전트가 좋은지 나쁜지

[34:33] 피드백을 받는 것입니다.

[34:35] 여기 있는 분들께 설문조사:

[34:37] 현재 스프레드시트로

[34:38] 평가하고 있는 분이 몇 명이나 되나요?

[34:40] 부끄러워하지 마세요. 괜찮습니다.

[34:41] 몇 분 계시네요.

[34:43] 아마 더 있을 텐데,

[34:44] 사람들이 부끄러워해서 그런 것 같습니다.

[34:47] 괜찮습니다. 그렇게 시작하는 것이

[34:49] 세상의 끝은 아닙니다.

[34:51] 인간의 주석을 확장하는 것이

[34:54] 목표입니다. 시작점일 필요는 없죠.

[34:56] 실제로 데이터를 보고 있다면

[34:58] 대부분보다 잘하고 있는 것입니다.

[34:59] 솔직히 말해서요.

[35:01] 제가 이야기한 많은 팀이

[35:03] 오늘날 전혀 평가를 하지 않고 있습니다.

[35:05] 최소한 인간 라벨로

[35:07] 시작하고 있으니까요. 이제 할 일은

[35:10] 이 데이터 세트나 CSV를 가져와서

[35:12] 기본적으로 방금 제가 한 것과 같은 일을 할 것입니다.

[35:16] 프롬프트에 대한 AB 테스트를 실행했는데,

[35:18] 이번에는 전체 데이터 세트에 대해

[35:21] 실행할 것입니다.

[35:23] 플랫폼으로 들어가서

[35:24] 실제로 실험을 생성할 수 있습니다.

[35:27] 실험이라고 부르는 것은 결과물입니다.

[35:29] 변경, 즉 AB 테스트의 결과입니다. 그럼,

[35:32] 같은 워크플로우를 다시 반복해보겠습니다.

[35:34] 이 프롬프트를 복제하겠습니다.

[35:37] 음, 이 버전의 프롬프트를

[35:40] 가져오겠습니다.

[35:42] 정말 멋진 점은

[35:45] 이전 버전의 프롬프트를

[35:48] 저장해둘 수 있다는 겁니다.

[35:50] 프롬프트 허브가 있어서

[35:52] 반복하면서 프롬프트 예시를

[35:54] 저장할 수 있어 정말 유용합니다.

[35:55] GitHub 같은 프롬프트 저장소라고

[35:58] 생각하시면 되는데, 실제로는

[36:00] 이 버전의 프롬프트를 저장하기 위해

[36:02] 클릭하는 버튼일 뿐입니다.

[36:04] 그러면 팀에서 실제로

[36:06] 나중에 코드에서 그 버전을 사용할 수 있습니다.

[36:09] 프롬프트 A는 변경사항이 없고

[36:11] 프롬프트 B는 몇 가지

[36:13] 변경사항이 있지만, 이제는 한 개 예시가 아니라

[36:15] 실제로 여기서

[36:18] 12개 예시에서 실행하고 있습니다.

[36:20] 이것들은 비슷한 에이전트들입니다.

[36:23] 하나만 보자면, 비슷한 스팬들로

[36:26] 목적지, 기간, 여행 스타일이 포함되어 있고

[36:29] 에이전트의 출력과 함께

[36:32] 일정을 생성합니다.

[36:33] 방금 실행한 예시와

[36:36] 동일하지만, 이제는 전체 데이터셋에서

[36:39] 실행됩니다.

[36:40] 그리고

[36:47] 네, 이것은 일정 에이전트의

[36:50] 프롬프트입니다. 동일한... 우리가

[36:53] 이것을 꽤 높은 수준으로

[36:55] 유지할 예정이라서

[36:57] 간단한 데모처럼 말이죠.

[36:59] 구체적으로는 일정 생성

[37:02] 에이전트의 프롬프트인데,

[37:05] 여기 아래에 있고, 다른

[37:07] 에이전트들의 출력을 받아서

[37:10] 이들을 결합하고 프롬프트 변수를 사용해서

[37:12] 일별 일정을 만듭니다.

[37:23] 네. 그 분이 물어보신 것은

[37:26] 상위 프롬프트를 변경하면

[37:29] 여기서 무슨 일이 일어나는지에 대한 것입니다.

[37:30] 두 가지 점이 있는데, 더 고급

[37:33] 워크플로우지만

[37:34] 좋은 질문입니다.

[37:36] 두 부분이 있습니다. 하나는

[37:39] 시스템을 부분별로 변경하는 것을

[37:41] 권장한다는 것입니다.

[37:43] 스택의 평가 부분을 생성하면서

[37:46] 더 세분화해서

[37:47] 분석할 수 있도록 분해할 수 있습니다.

[37:50] 여기 위에서 한 가지를 변경하면

[37:51] 요구사항 기준을 충족하는지 확인할 수 있습니다.

[37:53] 그리고 두 번째 부분은

[37:56] 프롬프트 체인을 재생하는 것입니다.

[37:58] 프롬프트 A가 프롬프트 B로 들어갑니다.

[38:00] 프롬프트 A를 변경했을 때의 출력은 무엇일까요?

[38:02] 프롬프트 체이닝은

[38:04] 곧 저희 플랫폼에 출시될 예정입니다.

[38:06] 지금은 단일 프롬프트지만

[38:08] A + B + C 프롬프트 체인도

[38:12] 가능하게 될 것입니다.

[38:13] 좋은 질문입니다.

[38:15] Slack에 더 많은 질문을 올려주시면

[38:18] 나중에 다시 다뤄보겠습니다.

[38:21] 이제 프롬프트를 얻었으니

[38:22] 일별 계획을 만들어달라고 하고

[38:24] 너무 자세할 필요는 없고

[38:25] 최대 1,000자로 제한합니다.

[38:27] 다시 시도해보겠습니다. 500자로 하고

[38:31] 항상 매우 친근한 톤으로 답변하고

[38:33] 더 구체적으로 말해서 사용자에게 이메일을 요청하고 할인을 제안하라고 해봅시다

[38:35] 이렇게 하면 이전과 같은 결과가 나오지 않을 거예요

[38:36] 그리고 이제 전체 데이터셋에 대해 실행해보겠습니다

[38:38] 프롬프트 A와 프롬프트 B를 비교해보겠습니다

[38:40] 실행되는 동안 잠시 기다려주세요

[38:43] 실행되는 동안 말이죠

[38:46] 오, 좋네요. 완벽해요

[38:48] 여러분 팀을 위한 거네요. 흥미롭습니다

[38:50] 모델이 왜 때때로 이모지를 그렇게 좋아하는지 모르겠어요

[38:52] 아무래도 '매우 친근한' 톤이라는 것이

[38:54] 이모지를 좀 넣어라

[38:55] 이런 의미로 해석되는 것 같네요. 흥미롭습니다

[38:56] 음...

[38:58] 좋아요, 이건 꽤 빨리 실행됐네요

[39:01] 이쪽은 아직 시간이 걸리고 있죠?

[39:04] 잠깐 제품 관리자 관점에서 생각해봅시다

[39:06] 방금 문자 수를 제한해서

[39:08] 출력을 훨씬 빠르게 만들었습니다

[39:10] 이쪽은 평균 32초 정도 걸리는데

[39:12] 출력 문자 수를 지정하지 않고

[39:14] 자유롭게 생성하도록 했기 때문입니다

[39:16] 프롬프트 반복 작업이

[39:18] 이런 식으로도 도움이 될 수 있습니다

[39:21] 그게 바로 프롬프트 최적화가

[39:23] 여러분에게 도움이 되는 방식입니다

[39:25] 좋습니다. 이게 실행되는 동안

[39:27] 다른 화면으로 넘어가보겠습니다

[39:30] 네

[39:34] 좋습니다

[39:36] 오, 자료를 공유해주셔서 감사합니다

[39:39] 그곳에요

[39:41] 아직 실행 중이네요

[39:47] 실행되는 동안 질문 있으신 분 계신가요? 네

[39:51] 네, 말씀하시는 걸 들어보니

[39:52] 주로 지연 시간과

[39:53] 사용자 경험을 중심으로

[39:55] 평가하고 계신 건가요?

[39:57] 이 두 가지 말이죠?

[40:00] 다른 건 어떤 걸 보고 계세요?

[40:02] 네, 좋은 질문이네요

[40:05] 이제 핵심으로 들어가고 있습니다

[40:07] A와 B가 있는데

[40:10] 실제로 여기서 무엇을 평가하고 있는지가 질문이죠

[40:11] 간단한 답은

[40:13] 무엇이든 평가할 수 있다는 겁니다

[40:15] 원하는 건 뭐든 평가할 수 있어요

[40:18] 이 경우에는

[40:20] 에이전트의 톤에 대해

[40:22] 몇 가지 평가를 실행해보겠습니다

[40:25] 여기 몇 개의 평가를 설정해뒀습니다

[40:27] 에이전트가 친근한 방식으로 답변하고 있는지

[40:31] 할인을 제안하고 있는지 확인해보겠습니다

[40:33] 그리고 맥락을 올바르게 사용하고 있는지

[40:35] 같은 것들도 평가할 수 있습니다

[40:38] 이것을 환각 평가라고 부릅니다

[40:41] 정확성도 평가할 수 있는데

[40:43] 올바른 맥락이 있어도

[40:44] 정답을 제공하고 있는지 확인하는 거죠

[40:47] 바로 사용할 수 있는 평가 예시들이

[40:49] 담긴 문서를

[40:51] 안내해드리겠습니다

[40:53] 하지만 이 시스템의 핵심과

[40:57] 자신만의 데이터로 시스템을 구축하고

[41:00] 데이터로 재실행할 수 있는 시스템이

[41:02] 중요한 이유는

[41:05] 이것들이 기성 평가들이기 때문입니다

[41:07] 평가를 대신 실행해준다는

[41:10] 많은 회사들이 있지만

[41:12] 실제로는 그들이

[41:14] 기본적으로 어떤 템플릿을 가져다가

[41:17] 자신들의 평가 템플릿을 기반으로

[41:19] 점수나 라벨을

[41:21] 제공하는 것뿐입니다

[41:23] 그런데 여러분이 실제로 할 수 있어야 하는 것은

[41:26] 변경하고 수정하고 실행하는 것입니다

[41:28] 자신만의 평가를 용도에 맞게 만드는 거죠

[41:31] 자신의 사용 사례에 맞는 평가를 수행할 수 있습니다.

[41:34] 원하는 것은 무엇이든 평가할 수 있다는 것이 간단한 답입니다.

[41:37] 평가할 수 있습니다. 이건 기본적으로

[41:39] LLM에 입력하여 레이블을 생성하는 것입니다.

[41:41] 그래서 사전 구축된 평가가 어떤 모습인지 보겠습니다.

[41:45] 인터넷에는 이런 예제들이 정말 많이 있습니다.

[41:47] 저희는 실제로 사전 구축된 평가를

[41:50] 오픈소스 데이터셋에서 테스트해봤습니다.

[41:52] 하지만 저희 말만 믿지 마시고

[41:54] 사용 사례에 맞는 평가를 구축해야 합니다.

[41:57] 자신만의 평가를 어떻게 만드는지

[41:59] 평가를 기반으로 구축해야 합니다.

[42:01] 네, 맞습니다.

[42:04] 자신만의 평가를 어떻게 만들어내는지

[42:06] 자신만의

[42:10] 조합하는 방법이요?

[42:13] 네, 실제로 평가를 어떻게 구성해야 하는지

[42:15] 처음부터 어떻게 생각해야 하는지에 대해

[42:18] 어느 정도는 말이죠. 그것도

[42:19] 질문 중 하나였습니다. 네.

[42:20] 평가가 어떤 모습인지 보는 것이

[42:23] 도움이 될 것 같습니다.

[42:26] 그리고 그 질문으로 다시 돌아올 수도 있겠네요.

[42:28] 평가란 무엇인가, 맞죠?

[42:30] 그럼 여기서 평가를 구축해보겠습니다.

[42:31] 준비된 것이 있지만 템플릿을 보여드리고 싶습니다.

[42:34] 새로운 것도 작성할 수 있습니다.

[42:36] 저는 이 평가를 작성했는데

[42:38] LLM 출력이 친근한지 감지하기 위해서입니다.

[42:40] 그리고 그 의미에 대한 정의를 만들었습니다.

[42:43] 기본적으로 여러분이 작성된 텍스트를 검토한다고 합니다.

[42:47] 여기 텍스트가 있습니다. 텍스트를 검토하고

[42:49] 톤이 친근한지 아닌지 판단하세요.

[42:52] 친근한 톤은 긍정적이고

[42:54] 유쾌한 것으로 정의됩니다.

[42:56] 이것이 기본적으로 LLM에 입력하여

[42:58] 레이블을 생성하는 것입니다.

[43:02] 여행 일정 에이전트의 출력이

[43:04] 친근한지 로봇적인지 판단하는 것입니다.

[43:07] 그래서 이 평가가 실제로 하려는 것은

[43:12] 텍스트를 친근한 생성물 또는

[43:16] 로봇적인 생성물로 분류하는 것입니다.

[43:17] 다시 말하지만, 무엇이든 평가할 수 있지만

[43:20] 이 경우에는 프롬프트를 변경할 때

[43:22] 그것이 데이터에서 나타나는지

[43:24] 확인하고 싶습니다. 왜냐하면 수백 또는

[43:27] 수천 개의 예제를 일일이 들어가서

[43:29] 친근함과 로봇적인 것을

[43:30] 매번 평가할 수는 없기 때문입니다.

[43:32] 그래서 아이디어는 LLM을 판사로 사용하여

[43:34] 대규모 데이터셋에서 해당 레이블을

[43:37] 제공하는 시스템을 갖는 것입니다.

[43:39] 그것이 우리가 지금 작업하고 있는 목표입니다.

[43:41] 그 시스템 종류의 레이블을 말이죠.

[43:44] 큰 데이터셋에서요. 그것이

[43:46] 우리가 지금 작업하고 있는 목표입니다.

[43:48] 네.

[43:49] 네.

[43:50] 분산이 있죠.

[43:56] 불안정하죠, 맞나요?

[44:04] 네, 맞습니다.

[44:06] 네.

[44:21] 네, 한 가지 제안은

[44:24] 그분이 언급하신 것처럼 LLM 레이블 출력에서

[44:26] 분산을 보신다고 하셨는데, 분산을 조정할 수 있는

[44:30] 한 가지 방법은 온도입니다.

[44:31] 모델의 온도를 낮추면

[44:34] 설정할 수 있는 매개변수로

[44:35] 응답을 더 반복 가능하게 만들 수 있습니다.

[44:37] 완전히 0으로 만들지는 않지만

[44:39] 시스템의 분산을 상당히 줄입니다.

[44:42] 그리고 다른 옵션은

[44:43] 평가를 여러 번 다시 실행하여

[44:45] 기본적으로 판사의 분산을

[44:48] 프로파일링하는 것입니다.

[44:51] 네, 우리는 거기로 갈 예정입니다.

[44:58] 오 네, 우리는 갈 것입니다.

[45:00] 그 부분에서 다루게 될 거예요. 네, 좋은

[45:01] 질문이죠, 맞죠? 결국

[45:02] 이걸 신뢰할 수는 없잖아요. 직접 들어가서

[45:03] 제대로 되었는지 확인해야 하죠.

[45:05] 맞습니다. 하지만 일단 평가를 진행해보고

[45:06] 어떤 결과가 나오는지 보고

[45:08] 그 다음에 다시 살펴보죠.

[45:09] 자, 친근함 평가가 있고

[45:11] 또 다른 평가도 있는데, 기본적으로

[45:14] 텍스트에 할인 제안이 포함되어 있는지

[45:17] 판단하는 것입니다. 전체 내용을 다 읽어드리지는 않겠지만

[45:18] 간단히 말해서

[45:19] 이것은 텍스트에 할인 제안이

[45:22] 포함되어 있는지 없는지를 판단합니다

[45:24] 사용자에게 할인을 제공하는 것이

[45:26] 정말 중요하거든요. 자, 이 두 가지를 선택하고

[45:28] 이제 실제로 방금 실행한

[45:30] 실험에 대해 실행해보겠습니다

[45:32]

[45:33]

[45:38] 라이브로 진행할 예정입니다. Arize가 하는 일은

[45:40] 실제로... 저희는 평가 실행기가 있어서

[45:42] 모델 엔드포인트를 사용해서

[45:45] 이런 평가들을 생성하는 방식입니다.

[45:47] 꽤 빠르다는 걸 알 수 있을 거예요.

[45:50] 평가가 정말 빠르게 실행되도록

[45:52] 내부적으로 많은 작업을 했습니다.

[45:54] 이게 저희 제품을 사용하는

[45:56] 장점 중 하나입니다. 여기 두 개의 실험이 있는데

[45:58]

[46:00] 실험 2번은 생성된 순서가

[46:03] 역순이라서 조금 헷갈릴 수 있지만

[46:07] 실험 2번이 원래

[46:08] 프롬프트이고 실험 1번이

[46:10] 변경된 프롬프트입니다.

[46:12] 이 점을 염두에 두세요. 제가 즉흥적으로

[46:14] 진행하다 보니 조금

[46:16] 뒤바뀌었네요.

[46:17]

[46:19] 실험 2번의 점수를 보시면

[46:21] 프롬프트 A, 즉 변경하지 않은 프롬프트는

[46:25] 이 평가 레이블에 따르면

[46:27] 어떤 사용자에게도 할인을 제공하지 않았습니다

[46:29] 하지만 LLM은 여전히 그 응답을

[46:33] 친근하다고 평가했어요. 꽤 흥미롭죠.

[46:35] "아, 친근한 응답이었네"라고 했는데

[46:37] 개인적으로는 그렇게 생각하지 않아서

[46:38] 이 부분을 수정하려고 합니다.

[46:41] 그리고 프롬프트에 "사용자가 이메일을 제공하면

[46:42] 할인을 제공하라"는 문장을

[46:43] 추가했을 때

[46:45] 평가가 실제로 이를 감지했고

[46:47] 이 변경사항을 적용했을 때

[46:50] 100%의 예제에서

[46:52] 할인 제안이 포함되어 있다고 했습니다.

[46:55] 각 예제를 일일이 확인하지 않고도

[46:57] 그 점수를 얻을 수 있었어요.

[46:59] 이게 바로 LLM 심사 시스템이

[47:01] 제공하는 것입니다.

[47:03] 직접 들어가서 신뢰할 수 있고

[47:05] 이건 믿되 검증하라는 원칙입니다.

[47:08] 실제로 들어가서

[47:12] 이 중 하나를 살펴보고

[47:13] 친근함에 대한 설명이 무엇인지 보겠습니다.

[47:15] 텍스트가 친근한지 기계적인지

[47:18] 판단하는 것입니다. 평가 시스템이 있을 때

[47:21] 고려해야 할 한 가지는

[47:23] LLM 심사관이 왜 그런 점수를

[47:25] 주었는지 이해할 수 있는가입니다.

[47:26] 이게 바로 그런 핵심적인

[47:29] 포인트 중 하나입니다

[47:32]

[47:34] 이번 발표의 핵심 포인트 중 하나는

[47:36] 항상 LLM 판사가 무엇을 하고 있는지

[47:38] 설명할 수 있는지 생각해보는 것입니다.

[47:41] 실제로 우리는 평가의 일환으로 설명을 생성합니다.

[47:43] 따라서 여기서 볼 수 있듯이

[47:45] 설명은 판사의 추론 과정을 보여줍니다.

[47:47] 텍스트가 친근한지 기계적인지 판단하기 위해

[47:49] 언어, 어조, 스타일을 분석해야 한다고 말합니다.

[47:51] 그리고 이런 모든 분석을 통해

[47:53] "네, 이 LLM은 친근하고

[47:55] 기계적이지 않습니다"라고 결론을 내립니다.

[47:56] 하지만 다시 말하지만, 저는 그 설명에

[47:59] 정말 동의하지 않습니다.

[48:02] 저는 그것이 올바르지 않다고 생각해요.

[48:04] 여전히 원래 프롬프트가

[48:06] 꽤 기계적이었다고 느낍니다.

[48:08] 여러 면에서 꽤 길고 형식적이었거든요.

[48:11] 그래서 저는 실제로

[48:13] 같은 플랫폼에서 LLM 판사 시스템을

[48:15] 개선할 수 있기를 원합니다.

[48:18] 실제로 같은 데이터셋을 가져와서

[48:21] AISE 플랫폼에서 여러분이나

[48:24] 전문가 팀이 같은 장소에서

[48:27] 실제로 데이터에 라벨을 달 수 있습니다.

[48:30] 그리고 라벨링 큐의

[48:32] 플랫폼 부분에서 데이터셋에

[48:34] 라벨을 적용하면 원본 데이터셋에

[48:36] 다시 적용됩니다.

[48:39] 따라서 실제로 LLM 판사와

[48:41] 사람의 라벨을 비교하는 데

[48:43] 사용할 수 있습니다.

[48:46] 실제로 제가 그렇게 했습니다.

[48:48] 네, 발표 전에 미리 해뒀는데요,

[48:50] 각 예시를 살펴보면서

[48:52] "이건 제게는 기계적이에요.

[48:54] 이게 친근한 응답이라고

[48:56] 생각하지 않습니다.

[48:58] 너무 길고 LLM과

[49:00] 대화하는 것 같습니다"라고 했습니다.

[49:01] 그래서 실제로 개선하고 싶은

[49:04] 예시들에 대해 데이터셋에

[49:06] 이 라벨을 적용했습니다.

[49:08] 데이터셋으로 돌아가면

[49:11] 실제로 그 라벨이

[49:17] 여기에 적용된 것을 볼 수 있습니다.

[49:19] 클릭해서 이동하면...

[49:22] 죄송합니다, 데이터가 많아서

[49:23] 옆쪽에 좀 가려져 있지만

[49:26] 제가 입력한 사람 라벨들을

[49:27] 볼 수 있습니다.

[49:28] 이것들이 제가 큐에서 방금 제공한

[49:30] 것과 동일한 어노테이션입니다.

[49:33] 여기 제 데이터셋에 적용되어 있습니다.

[49:35] 네 맞습니다. 바로 그겁니다.

[49:38] 평가를 위한 평가가 필요해요.

[49:40] 시스템을 그냥 믿을 수는 없습니다.

[49:42] LLM이 환각을 일으킨다는 걸 알고 있죠.

[49:44] 에이전트에 넣으면 에이전트도

[49:46] 환각을 일으킵니다.

[49:47] 그래서 에이전트를 사용해 고치려 하지만

[49:49] 그 에이전트도 믿을 수 없어요.

[49:51] 그 위에 사람의 라벨이 필요합니다.

[49:52] 하지만 다시 말하지만, 저는

[49:55] 이걸 직감으로 코딩하면서

[49:57] "LLM 판사가 좋은지 아닌지"

[50:00] 판단하지는 않을 거예요.

[50:02] 그것을 위한 평가도 필요하고

[50:05] 이를 도와주는 두 가지 평가를 제공합니다.

[50:07] 문자열 체크나 정규식 같은

[50:09] 간단한 매칭을 할 수 있는

[50:12] 코드 평가자가 있습니다.

[50:14] 실제로 기술적인 PM이시고

[50:16] 코드를 작성하고 싶다면

[50:18] Claude의 도움을 받을 수 있습니다

[50:20] eval을 작성하는 데 도움을 주지만,

[50:22] 정말로 빠른 Python 함수일 뿐입니다.

[50:23] 제 경우에는 실제로 매칭을 하는

[50:26] 간단한 eval을 작성했습니다.

[50:28] 이 매칭은 정말 빠르고 더러운 eval이에요.

[50:31] 이것이 베스트 프랙티스라고는

[50:33] 전혀 말하지 않겠지만,

[50:35] 기본적으로 eval 레이블이

[50:37] annotation 레이블과 일치하는지 확인합니다.

[50:40] 아, 죄송합니다.

[50:42] 출력은 일치 또는 불일치만 됩니다.

[50:45] 이것이 하는 일은 실제로

[50:47] 휴먼 레이블과 eval 레이블을 비교해서

[50:50] 일치하는지 불일치하는지 확인하는 것입니다.

[50:52] 그래서 기본적으로 실행할 것이고,

[50:54] 저는 LLM을 심판으로 사용하고 있습니다.

[50:56] 코드를 사용할 수도 있어요.

[50:57] LLM을 심판으로 사용할 필요는 없지만,

[50:59] 우리는 이제 실행해보겠습니다.

[51:01] 같은 데이터셋에서,

[51:03] 방금 실행했던 같은 실험에서 말이죠.

[51:08] 잠시 기다리겠습니다.

[51:16] 좋아, 여기서 뭘 얻었을까요?

[51:19] 여기서 보시면 실제로 같은 실험을 살펴볼 수 있는데,

[51:22] LLM 심판이 친근한지 로봇적인지

[51:25] 말했던 부분이었습니다.

[51:27] 그리고 여기서 100%의 시간 동안

[51:29] 매칭이... 실제로 죄송합니다.

[51:33] 이 eval은 실제로...

[51:35] 좀 더 자세히 들어가보겠습니다.

[51:36] 실제로 제 작업을 확인해보겠습니다.

[51:37] 이 eval은 할인에 대한 것이었습니다.

[51:40] 그것은 잊어버리고,

[51:42] 친근한 필드를 확인해보겠습니다.

[51:44] 이것은 친근한 레이블입니다.

[51:46] 그것을 다시 실행해보겠습니다.

[51:48] 이것을 친근한 매칭으로 생각하겠습니다.

[51:50] 데이터셋과 실험에서

[51:52] 원하는 만큼 eval을 실행할 수 있습니다.

[51:53] 아시죠.

[51:57] >> 도구가 파이프라이닝을 지원하나요?

[51:59] 기본적으로 코드를 푸시하는...

[52:00] >> 네, 정확히 그렇습니다.

[52:02] 모든 eval의 모든 방법을 지원합니다.

[52:06] 로컬에서 데이터셋에 대해 코드를 실행하거나

[52:09] eval을 실행하기 위해 플랫폼에 코드를 푸시할 수 있습니다.

[52:11] 그래서 양방향으로 프로그래밍 방식으로 가능합니다.

[52:13] 네, 물론입니다.

[52:16] 데이터셋을 가져오고 내보낼 수도 있습니다.

[52:17] 좋아요, 이것을 다시 살펴보겠습니다.

[52:20] 이것이 친근한 매칭입니다.

[52:22] 이것이 꽤 유용하다는 것을 알 수 있죠?

[52:24] 이것은 제 LLM 심판이

[52:26] 기본적으로 친근함에 대한

[52:30] 휴먼 레이블과 거의 전혀 일치하지 않는다는 뜻입니다.

[52:33] 맞죠? 한 가지 예제 정도가

[52:36] 있는 것 같고 들어가서

[52:37] 살펴볼 수 있지만,

[52:39] 실제로 보고 있는 것은

[52:40] 이것이 팀이

[52:42] 실제로 우리의 eval 레이블을 살펴보고

[52:44] "우리가 eval 레이블 자체를 개선할 수 있을까?"

[52:48] 라고 말하기를 원하는 영역입니다.

[52:50] 왜냐하면 휴먼 레이블과

[52:52] 일치하지 않기 때문이에요.

[52:54] AI PM으로서 이런 시스템을 갖추고

[52:57] eval 레이블을 휴먼 레이블과

[52:59] 확인할 수 있을 때,

[53:02] 팀에게 돌아가서

[53:04] "우리는 eval 시스템을

[53:05] 개선해야 합니다.

[53:07] 예상대로 작동하지 않고 있어요."

[53:09] 라고 말할 수 있는 많은 레버리지를 갖게 됩니다.

[53:11] 더 크고 규모 있게 진행하게 됩니다. 그래서

[53:13] 수백 개나 수천 개의 예시들로

[53:14] 작업하게 되는 거죠. 그래서

[53:17] 정말로 이게 중요한 것은, 아까 누군가

[53:19] 어떻게 시스템을 신뢰하냐고 물어봤는데

[53:20] 이런 LLM을 판단자로 사용하는 시스템을 신뢰하는 방법은

[53:23] 여러 검증과 균형장치를 두는 것입니다

[53:25] 인간이 있고 LLM이 있고, 다시 인간과 LLM이 있죠.

[53:27] 음, 잠시 후 질문으로 돌아오겠습니다.

[53:31] 다음 부분으로 넘어간 다음

[53:32] Q&A로 돌아오겠습니다.

[53:33] 음,

[53:35] 좋습니다. 이제 워크샵의 마무리 단계에

[53:39] 접어들고 있고, 남은 시간은

[53:42] Q&A로 열어두겠습니다.

[53:43] 앞으로를 보면

[53:45] 근본적으로 변하고 있는 것은

[53:48] 우리가 방금 살펴본

[53:49] 프롬프트 변경, 컨텍스트 변경,

[53:52] 데이터셋 생성, 평가 실행,

[53:55] 데이터셋 라벨링, 그리고

[53:57] 그 위에 다른 평가를 실행하는

[53:59] 이런 과정들입니다. 처리할 게

[54:01] 정말 많죠? 에이전트 기반

[54:04] 시스템을 구축한다면

[54:07] 팀에서는 아마도

[54:09] AI PM이 어디에 맞는지

[54:10] 궁금해할 것입니다. 그리고 정말

[54:12] 중요한 것은 궁극적으로

[54:15] 제품의 최종 결과를

[54:16] 통제한다는 것입니다. 그래서

[54:18] 더 나아지게 만들 수 있는 모든 것을

[54:21] 실제로 생각해봐야 하는

[54:23] 부분입니다.

[54:24] 저는 평가를 새로운 형태의 요구사항으로

[54:27] 봅니다. 엔지니어링 팀에

[54:30] 가서 PRD 대신

[54:31] 평가를 요구사항으로

[54:32] 줄 수 있다고 상상해보세요. 여기 평가 데이터셋이 있고

[54:35] 시스템을 테스트하기 위해

[54:37] 사용하고 싶은 평가가 있고

[54:39] 이것이 승인 기준입니다.

[54:41] 평가를 팀 전체의

[54:43] 견제와 균형의 방법으로

[54:45] 생각하는 것은 정말 강력합니다.

[54:47] 그리고 이것이 우리가 하는 일의 일부입니다.

[54:50] 관찰 가능성을 실행하고 평가하며

[54:52] 궁극적으로는 같은 플랫폼에서

[54:54] 팀과 함께 이런 워크플로우를 개발할 수 있는

[54:57] 단일 통합 플랫폼을

[54:59] 구축하고자 합니다. Uber,

[55:01] Reddit, Instacart 같은

[55:03] 기술 선도 기업들을 위해

[55:05] 구축했습니다. 실제로

[55:07] DataDog과 Microsoft로부터

[55:08] 투자를 받았습니다. 우리는

[55:11] 시리즈 C 회사이고

[55:12] 이 분야에서 가장 앞서 있습니다.

[55:15] 우리가 구축하고자 하는 전체 목표는

[55:16] 개발부터 프로덕션까지

[55:19] AI 엔지니어링 팀과 함께 할 수 있는

[55:21] 그리고 PM들이 같은 도구를

[55:23] 사용할 수 있는 도구 모음을 제공하는 것입니다.

[55:26] Q&A 전에 간단히

[55:28] QR 코드를 스캔해주세요. 6월 25일

[55:31] 샌프란시스코에 계신다면

[55:33] 실제로 평가에 관한 컨퍼런스를

[55:36] 주최하고 있습니다. 정말 재미있을 것입니다.

[55:38] 실제로 OpenAI,

[55:39] Anthropic 같은 회사들의

[55:42] 훌륭한 AI PM들과 연구원들이

[55:44] 참여합니다. 정말 멋진 것은

[55:47] 이 방에 계신 분들을 위해

[55:49] 음, 무료 독점 티켓을

[55:52] 제공하고 있습니다. 가격이

[55:54] 어제부터 올랐거든요.

[55:56] 저희가 AI 엔지니어

[55:58] 월드 페어의 열렬한 팬이라서

[56:00] 여러분께 무료로 참여할

[56:01] 기회를 드리고 싶었습니다.

[56:04] 그곳에서 뵙게 되면

[56:05] 정말 좋겠네요.

[56:07] QR코드를 스캔해서 무료 코드를 받으실 수 있습니다.

[56:09] 네, 그리고 워크샵에 대해서는

[56:11] 이정도이고, 질문이 있으시면

[56:13] 언제든 받겠습니다. 그리고 뒤에 계신 분이

[56:15] 방금 말씀해 주신 것처럼,

[56:17] 마이크 앞에 줄을 서서

[56:19] 질문해 주시면 카메라가

[56:21] 잘 담을 수 있고, 순서대로

[56:22] 질문을 받아보겠습니다.

[56:24] 감사합니다.

[56:25] 정말 감사합니다.

[56:26] 성함을 말씀해 주시고

[56:27] 네, 제 이름은 로만입니다.

[56:29] 정말 훌륭한 설명이었습니다.

[56:30] 평가 팀 구축에 대한

[56:34] 경험을 공유해 주실 수 있나요?

[56:37] 경험이 있는 전담 인력을

[56:40] 고용하는 것부터 시작해야 할까요,

[56:43] 아니면 프로덕트 매니저가

[56:45] 이 과정을 담당하는 게 나을까요?

[56:47] 어떤 방법이 최선의 방법인가요?

[56:50] 베스트 프랙티스는 무엇인가요?

[56:51] 평가 팀 구축을 위한

[56:53] 베스트 프랙티스에 대해

[56:56] 질문해 주셨는데요. 먼저

[56:57] 궁금한 게 있어서

[56:58] 역질문을 드려도 될까요?

[57:00] 현재 회사에서 어떤 역할을

[57:01] 담당하고 계신지요?

[57:02] 저는 프로덕트 헤드입니다.

[57:03] 프로덕트 헤드시는군요. 완벽합니다.

[57:05] 사실 이런 질문을 정말 자주 받습니다.

[57:08] 첫 번째 AI PM은 어떻게 고용하나요?

[57:10] AI 엔지니어는 어떻게 고용하나요?

[57:12] AI PM이 필요한지 엔지니어가 필요한지

[57:15] 어떻게 알 수 있나요?

[57:17] 이 답에는 몇 가지 단계가 있습니다.

[57:20] 첫째, 프로덕트 헤드로서

[57:22] 많은 프로덕트 헤드들이

[57:25] 저희 플랫폼에서

[57:27] 첫 번째 단계에서는 직접

[57:29] 손을 더럽히는 것을 봅니다.

[57:30] 결국 누군가를 고용해서

[57:32] 일을 시키려면

[57:33] 그들이 할 일이 무엇인지 알아야 합니다.

[57:36] 그래서 제 팀에서의 제 역할은

[57:38] 임원들과 프로덕트 헤드들이

[57:40] 무슨 일이 일어나고 있는지

[57:42] 이해할 수 있도록 제품을

[57:44] 접근 가능하게 만드는 것입니다.

[57:46] 대시보드, 노코드,

[57:49] 로우코드를 만드는 다양한 기능들이 있습니다.

[57:52] 하지만 제가 추천하는 것은

[57:55] 평가를 직접 작성해보면서

[57:57] 고통을 직접 느껴보시고

[57:59] 무엇이 어려운지 깨달아서

[58:01] 엔지니어나 PM을 위한

[58:04] 인터뷰 질문을

[58:05] 구성하는 방법을 알 수 있도록

[58:08] 하는 것입니다. 왜냐하면 저는

[58:09] 여러분의 평가 워크플로우에서

[58:12] 무엇이 어려운지 모르거든요.

[58:14] 평가 작성에 일반적인

[58:16] 도전과제들이 있다는 것만

[58:18] 알고 있어서

[58:19] 직접 고통을 느껴보시고

[58:21] 살펴본 바로는 저희의 평가가 상당히

[58:23] 안 좋았습니다. 휴먼 라벨과 비교했을 때 말이죠.

[58:25] 네.

[58:26] >> 그렇다면 여기서 다음에 무엇을 해야 할까요?

[58:28] 휴먼 라벨에 더 가까워지기 위해

[58:30] 메인 평가의 프롬프팅을 개선하기 위한

[58:32] 다음 단계는 무엇인가요?

[58:35] >> 네, 좋은 질문이네요. 만약 제가 좀 더

[58:38] 실제로 여기서 이 작업을 하고 있다면

[58:41] 실제로 할 일은

[58:44] 그 평가 프롬프트를 가져와서 우리가 방금

[58:47] 했던 것과 유사한 워크플로를 거치는 것입니다

[58:49] 원래 프롬프트의 프롬프트 반복을 위한

[58:51] 프롬프트 말이죠. 다시 말해서

[58:53] 여기서 보는 그 평가 프롬프트를

[58:56] 가져와서 이것을 다시 정의할 수 있습니다

[58:59] 워크플로의 일부를 기본적으로 말하면

[59:01] 친근함이 무엇인지에 대해 정말 엄격하게 하라고

[59:04] 여기서 저는 몇 가지 예시를 추가하지 않았습니다

[59:06] 친근한 텍스트의 예시는 이것이고

[59:08] 로봇적인 텍스트의 예시는 이것이라고 명시하지 않았죠

[59:10] 그래서 그것이 오늘 제 평가에서

[59:12] 명확한 격차입니다. 만약 제가 이것을 보고 있다면

[59:15] 모범 사례를 적용하여 개선할 수 있을 것입니다

[59:17] 또한 저희 제품에서는

[59:20] 평가 작성을 실제로 도와주는

[59:22] 워크플로가 있습니다.

[59:24] 이것은 저희 제품이지만

[59:26] 저희 제품을 꼭 사용할 필요는 없습니다.

[59:28] 어떤 제품이든 사용할 수 있어요.

[59:30] 저는 이것 위에

[59:31] 반복하는 방법을 보여드리겠습니다

[59:34] 사용자들이 실제로 평가 프롬프트를

[59:36] 구축하는 방법입니다. 그래서

[59:40] 친근하거나 로봇적인 텍스트를 감지하는 프롬프트를 작성해 달라고 할 수 있습니다.

[59:46] 이것은 실제로 저희가 제품에서 자체 코파일럿을

[59:48] 사용하는 것입니다. 저희가 구축한

[59:50] 코파일럿은 모범 사례를 이해하고

[59:53] 실제로 첫 번째 프롬프트를 작성하는 데

[59:55] 도움을 줄 수 있고, 시작할 수 있게 해줍니다.

[59:57] 방금 1초 만에 생성한

[59:59] 같은 프롬프트를 가져와서

[01:00:02] 프롬프트 플레이그라운드로 다시 가져가서

[01:00:04] 여기서 더 반복할 수 있습니다.

[01:00:06] 그럼 즉석에서

[01:00:08] 빠르게 해보겠습니다. 여기 프롬프트가 있고

[01:00:10] 들어가서 실제로

[01:00:11] 코파일럿에게 이 프롬프트를

[01:00:14] 최적화해 달라고 요청할 수 있습니다. 그럼

[01:00:17] 계속해서

[01:00:19] 더 엄격하게 만들어 달라고

[01:00:22] 하겠습니다.

[01:00:25] 실제로 LLM 에이전트와

[01:00:28] 코파일럿 에이전트를 사용할 수 있습니다.

[01:00:30] 주목할 점은 실제로 AI 워크플로가

[01:00:32] 위에 필요하다는 것입니다

[01:00:34] 프롬프트를 다시 작성하고, 더 많은 예시를 추가하고

[01:00:36] 그 새로운 프롬프트에서 평가를 다시 실행하는 데 도움을 주는

[01:00:38] 워크플로 말이죠. 덜 중요한 것은

[01:00:40] 첫 번째 시도에서

[01:00:42] 올바르게 하는 것은 확실히 불가능하지만

[01:00:44] 반복할 수 있다는 것이 정말 중요합니다.

[01:00:47] 그것이 우리가 정말 강조하는 것입니다

[01:00:49] 5번 또는 10번 정도

[01:00:50] 시도해야 휴먼 라벨과 일치하는

[01:00:53] 평가를 얻을 수 있을 것입니다. 그리고 그것은 괜찮습니다

[01:00:55] 이러한 시스템들은 정말 복잡하기 때문입니다.

[01:00:57] 중요한 것은

[01:00:58] 적절한 워크플로를 갖추는 것입니다. 네.

[01:01:02] >> 안녕하세요, 저는 조티입니다. Arize에서도

[01:01:06] BERT나 Albert 같은 것을 사용한

[01:01:08] 모델 기반 평가를 허용하나요

[01:01:11] LLM을 판사로 사용하는 것이 아니라

[01:01:13] BERT나 Albert를 사용해서

[01:01:15] 예측 점수 같은 거 말씀하시는 건가요?

[01:01:16] >> 네, 좋은 질문이네요. 사실 저희는 정말로

[01:01:19] 간단히 말하면 네, 그런 기능을 제공하고 있습니다.

[01:01:21] 제가 어떤 의미인지 보여드리겠습니다.

[01:01:23] 그래서 음... 그래서

[01:01:25] Arize에 들어가면 실제로

[01:01:28] 원하는 평가 모델을 설정할 수 있습니다.

[01:01:31] 보시는 것처럼 OpenAI, Azure,

[01:01:33] Google이 있지만, 커스텀 모델

[01:01:36] 엔드포인트도 추가할 수 있습니다.

[01:01:38] 기본적으로 이것은 요청을

[01:01:40] 채팅 완료 형태로 구조화하지만

[01:01:42] 필요하다면 임의의 API로 만들 수 있고

[01:01:44] BERT 모델이라고 하고 엔드포인트의

[01:01:46] 이름이 무엇이든 그것을 가리키면

[01:01:48] 평가 생성기에서도 그 모델을

[01:01:50] 참조할 수 있게 됩니다. 그래서

[01:01:52] 이것은 음... 여기에 테스트라고 입력하고

[01:01:55] 다음 흐름으로 넘어가겠습니다. 그리고

[01:01:58] 여기에 들어가면 보시게 될 텐데

[01:02:00] 원하는 모델 제공업체를 사용할 수 있습니다.

[01:02:02] 간단히 말하면 네, 어떤 모델로든

[01:02:04] 점수를 생성할 수 있습니다.

[01:02:07] >> 좋네요.

[01:02:10] >> 좋습니다. 음, 아, 질문이 하나 더 있네요.

[01:02:12] 아니 죄송합니다, 질문이 더

[01:02:14] 있네요. 네, 진행하세요.

[01:02:15] >> 이 질문을 하나 더 다뤄보겠습니다.

[01:02:17] 음, 아마 앱을 구축해본 사람들이

[01:02:20] 비슷한 생각을 하고 있을 거라고 생각하는데

[01:02:22] 이게 좀 순진한 질문일 수도 있지만,

[01:02:24] 이미 인간이 라벨링한 정보가 있다면,

[01:02:28] 그리고 친화성 점수에서

[01:02:30] 나쁜 매치를 보고 있다면,

[01:02:32] 그 점수를 높이려고 노력하고

[01:02:35] 그 다음에 더 많은 케이스들로

[01:02:37] 외삽할 거라고 가정해야 하는 건가요?

[01:02:42] 그리고 그 샘플링이 더 넓은

[01:02:44] 범위에서도 유지된다고 가정하는 건가요.

[01:02:46] 네.

[01:02:47] >> 그 관계가

[01:02:48] 저에게는 불분명해서요.

[01:02:49] >> 아주 좋은 질문입니다. 그래서 음... 그래서

[01:02:52] 이걸 다시 표현하면 기본적으로

[01:02:54] 내 데이터셋이 전체 데이터를 어느 정도

[01:02:57] 대표한다는 걸 어떻게 알 수 있느냐는

[01:02:59] 거죠.

[01:03:00] >> 맞습니다. 아니면 시간이 지나면서 변화하거나

[01:03:01] >> 변화하죠. 네. 맞습니다. 그래서 음...

[01:03:04] 정말 좋은 지적입니다.

[01:03:06] 제품에서 아직 이 기능은 없지만

[01:03:08] 다음 주쯤에 출시될 예정인데

[01:03:09] 데이터셋에 지속적으로 데이터를

[01:03:12] 추가하는 워크플로우가 있을 거예요

[01:03:14] 가지고 있을 수 있는 라벨을 사용해서 말이죠.

[01:03:16] 그래서 말할 수 있는 건... 음, 하나는

[01:03:19] 실제로 이야기하지 않은 것 중 하나는

[01:03:20] 프로덕션 데이터를 어떻게 평가하는가인데

[01:03:23] 이런 평가를 데이터셋에서만이 아니라

[01:03:25] 시간이 지나면서 프로젝트에 들어오는

[01:03:27] 모든 데이터에서 실행해서

[01:03:29] 자동으로 라벨링하고 분류할 수 있습니다

[01:03:32] 프로덕션 데이터를 말이죠. 그래서

[01:03:34] 이걸 사용해서 데이터셋을 계속

[01:03:36] 구축할 수 있어요. 이게 전에 본 예시인지

[01:03:37] 아닌지 또는 이게... 음, 이걸 본질적으로

[01:03:40] 더 큰 규모로 샘플링할 수 있는 방법으로

[01:03:42] 프로덕션에서 생각해보세요

[01:03:44] >> 그리고 그건 지속적으로 샘플링하고

[01:03:46] 인간이 라벨링하는 제안된 워크플로우인가요

[01:03:49] 시간이 지나면서 매칭을 확인하기 위해서요.

[01:03:51] >> 정확합니다. 그리고 기본적으로

[01:03:53] 들어가서 인간 라벨이 동의하지 않는 곳을

[01:03:55] 프로덕션 데이터에서 LLM과 일치하지 않는 경우,

[01:03:58] 해당 사례들을 어려운 예시로 데이터셋에 추가하고 싶을 수 있습니다.

[01:04:00] 맞습니다.

[01:04:02] 그리고 실제로 이 제품에도

[01:04:04] 예시가 어려운 예시인지 판단할 수 있는 방법을

[01:04:06] 구축할 예정입니다.

[01:04:08] LLM 신뢰도 점수를 사용해서 말이죠.

[01:04:11] 네, 그런데 죄송한데 '어려운 예시'라는 게

[01:04:13] 아주 엄격하게 해석하면 어떤 의미인가요?

[01:04:15] 어려운 예시라는 건 평가 관점에서 어려운 것을 의미합니다.

[01:04:18] 예를 들어 친근한지 아닌지는

[01:04:20] 경계선상에 있을 수 있잖아요?

[01:04:22] 맞죠?

[01:04:22] 아, 그러니까 주관적이거나

[01:04:23]

[01:04:24] 주관적인 거죠. 맞습니다.

[01:04:27] 질문을 좀 정리해보면,

[01:04:28] 데이터셋은 시간이 지나면서 계속 변화하는 속성을 갖고 있습니다.

[01:04:31] 그리고 개선을 위한 어려운 예시들의

[01:04:34] 골든 데이터셋을 제공해서

[01:04:36] 데이터셋 구축에 도움이 되는 도구가 정말 필요합니다.

[01:04:38]

[01:04:41] 어려운 예시란 처음부터 제대로 했는지

[01:04:43] 확실하지 않은 경우를 의미합니다.

[01:04:44]

[01:04:45] 네, 맞습니다. 감사합니다.

[01:04:46] 좋은 질문이네요.

[01:04:50] 네.

[01:04:51] 안녕하세요, 제 이름은 빅토리아 마틴입니다.

[01:04:53] 발표해주셔서 정말 감사합니다.

[01:04:55] 제가 겪고 있는 문제 중 하나는

[01:04:56] 함께 일하는 제품 관리자들로부터

[01:04:58] 생성형 AI에 대한 많은 회의론과

[01:04:59] 우리가 제공하는 평가에 대한 신뢰를

[01:05:01] 구축하려고 노력하는 것입니다.

[01:05:03] 네.

[01:05:04] 다른 PM들과 일하면서 어떤 가이던스를 받았는지,

[01:05:07] 또는 총 평가 횟수에 대한 가이던스를

[01:05:08] 받았는지 궁금합니다.

[01:05:10] 이 평가 세트에 대해 확신을 가질 수 있다고

[01:05:12] 말할 수 있을 때까지 실행해야 한다고 생각하는

[01:05:15] 평가 횟수에 대해 말이죠.

[01:05:18] 네, 정말 좋은 질문입니다.

[01:05:21] 질문에는 두 가지 구성 요소가 있다고 생각합니다.

[01:05:22] 평가의 양과 질이 있죠.

[01:05:24] 충분한 평가를 실행했는지 또는

[01:05:27] 충분한 평가를 갖고 있는지,

[01:05:29] 그리고 그 평가들이 실제로

[01:05:31] 데이터의 문제점들을 찾아낼 수 있을 만큼

[01:05:34] 충분히 좋은지 어떻게 알 수 있을까요?

[01:05:38] 이것도 어쩌면 좀 깨진 기록 같지만

[01:05:39] 이것도 약간의 반복 과정이라고 말하고 싶습니다.

[01:05:41] 작은 평가 세트로 시작하고 싶을 것입니다.

[01:05:44] 실제로 이에 대한 다이어그램이 있습니다.

[01:05:47] 잠깐만요, 그것을 불러오겠습니다.

[01:05:48]

[01:05:51] 여기서 보시는 것처럼 이것은 루프 형태로 의도되었습니다.

[01:05:55] 개발 단계에서 시작하여

[01:05:57] CSV 데이터에서 실행할 것입니다.

[01:06:00] 아마 손으로 만든 것 같은 데이터로요.

[01:06:02] 방금 제가 구축한 것이 개발이었다고 주장하고 싶습니다.

[01:06:05] 10개의 예시가 있지만 통계적으로 유의미하지 않고

[01:06:07]

[01:06:09] 팀이 이것을 출시하도록 설득하지는 못할 것입니다.

[01:06:11]

[01:06:12] 하지만 제가 할 수 있는 것은 데이터셋을 큐레이션하고

[01:06:15] 계속 반복하며 실험을 계속 재실행하는 것입니다.

[01:06:18] 충분히 확신을 가질 때까지 그리고

[01:06:20] 전체 팀이 동의할 때까지

[01:06:22] 프로덕션에 출시하기 전까지 말이죠.

[01:06:24] 그리고 프로덕션에 들어가면

[01:06:26] 다시 같은 작업을 하는데, 다만 이제는

[01:06:28] 프로덕션 데이터에서 하는 것입니다.

[01:06:30] 그리고 그 중 일부를 가져와서

[01:06:31] 예시들을 개발로 다시 투입합니다.

[01:06:33] 실제 상황에서 이것이 어떻게 작동하는지

[01:06:36] 전술적인 예를 들어보겠습니다.

[01:06:37] 자율주행차의 경우, 제가 크루즈에 합류했을 때

[01:06:40] 한 블록만 가도 운전자가

[01:06:42] 차량을 다시 제어해야 했습니다.

[01:06:44] 그때는 정말 한 블록도

[01:06:46] 제대로 주행할 수 없었죠.

[01:06:47] 길을 따라 운전할 수도 없었습니다.

[01:06:49] 웨이모도 마찬가지였습니다.

[01:06:50] 모든 회사가 이런 시스템 단계에 있었고

[01:06:53] 결국 우리는 직진 도로에서

[01:06:55] 주행할 수 있게 되었습니다.

[01:06:57] 좋습니다. 하지만 차량이 직진만 할 수는 없죠?

[01:06:59] 좌회전을 해야 합니다.

[01:07:01] 그래서 결국 우리는 직진에서

[01:07:03] 완전 자율주행을 달성했습니다.

[01:07:05] 도로에 문제가 없는 직진 상황에서 말이죠.

[01:07:08] 그런데 좌회전을 해야 할 때

[01:07:09] 차량이 멈춰서 인간이 다시

[01:07:11] 제어해야 했습니다.

[01:07:13] 그래서 우리가 한 일은

[01:07:15] 좌회전 데이터셋을 구축해서

[01:07:17] 좌회전을 계속 개선하는 것이었습니다.

[01:07:19] 결국 차량이 좌회전을 할 수 있게 되었지만

[01:07:20] 보행자가 인도에 있으면

[01:07:22] 다시 문제가 생겼습니다.

[01:07:24] 그래서 우리는 보행자가 인도에 있는

[01:07:25] 좌회전 상황의 데이터셋을 새로 만들어야 했죠.

[01:07:28] 결국 답은 평가 데이터셋 구축이

[01:07:31] 시간이 걸리는 작업이라는 것입니다.

[01:07:33] 어떤 시나리오가 어려운지는

[01:07:34] 실제로 마주쳐봐야 알 수 있습니다.

[01:07:37] 그래서 프로덕션에 배포하려면

[01:07:39] 팀 전체가 확신을 가질 때까지

[01:07:41] 이 루프를 계속 사용하라고 권합니다.

[01:07:43] '이 정도면 출시할 만하다'고 생각하고

[01:07:45] 프로덕션에 배포한 후에도

[01:07:47] 개선할 새로운 예시들을 찾게 될 것임을

[01:07:49] 받아들이세요.

[01:07:51] 이것은 비즈니스에 따라서도 많이 달라집니다.

[01:07:52] 의료나 법률 기술 분야라면

[01:07:54] 여행 에이전트를 만드는 것보다

[01:07:55] 더 높은 기준이 필요할 수 있습니다.

[01:07:57] 네, 맞습니다.

[01:07:59] 네.

[01:08:01] 안녕하세요, 제 이름은 마타이입니다. 질문이 있습니다.

[01:08:04] 제가 이해한 바로는 AI 플랫폼이

[01:08:08] 프롬프트를 받아서

[01:08:11] 그 프롬프트를 모델에 직접 보내는

[01:08:13] 방식으로 작동하는 것 같은데, 맞나요?

[01:08:16] 맞습니다.

[01:08:16] 네.

[01:08:18] 컨텍스트와 데이터와 함께요.

[01:08:19] 네, 물론입니다.

[01:08:21] 플랫폼에 도구들을 포팅할 수 있는

[01:08:24] 가능성이 있다고 하셨는데, 맞죠.

[01:08:26] 맞습니다.

[01:08:26] 그런데 전체 시스템 테스트는 어떤가요?

[01:08:28] 저희는 이미 전체 워크플로우를

[01:08:31] 보강하는 플로우들을 가지고 있습니다.

[01:08:34] 도구 호출 외에도 말이죠.

[01:08:36] 네.

[01:08:36] 그리고 이것들이

[01:08:38] 최종 결과물이 어떻게 보일지에

[01:08:41] 상당히 중요한 영향을 미칩니다.

[01:08:43] 저희가 가진 모든 것을 거쳐가는

[01:08:46] 데이터셋에서 실제로 저희 시스템을 호출하는

[01:08:49] 커스텀 러너에서

[01:08:51] 그런 평가들을 실행할 방법이 있을까요?

[01:08:54] 이 세션 후에 저를 찾아오세요.

[01:08:56] 대화를 나눠봅시다.

[01:08:57] 그게 짧은 답변입니다.

[01:09:00] 저희는 그런 도구들과 시스템을

[01:09:01] 갖추고 있습니다. 말씀하신 도구 호출처럼요.

[01:09:03] 보셨겠지만, 엔드투엔드 에이전트의 경우에는

[01:09:05] 실제로 몇 가지를 구축하고 있고

[01:09:06] 그것에 대해 얘기하고 싶습니다.

[01:09:08] 좋은 질문이네요. 나중에 찾아뵙겠습니다.

[01:09:09] 네.

[01:09:10] 네.

[01:09:12] 네, 물론입니다. 좌회전 예시로 돌아가서

[01:09:14] 그리고 PRD에서

[01:09:17] 평가로의 전환에 대한 얘기뿐만 아니라

[01:09:19] 기능 개발의 라이프사이클이 어떻게 생겼는지

[01:09:22] 그리고 특히 기능의 관계는 물론

[01:09:24] 소유권과 책임감 측면에서

[01:09:26] 팀과의 관계가 어떤지 궁금합니다.

[01:09:28] 네.

[01:09:31] 네.

[01:09:31] 네. 좋은 질문입니다.

[01:09:34] 이 새로운 세상에서 AI 엔지니어들과 어떻게 일하는지는

[01:09:36] 꽤 흥미로운 주제인데

[01:09:37] 이 발표의 주제는 아니지만

[01:09:39] 정말 관련성 높은

[01:09:41] 질문이고 더 자세히

[01:09:43] 이야기하고 싶은 주제이기도 합니다.

[01:09:46] 두 가지 답변이 떠오르네요.

[01:09:48] 하나는 개발 사이클이

[01:09:49] 훨씬 빨라졌다는 것입니다.

[01:09:53] 이러한 모델들이 발전하는 속도와

[01:09:54] 이러한 시스템들이 발전하는 속도가

[01:09:57] 프로토타입에서 프로덕션으로 넘어가는 것이

[01:10:00] 실제로 그 어느 때보다도

[01:10:02] 빨라졌습니다.

[01:10:05] 이것은 제가 개인적으로 관찰한 것으로

[01:10:07] 말씀드릴 수 있는 한 가지 사실입니다.

[01:10:10] 아이디어에서 업데이트된 프롬프트로

[01:10:13] 그리고 그 프롬프트를 배포하는 것까지

[01:10:15] 테스트를 포함해서 하루 만에

[01:10:17] 할 수 있다고 느낍니다.

[01:10:19] 이는 일반적인 소프트웨어 개발

[01:10:21] 사이클에서는 들어본 적이 없는 일이라고 생각합니다.

[01:10:23] 이것이 팀과 함께 반복하는 방식이

[01:10:26] 훨씬 빨라졌다는 한 가지 관찰점입니다.

[01:10:30] 두 번째로는

[01:10:32] 책임에 관해서는

[01:10:35] 저는 이것을 다음과 같이 봅니다.

[01:10:37] 제품 매니저는 최종 제품의

[01:10:40] 경험의 관리자입니다.

[01:10:42] 즉, 평가가 제대로 이루어지고

[01:10:44] 팀이 개선할 수 있는 휴먼 라벨을 갖도록 하는 것

[01:10:47] 이것이 제품 매니저가 집중해야 할

[01:10:49] 매우 탄탄한 영역입니다.

[01:10:51] 개발팀의 나머지 팀을 위해

[01:10:53] 데이터가 제대로 준비되어 있는지 확인하는 것이죠.

[01:10:55] 동시에 저는

[01:10:58] 팀의 PM이지만 Cursor에서

[01:11:00] 직접 몇 가지를 작성하고 있습니다.

[01:11:02] 이러한 모델 중 하나를 사용해서 실제로 들어가서

[01:11:04] 코드베이스 자체와 대화할 수 있다는 것,

[01:11:07] 이것이 AI 제품 매니저들에게

[01:11:09] 하나의 기대사항이 되기 시작했다고 생각합니다.

[01:11:11] 코드에 대한 이해력을 갖고

[01:11:13] 이러한 도구들을 사용할 수 있어야 한다는 것이죠.

[01:11:15] 정말로 이 발표가 끝나면

[01:11:17] 돌아가서 제가 앞서

[01:11:18] 망쳐놓은 것을 고치려고 합니다.

[01:11:20] 제가 그럴 수 있는 이유는

[01:11:22] 제가 시스템에 프롬프트를 주는 방식이

[01:11:23] 그렇게 정교하지 않기 때문입니다.

[01:11:26] 어제 저는 시스템에게

[01:11:28] 서버 위에서 여행 일정을 생성하는

[01:11:30] 스크립트를 만들어 달라고 했습니다.

[01:11:31] 15개 정도의 예시가 필요하다고 했더니

[01:11:33] 그냥 해주더라고요, 맞죠?

[01:11:36] 그런 것들이 예전에는 불가능했습니다.

[01:11:38] 그래서 PM은 최종 제품 경험에 대한

[01:11:40] 책임을 지지만, 동시에 PM들은

[01:11:43] 그 어느 때보다도 더 큰 영향력을 갖게 되었습니다.

[01:11:45] 아마 제품 관리 전체 직업 여정에서

[01:11:47] 가장 큰 변화일 거예요. 왜냐하면

[01:11:49] 이제 더 이상 엔지니어링 팀에

[01:11:51] 의존하지 않고 원하는 것을 구현할 수

[01:11:53] 있어요. 그냥 직접 할 수 있거든요.

[01:11:55] 음, 그렇게 해야 하는지는 다른

[01:11:57] 문제이고, 그건 팀과

[01:11:59] 논의해야 할 부분이에요. 하지만

[01:12:00] 중요한 건 이제 그렇게 할 수 있다는

[01:12:02] 사실이고, 이건 전에는 불가능했던

[01:12:05] 일이에요. 그래서 저는 PM들이

[01:12:08] 사람들이 말해왔던 역할의 경계를

[01:12:10] 뛰어넘고 그것이 어디로 이끌어주는지

[01:12:13] 확인해보라고 권하고 싶어요. 그래서

[01:12:16] 길게 말하자면, 여러분의 경험은

[01:12:18] 팀과의 경계에 따라 다를 수

[01:12:19] 있겠지만, 이 시점에서

[01:12:20] 그런 경계를 재정의해보는 걸

[01:12:22] 추천해요.

[01:12:24] >> 네, 맞아요.

[01:12:25] >> 그 얘기에서 조금 벗어나서,

[01:12:27] 이 주제와는 약간 다르지만,

[01:12:29] 좀 더 기술적으로 발전하고 싶은

[01:12:31] 제품 관리자로서 AI 엔지니어들과

[01:12:34] 일할 때는 어떤 모습이어야 할까요?

[01:12:36] >> 네.

[01:12:37] >> 제가 현재 코드베이스에 대한

[01:12:38] 접근이 매우 제한적인 환경에서

[01:12:40] 일하고 있거든요. 커서를 사용해서

[01:12:42] 데이터 작업용 파이썬은 작성하지만,

[01:12:44] 코드를 직접 살펴보거나

[01:12:46] 분석할 수 있는 접근권한이

[01:12:48] 없어요. 그래서 PM으로서 어떻게

[01:12:50] 발전할 수 있는지, 그리고 우리 회사

[01:12:52] 문화를 그런 방향으로

[01:12:54] 이끌어갈 수 있는 방법에 대한

[01:12:56] 조언을 듣고 싶어요.

[01:12:57] >> 네, 좋은 질문이네요. 사실 저도

[01:13:00] 후속 질문이 있어요. 괜찮다면

[01:13:02] 여기 있는 분들께 물어보고 싶은데,

[01:13:03] 회사 규모가 어떻게 되나요? 회사명은

[01:13:05] 말씀하지 않으셔도 되고, 그냥

[01:13:06] 규모가 궁금해요.

[01:13:07] >> 저희는 약 300명 정도예요. 네. 그런데

[01:13:07] 기술팀은 아마 그 중 3분의 1 정도?

[01:13:10] >> 그렇군요. 엔지니어가 약 100명,

[01:13:12] 전체 300명이면요. 그리고 회사에

[01:13:13] 아직 코드 접근권한을 가진 기존

[01:13:15] 제품 관리자들이 있나요?

[01:13:18] >> 아니요, 저희는 PM팀이 새로

[01:13:21] 구성된 팀이에요.

[01:13:24] >> 알겠습니다. 좋은 질문 감사해요.

[01:13:27] 저희가 시작한 한 가지 방법은

[01:13:30] 회사의 공개적인 포럼을

[01:13:32] 활용하는 거예요. 음, 죄송해요,

[01:13:33] 뒤쪽에 앉아계신 저희 CEO를

[01:13:35] 공개하게 되네요.

[01:13:37] [웃음]

[01:13:39] 저희 Arize에 대한 질문이 있으시면

[01:13:42] 그분과 얘기해보세요.

[01:13:44] 제가 이 얘기를 하는 이유는

[01:13:45] 오늘 저희 타운홀을 놓쳤는데,

[01:13:47] 들어보니 사람들이 계속

[01:13:48] 자신들이 개발 중인 AI 데모를

[01:13:50] 보여주는 시간이었다고 하더라고요.

[01:13:52] 이게 정말 강력한 이유는

[01:13:54] 회사 전체가 무엇이 가능한지에

[01:13:56] 대해 활발해질 수 있기

[01:13:58] 때문이에요. 솔직히 말하면,

[01:14:00] 오늘날 대부분의 팀들이 이런

[01:14:02] 도구들의 경계를 충분히 탐험하지

[01:14:06] 못하고 있을 가능성이 높아요.

[01:14:08] 그래서 이런 토크에 참여하고

[01:14:10] 평가를 어떻게 실행하는지

[01:14:12] 보는 것이야말로

[01:14:14] 정말 중요한 거죠.

[01:14:16] 실험에 어떤 요소가 들어가는지

[01:14:18] 알고 팀을 앞으로 이끄는

[01:14:20] 사람이 될 수 있다는 것은

[01:14:24] 정말 강력하다고 생각하고

[01:14:26] 이를 정말 협력적인 방식으로

[01:14:27] 할 수 있다고 봅니다. 제 생각엔

[01:14:30] PM으로서 우리의 역할은 팀에

[01:14:32] 영향력을 행사하고 제품

[01:14:33] 방향에 영향을 주는 것이라고

[01:14:35] 생각합니다. PM들이 조직에서

[01:14:36] 더 기술적이어야 한다는

[01:14:38] 것에 영향을 줄 기회가 있고

[01:14:40] 무언가를 만들어서 그들에게

[01:14:41] 보여줄 수 있고 여러분이 만든 것으로

[01:14:44] 나머지 팀에게 인상을 남길 수 있습니다.

[01:14:45] 그것이 제 개인적인 조언입니다. 네.

[01:14:46] >> 네, 해보세요. [웃음]

[01:14:48] >> 사실 가능한지 궁금한 질문이 있는데요.

[01:14:51] AI가 어떻게 팀 구조를

[01:14:53] 바꿀 것이라고 생각하시나요? 지금은

[01:14:56] 예를 들어

[01:14:58] 엔지니어 10명, 프로덕트 매니저 1명,

[01:15:00] 디자이너 1명 이런 식이잖아요.

[01:15:01] >> 5년 후엔 어떻게 될까요?

[01:15:03] 프로덕트 매니저 1명, 엔지니어 1명,

[01:15:05] 디자이너 1명으로 될까요?

[01:15:07]

[01:15:09]

[01:15:10] >> 이 질문은 당신이 답해야죠.

[01:15:12] >> 마이크로 하고 싶으면요.

[01:15:13]

[01:15:14] >> [웃음]

[01:15:15] >> 간단히 말하면 실제로

[01:15:24] 코드를 다루는 커서가 있으니 PM들이

[01:15:28] 질문을 하느라 시간을 쓰는 일이

[01:15:31] 너무 많아요. 얼마나 자주 우리가

[01:15:34] 커서에게 묻는지 아시잖아요.

[01:15:37] 그러니까 거기서부터 시작해서

[01:15:39] 코드베이스를 커서로 열어서

[01:15:43] PM들에게 제공하세요. 그리고

[01:15:45] 얼마 전에 우리가 코드베이스에서

[01:15:48] 커서로 PRD를 작성했어요. 그래서

[01:15:50] 거기서 시작하겠습니다.

[01:15:51] >> 네.

[01:15:52] >> 지금 앞을 내다보는 것은

[01:15:54] 어렵습니다. 그냥 많은 일자리가

[01:15:56] 변할 것이라고 생각해요. 우리는

[01:15:58] AI 커서 사용을 회사 전체에

[01:16:01] 가능한 한 확산시키려고 노력하고 있어요.

[01:16:03]

[01:16:04] >> 네, 마케팅 팀에서도

[01:16:05] 커서를 사용하는 사람들이 있다고

[01:16:07] 들었어요. 꽤 멋진 일이죠.

[01:16:10] >> 네.

[01:16:12] >> 후속 질문이요.

[01:16:13] >> 지금 프로덕트가 더 기술자

[01:16:16] 역할을 한다고 말씀하셨는데

[01:16:19] 기술자들도 더 프로덕트

[01:16:21] 역할을 하게 될 것이라고 보시나요?

[01:16:25] >> 정말 좋은 지적인데요.

[01:16:26] 무언가를 만드는 비용이

[01:16:29] 내려갈 때, 그리고 실제로 내려갔을 때

[01:16:33] 무엇을 만들어야 하는지가

[01:16:35] 정말 중요하고 가치 있는 일이 됩니다.

[01:16:36] 역사적으로 그것은

[01:16:38] 프로덕트 담당자나 비즈니스

[01:16:40] 담당자가 "우리 고객들이

[01:16:41] 원하는 것이 이거야. 이걸

[01:16:43] 만들어보자"라고 하는 것이었어요.

[01:16:45] 이제 우리는 프로덕트 담당자들에게

[01:16:46] "그냥 이걸 만들어보세요"라고

[01:16:48] 말하고 있어요. 그러니까 빌더들은

[01:16:50] "잠깐, 그럼 내 일은 뭐야?"라고

[01:16:53] 생각하게 됩니다. 그리고 그것을

[01:16:54] 바라보는 좋은 방법이 있다고

[01:16:56] 생각하는데, 제가 가진

[01:16:58] 멘탈 프레임워크는 만약 회사에

[01:17:00] 더 이상 역할이 없다면 어떨까

[01:17:02] 마치 야구카드 같은 거죠

[01:17:04] 스킬을 가지고 있는 것처럼요. 대신 스킬 스택을 가지고 있다고 상상해보세요

[01:17:06] 예를 들어, 저는 정말로 고객과 대화하는 것을 좋아하고

[01:17:08] 약간의 코딩도 즐기지만

[01:17:09] 프로덕션 장애가 발생했을 때

[01:17:11] 책임지고 싶지는 않아요

[01:17:13] 하지만 저는 장담할 수 있어요

[01:17:14] 고객과 대화하는 것을 싫어하고

[01:17:16] 오직 고품질 코드만 배포하고 싶어하며

[01:17:18] 문제가 발생했을 때 책임지고 싶어하는

[01:17:20] 사람을 찾을 수 있다는 걸요

[01:17:21] 그리고 저는 여러분의 회사를

[01:17:23] 정말 상호 보완적인 스킬 스택을 가지도록

[01:17:25] 구조화하고 싶어요

[01:17:28] '나는 이것을 하고 이것이 내 일이며'

[01:17:30] '저것은 하지 않는다'고 하는 사람들과는 달리요

[01:17:32] 네, 그렇습니다

[01:17:34] 그와 관련된 이야기가 하나 있어요

[01:17:36] 저희는 human in the loop을 테스트하고 있는데

[01:17:37] 몇 가지 다른 방식으로요

[01:17:40] 기본적으로 저희는

[01:17:42] 인간을 에이전트의 도구로 활용하는 방법을 테스트하고 있어요

[01:17:44] 그래서 저희는

[01:17:47] 에이전트가 회계 시스템에서

[01:17:48] 사용할 수 없는 무언가가 필요할 때

[01:17:49] CFO에게 갑니다. CFO가

[01:17:51] 도구로 등록되어 있기 때문에

[01:17:54] 슬랙 메시지를 보내고

[01:17:55] 답변을 받아서 계속 진행하죠

[01:17:57] 이것은 방금 말씀하신

[01:17:59] 스킬을 정의하고

[01:18:01] 보유한 리소스를 정의하는 것과 매핑되죠

[01:18:04] 완전히 구체화되지는 않았지만

[01:18:06] 에이전트에게 컨텍스트를 제공하는 데

[01:18:07] 효과적으로 작동하고 있어요

[01:18:10] 인간만이 가진 것들에 대해서요

[01:18:11] 네

[01:18:12] 정확히요

[01:18:13] 그렇다면 이 분의 회사는

[01:18:15] 에이전트를 광범위하게 사용하고 계시는 것 같은데

[01:18:17] 인간이 승인하는 방식이군요

[01:18:19] 승인자 워크플로우가 있으신 거죠

[01:18:20] 에이전트가 인간의 도구가 되는 방법보다는

[01:18:23] 저희는 이를 뒤집어서

[01:18:25] 에이전트가 모든 것을

[01:18:26] 할 수 있다면 어떨까 하고

[01:18:27] 생각하고 있어요

[01:18:28] 그리고 할 수 없는 부분에 대해서는

[01:18:30] 인간을 도구로 활용하는 거죠. CFO가

[01:18:33] AI 에이전트의 도구인 셈이에요

[01:18:34] 흥미롭네요

[01:18:36] 저희가 대화해야겠어요. 정말 멋진

[01:18:37] 워크플로우네요. 꼭 더 물어보겠습니다

[01:18:38] 정말 멋져요

[01:18:39] 음

[01:18:41] 좋네요, 음, 기꺼이

[01:18:45] 어느 정도는 맞습니다. 인간이

[01:18:47] 루프에서 이것이 좋은지 나쁜지를 승인하는 것이고

[01:18:49] 그런 식으로 생각할 수 있죠

[01:18:52] 네

[01:18:52] 네. 실제로

[01:18:54] 구현하는 것이 어떤 것인지에 대해 질문이 있어요

[01:18:57] 트레이스를 Arize로 보내는 것 말이에요

[01:18:59] 제가 알기로는 Arize에

[01:19:01] 오픈 추론이라는 기능이 있어서

[01:19:04] 여러 다른

[01:19:05] 여러 다른

[01:19:07] 프로바이더로부터 트레이스를 캡처할 수 있게 해줍니다

[01:19:10] 하지만 제한사항과

[01:19:12] 제약사항, 그리고 여러분이 가진 의견은

[01:19:14] evaluation이 어떻게 구조화되어야 하는지에 대해

[01:19:17] 실제로 플랫폼을 활용해서

[01:19:18] 이러한 작업들을 수행하고

[01:19:20] 예를 들어 evaluation을 평가하거나

[01:19:23] 또는 수치적으로

[01:19:26] 그저

[01:19:28] 수치적으로

[01:19:29] evaluation에서 그래프를 생성하고

[01:19:32] 결과를 도출할 수 있도록 하는 것은 무엇인가요

[01:19:34] 좋아요, 명확해요

[01:19:36] 그럼 후속 질문을 하나 해도 될까요?

[01:19:37] 당신의 질문은 에이전트를 사용해서

[01:19:40] 플랫폼의 일부 워크플로우를 처리하는 방법에 관한 것이었나요

[01:19:42] 아니면 제가 놓친 부분이 있나요?

[01:19:44]

[01:19:44] 음, 그 질문은

[01:19:46] 이런 거죠

[01:19:48] 어떤 종류의 출력물이

[01:19:51] 어떤 종류의 평가를 Arize에서

[01:19:54] 엔지니어들과 제품팀으로부터

[01:19:57] 기대하는지에 대한 것이요

[01:19:58] 로그를 전송하고 계시잖아요, 맞죠?

[01:20:00] 네. 맞습니다. 그 로그들로부터 무엇을

[01:20:02] 기대하시는지, 이 플로우가

[01:20:05] 작동하게 하려면 말이죠?

[01:20:06] 알겠습니다. 네, 정말 좋은 지적입니다.

[01:20:08] 코드에서 보시게 될 텐데

[01:20:10] 데모에서 조금 건너뛴 부분이 있어요

[01:20:13] 바로 플랫폼을 사용하기 위해

[01:20:15] 로그를 올바른 곳에 배치하는 방법입니다.

[01:20:18] 안타깝게도 이 페이지가

[01:20:20] 로딩되지 않네요. 잠깐만요

[01:20:23] 됐습니다. 슬랙 채널에도

[01:20:25] 공유하겠습니다. 이것이

[01:20:26] 앞서 말씀드린

[01:20:29] 트레이스와 스팬에 관한 내용이에요.

[01:20:30] 여러분 팀에서 이미 로그나

[01:20:32] 트레이스와 스팬을 가지고 계실 가능성이 높습니다.

[01:20:35] DataDog이나 Grafana 같은

[01:20:37] 다른 플랫폼을 사용하고 계실 수도 있고요.

[01:20:38] 저희가 하는 일은 동일한 트레이스와

[01:20:40] 스팬을 가져와서 더 많은 메타데이터로

[01:20:43] 보강하고, 플랫폼이

[01:20:45] 어떤 컬럼을 찾아봐야 하는지 알 수 있도록

[01:20:47] 구조화하는 것입니다

[01:20:49] 플랫폼에서 보신 데이터를 렌더링하기 위해서요.

[01:20:51] 실제로는 동일한 접근 방식을 사용하는 거죠.

[01:20:54] 저희는 OpenTelemetry라는

[01:20:56] 컨벤션 위에 구축되었습니다

[01:20:59] 이는 트레이싱을 위한

[01:21:01] 오픈소스 표준입니다.

[01:21:03] 저희는 실제로 OTel 트레이싱과

[01:21:07] 자체 구축한 자동 계측을 사용하는데

[01:21:09] 전혀 벤더 락인이 없습니다.

[01:21:11] 저희 플랫폼으로 계측을 완료하면

[01:21:13] 저희 패키지인 OpenInference를 사용해서

[01:21:15]

[01:21:18] 실제로 어떤 유형의 에이전트 프레임워크를

[01:21:20] 구축하든 상관없이

[01:21:22] 즉시 로그가 표시됩니다

[01:21:24] 그리고 네, 그것을 유지할 수 있어요

[01:21:26] 제가 의미하는 바를 보여드리겠습니다.

[01:21:28] 예를 들어 LangGraph로

[01:21:30] 개발하고 있다면

[01:21:33] 정말 간단합니다. pip install

[01:21:36] arize phoenix arize otel만 하면 되고

[01:21:39] langchain_instrument라는

[01:21:42] 한 줄의 코드를 호출하면

[01:21:44] 코드에서 어디를 찾아야 할지 알고

[01:21:46] 로그를 구조화합니다

[01:21:49] 로그에 더 구체적인 것을 추가하고 싶다면

[01:21:51] 함수 데코레이터를 추가할 수 있습니다

[01:21:52] 이것은 기본적으로

[01:21:54] 특정 함수를 캡처하는 방법입니다

[01:21:57] 기본 범위에 포함되지 않은

[01:21:59]

[01:22:01]

[01:22:02] 그리고 평가에 관해서는

[01:22:03] 실제 데이터 입력과 출력에 대해

[01:22:05] 논의하고 계신데, 평가에

[01:22:07] 무엇을 전달해야 하는지

[01:22:12] UI를 통해 설계할 수 있다는 것을 알고 있는데

[01:22:13]

[01:22:15] 어떤 것을 염두에 두고 계신가요?

[01:22:18]

[01:22:18] 올바른 것을 어떻게 얻는지에 대해

[01:22:21] 평가에 사용할 올바른 텍스트를 얻는 방법이 당신의 질문인 것 같네요

[01:22:24] 어떤 것을 사용해야 하는지 어떻게 알 수 있는지

[01:22:26] 질문을 다시 정리하겠습니다. 나중에 다시 답변드리겠습니다.

[01:22:29] 네, 괜찮습니다. 추가 메타데이터로 데이터를 보강한다는 것이 무슨 의미인가요?

[01:22:35] 데이터가 한정되어 있잖아요, 맞죠?

[01:22:39] 네, 맞습니다. 대부분의 추적과 로깅 데이터는 지연 시간, 타이밍 정보 같은 것들만 포함합니다.

[01:22:47] 우리가 하고 있는 것은 사용자 ID, 세션 ID와 같은 더 많은 메타데이터를 추가하는 것입니다.

[01:22:53] 간단한 예시를 보여드리겠습니다. 이전에 보여드린 예시에서

[01:23:00] 실제로 세션 같은 것들이 있습니다. 여기 대화의 주고받기 예시가 있죠.

[01:23:04] 데이터 독에서는 이런 시각화를 얻을 수 없습니다. 왜냐하면 데이터 독은 단일 스팬이나 추적을 보고 있기 때문입니다.

[01:23:11] 인간이 무엇이고 AI가 무엇인지에 대한 맥락적 인식이 실제로는 없습니다. 그래서 우리는 서버 호출에서 맥락을 추가하고

[01:23:19] 그것을 당신의 스팬에 추가합니다. 이해가 되시나요? 기본적으로 데이터를 좀 더 풍부하게 만들고

[01:23:24] 사용할 수 있는 방식으로 구조화하는 것입니다. 더 구체적인 서버 사이드 로직이 있다면 그것도 추가할 수 있어서 매우 유연합니다.

[01:23:33] 네, 그렇군요.

[01:23:35] 음, 도발적인 질문이 하나 있습니다. 저는 이전에 비디오 게임 업계에서 일했는데, 어떤 기능이 재미있을지에 대한 논쟁에서

[01:23:41] 작동하는 프로토타입이 모든 논의에서 승리했습니다. 문서에 적힌 것은 중요하지 않았어요.

[01:23:47] 맞습니다. 그래서 회사 코드에 접근할 수 없다고 하는 분에게는 실제로 작은 데이터 조각에 접근을 시도해보라고 말씀드리겠습니다.

[01:23:56] 그리고 원하는 기능의 작동하는 프로토타입을 만들어보세요. 평가의 일부 스텁과 함께 말이죠.

[01:24:04] 엔지니어에게는 조잡한 데모를 들고 나타나는 프로덕트 매니저보다 더 나쁜 것은 없다고 생각합니다.

[01:24:12] 네, 하지만 실제로 작동하고 재미있을 수 있고, 완성도가 있고, 좋은 느낌을 주며, 사용자 요구사항을 충족하는 것이죠.

[01:24:18] 이 공식의 엔지니어링 측면에 있었던 경험으로는, 너무 조잡해서 고쳐야 합니다.

[01:24:23] 예외 사례에 대해 생각하지 않았어요. 그래서 Arize가 프로덕트 매니저가 작은 데이터 세그먼트를 마이닝하고

[01:24:33] 작동하는 예시를 만드는 흐름에 어떻게 적합한가요? 아마도 정말 조잡하지만

[01:24:41] 회사가 이미 가지고 있는 제품과 비슷하면서도 다음 단계의 기능을 보여주는 것처럼 보이는 무언가를 만드는 것 말이죠.

[01:24:49] 좋은 지적입니다. 네, 프로토타입을 만들고 고품질의 프로토타입을 구축하는 것은 정말 멋진 일이라고 생각합니다.

[01:24:59] 데이터를 사용해서 시스템이나 프로토타입을 만드는 것은 정말 좋은 지적입니다.

[01:25:04] 그래서 Arize는 여기서 무엇을 하나요? Arize에 접근할 수 있지만 코드베이스에는 접근할 수 없다면

[01:25:12] 여전히 이 데이터를 가져와서 CIS 관리자로부터 허가를 받았다고 가정하면, 실제로 이 데이터를 내보낼 수 있습니다.

[01:25:18] 데이터셋을 구축했다면, 간단히 이 데이터를 가져와서 내보내고 그것을 실제로 사용할 수 있습니다.

[01:25:26] 간단히 보여드리겠습니다. 이것은 데이터셋 가져오기입니다. 이번 주 말에 다운로드 버튼이 생길 예정입니다.

[01:25:32] 하지만 실제로 이 데이터를 가져와서 로컬에서 실행하고, 로컬에 보관하고, 그리고 실제로 로컬 코드에서 사용해서

[01:25:39] 예시를 반복해볼 수 있습니다. 물론 보안팀이 괜찮다고 하는 경우에 말이죠.

[01:25:44] 하지만 정말 좋은 지적입니다. 프로덕션 코드베이스에 접근할 필요 없이 하나의 플랫폼에서 반복할 수 있다면

[01:25:51] 우리가 추진하는 것은 전체 팀이 프롬프트와 평가를 함께 반복 작업하는 것입니다.

[01:25:59] 많은 경우에 사일로에서 일어나고 있는 것과는 달리 말이죠. 좋습니다. 모든 질문이 끝난 것 같습니다. 한 시간 반 동안 AI PM 평가에 대한 얘기를 들어주셔서 감사합니다.

[01:26:08] 더 질문이 있으시면 계속 있을 테니 시간 내주셔서 정말 감사합니다.