[00:01]
Gemini 2.5 Flash가 목요일에 출시되었는데, 마침 그때
[00:03]
제가 아이들과 캠핑을 가는 중이었어요.
[00:05]
그래서 시간을 내서 MacBook으로
[00:08]
이것을 테스트해보고 제가 만든 평가 프레임워크로
[00:10]
테스트를 해봤는데, 이에 대해서는
[00:12]
잠시 후에 더 자세히 설명드리겠습니다.
[00:14]
실제 제 코드베이스에서
[00:15]
성능을 테스트해봤고, 그 결과도
[00:17]
공유해드리겠습니다. 하지만 그전에
[00:20]
Gemini Flash 2.0에 대해 언급하고 싶습니다.
[00:22]
이 모델은 제가 몇 달 전까지 정말 많이 사용했던 모델입니다.
[00:26]
이 모델은 가성비 최강자 중 하나였죠.
[00:31]
제가 자주 찾는 모델 중 하나였습니다.
[00:34]
그리고 Gemini Flash 2.5는
[00:37]
이러한 명성을 이어받았다고 생각합니다.
[00:39]
제 생각에는 여전히 가성비 최강자입니다.
[00:42]
제가 지금까지 진행한 모든 테스트에서
[00:45]
가격 대비 성능이 가장 뛰어났습니다.
[00:48]
이에 대해 좀 더 자세히 살펴보겠습니다.
[00:49]
아레나 점수는 약간의 의구심을 가지고 봐야 하지만
[00:52]
제대로 측정했을 때는
[00:54]
모델의 성능을 판단하는 좋은 기준이 된다고 생각합니다.
[00:56]
이 경우 특히
[00:59]
모델의 성능이
[01:01]
매우 뛰어난 것을 볼 수 있습니다.
[01:04]
Gemini 2.5 시리즈의 백만 토큰당 가격이
[01:08]
아레나 점수와 비교했을 때 정말 놀랍습니다.
[01:12]
아레나 점수 대비 가격이 매우 경쟁력 있죠.
[01:15]
현재 Gemini 2.5 Flash 프리뷰 버전은
[01:18]
아직 많은 투표를 받지 않아서
[01:22]
점수가 더 낮아질 수 있지만
[01:24]
이 정도의 저렴한 가격으로
[01:27]
더 큰 모델들과 비슷한 성능을 보여주는 것은
[01:32]
정말 놀라운 일입니다.
[01:35]
이에 대한 자세한 통계를
[01:36]
곧 보여드리겠습니다. 한 가지
[01:39]
강조하고 싶은 점은
[01:40]
thinking 모드를 켰을 때와 껐을 때의
[01:42]
출력 토큰 가격 차이입니다.
[01:45]
처음에 제 가설은
[01:48]
코딩할 때는 대부분
[01:51]
thinking 모드를 켜는 것이 좋을 거라고
[01:54]
생각했는데, 실제로는
[01:56]
그렇지 않다는 것을 발견했고
[01:59]
대부분의 작업을
[02:00]
thinking 모드 없이 더 잘 수행할 수 있었습니다.
[02:02]
여러분도 같은 경험을 하셨는지 궁금합니다.
[02:04]
특히 저는
[02:07]
때때로 코드 비교(diffing)에서
[02:10]
더 많은 문제가 발생하고
[02:14]
root 코드 내에서 특정 도구 호출에
[02:17]
thinking 모드가 켜져 있을 때 문제가 있었습니다.
[02:19]
이는 아마도 컨텍스트 윈도우가
[02:21]
증가함에 따라 발생하는 문제로 보입니다.
[02:25]
코드 비교도 잘 안 되고 도구 호출도
[02:28]
잘 작동하지 않았죠. 이제
[02:30]
root 코드에서의 평가 시스템에 대해
[02:32]
말씀드리겠습니다. 이것은
[02:34]
제가 실제로 테스트하고 있는
[02:36]
화면 녹화기입니다. 이것은
[02:39]
로컬 버전의 Loom이라고 생각하시면 됩니다.
[02:42]
웹캠과 모니터를 연결할 수 있고
[02:45]
여러 파일에서 작동할 수 있습니다.
[02:49]
제 평가 시스템이 현재
[02:52]
작동하는 방식을 설명드리면
[02:54]
더 견고하게 만들어가는 중인데
[02:56]
최대한 완벽하게 만들려고
[02:59]
노력하고 있습니다. 기본적으로
[03:03]
충족해야 할 요구사항 목록을 제시합니다.
[03:05]
예를 들어, 필요한 파일들,
[03:07]
존재해야 하는 파일들, 필요한 테스트들,
[03:10]
그리고 매우 구체적으로
[03:13]
필요한 기능들에 대해
[03:14]
설명합니다. 이는 0부터 4까지의
[03:18]
등급 척도를 사용합니다.
[03:20]
이것을 모두 퍼센트로 환산하여
[03:23]
잠시 후에 차트로 보여드리겠습니다.
[03:25]
점수는 몇 가지 방식으로 산출됩니다.
[03:28]
첫째, 출력을 검증하기 위한
[03:31]
파이썬 스크립트 시리즈가 있습니다.
[03:33]
간단한 예로 파일이
[03:35]
존재하는지 확인하는 것이 있죠.
[03:36]
둘째, LLM을 심사관으로 사용하여
[03:40]
3번 실행하고 중간값을 취합니다.
[03:41]
매우 복잡한 심사 프롬프트가 있고
[03:45]
심사 프롬프트를 받아들이고
[03:48]
점수를 검증하는 심사 모드를
[03:52]
구축했습니다.
[03:53]
제가 테스트해본 결과, 심사 점수 간의 편차는
[03:58]
약 15% 정도입니다.
[04:01]
그래서 중간값을 사용하는데,
[04:04]
비교적 일관성이 있습니다. 만약
[04:07]
이상치가 있다면 표시를 하고
[04:09]
사람이 직접 개입하여
[04:13]
점수에 대한 판단을 내립니다.
[04:15]
또한 검토 중인 애플리케이션의
[04:18]
좋은 예시와 나쁜 예시를 제공합니다.
[04:21]
이 모든 것을 고려하여
[04:24]
살펴보면
[04:26]
여기 제 평가 테스트 중 하나가 있습니다.
[04:30]
이것은 화면 녹화 테스트입니다.
[04:32]
이것은 코드 모드로만 실행되었습니다.
[04:36]
퍼센트는 모든 요구사항을 충족하고
[04:38]
완벽하게 실행되는 것을
[04:42]
의미합니다.
[04:42]
여기서 놀라운 점은
[04:45]
GPT4.1과 GPT4.0 Mini가 모두
[04:50]
약 30%의 점수를 받은 반면
[04:54]
Flash 2.5 비사고 버전은 약 60%를 기록했고
[04:57]
Flash 2.5 사고 버전은
[05:00]
46%를 기록했다는 것입니다.
[05:02]
이때부터 저는 진지하게
[05:05]
사고 방식에 대해 의문을 갖기 시작했고
[05:07]
이러한 성능을 보기 시작했습니다.
[05:10]
여러 번 실행해봤는데 이 결과들은
[05:13]
매우 일관적이었습니다. 오차 범위는
[05:15]
약 3~5% 정도로
[05:17]
점수 산정 과정에서
[05:19]
발생합니다. 따라서 여기에
[05:21]
막대가 있다고 상상해보면
[05:24]
위아래로 3~5% 정도 될 수 있습니다.
[05:26]
따라서 점수가 매우 근접하다면
[05:28]
오차 범위 내라고
[05:30]
생각할 수 있습니다. 여기서 주목할 점은
[05:32]
이들 간의 차이입니다.
[05:35]
GPT4.1은 훨씬 더 비싼 모델이지만
[05:38]
코드 모드에서는 매우 일관되게
[05:41]
이 특정 문제에서 Flash 2.5보다 성능이 떨어졌습니다.
[05:44]
이제 제 마이크로매니저
[05:47]
코딩 오케스트레이터에 대해
[05:48]
소개하고 싶은데, 이는
[05:50]
다음 벤치마크로 넘어가기 전에
[05:52]
매우 중요한 부분입니다.
[05:54]
이것은 작업을 더 작은 단위로 나누며
[05:57]
각각은 자체 컨텍스트
[06:00]
윈도우를 가집니다. 첫 번째 테스트에서
[06:02]
우리가 방금 언급했던 각 모드에서
[06:06]
모델을 설정했습니다. 아키텍트,
[06:10]
연구원, 마이크로매니저, 인턴,
[06:12]
주니어, 미드레벨, 시니어, 디자이너
[06:14]
모두 테스트 중인 모델로 설정했습니다.
[06:17]
GPT4.1은 코드 모드에서 했던
[06:21]
동일한 문제에서
[06:22]
75%까지 상승했습니다. 실제로 최고점은
[06:27]
80%에 근접했고, 최저점은
[06:30]
71% 약간 위였습니다.
[06:35]
GPT4.1은 뛰어난 성능을 보였습니다.
[06:39]
그다음 Flash 2.5 사고 버전을 보면
[06:42]
약 46%에서 60% 정도로 증가했습니다.
[06:47]
실제 정확한 수치는 62%입니다.
[06:52]
반면 비사고 버전은
[06:55]
거의 동일한 수준을
[06:57]
유지했습니다.
[06:59]
사실 약간의 차이가 있을 수 있습니다.
[07:02]
오차 범위의 차이가 있었는데
[07:04]
실제로 약간 더 나빠졌습니다. GPT4.0 mini와
[07:07]
GPT4.1 mini는 성능이 크게 저하되어
[07:12]
각각 8%와 12%로 떨어졌습니다. 이는
[07:15]
아키텍트나 마이크로매니저,
[07:18]
디자이너로서의 역할을
[07:21]
제대로 수행하지 못했기 때문입니다.
[07:23]
결과적으로 필요한 요구사항들을
[07:26]
많이 놓치게 되었죠.
[07:28]
[07:29]
이는 모든 역할을 부여했을 때의 결과입니다.
[07:32]
GPT4.1은 더 비싼 모델인데,
[07:35]
이러한 테스트를 실행해보니
[07:38]
제가 만든 마이크로매니저가
[07:41]
일부 모델에서는 더 나은 코딩을 할 수 있다는 것이 입증되었습니다.
[07:45]
이제 혼합 모델 관점에서 살펴보겠습니다.
[07:49]
실제로 우리는
[07:50]
Gemini를 사용할 건데
[07:52]
[07:54]
2.5를 아키텍트와
[07:57]
마이크로매니저로 사용하고
[07:59]
왼쪽에 나열된 모델들을
[08:02]
다른 모드에 사용할 것입니다. 다시 말해서
[08:06]
더 강력한 모델인 Gemini 2.5 Pro로
[08:09]
아키텍처와 오케스트레이터를 관리할 것입니다.
[08:12]
그 결과를 보면 GPT4.1이
[08:14]
80% 초반대로 올라갔습니다.
[08:17]
매우 매우 좋은 성과를 보였죠. 하지만
[08:21]
Gemini 2.5 thinking과
[08:24]
non-thinking 버전을 보면
[08:27]
런타임 오류를 포함해도
[08:31]
약간의 차이만 있을 뿐
[08:32]
75%에서 80% 정도를 기록했습니다.
[08:36]
GPT4.0 mini와 GPT4.1 Mini는
[08:40]
50%에
[08:42]
근접했는데, 이는 같은 모델로 실행했을 때와 비교하면
[08:46]
놀라운 향상입니다. 이 점이 제게
[08:49]
정말 흥미진진한 부분인데요.
[08:51]
이러한 테스트를 실행하는 데
[08:53]
시간이 좀 걸립니다.
[08:55]
모든 평가를
[08:57]
여러 번 실행하고 싶기 때문이죠.
[08:59]
자, 이제 다음 결과를 보겠습니다. 이건 Eval 2인데
[09:02]
여기서 오타가 하나 있었습니다.
[09:05]
GPT04 mini라고 했는데, 실제로는 GPT04
[09:08]
mini입니다.
[09:10]
이 모델이 압도적이었는데
[09:11]
너무나 놀라운 성과를 보여서
[09:17]
정말 놀랐습니다.
[09:19]
이 테스트는 실제로 2-3회
[09:21]
더 실행해봤는데
[09:24]
편차가 매우 일관적이었습니다.
[09:27]
대부분의 경우 90% 이상을
[09:30]
기록했고 최대 95%까지 도달했습니다.
[09:33]
그리고 Flash 2.5의
[09:35]
non-thinking 버전이 thinking 버전보다
[09:38]
더 좋은 성능을 보였습니다.
[09:41]
이는 토큰 수가 증가하면서
[09:43]
발생한 현상이라고 생각합니다. thinking 모드가
[09:48]
코드 모드에서 성능이 떨어지는 것은
[09:50]
토큰 생성 능력 때문이라고 봅니다.
[09:55]
맥락이 늘어날수록
[09:57]
품질이 저하되는 것 같습니다.
[10:00]
반면 오케스트레이터에서는
[10:01]
더 나은 성능을 보이는데,
[10:03]
이는 맥락을 부분적으로 살펴보기 때문입니다.
[10:06]
놀랍게도 GPT4.1과 GPT4.1
[10:10]
Mini는 매우 저조한 성능을 보였습니다.
[10:13]
여기서 얻은 몇 가지 교훈이 있는데
[10:15]
문제에 따라 모델의 중요성이 매우 크다는 것입니다.
[10:18]
04 Mini가 이번 테스트에서 놀라웠는데
[10:21]
이와 관련해서
[10:23]
모든 평가와 코드 프롬프트를
[10:25]
오픈소스로 공개할 계획입니다.
[10:27]
시간이 좀 걸리겠지만
[10:28]
여러분들도
[10:29]
직접 실행해볼 수 있게 할 예정입니다.
[10:33]
GPT4.1은 제가 테스트한 방식에서는
[10:36]
코드 모드만으로는 좋은 성능을 보여주지 못했습니다.
[10:38]
하지만 제 오케스트레이터에서는
[10:41]
놀라울 정도로 뛰어난 성능을 보여줬죠.
[10:45]
이것이 바로 제가 왜
[10:47]
제가 대화하는 사람들 중 일부가
[10:49]
GPT4.1의 코딩 능력이 좋지 않다고 불평하는지
[10:52]
이해하게 된 이유입니다. 코드 모드에서는 실제로 성능이 떨어지거든요.
[10:57]
Eval 3를 실행했을 때
[11:00]
아쉽게도 복잡도가 매우 높아서
[11:02]
점수가 일관성이 부족해 결과를 보여드리기가
[11:06]
어려운 상황입니다.
[11:08]
참고로 말씀드리면
[11:11]
GPT4.1 미니와 GPT04 미니는
[11:15]
의미 있는 방식으로 과제를 완료하지 못했습니다.
[11:17]
그들의 점수는 한 자릿수에 불과했고
[11:19]
Flash 2.5는 약 30%의 성능을 보여줬습니다.
[11:23]
그리고 생각하지 않는 버전의 Flash 2.5는
[11:25]
실제로 약 40% 정도였습니다.
[11:28]
GPT4.1도 매우 저조한 성능을 보였죠.
[11:33]
그래서 Eval 3를 공개하기 전에
[11:35]
안정화 작업이 필요합니다.
[11:37]
아직 제가 만들고 있는
[11:39]
프레임워크의 초기 단계이기도 하고요.
[11:40]
이제 Ader Polyglot
[11:43]
리더보드를 살펴보겠습니다.
[11:45]
여기서 보시면 Gemini 2.0 Flash보다
[11:48]
훨씬 더 좋은 성능을 보여주는 것을 알 수 있습니다.
[11:50]
제가 사용해본 결과로는 이 Z 모델이
[11:53]
제가 사용하는 언어들에서
[11:55]
큰 발전을 이루었다고 생각합니다.
[11:58]
또한 GPT4.1과 매우 근접한 성능을 보여주는데
[12:03]
이 차트를 보시면
[12:06]
제가 말씀드린 내용을 확인하실 수 있습니다.
[12:09]
이걸 보세요. 이것은
[12:12]
제 마이크로 매니저로 진행한
[12:14]
특정 테스트 결과입니다.
[12:18]
보시다시피 GPT4.1보다
[12:20]
몇 퍼센트 포인트 더 좋은 성능을 보여주는데
[12:24]
훨씬 더 저렴한 가격으로 가능합니다.
[12:27]
물론 Gemini 2.5 Pro Preview가 더 좋고
[12:29]
이것과 페어링하면
[12:31]
정말 놀라운 결과를 얻을 수 있습니다.
[12:34]
그래서 제가 내일부터 사용할
[12:36]
팀 구성을 말씀드리면, Gemini 2.5 Pro Preview를
[12:40]
마이크로 매니저로, Claude 3.7 Sonic을
[12:44]
디자이너로 사용할 예정입니다.
[12:46]
사실 Claude의 자리를 대체한 모델은
[12:49]
아직 없었죠. 그리고
[12:51]
Gemini Flash 2.5 Preview를 임시로
[12:53]
실행해서 더 많은 경험을 쌓을 예정입니다.
[12:56]
이 모델을 더 잘 이해하기 위해
[12:57]
주니어 레벨에서도 실행할 예정이고
[13:00]
미들 레벨에서는
[13:03]
GPT4.1을 사용할 예정입니다. 특히
[13:05]
마이크로 매니저 도구에서
[13:08]
더 좋은 성능을 보여주거든요.
[13:10]
시니어는 Gemini 2.5 Pro를 유지하고
[13:13]
연구원은 당연히
[13:14]
2.0에서 2.5로 업그레이드됩니다.
[13:17]
매우 합리적인 선택이죠.
[13:20]
아키텍트는 Gemini 2.5 Pro를 사용할 건데
[13:22]
잠깐 생각해보면
[13:25]
얼마 전만 해도 이런 구성을
[13:28]
실행할 때
[13:29]
모든 것이
[13:32]
OpenAI와 Claude였는데, 이제는 Google이
[13:36]
제 코딩 팀을 지배하기 시작했네요.
[13:39]
정말 놀라운 일입니다.
[13:41]
이 구성을 얼마나 유지할지는 두고 봐야겠지만
[13:44]
초기 징후를 봤을 때 이 모델은
[13:48]
정말 놀랍도록
[13:50]
비용 효율적이면서도
[13:52]
코딩을 아주 잘합니다. MCP 서버도
[13:55]
정확하게 호출하고 웹 검색도
[13:58]
제대로 수행하면서 정보를 가져왔습니다.
[14:00]
이 모델들에 매우 매우 감동받았습니다
[14:03]
실제로 제 미들웨어를 이것으로
[14:05]
교체하는 것도 괜찮을 것 같습니다. 하지만 솔직히
[14:08]
GPT로 다시 돌아가서 말씀드리면
[14:12]
제 마이크로매니저에서 GPT4.1이 너무나 잘 작동해서
[14:15]
아직은 교체하기가 어렵습니다
[14:18]
왜냐하면 적절히 가이드만 한다면
[14:21]
정말 놀라운 성과를
[14:24]
보여주기 때문입니다. 이제
[14:26]
전반적인 생각을 마무리하겠습니다
[14:28]
우리가 이 모델을 가지게 된 것이
[14:30]
정말 행운이라고 말씀드리고 싶습니다. 2.0에서
[14:32]
큰 업그레이드가 이루어졌고, 가격 대비 가치가
[14:37]
정말 뛰어납니다. 2.0과 비교했을 때 대등한 수준이며
[14:41]
일관성과 출력 품질이 매우 뛰어납니다
[14:46]
코드베이스를 다루는 능력이
[14:48]
훨씬 더 좋아졌습니다. 이 모델에 매우 감동받았습니다
[14:52]
제가 코드베이스에서 매우
[14:54]
어려운 작업들을 마이크로매니저를 통해 실행해보았는데
[14:57]
제가 보여드린 방식으로 통합했을 때
[14:59]
정말 잘 작동했고
[15:01]
주니어 레벨과 인턴 레벨에서
[15:04]
일관되게 호출되었으며
[15:06]
놀라운 성과를 보여주었습니다
[15:09]
더 강력한 모델들과 비교해도
[15:12]
많은 가능성을 열어줍니다. 만약
[15:15]
마이크로매니저를 사용하지 않고
[15:17]
부메랑 모드를 사용한다면
[15:19]
조금 더 어려워질 수 있습니다. 부메랑 모드는
[15:21]
코드 모드, 아키텍트 모드,
[15:23]
부메랑 모드로만 제한되어 있기 때문입니다
[15:27]
조금 까다롭긴 하지만
[15:29]
부메랑 모드를 수정하여
[15:31]
여러 모드를 추가할 수 있습니다
[15:33]
간단한 작업의 경우 코드 모드로
[15:36]
전환하도록 설정할 수 있죠. 또 다른 장점은
[15:38]
매우 큰 컨텍스트 윈도우를 가지고 있어서
[15:40]
이에 대해 전혀 걱정할 필요가 없다는 것입니다
[15:42]
이 모델들은 상당히 잘 수행되며
[15:45]
컨텍스트를 잘 유지한다는 것을 알 수 있습니다
[15:48]
제가 이 모델들을 테스트해봤는데
[15:51]
컨텍스트 윈도우에서
[15:53]
50만에서 70만 토큰까지 테스트해봤고
[15:56]
기억력이 정말 놀랍도록 좋았습니다
[16:01]
하지만 생각 모드 설정에
[16:03]
약간의 작업이 필요할 것 같습니다
[16:06]
특히 코드 모드에서
[16:08]
지속적으로 더 나쁜
[16:10]
결과를 얻었기 때문입니다. 이는 조금 이상한 점인데
[16:14]
평가를 시작하기 전에
[16:16]
물어보았다면
[16:19]
반대의 결과를 예상했을 것입니다
[16:21]
충분한 생각 토큰을
[16:22]
제공하도록 설정했고
[16:24]
어떤 방식으로도 제한하지 않았습니다
[16:27]
아마도 커스텀 온도 설정이
[16:29]
변경되어야 할 것 같습니다. 이 부분에 대해
[16:31]
좀 더 연구가 필요합니다
[16:33]
이 모델의 약점은
[16:36]
특히 diff와 루트 코드에서 나타나는데
[16:40]
확실히 증명할 순 없지만
[16:43]
컨텍스트 윈도우가 커질수록
[16:45]
성능이 저하되는 것 같습니다
[16:47]
이는 제가 특히
[16:50]
코드 모드에서 생각 버전을 실행할 때
[16:53]
발생했는데, 컨텍스트 윈도우가
[16:56]
약 10만 토큰에 도달하면
[16:59]
diff 에러가 발생하기 시작했습니다
[17:02]
항상 그런 것은 아니었지만
[17:04]
제가 관찰한 결과를 퍼센트로 표현하자면
[17:07]
컨텍스트 윈도우가
[17:09]
커질수록 diff 실패율이
[17:12]
더 높아졌습니다
[17:15]
여기에는 상관관계가 있는 것 같고
[17:18]
이것이 한계점이라고 할 수 있습니다
[17:22]
그리고 제가 생각하기에
[17:25]
thinking 모드는 아마도 단순 코드 작성에는
[17:27]
사용하지 않는 것이 좋을 것 같습니다
[17:30]
주니어 모드에도 적합하지 않고
[17:32]
인턴 모드에도 적합하지 않으며
[17:34]
코드 모드에도 적합하지 않습니다
[17:36]
이것은 아키텍트 모드나
[17:38]
혹은 어떤 종류의 계획을 세울 때
[17:41]
가벼운 오케스트레이터 역할로
[17:43]
사용하면 괜찮을 것 같습니다
[17:46]
하지만 그런 용도로도
[17:48]
사용하지 않을 것 같네요. 아직은
[17:51]
Rico에서 thinking 모드를 켜는 것이
[17:53]
의미가 있는지 확실하지 않습니다
[17:56]
더 많은 테스트가 필요하고, 실제로
[18:00]
이 모델에 대한 위협을 생각해보면
[18:01]
O4 mini가 아마도 가격 대비 가치 면에서
[18:04]
가장 큰 위협일 것 같습니다. O4 mini는
[18:07]
실제로 몇몇 케이스에서 좋은 성능을 보이는데
[18:10]
때로는 Gemini 2.5 Flash보다 좋기도 하고 나쁘기도 합니다
[18:13]
하지만 제가 느끼기에 Gemini 2.5 Flash는
[18:17]
여전히 우위를 가지고 있다고 생각합니다
[18:21]
시간이 지나면서 계속 모니터링해야 하고
[18:24]
더 많은 테스트를 완료해서
[18:25]
전반적인 결과를
[18:27]
확인해봐야 할 것 같습니다
[18:28]
하지만 전체적으로 이 모델에 대해
[18:31]
매우 만족하고 있습니다
[18:34]
다음 주에도 계속 사용하면서
[18:37]
추가적인 발견 사항들을 보고하겠습니다
[18:40]
이것으로 마무리하겠습니다
[18:42]
도움이 되었길 바랍니다
[18:44]
제가 평가를 진행하는 방식에 대해
[18:45]
여러분의 생각을 알려주세요
[18:47]
제가 수행하고 있는
[18:49]
평가 작업에 많은 시간을 투자하고 있는데
[18:51]
실제로 두 개의 평가 프레임워크를
[18:53]
구축하고 있습니다
[18:55]
코딩과
[18:56]
LLM이 우리 회사의 도메인인
[19:00]
마케팅 분야에서 어떻게 수행되는지
[19:02]
벤치마킹하기 위해서입니다
[19:05]
이 부분에서 정말 뛰어나지고 싶어서
[19:07]
평가 작업의 깊은 부분까지
[19:10]
파고들었습니다. 평가가 어떻게 작동하는지
[19:11]
LLM을 심사관으로 활용하는 방법
[19:15]
필요할 때 인간 중심 평가를 하는 방법
[19:18]
알고리즘적으로 점수를 매기는 방법 등을
[19:20]
연구했습니다. 일관성 있는
[19:22]
좋은 시스템을 만드는 것은 결코 쉽지 않습니다
[19:26]
오늘 보여드린 테스트들은
[19:28]
아직 초기 단계이지만
[19:30]
지금까지 작업한 테스트 실행에서
[19:33]
일관성이 매우 좋았고
[19:35]
특히 처음 두 개의
[19:37]
평가에서는
[19:39]
매우 좋은 결과를 얻었습니다
[19:43]
같은 범위 내에서 계속해서
[19:45]
일관된 점수를 얻었고
[19:47]
극단적인 이상치는 거의 없었습니다
[19:50]
계속해서 이를 개선하고
[19:53]
발전시켜 나갈 예정입니다
[19:54]
아직 우리 Discord에 참여하지 않으셨다면
[19:57]
참여해 주시면 좋겠습니다
[20:00]
주말에 캠핑을 다녀오고
[20:02]
이 모델 작업에 집중하느라
[20:04]
제가 없는 동안 있었던 일들을
[20:07]
따라잡느라 바빴습니다
[20:09]
제가 없는 동안 일어난
[20:11]
모든 일들을 확인해야 합니다. 좋아요 버튼과
[20:13]
구독도 고려해 주시면
[20:15]
정말 감사하겠습니다
[20:17]
다음에 또 만나요, 여러분