스크립트
00:00:00안녕하세요, 제 목소리 잘 들리시나요? 좋습니다. 오늘 주어진 시간이 20분 정도로 짧아서, 바로 본론으로
00:00:20들어갈까 합니다. 제 이름은 디트(Deet)이고, Reducto의 공동 창업자이자 CEO입니다. 오늘 저희가 이야기해 보고 싶은 것은
00:00:25현실 세계에서 실제로 작동하는 에이전트를 구축할 때 매우 실용적이지만 어쩌면 그리 화려하진 않은 부분인 '데이터'입니다. 오늘 데이터에 대한 발표를 이미 많이 보셨을 텐데요. 저희는 주로 가장 다루기 힘든 데이터 소스, 즉 비정형 이미지, PDF, 스프레드시트처럼 인간이 매일 사용하는 모든 데이터를 다루는 분들을 위한 인프라 구축에 집중해 왔습니다. 혹시 이미 Reducto를 사용해 보셨거나 체험해 보신 분 계신가요? 좋네요.
00:00:55시작하기에 앞서 이해를 돕자면, 저희는 에이전트 기반의 문서 처리 플랫폼입니다. 그래서 세계 최고의 AI 팀들이 달성하고자 하는 목표에 맞춰 AI 애플리케이션과 워크플로를 구축할 수 있도록 지원하고 있습니다.
00:01:08여기에는 오늘 여러분이 많이 보셨을 AI 네이티브 기업들, 즉 Harvey, Ligo, Rogo 같은 기업들뿐만 아니라 세계 최대 규모의 엔터프라이즈 기업들도 포함됩니다. 이 부분이 오늘 나눌 이야기에서 중요한 맥락이라고 생각합니다.
00:01:19저희는 거대 빅테크 기업, 글로벌 금융 기관, 보험사 등 수십 년 치의 히스토리 데이터를 보유하고 있지만, 기존에는 데모 수준을 넘어 실제 활용하기가 너무나 어려웠던 고객들과 협력하고 있습니다.
00:01:34그리고 이 모든 기업에 걸쳐, 지금까지 고객들을 위해 수십억 건 이상의 문서를 처리해 왔습니다. 뒤에 붙은 더하기 기호(+)는 제가 좀 귀찮아서 그냥 둔 건데, 수치가 계속 늘어나고 있으니 그대로 두겠습니다.
00:01:46하지만 이를 통해 저희가 배운 핵심이자 오늘 집중하고 싶은 부분은 Reducto 제품 그 자체가 아닙니다.
00:01:51저희가 알게 된 복잡하고 미묘한 인사이트들이며, 여러분이 돌아가서 직접 하시는 작업에 적용할 수 있는 내용들입니다.
00:01:58저희가 수행한 수많은 작업과 배운 점들은 최근 AI 애플리케이션의 범주가 크게 변했다는 광범위한 주제의 맥락 속에 있습니다.
00:02:07단순한 정보 요약 제품에서 실제로 업무를 수행하는 에이전트로 말이죠.
00:02:13그리고 이에 따라 논의해 볼 만한 몇 가지 핵심 요소들을 발견했습니다.
00:02:16첫째는 문제 자체를 정의하는 것입니다. 트위터에서 수십 개의 PDF 처리 서비스 출시 소식을 보셨겠지만, 왜 사람들이 병목 현상을 겪고 유독 PDF가 어려운지 말입니다.
00:02:26다양한 도구들의 장단점을 파악하는 부분도 있습니다.
00:02:31저희는 기존 비전(CV) 기술과 시각-언어 모델(VLM)이 쓰여야 할 적재적소가 따로 있다고 생각합니다.
00:02:35그리고 더 흥미롭게도, 이번 발표의 후반부는 차세대 프런티어에 초점을 맞출 예정입니다.
00:02:40에이전트를 루프에 포함시킴으로써 가능해진 것들을 다룹니다.
00:02:43다양한 유형의 작업을 위해 평가 환경(harness)을 활용하면서 얻은 깨달음들이죠.
00:02:47그리고 RAG에서 에이전트 제품 구축으로 넘어가면서 배운 평가(Evaluation) 관련 경험들입니다.
00:02:53우선 첫 번째 주제부터 시작해 보겠습니다. 아마 귀에 못이 박히도록 들으셨을 이야기입니다.
00:02:58몇 년 전 AI 엔지니어 행사에 가보셨다면, 모든 발표마다 등장했던 단어는 단연 'RAG'였을 겁니다.
00:03:04그리고 다들 어떤 형태로든 RAG 애플리케이션을 만들고 있었죠.
00:03:07한동안 모든 애플리케이션은 사실상 일종의 정보 요약 서비스였습니다, 그렇죠?
00:03:12완벽한 프롬프트든 사용자가 업로드한 파일이든, 특정 맥락에서 정보를 가져오는 방식이었습니다.
00:03:19그리고 검색 서비스 같은 것을 구현했죠.
00:03:22엔터프라이즈 검색을 구축하거나,
00:03:23콘텐츠를 바탕으로 간단한 질의응답을 해주는 챗봇을 만들었습니다.
00:03:27그게 전부였습니다.
00:03:28하지만 오늘날 수없이 들으셨을 유행어는 바로 '에이전트'입니다.
00:03:34엔지니어분들이라면 Claude Code 같은 도구가 수많은 작업의 엔드투엔드 과정을 대신해 주는 경험을 해보셨을 겁니다.
00:03:41그리고 그와 동일한 변화가 온갖 종류의 사무직 업무에서도 일어나기 시작하고 있습니다.
00:03:46금융, 보험, 의료 등 분야를 막론하고 자율적인 의사결정이 이뤄지기 시작했습니다.
00:03:51단순히 PDF의 질문에 답하는 것을 넘어, PDF를 직접 생성하고 수정하는 등 완전한 최종 산출물을 만들어 내려고 합니다.
00:03:58이는 완전히 다른 접근 방식입니다.
00:04:00단순히 검색 플랫폼을 구축하는 것에 비해 필요한 도구와 직면하는 문제들이 크게 달라집니다.
00:04:06그리고 이 모든 것의 공통 핵심은, 여러 단계로 이뤄진 파이프라인을 다루기 시작할 때 해결해야 할 문제가 훨씬 더 중요해진다는 점입니다.
00:04:18단순히 질의응답만 할 때도 당연히 답변 자체에서 오는 리스크는 존재합니다.
00:04:24하지만 에이전트가 여러 파일 소스를 거치며 연쇄적인 결정을 내리고 여러 데이터 소스를 불러올 때, 잘못된 입력이 들어오면 파이프라인 전체에 위험이 매우 광범위하게 퍼지게 됩니다.
00:04:36그리고 그것이 바로 저희가 집중하는 부분입니다.
00:04:38결국 현실 세계에서 언어 모델 도구의 가치는 그 지능을 어떤 맥락에 적용하느냐에 따라서만 발휘되기 때문입니다.
00:04:48많은 기업에서 데이터는 비정형이고, 파편화되어 있으며, 멀티모달 형태를 띱니다.
00:04:53깔끔하게 정리된 저장소 형태가 아닙니다.
00:04:56다양한 조직의 임의의 팀들이 Google Drive, Box 등 온갖 장소에 자료를 올려둡니다.
00:05:04기본적으로 비정형 형태인 데이터 포맷들을 접하게 될 것입니다.
00:05:07자신의 말뭉치(corpus)에 정확히 어떤 데이터가 들어있는지조차 모를 수 있습니다.
00:05:11그리고 그로 인해 온갖 후속 문제들이 발생하게 됩니다.
00:05:14파싱 및 추출 정확도 문제가 발생할 수 있고, 이는 분명 중요한 문제입니다.
00:05:18하지만 올바른 맥락을 검색해 오고 있는지의 문제이기도 합니다.
00:05:22그 맥락과 실제로 어떻게 상호작용하고 수정을 적용할 것인가에 대한 문제이기도 하죠.
00:05:27그리고 Reducto나 이 분야의 다른 이들이 거듭 강조해 온 사실은, 놀랍게도 PDF가 여전히 매우 어려운 문제라는 점입니다.
00:05:36여러 파운데이션 모델 기업들과 협력하는 데이터 연구소인 Surge를 팔로우하는 분이 계신지 모르겠습니다.
00:05:42그들이 만든 GDP PDF라는 훌륭한 벤치마크가 있는데, 최신 프런티어 모델조차 여기서 점수가 30% 수준에 불과합니다.
00:05:52이 테스트는 완전히 '모델이 PDF 같은 문서의 내용을 훑어보고 실제로 정확한 판단을 내릴 수 있는가'라는 개념에 기반하고 있습니다.
00:06:01PDF가 어려운 이유는(잠시 후 그 벤치마크로 다시 돌아오겠습니다만) 근본적으로 아주 오래된 파일 형식이자 완전히 다른 목적으로 설계되었기 때문입니다.
00:06:11제가 살아온 날보다 더 오랫동안 PDF 처리를 연구해 온 분들도 실제로 만난 적이 있습니다.
00:06:161990년대 초반에 PDF 인쇄용 프린터 드라이버를 개발하셨던 분들도 만나봤죠.
00:06:21그때는 그게 목적이었습니다.
00:06:22처음 작성했을 때의 문서 내용을 충실하게 구현하고, 마지막에 종이로 인쇄할 수 있게 만드는 것이었죠.
00:06:30오늘날 다루는 고민들의 대부분은 인쇄와는 거리가 셉니다.
00:06:33궁극적으로 우리가 원하는 것은 에이전트가 효과적으로 추론할 수 있는 마크다운 형태의 표현입니다.
00:06:39그리고 현실 세계에서 인간은 수많은 맥락을 시각적으로 인코딩합니다.
00:06:44투자은행(IB)에 갓 입사한 신입 금융 애널리스트가 '에이전트가 이 발표 자료를 잘 읽을 수 있을까?'를 고민하면서 작성하진 않거든요.
00:06:54매우 창의적인 슬라이드들을 만들어 냅니다.
00:06:57황금 알을 낳는 거위가 그려진 소프트뱅크의 슬라이드를 보신 적이 있을 겁니다.
00:07:01그런 디테일들이 중요합니다.
00:07:02그렇지 않나요?
00:07:03추론해야 할 데이터의 상당수는 눈금선이 명확하지 않거나 병합된 셀이 나누어져 있는 표 구조일 것입니다.
00:07:10꺾은선 차트나 그래프 같은 것들도 있을 것이고요.
00:07:12사람인 저조차 알아보기도 힘든 엉망인 손글씨도 있을 것입니다.
00:07:17그런 롱테일 예외 상황들을 다루려면 바로 이러한 문제를 해결해야 합니다.
00:07:22저희가 2023년에 회사를 설립한 이유는 이 분야에서 일종의 비약적인 도약이 가능하다고 느꼈기 때문입니다.
00:07:29한동안 사람들은 PDF 처리 문제를 고민할 때 NLP 파이프라인을 약간 변형한 방식을 사용하곤 했습니다.
00:07:37단순한 OCR을 거친 뒤 그 텍스트를 후처리하는 방식이었죠.
00:07:41레이아웃이 매우 일정한 경우에는 그 방식이 잘 동작했습니다.
00:07:44그렇죠?
00:07:45W2 서식이 항상 동일한 형태라는 걸 안다면, 템플릿화해서 해결할 수 있는 제한된 범위의 문제입니다.
00:07:51하지만 VLM이 흥미로운 이유는 근본적으로 범용적인 성격을 띠기 때문입니다.
00:07:56처음으로 '사람이 읽는 방식 그대로 문서를 읽는다'는 전제가 가능해진 것입니다.
00:08:01'롱테일 문제들을 해결하겠다'는 전제를 세울 수 있게 된 거죠.
00:08:04그래서 기존 OCR로는 불가능했던 손글씨 처리 같은 온갖 작업에서 VLM이 놀라운 성능을 보인다는 것을 알게 되었습니다.
00:08:12하지만 반대로, 이것이 만능 해결책은 아니라고 생각합니다.
00:08:16대규모로 이 문제를 해결해야 하거나 수억 건의 문서를 다루는 기업이라면,
00:08:21결정론성(determinism)과 같은 여러 부차적인 요소들을 깊이 고려해야 합니다.
00:08:25처리 효율성도 매우 신경 쓰일 수밖에 없습니다.
00:08:27따라서 특정 작업에서는 전통적인 비전(CV) 기술이 여전히 강력한 위력을 발휘한다는 점을 확인했습니다.
00:08:33자율주행차 연구가 발전하면서 이 부분은 상대적으로 과소평가되어 왔습니다.
00:08:37객체 탐지(Object detection) 같은 기술은 10년 전보다 훨씬 정교해졌습니다.
00:08:42그래서 1억 개 미만의 파라미터를 가진 모델들도 문서의 레이아웃을 감지하는 등의 작업에 매우 효과적입니다.
00:08:48거대 파운데이션 모델을 쓰지 않고도 아주 뛰어난 성과를 낼 수 있습니다.
00:08:52심지어 CPU에서도 실행 가능한 모델들입니다.
00:08:54대규모 환경에서도 무리 없이 돌릴 수 있죠.
00:08:55영역 단위로 처리하기 까다로운 부분이 어디인지 확실히 파악할 수 있습니다.
00:09:00그리고 VLM은 '시맨틱(의미론)'이라는 개념을 도입해 줍니다.
00:09:03파이프라인에서 발생하기 쉬운 오류 유형을 직접 식별하고 수정할 수 있게 됩니다.
00:09:09그리고 이 시맨틱 개념을 바탕으로, 문제를 분해하고 까다로운 요소가 어디 있는지 명확히 파악할 수 있다면,
00:09:18페이지 내 텍스트를 세그먼트화하고 손글씨 위치를 이해한 상태에서,
00:09:21일종의 '에이전트 인 더 루프(agent in the loop)' 개념을 도입할 수 있습니다.
00:09:25과거에는 사람이 검수팀이 되어 직접 주석을 달고 오류를 수정했다면,
00:09:29이제 VLM은 저희가 '에이전트 기반 OCR(agentic OCR)'이라 부르는 새로운 방식을 제공할 수 있습니다.
00:09:33실제로 저희가 구현한 방식은, IDE에서 빠른 편집을 지원하는 Cursor 같은 도구를 써보셨다면 이해하기 쉬운데,
00:09:41출력 결과에 토큰 단위의 수정을 적용하는 추측성 디코딩(speculative decoding)과 유사합니다.
00:09:45여기서도 비슷한 원리를 적용할 수 있습니다. 그저 OCR 결과를 Gemini에 보내서
00:09:51화려한 프롬프트를 작성하고 원본에서 너무 벗어나지 말아 달라고 정중히 요청하는 식이 아닙니다.
00:09:56그런 식으로 다음 토큰 예측을 수행하게 되면,
00:09:58아무리 똑똑한 모델이라도 원본 문서의 내용과 다르게
00:10:02임의로 내용을 수정해 버리는 새로운 손실 케이스가 발생하기 때문입니다.
00:10:05'합계'라는 단어가 보이고 문서의 표에 사람이 낸 오류가 있다면,
00:10:08모델이 직접 표의 값을 다 합산해서 고쳐버리는 일이 벌어지기도 합니다.
00:10:13정작 필요한 것은 원하는 토큰 단위의 오류만 정밀하게 수정하는 것입니다.
00:10:16마침표와 쉼표, 숫자 0과 알파벳 O가 헷갈린 것을 바로잡는 것처럼,
00:10:19그런 세세한 디테일들이 정말 중요합니다.
00:10:21이는 사람이 그 문서를 읽었을 때 보았을 형태를
00:10:25어떻게 실제로 구현해 낼 것인가의 문제입니다.
00:10:27저희가 보기에 에이전트 기반 OCR은 '휴먼 인 더 루프(Human-in-the-loop)' 비유와 거의 유사합니다.
00:10:34CV와 VLM 파싱을 통해 1차 입력을 거친 뒤,
00:10:39검증 및 수정 레이어를 거쳐 신뢰도 높은 최종 출력을 도출해 내는 방식입니다.
00:10:44하지만 앞서 말씀드렸듯, 문제가 단순히 파싱과 추출에만 국한된다고 보지 않습니다.
00:10:50훌륭한 문서-마크다운 파이프라인을 갖추고 있다 하더라도,
00:10:56파이프라인의 세부 사항들을 면밀히 고민하는 것이 중요합니다.
00:10:59좋은 예로, RAG 플랫폼을 구축해 보셨다면
00:11:04표(table) 같은 요소를 어떻게 다룰지 고민해 보셨을 겁니다.
00:11:07마크다운 같은 형식으로 잘 인코딩할 수 있는 것은 많습니다.
00:11:13하지만 셀 병합에 수많은 의미가 담겨 있는 이러한 표의 경우,
00:11:18그러한 구조를 보존하는 것이 중요합니다.
00:11:20그리고 이건 모델의 한계가 아닙니다.
00:11:22LLM은 동일한 표의 HTML 구조를 추론하는 데 매우 뛰어납니다.
00:11:26하지만 토큰 낭비가 심해져 비용이 빠르게 증가합니다.
00:11:29반대로 그 반대 극단으로 가서
00:11:31단순한 표까지 전부 HTML로 인코딩하고 싶지는 않을 것입니다.
00:11:35불필요한 HTML 태그가 너무 많이 생기기 때문이죠.
00:11:38그래서 저희는 이 문제를 동적인 과제로 접근했습니다.
00:11:42단순한 표라면 마크다운으로 데이터를 근사 처리하면 됩니다.
00:11:47복잡한 표라면 HTML 같은 방식을 사용하는 것이 좋지만,
00:11:50파이프라인에서 고려해야 할 대상이 언어 모델뿐만은 아닙니다.
00:11:55임베딩과 관련된 작업을 하고 있다면,
00:11:57해당 컨텍스트의 검색(Retrieval)이라는 이차적인 문제도 발생합니다.
00:12:01아까 보여드린 것과 동일한 표도
00:12:03HTML 표현 방식으로 보면 정말 지저분합니다.
00:12:08스니펫의 대부분이 단순한 HTML 태그일 뿐이죠.
00:12:11단지 문서의 구조를 분류하고 있을 뿐입니다.
00:12:14안타까운 점은, 일반적인 일괄 평가(Eval)에서는
00:12:17모델이 할 일을 대신해 주는 콘텐츠가 포함되어
00:12:22찾고자 하는 바를 정확히 짚어줄지 모르지만,
00:12:24실제 사람은 표에 있는 값을 일일이 나열하지 않는다는 것입니다.
00:12:28“시간 경과에 따라 매출이 어떻게 변했나?”라고 물을 뿐이며,
00:12:30관련된 적절한 표를 알아서 검색해 올 것이라 기대합니다.
00:12:34언어 모델은 해당 텍스트를 효과적으로 추론할 수 있지만,
00:12:37대규모 코퍼스에서 데이터를 추출할 때
00:12:39임베딩 모델은 사람이 입력한 자연어 프롬프트와
00:12:44HTML 태그와 숫자가 엉킨 지저분한 덩어리를 매칭하는 데 애를 먹습니다.
00:12:47따라서 적은 노력으로 큰 효과를 볼 수 있는 주요 방법은
00:12:51임베딩 모델 자체에 더 맞춤화된 표현을 만드는 것입니다.
00:12:55동일한 표를 바탕으로
00:12:56표의 자연어 표현을 작성함으로써,
00:12:58두 방식의 장점을 모두 취하는 것이죠.
00:13:00추론을 위해 모델에 데이터를 전달할 때는
00:13:02HTML 표 표현 방식을 사용하고,
00:13:04올바른 스니펫을 확실히 검색하고자 할 때는
00:13:07해당 자연어 블록을 활용하는 것입니다.
00:13:12그 외에도 단순 파싱과 추출을 넘어선 다양한 작업들이 존재합니다.
00:13:18역사적으로 업계의 관심은 파싱과 추출에 집중되어 왔습니다.
00:13:22그 영역에서 엄청난 성능 향상이 가능하다고 믿기 때문입니다.
00:13:25앞서 언급한 GDP PDF 벤치마크는
00:13:30데이터 파이프라인을 개선했을 때 얻을 수 있는 결과를
00:13:34잘 보여주는 대표적인 사례입니다.
00:13:37앞서 말씀드린 것과 동일한 벤치마크를 수행했을 때,
00:13:40아쉽게도 Fable은 접근 권한이 차단되어
00:13:43테스트해보지 못했습니다.
00:13:46하지만 다른 모델들에 원본 PDF와 함께
00:13:50파싱 결과와 같은 구조화된 표현을 제공하면,
00:13:52모델 종류에 관계없이,
00:13:55Gemini, Anthropic, OpenAI 모두에서
00:13:58더 나은 입력값 덕분에 최종 LLM 성능이 실제로 향상되는 것을 볼 수 있습니다.
00:14:04심지어 GPT-4.5나 Opus 같은 모델은
00:14:09기본 상태의 Fable 성능을 앞서기도 합니다.
00:14:12단순히 정확도 측면뿐만 아니라, 더 좋은 입력을 제공한 결과
00:14:17모델이 사용하는 추론 토큰 수 자체도 줄어듭니다.
00:14:20데이터 표현보다 실제 출력 결과에 더 집중할 수 있게 되는 것이죠.
00:14:24결과적으로 지연 시간(Latency)을 낮추고
00:14:27정답에 더 빠르게 도달할 수 있습니다.
00:14:30하지만 이러한 파이프라인을 구축하고
00:14:33파싱 레이어의 모든 요소를 꼼꼼히 점검한 후에도,
00:14:37사람이 다루는 작업의 상당수는 코퍼스 내 데이터 범위를
00:14:41실제로 이해하고, 적절한 파이프라인으로 라우팅하며
00:14:44문제를 분해하거나, 마지막에 문서를 수정·편집하는 작업을 필요로 합니다.
00:14:48그래서 저희는 언어 모델이 문서와 수행하는 모든 상호작용을
00:14:51사람이 직접 다루는 것처럼 효과적으로 만들 수 있을지
00:14:54고민하며 문제에 접근하고자 했습니다.
00:14:57양식을 작성할 때 필드 입력의 정밀도를
00:15:00어떻게 보장할 것인가 하는 문제처럼 말이죠.
00:15:03오케스트레이션 측면에서 아주 좋은 예로,
00:15:05분류 및 분할 작업은 LLM이 최상의 성능을 내도록 돕는
00:15:08매우 저평가된 방법이라고 생각합니다.
00:15:12물론 원하는 만큼 많은 컨텍스트를 쏟아부을 수도 있고,
00:15:14'건초더미에서 바늘 찾기' 식의 테스트라면
00:15:17괜찮을지 모릅니다.
00:15:19하지만 실제 환경에서는 너무 많은 정보를 전달함으로 인해
00:15:20토큰 비용 문제를 떠나 품질 저하 현상이 발생합니다.
00:15:24대신, 올바른 문서를 적절한 종류의 파이프라인으로
00:15:28어떻게 분류할지 등에 대해 고민함으로써
00:15:33성능 향상의 여지를 크게 확보할 수 있음을 확인했습니다.
00:15:36대용량 문서의 경우에도
00:15:38실제 관련이 있는 스니펫만 전달되도록 보장하는 방법이 중요합니다.
00:15:41종이 우편물 같은 것을 처리해야 하는 유즈케이스에서는
00:15:43우편물 묶음이 수백 페이지에 달할 수 있습니다.
00:15:47그 안에 어떤 내용이 들어 있을지 미리 알 수 없고,
00:15:50내용이 서로 섞여 들어간 문제도 있을 수 있습니다.
00:15:53이러한 정돈 작업을 모델에게 시키는 것은
00:15:57달성하려는 본래 작업, 즉 우편물 데이터 추출,
00:16:01추론, 혹은 의사결정과 같은 작업으로부터
00:16:03주의를 산만하게 만드는 일이 됩니다.
00:16:05앞서 말씀드렸듯, 후반부 내용이 더 흥미로운 부분이라 생각하는데
00:16:10초기 분류 및 분할 레이어를 갖추고
00:16:13정렬 문제를 해결하고 난 이후의 단계입니다.
00:16:16저희 팀이 매우 흥미롭게 보고 있는 부분은,
00:16:20에이전트 하네스(Agent Harness)가 기존의 해결하기 어렵던 난제들을
00:16:22돌파할 수 있는 매우 유망한 프론티어가 되었다는 점입니다.
00:16:26잠시 후 말씀드릴 좋은 예시 중 하나가
00:16:29꺾은선그래프 같은 차트 처리입니다.
00:16:34저희는 세계 최대 규모의 여러 헤지펀드와 협력하고 있는데,
00:16:37꺾은선그래프는 역사적으로 다루기 매우 까다로웠습니다.
00:16:39첫째로 이미지 형식이기 때문이고,
00:16:41둘째로 픽셀 수준의 세밀함이 존재하여
00:16:43기존 비전 인코더를 사용하면
00:16:46정보 손실이 발생하기 쉽기 때문입니다.
00:16:49매출 추이에 대한 대략적인 플롯은 얻을 수 있어도,
00:16:52개별 데이터 포인트는 놓치게 됩니다.
00:16:53그래서 저희는 에이전트가 다루고자 하는
00:16:55특정 유형의 문제를 해결할 수 있도록
00:16:57적절한 도구를 제공하는 방법에 대해 고민해 왔습니다.
00:17:00차트 추출의 경우, 왼쪽 차트에는
00:17:04방대한 양의 데이터 표가 인코딩되어 있습니다.
00:17:05모든 픽셀을 직접 플롯하려고 시도한다면
00:17:09매우 어려운 작업이 될 것입니다.
00:17:11또한 모델이 선 사이의 복잡한 굴곡을
00:17:14대략적으로 추정하는 것조차 힘든 일입니다.
00:17:16단 한 번의 시도(Single-shot)로 이를 처리할 수 있는
00:17:19기성 모델은 존재하지 않습니다.
00:17:22오른쪽에 보이는 것은 원본 꺾은선그래프를 바탕으로
00:17:24생성해 낸 마크다운 표의 재구성 결과입니다.
00:17:25이러한 결과에 도달할 수 있었던 유일한 방법은
00:17:28온갖 도구를 갖춘 에이전트를 활용하는 것이었습니다.
00:17:30원본 선 그래프로부터
00:17:32재구성할 수 있었던 복원물입니다.
00:17:34그리고 이걸 가능하게 한 유일한 방법은
00:17:36온갖 도구를 갖춘 에이전트를 쓰는 것이었습니다.
00:17:37자체 코드 인터프리터도 있고
00:17:40생성 중인 차트를 시각화하는 능력도 있죠.
00:17:41그리고 반복 작업을 거치며
00:17:45선 그래프의 오류를 계속해서 찾아내어
00:17:47최종 출력물에 도달하게 됩니다.
00:17:51이는 구조화된 추출 같은 문제에도 동일하게 적용됩니다.
00:17:53한동안 문서 기반 구조화 출력 기능을
00:17:55제공해 오기도 했지만,
00:17:57동일한 작업에 에이전트 하네스를 결합하면
00:18:00한 단계 더 진보할 수 있습니다.
00:18:03상위 에이전트가 하위 에이전트가 따를
00:18:05검증 기준을 설정하도록 할 수 있죠.
00:18:09수만 개의 필드가 있는 CBP 서식 같은 경우
00:18:11조용히 발생하는 문제가
00:18:13많이 발견되기도 합니다.
00:18:15내용이나 행이 누락되는 것처럼요.
00:18:17오늘 아침 MicroOne이 이 분야에서
00:18:20매우 유용한 벤치마크를 발표했는데,
00:18:23시장에는 양극화가 존재합니다.
00:18:24최고의 추론 능력을 가진 프론티어 모델은 정밀도가 매우 높습니다.
00:18:28행을 추출해내기만 했다면
00:18:30지어낸 환각 행일 확률은 낮죠.
00:18:31실제로 정확히 추출한 것입니다.
00:18:33하지만 벤치마크 전반에서 많은 내용을 소리 없이 누락합니다.
00:18:37재현율이 크게 떨어지는 편이죠.
00:18:39반면에 많은 전문 문서 처리 서비스는
00:18:42정밀도 관점에서는 프론티어 모델에 뒤처지지만
00:18:46재현율 관점에서는 그 격차를 좁힙니다.
00:18:48그래서 항상 이러한 절충점이 존재해 왔습니다.
00:18:51그리고 에이전트 하네스를 도입하고 나서야
00:18:54이러한 작업에서 정밀도와 재현율 모두의
00:18:57극대화 지점을 찾을 수 있었습니다.
00:19:00마지막으로, 어쩌면 이번 발표에서 가장 중요한 점은
00:19:04결국 평가(Eval)가 모든 의사결정의
00:19:09기반이 되어야 한다는 것입니다.
00:19:10이는 저희 제품 철학에서도 핵심적인 부분이었습니다.
00:19:12평가 대상이 되는 기성 데이터셋은 물론
00:19:16실시간 운영 환경 모니터링에도 적용되죠.
00:19:19실제 운용 데이터는 준비된 평가 세트와는
00:19:21다를 수밖에 없기 때문입니다.
00:19:25그리고 평가를 단순히 거시적인 관점으로만
00:19:28보지 않는 것이 정말 중요합니다.
00:19:30저희와 함께하는 최고의 팀들은
00:19:33파이프라인의 각 단계별로 미시적인 수준에서 평가를 살펴봅니다.
00:19:36가장 먼저 해야 할 일은 파이프라인의 입력값이
00:19:38파이프라인으로 들어오는 입력이 훌륭한지 확인하는 것입니다.
00:19:40당연히 파싱 파이프라인 같은 요소들을 평가해야겠죠.
00:19:43하지만 파싱이 완벽하더라도 검색 파이프라인이 엉망이라면
00:19:47올바른 문맥을 전달하지 못하므로 아무런 도움이 되지 않습니다.
00:19:50따라서 세부적인 요소까지 깊이 고민하는 것이 중요합니다.
00:19:52검색 파이프라인이나
00:19:54파이프라인 말단의 포맷팅 같은 부분들 말이죠.
00:19:56그리고 결국 가장 중요한 것은
00:19:58최종 에이전트의 성능을 향상시킬 수 있느냐입니다.
00:20:03마지막으로 저희가 나아가는 방향과
00:20:06업계가 어디로 향하고 있는지 말씀드리며 마치겠습니다.
00:20:08가장 중요한 점은, 에이전트가 발전함에 따라
00:20:12몇 년 전 사용하던 결정론적 파이프라인 구조에서
00:20:15벗어날 수 있게 되었다는 사실입니다.
00:20:17저희 고객 중 상당수는 에이전트가 탐색할 수 있는
00:20:20일종의 파일 시스템을 구축하고
00:20:22어떤 도구를 사용할지 에이전트가 직접 결정하게 만듭니다.
00:20:25그래서 저희는 CLI를 만들어, 문서가 항상 정해진 흐름만 따르는
00:20:28엔드투엔드 파이프라인을 구축하는 대신,
00:20:32특정 유형의 문서를 읽을 필요가 있는지 에이전트가 판단하게 합니다.
00:20:35그리고 이를 두 가지 세트로 분할합니다.
00:20:38하나는 에이전트가 필요에 따라 읽는 본문 영역이고,
00:20:41다른 하나는 필요한 모든 메타데이터 세트입니다.
00:20:44출처 인용 등을 처리할 때 바운딩 박스가 필요할 수도 있는 것처럼요.
00:20:47기타 등등의 것들 말이죠.
00:20:50편집에 대한 이 부분은 넘어가겠습니다.
00:20:52여기서 흥미로운 작업이 많이 이루어지고 있다고 생각합니다.
00:20:54일부는 이미 출시했지만, 향후 몇 달 안으로
00:20:57문서 생성 같은 기능에 더욱 집중하는 모습을 보실 수 있을 겁니다.
00:21:01오늘 내용을 요약해 보자면, 시간을 내어주셔서 진심으로 감사드리며
00:21:04첫째, 파싱 문제를 세분화하여 접근하시길 강력히 권장합니다.
00:21:08가능한 한 적재적소에 맞는 도구를 사용하는 개념으로 생각하셔야
00:21:11정확도, 비용, 지연 시간 측면에서 최적의 프론티어 구간에 도달할 수 있습니다.
00:21:16둘째, 에이전트 기반 검증은 업계에서 한동안 없었던 가장 큰 혁신적인 변화이며,
00:21:21프로덕션 환경에서 제대로 작동하는 파이프라인을 구축할 수 있는 정말 좋은 기회입니다.
00:21:26셋째, 적은 노력으로도 세부적인 부분에서 큰 개선 여지를 얻을 수 있습니다.
00:21:31소비자에 맞게 데이터를 포맷팅하는 것처럼 말이죠.
00:21:34넷째, 비슷한 맥락에서 단순히 데이터 처리뿐만 아니라
00:21:39데이터 오케스트레이션에 대해 고민하는 것이 정말 중요합니다.
00:21:41따라서 파이프라인을 확장하는 방법으로
00:21:44분류 및 분할 도구를 항상 고려해야 합니다.
00:21:46다섯째, 모든 단계에서 반드시 평가(eval)를 진행하세요.
00:21:49여섯째, 귀사에 맞는 다음 프론티어가 어떤 모습일지 깊이 고민해 보세요.
00:21:52오늘날 가장 성공적인 기업들 대부분은 2~3년 전에 우리가 했던 방식에서
00:21:56많이 벗어나고 있기 때문입니다.
00:21:59질문이 있으시다면 언제든지 편하게 연락 주시기 바랍니다.
00:22:03제 이메일은 이름@reducto.ai입니다.
00:22:06귀사의 사용 사례에 도움이 될 수 있다면 웹사이트를 통해서도 문의하실 수 있습니다.
00:22:10감사합니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기