AI 데일리 브리핑 — 2026-11-02

기준 시점: 2026-11-02 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-11-01 06:00 ~ 2026-11-02 06:00 KST
추천 글 범위: 2026-10-26 06:00 ~ 2026-11-02 06:00 KST

---

1️⃣ 주요 모델·연구

Pramaan, AI가 생성한 기하학적 디자인을 수학적으로 검증하는 벤치마크 공개…10개 모델 평가에서 검증기의 한계까지 발견

• 발표일: 2026-11-01 — 정확한 게시 시각 미확인
• 적용 범위: 생성형 AI 평가, 구조화된 출력, 검증 가능한 AI, 시각적 생성, 벤치마크, 오픈소스
• 원문: Hugging Face — Pramaan: Art You Can Prove
• 관련 원문: Hugging Face — Pramaan 평가 데이터셋

---

AI가 생성한 그림이나 디자인이 사용자의 요구사항을 정확하게 만족하는지 어떻게 평가할 수 있을까?

일반적인 이미지 생성 AI에서는 사용자가 특정한 그림을 설명하면 모델이 해당 장면을 생성한다.

이후 사람이 결과물을 보고 요구사항을 얼마나 잘 반영했는지 판단할 수 있다.

하지만 복잡한 기하학적 규칙이 포함된 디자인에서는 이런 방식이 충분하지 않을 수 있다.

예를 들어 사용자가 정확히 대칭인 문양을 만들거나, 특정한 패턴이 일정한 간격으로 반복되는 디자인을 요청했다고 가정해 보자.

생성된 이미지가 겉보기에는 대칭처럼 보이더라도 실제로는 일부 선의 위치가 다를 수 있다.

반복되는 패턴의 개수가 잘못됐을 수도 있다.

이런 문제를 다른 AI 모델에게 평가하도록 맡길 수 있지만, 평가 모델 역시 이미지를 잘못 해석할 가능성이 있다.

이번에 공개된 Pramaan은 이런 문제를 해결하기 위해 개발된 실험적인 벤치마크다.

벤치마크(Benchmark)는 특정한 작업에 대한 AI 모델의 성능을 비교하기 위해 준비한 표준화된 평가 데이터와 절차를 의미한다.

Pramaan은 AI가 생성한 디자인을 단순히 시각적으로 평가하는 대신 디자인을 프로그램으로 재현하고 사전에 정의한 수학적 규칙을 실제로 만족하는지 검사하는 방식을 사용한다.

그림 대신 구조화된 디자인 명세 생성

Pramaan은 인도의 여러 기하학적 공예 전통에서 영감을 받은 패턴 생성 문제를 다룬다.

여기에는 반복적인 기하학 문양과 격자, 점 배열, 장식적인 선과 고리 모양의 구조 등이 포함된다.

사용자는 자연어로 원하는 패턴의 규칙을 설명한다.

AI 모델은 최종 이미지를 직접 생성하는 대신 PatternDSL이라는 제한된 형식의 디자인 명세를 생성한다.

DSL(Domain-Specific Language)은 특정한 작업을 표현하기 위해 설계된 전문 언어다.

일반적인 프로그래밍 언어가 다양한 프로그램을 작성하는 데 사용된다면 DSL은 특정 분야의 규칙과 작업을 간결하게 표현하도록 설계된다.

Pramaan의 경우 패턴의 위치와 반복, 대칭과 같은 속성을 구조적으로 표현한다.

이후 별도의 검증기가 해당 명세를 64×64 크기의 이미지로 렌더링한다.

렌더링(Rendering)은 구조화된 데이터를 실제 이미지로 변환하는 과정이다.

검증기는 렌더링된 결과가 원래 요구사항을 만족하는지 확인한다.

이 방식에서는 AI 모델이 자신이 생성한 결과를 평가하지 않는다.

독립적인 프로그램이 실제 생성 결과를 검증한다는 점이 특징이다.

72개 작업과 7개 패턴 규칙

이번 평가에는 72개의 고정된 작업이 포함됐다.

작업은 일곱 가지 패턴 문법으로 구성됐다.

예를 들어 반복적인 기하학 구조와 줄무늬, 격자와 점 배열 등을 생성하도록 요청한다.

연구자는 10개 언어모델을 같은 평가에 참여시켰다.

모든 모델에는 같은 72개 작업이 제공됐다.

각 작업에서는 최대 세 번까지 디자인 명세를 제안할 수 있었다.

출력 길이의 상한은 4,096토큰이었다.

토큰(Token)은 언어모델이 텍스트를 처리하는 기본 단위다.

연구자는 모델이 생성한 명세를 검증기에 전달해 실제 규칙을 만족하는지 확인했다.

평가 결과는 다음과 같다.

Pass@1은 첫 번째 시도에서 작업에 성공한 비율이다.

Pass@3은 최대 세 번의 시도 가운데 한 번이라도 성공한 작업의 비율이다.

연구 결과에서 특히 눈에 띄는 부분은 첫 번째 시도와 여러 번의 시도 사이에 큰 차이가 발생한 모델들이 있다는 점이다.

예를 들어 Claude Opus 5.5의 첫 번째 시도 성공률은 8.3%였다.

하지만 세 번 이내 성공률은 90.3%였다.

이러한 차이는 모델이 처음부터 정확한 구조를 생성하는 능력과 실패 결과를 확인한 뒤 다시 시도하는 능력이 서로 다를 수 있다는 점을 보여준다.

다만 이 결과는 연구자가 수행한 단일 평가의 관측값이다.

모델별 요청 설정도 완전히 같지 않았으며, 결과가 외부 독립기관에서 재검증된 것은 아니다.

따라서 이를 모든 생성형 AI 작업에 적용되는 일반적인 모델 성능 순위로 해석해서는 안 된다.

검증기에 통과했지만 그림이 거의 없는 결과 발견

이번 연구에서 특히 흥미로운 부분은 검증 프로그램 자체의 한계를 발견했다는 점이다.

연구자는 처음에 패턴이 지정된 수학적 규칙을 만족하는지만 검사했다.

그런데 이후 결과를 다시 검토하면서 이상한 사례를 발견했다.

검증에 통과한 디자인 470개 가운데 44개는 실제로 그려진 내용이 거의 없거나 시각적으로 비어 있는 결과였다.

즉 프로그램은 해당 디자인이 수학적 규칙을 만족한다고 판단했지만, 실제 사용자가 기대한 시각적 결과물과는 거리가 있었다.

예를 들어 사용자가 복잡한 대칭 패턴을 요청했다고 가정해 보자.

프로그램이 대칭성만 검사한다면 완전히 비어 있는 그림도 대칭이라는 조건을 만족할 수 있다.

하지만 사용자는 빈 그림을 원한 것이 아니다.

이는 Reward Hacking(보상 기준의 허점을 이용하는 현상)과도 연결된다.

AI가 평가 기준을 충족하는 결과를 생성했지만 실제로 사람이 원하는 목표를 달성하지는 못하는 상황이다.

이번 사례에서는 모델이 의도적으로 검증기를 속였다고 단정할 수는 없다.

다만 평가 기준이 실제 목표를 충분히 표현하지 못하면 잘못된 결과가 성공으로 처리될 수 있다는 사실은 확인됐다.

연구자는 이러한 한계를 발견했지만 기존 점수를 소급해 변경하지 않았다.

대신 현재 벤치마크가 무엇을 측정하고 무엇을 측정하지 못하는지 명확하게 공개했다.

향후에는 실제 이미지에 충분한 시각적 내용이 포함됐는지 검사하는 별도의 기준을 추가할 수 있다고 설명한다.

수학적 정확성과 시각적 품질은 다른 문제

Pramaan은 디자인의 미적 완성도를 평가하는 도구가 아니다.

예를 들어 어떤 문양이 아름다운지, 실제 전통 공예를 충실하게 표현했는지, 문화적인 의미를 올바르게 반영했는지는 검증하지 않는다.

또한 실제 인쇄물이나 제조용 디자인으로 사용할 수 있는지도 평가하지 않는다.

현재 검증 대상은 64×64 격자에서 정의한 수학적 규칙의 충족 여부다.

따라서 특정 모델이 Pramaan에서 높은 점수를 기록했다고 해서 일반적인 이미지 생성 품질이나 디자인 능력이 더 뛰어나다고 판단할 수는 없다.

이번 연구는 비교적 작은 규모의 실험이다.

72개 작업만으로 모든 구조화된 생성 작업의 성능을 판단할 수는 없다.

그럼에도 AI가 생성한 결과를 다른 AI에게 평가하도록 맡기는 대신 독립적인 프로그램으로 검증하는 방식을 실제로 구현했다는 점에서 살펴볼 가치가 있다.

특히 최근 AI 코딩 에이전트와 업무 자동화 시스템에서도 비슷한 문제가 발생하고 있다.

모델이 작업을 완료했다고 설명하더라도 실제 파일이나 데이터베이스가 올바르게 변경됐는지 확인해야 하기 때문이다.

이번 연구는 생성형 AI의 평가에서 그럴듯한 결과와 실제로 검증된 결과를 구분해야 한다는 문제를 구체적인 사례로 보여준다.

---

2️⃣ AI 제품·서비스

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

3️⃣ 개발 도구·에이전트

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

4️⃣ 산업·정책·안전

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

📚 추천 글

AtMem routed-v4 on DolphinBench: 479/600, and what the failed actions show

• 저자: Javad Taghia
• 발행: Hugging Face Community / 독립 에이전트 연구
• 게시일: 2026-10-31
• 원문: Hugging Face — AtMem routed-v4 on DolphinBench: 479/600, and what the failed actions show

---

AI 에이전트가 사용자의 요청을 이해하고도 실제 작업을 올바르게 수행하지 못하는 이유는 무엇일까?

이번 글은 개인적인 기억과 외부 도구를 사용하는 AI 에이전트의 성능을 실제 평가 데이터로 분석한다.

특히 단순히 벤치마크 점수가 몇 퍼센트 개선됐다는 사실보다 실패한 작업을 다시 분석해 정확히 어느 단계에서 무엇이 잘못됐는지 추적한 과정이 흥미롭다.

대답을 잘하는 것과 실제 행동을 완료하는 것은 다르다

일반적인 언어모델 평가에서는 사용자가 질문하면 모델이 생성한 답변을 검사한다.

예를 들어 특정한 정보를 정확하게 설명했는지 확인할 수 있다.

하지만 AI 에이전트는 실제 외부 프로그램을 사용할 수 있다.

예를 들어 사용자가 캘린더에 일정을 추가하라고 요청했다고 가정해 보자.

에이전트가 일정이 추가됐다고 답변했더라도 실제 캘린더에 이벤트가 생성되지 않았다면 작업은 실패한 것이다.

이런 문제를 평가하기 위해 DolphinBench라는 벤치마크가 사용된다.

DolphinBench에는 이메일과 캘린더, 문서와 코드 리뷰, 여행 관련 업무 등이 포함된다.

각 작업에는 가상의 사용자가 존재한다.

해당 사용자는 과거 대화와 선호, 일정과 여러 업무 정보를 가지고 있다.

AI 에이전트는 이러한 정보를 참고해 실제 연결된 프로그램의 도구를 호출해야 한다.

평가에서는 모델의 최종 답변보다 실제 도구 호출과 그 결과를 중요하게 다룬다.

600개 작업에서 성공률 65.00% → 79.83%

연구자는 AtMem이라는 기억 시스템을 사용하는 에이전트를 평가했다.

AtMem은 과거 대화에서 유용한 정보를 저장하고 필요한 순간에 검색하도록 돕는 시스템이다.

이번 평가에서는 600개 작업을 사용했다.

이전 버전과 새로운 실행 구성을 비교한 결과는 다음과 같다.

새로운 실행 구성에서는 기존에 실패했던 120개 작업을 성공시켰다.

하지만 기존에 성공했던 작업 가운데 31개는 새롭게 실패했다.

따라서 순증가한 성공 작업은 89개였다.

여기서 중요한 점은 모든 변화가 긍정적인 것은 아니라는 사실이다.

새로운 구조를 추가하면서 일부 작업이 개선됐지만 다른 작업에서는 문제가 발생했다.

실제 AI 에이전트 시스템에서는 이런 현상을 Regression(회귀 또는 기능 퇴행)이라고 한다.

새로운 변경사항을 적용한 뒤 이전에 정상적으로 작동하던 기능이 실패하는 상황이다.

또한 이번 수치는 연구자가 직접 실행하고 평가한 결과다.

독립적인 벤치마크 운영기관이 공식 순위로 승인한 결과는 아니다.

새로운 모델보다 실행 구조를 변경

이번 연구에서 중요한 부분은 기반 모델을 새롭게 학습하지 않았다는 점이다.

연구자는 에이전트 주변의 실행 구조를 변경했다.

주요 변경사항은 네 가지다.

Route Guard는 사용자가 특정한 연결 프로그램에서 작업하라고 요청했을 때 에이전트가 다른 실행 경로로 우회하는 일을 제한한다.

예를 들어 사용자가 연결된 캘린더에 일정을 추가하라고 요청했는데 에이전트가 로컬 컴퓨터의 다른 프로그램에 기록하려 한다면 이를 차단할 수 있다.

Commit Checkpoint는 중요한 쓰기 작업을 수행하기 전에 관련 기억을 다시 확인하도록 만든다.

예를 들어 사용자에게 중요한 이메일을 보내기 전에 과거 대화에 수신자나 금액, 승인 조건에 관한 정보가 있는지 확인하도록 유도한다.

Completion Tracking은 요청한 작업이 실제로 완료됐는지 추적한다.

도구 호출이 실패했거나 결과가 확인되지 않았다면 작업이 완료됐다고 판단하지 않도록 돕는다.

Standing Facts는 사용자의 과거 대화에서 장기간 유효할 수 있는 규칙과 선호를 추출해 제공한다.

예를 들어 특정 금액 이상의 결제에는 반드시 승인이 필요하다는 규칙을 저장할 수 있다.

이렇게 하면 모델의 능력을 직접 변경하지 않고도 실제 작업의 성공률을 높일 가능성이 있다.

실패한 123개 쓰기 작업 분석

연구자는 실패한 작업을 다시 실행 기록 수준에서 분석했다.

전체 평가에는 727개의 필수 행동 그룹이 존재했다.

이 가운데 읽기 작업은 100개였으며 98개가 성공했다.

쓰기 작업은 627개였고 504개가 성공했다.

따라서 실패한 쓰기 작업은 123개였다.

연구팀은 이 123개를 다시 분류했다.

가장 많은 문제는 필수 정보가 누락된 경우였다.

예를 들어 일정이 특정한 장소에서 진행돼야 하는데 실제 캘린더 이벤트에는 장소가 빠질 수 있다.

또는 결제 승인 조건을 이메일에 포함해야 하는데 해당 조건을 생략할 수 있다.

이런 경우 에이전트는 실제로 도구를 실행했다.

하지만 도구에 전달한 내용이 사용자의 요구사항을 충분히 만족하지 못했다.

이는 중요한 차이다.

올바른 프로그램을 호출하는 능력과 올바른 내용을 전달하는 능력은 서로 다르다.

기억을 불러왔다고 반드시 적용하는 것은 아니다

연구자가 확인한 가장 흥미로운 실패 유형은 저장된 정보를 실제로 불러왔는데도 최종 행동에 반영하지 않은 사례다.

예를 들어 과거 대화에 특정 금액 이상의 결제는 항상 수동 검토가 필요하다는 규칙이 존재한다고 가정해 보자.

에이전트가 해당 기억을 검색하고 읽었다.

그런데 실제로 발송한 이메일에는 그 조건이 충분히 반영되지 않았다.

이 경우 기억 검색은 성공했지만 실제 작업은 실패했다.

연구자는 이런 상황을 명확한 증거로 확인한 사례가 2개라고 밝혔다.

다만 나머지 실패에서 같은 문제가 존재하지 않았다는 의미는 아니다.

기억이 실제로 전달됐는지 확인할 증거가 충분하지 않은 사례도 있기 때문이다.

따라서 연구자는 기억이 전달됐지만 사용되지 않은 문제가 정확히 두 번만 발생했다고 주장하지 않는다.

확인 가능한 사례가 최소 두 개 존재한다는 의미다.

이러한 구분은 AI 에이전트의 실패를 분석할 때 중요하다.

기억 시스템이 잘못됐는지, 모델이 기억을 잘못 해석했는지, 실제 도구 호출에서 정보가 누락됐는지를 구분해야 하기 때문이다.

평가 결과의 중요한 한계

이번 연구는 공개된 600개 벤치마크 작업을 개발 과정에서도 활용했다.

따라서 새로운 작업을 처음 접했을 때의 일반화 성능을 측정한 독립 테스트가 아니다.

또한 각 작업은 한 번씩 실행됐다.

언어모델의 결과는 실행할 때마다 달라질 수 있으므로 반복 실행에 따른 변동성도 별도로 측정되지 않았다.

실험에 사용한 AtMem 버전은 특정한 연구용 커밋이며 현재 공개된 베타 버전과도 차이가 있다.

따라서 이번 성공률을 공개 제품의 일반적인 성능이라고 해석해서는 안 된다.

그럼에도 이번 글은 AI 에이전트의 실제 실패를 분석하는 방법을 자세하게 설명한다.

특히 도구 선택과 기억 검색, 실제 입력값, 작업 완료 여부를 서로 다른 단계로 나누어 평가해야 한다는 점에서 참고할 가치가 있다.

---

Clover-35B-A3B-Preview: A New Way for Intelligence

• 저자: DiffuSpace Core Team
• 발행: DiffuSpace / Hugging Face
• 게시일: 2026-10-30
• 원문: Hugging Face — Clover-35B-A3B-Preview: A New Way for Intelligence
• 관련 원문: Hugging Face — Clover-35B-A3B-Preview 모델

---

최근 대부분의 언어모델은 답변을 한 토큰씩 생성한다.

예를 들어 모델이 문장을 작성할 때 첫 번째 토큰을 생성한 뒤 그 결과를 참고해 두 번째 토큰을 생성하는 방식이다.

이런 구조를 Autoregressive Model(자기회귀 모델)이라고 한다.

현재의 많은 대형 언어모델은 이 방식을 사용한다.

하지만 자기회귀 모델에서는 다음 토큰을 생성하기 전에 이전 토큰의 계산이 완료돼야 한다.

따라서 출력이 길어질수록 생성에 필요한 시간이 증가할 수 있다.

이번 글은 이런 문제를 해결하기 위해 Diffusion Language Model(확산 언어모델)을 사용한 새로운 연구를 소개한다.

특히 모델을 단순히 빠르게 만드는 것뿐 아니라 실제 코딩 에이전트와 도구 호출 작업에서도 높은 성능을 유지할 수 있는지 평가했다.

언어모델에 확산 구조를 적용

확산 모델은 이미지 생성에서 널리 사용되는 기술이다.

일반적인 확산 모델은 무작위 잡음에서 시작해 여러 단계를 거쳐 원하는 이미지를 생성한다.

언어모델에서는 비슷한 개념을 토큰 생성에 적용할 수 있다.

예를 들어 하나의 문장을 처음부터 왼쪽에서 오른쪽으로만 작성하는 대신 여러 토큰의 후보를 만들고 반복적으로 수정하는 방식이다.

Clover는 이런 구조 가운데 Block Diffusion(블록 단위 확산)을 사용한다.

모델은 텍스트를 일정한 크기의 블록으로 나누어 생성한다.

각 블록 안에서는 여러 토큰의 관계를 양방향으로 참고하면서 결과를 수정할 수 있다.

반면 이미 생성된 이전 블록의 정보는 별도의 압축된 상태로 관리한다.

이렇게 하면 긴 과거 문맥을 참고하면서도 현재 생성 중인 블록을 병렬로 처리할 수 있다.

350억 파라미터 가운데 30억 개만 활성화

Clover-35B-A3B-Preview는 약 350억 개의 전체 파라미터를 가진 모델이다.

하지만 실제로 토큰 하나를 처리할 때 활성화되는 파라미터는 약 30억 개다.

이는 MoE(Mixture of Experts) 구조를 사용하기 때문이다.

MoE는 여러 전문 신경망 가운데 필요한 일부만 선택적으로 실행하는 모델 구조다.

Clover는 이러한 MoE와 확산 언어모델을 결합했다.

연구팀은 기존 Qwen 계열의 모델 구조를 바탕으로 학습했다.

이후 Bidirectional Gated DeltaNet을 블록 단위 생성에 맞게 다시 설계했다.

Gated DeltaNet은 이전 입력의 정보를 내부 상태에 요약해 순차적으로 처리하는 신경망 구조다.

Clover는 기존에 생성한 텍스트의 정보를 압축된 상태로 유지하면서 현재 블록 안의 토큰끼리는 양방향으로 정보를 교환하도록 만들었다.

이런 구조는 과거의 모든 토큰을 매번 자세하게 다시 계산하는 부담을 줄이려는 접근이다.

코딩 에이전트 평가 결과

DiffuSpace는 여러 코딩과 도구 사용 벤치마크에서 Clover를 평가했다.

대표적인 결과는 다음과 같다.

SWE-bench Verified는 실제 소프트웨어 저장소의 문제를 해결하는 능력을 평가한다.

Terminal-Bench는 터미널 환경에서 명령을 실행하고 여러 단계의 작업을 완료하는 능력을 측정한다.

τ³는 실제 업무 형태의 여러 단계 작업과 도구 사용을 평가하는 벤치마크다.

DiffuSpace는 이번 비교에서 Clover가 비슷한 규모의 Qwen 모델과 다른 확산 언어모델보다 높은 점수를 기록했다고 밝혔다.

다만 이러한 결과는 DiffuSpace가 직접 수행한 평가다.

모든 모델을 외부 독립기관이 동일한 조건으로 다시 검증한 결과는 아니다.

또한 어떤 에이전트 실행 환경을 사용했는지에 따라 실제 작업 성공률이 달라질 수 있다.

초당 680토큰의 생성 속도

연구팀은 실제 추론 속도도 공개했다.

단일 NVIDIA GB300 GPU에서 BF16 정밀도와 배치 크기 1을 사용했을 때 초당 680토큰을 생성했다고 밝혔다.

NVIDIA H200 GPU에서는 초당 515토큰을 기록했다.

비교 대상으로 사용한 Qwen 모델의 최적화된 실행 구성은 H200에서 초당 365토큰이었다.

다만 이 결과는 특정한 내부 에이전트 작업을 대상으로 측정했다.

모든 종류의 입력과 출력 길이에서 같은 속도가 나타난다는 의미는 아니다.

또한 실제 에이전트의 전체 작업 시간에는 모델 추론뿐 아니라 웹 검색과 프로그램 실행, 외부 API 응답시간도 포함된다.

따라서 출력 생성 속도가 두 배 빨라진다고 해서 전체 에이전트 작업도 반드시 두 배 빨라지는 것은 아니다.

로컬 GPU에서도 실행 가능

연구팀은 Clover의 INT4 양자화 버전을 16GB VRAM을 가진 NVIDIA RTX 5070 Ti에서 실행한 사례도 공개했다.

Quantization(양자화)은 모델의 가중치를 낮은 정밀도로 표현해 메모리 사용량과 일부 계산 비용을 줄이는 기술이다.

해당 환경에서는 MATH-500 평가에서 초당 101.8토큰을 생성했다고 밝혔다.

다만 이는 특정한 양자화와 실행 구성에서 얻어진 결과다.

일반적인 16GB GPU에서 모든 설정과 컨텍스트 길이를 동일하게 사용할 수 있다는 의미는 아니다.

또한 낮은 정밀도로 변환하면 일부 계산 결과가 달라질 수 있으므로 원래 모델과의 정확도 비교가 필요하다.

Clover의 모델 가중치와 관련 코드는 Apache 2.0 라이선스로 공개됐다.

하지만 발표 시점에는 일부 실행 엔진과 코딩 에이전트 도구의 통합이 개발 중이었다.

특히 연구팀이 소개한 별도의 구조화된 판단 모델은 향후 공개할 계획이므로 현재 Clover의 기본 모델과 구분해야 한다.

이번 글은 언어모델의 발전이 파라미터 규모와 학습 데이터의 증가뿐 아니라 토큰을 어떤 순서와 구조로 생성할 것인가라는 근본적인 아키텍처 연구에서도 진행되고 있음을 보여준다.

---

Making Offline Speech APIs Behave Like a Streaming Conversation

• 저자: Gökdeniz Gülmez
• 발행: Hugging Face Community / JOSIE-Voice 개발 프로젝트
• 게시일: 2026-10-31
• 원문: Hugging Face — Making Offline Speech APIs Behave Like a Streaming Conversation

---

실시간 음성 AI를 만들려면 반드시 실시간 음성 처리를 지원하는 모델이 필요할까?

예를 들어 사용자가 AI 음성 비서에게 질문한다고 가정해 보자.

사용자는 자신이 말하는 동안 음성 인식 결과가 화면에 나타나기를 기대할 수 있다.

또한 질문을 마친 뒤 AI가 가능한 한 빠르게 대답하기를 원할 수 있다.

하지만 실제 음성 인식 모델과 음성 합성 모델이 항상 실시간 입력을 지원하는 것은 아니다.

일부 음성 인식 모델은 완성된 녹음 파일을 전달받아야 결과를 반환한다.

음성 합성 모델도 완성된 문장을 입력받아야 실제 소리를 생성할 수 있다.

이번 글은 이런 제한을 가진 모델을 사용하면서도 실시간 대화와 비슷한 사용자 경험을 만드는 소프트웨어 구조를 설명한다.

특히 모델의 가중치를 변경하거나 새로운 음성모델을 학습시키지 않고, 입력과 출력의 처리 순서를 변경하는 방법에 집중했다는 점이 유용하다.

스트리밍에는 서로 다른 세 가지 의미가 있다

일반적으로 스트리밍이라고 하면 데이터를 조금씩 전달하는 방식을 생각하기 쉽다.

하지만 음성 AI에서는 세 가지 능력을 구분해야 한다.

첫 번째는 새로운 음성 데이터를 점진적으로 전달받는 능력이다.

두 번째는 이전 음성을 처리한 내부 상태를 유지하면서 새로운 음성을 처리하는 능력이다.

세 번째는 전체 결과가 완성되기 전에 일부 출력을 반환하는 능력이다.

이 세 기능은 서로 다르다.

예를 들어 어떤 음성 합성 모델은 완성된 문장을 입력받아야 한다.

하지만 실제 음성을 생성할 때는 소리의 일부를 순차적으로 반환할 수 있다.

이 경우 출력은 스트리밍이지만 입력은 스트리밍이라고 보기 어렵다.

저자는 이런 차이를 명확하게 구분해야 실제 시스템의 성능을 정확하게 이해할 수 있다고 설명한다.

전체 음성을 조금씩 다시 인식

이번 프로젝트인 JOSIE-Voice에서는 음성 인식 모델을 반복적으로 호출하는 방법을 사용했다.

처음에는 사용자가 말한 첫 번째 구간의 음성을 인식한다.

이후 새로운 음성이 들어오면 기존 음성과 새로운 음성을 합쳐 다시 인식한다.

예를 들어 다음과 같은 방식이다.

이 방식에서는 사용자가 말을 끝내기 전에도 임시 인식 결과를 화면에 표시할 수 있다.

다만 임시 결과는 확정된 문장이 아니다.

예를 들어 처음에는 특정 단어로 인식했더라도 이후 음성을 추가로 들으면 앞선 단어의 해석이 달라질 수 있다.

따라서 새로운 결과가 도착했을 때 이전의 임시 텍스트를 단순히 뒤에 이어 붙여서는 안 된다.

기존의 임시 인식 결과를 새로운 결과로 교체해야 한다.

JOSIE-Voice는 초기 음성 버퍼를 약 0.4초로 설정하고 이후 약 0.6초 간격으로 새로운 부분 인식을 요청하도록 구성했다.

하지만 0.6초마다 요청한다는 사실이 실제 음성 인식 결과가 항상 0.6초 이내에 반환된다는 의미는 아니다.

모델의 실행 시간은 하드웨어와 입력 길이에 따라 달라진다.

반복 인식에는 계산 비용이 증가

이 방식에는 단점이 있다.

음성이 길어질수록 이미 인식한 앞부분을 계속 다시 처리해야 한다.

예를 들어 10초 동안 사용자가 말한다면 마지막 인식 요청에서는 전체 10초의 음성을 다시 처리해야 한다.

따라서 여러 번의 호출에서 처리한 전체 음성 길이의 합은 실제 녹음 길이보다 훨씬 커질 수 있다.

저자는 음성의 길이를 L, 인식 요청 간격을 Δ라고 할 때 반복적으로 처리하는 전체 음성 길이가 대략 다음과 비례할 수 있다고 설명한다.

L² / (2Δ)

즉 발언이 길어질수록 중복 처리 비용이 빠르게 증가할 수 있다.

이는 일반적인 짧은 음성 대화에는 활용할 수 있지만 장시간 강의나 회의의 전체 녹음을 처리하는 데는 비효율적일 수 있다는 의미다.

저자는 이런 상황에서는 실제 증분 처리를 지원하는 음성 인식 모델이나 다른 구간 관리 방법이 더 적합할 수 있다고 설명한다.

AI의 답변은 문장 단위로 음성 생성

출력에서는 반대 문제가 발생한다.

언어모델은 답변을 토큰 단위로 조금씩 생성할 수 있다.

하지만 음성 합성 모델은 완성된 문장을 필요로 할 수 있다.

JOSIE-Voice는 이를 해결하기 위해 언어모델이 생성한 텍스트를 문장이나 절 단위로 나눈다.

첫 번째 문장이 완성되면 전체 답변이 끝나지 않았더라도 음성 합성 모델에 전달한다.

이후 언어모델이 두 번째 문장을 생성하는 동안 첫 번째 문장의 음성을 합성하거나 재생할 수 있다.

이렇게 하면 모델이 전체 답변을 완성할 때까지 기다릴 필요가 줄어든다.

이를 Pipelining(파이프라이닝)이라고 한다.

여러 처리 단계를 순차적으로 모두 끝낸 뒤 다음 작업을 시작하는 대신 서로 다른 단계를 겹쳐 실행하는 방식이다.

예를 들어 첫 번째 문장의 음성을 재생하는 동안 두 번째 문장을 생성하고 세 번째 문장을 준비할 수 있다.

하지만 문장마다 별도로 음성을 합성하면 억양과 말의 흐름이 부자연스러워질 수 있다.

각 문장 사이에 불필요한 침묵이 발생할 수도 있다.

따라서 저자는 음성 구간의 앞뒤에 포함된 침묵을 정리하고 문장 사이의 연결을 조정하는 방법도 설명한다.

도구 호출이 발생하면 음성 버퍼를 비워야 한다

이번 글에서 특히 흥미로운 부분은 AI 에이전트의 도구 호출과 음성 출력이 충돌하는 상황이다.

예를 들어 AI가 사용자의 질문을 듣고 외부 정보를 검색하려 한다고 가정해 보자.

모델은 먼저 사용자에게 확인해 보겠다는 짧은 문장을 생성할 수 있다.

이후 웹 검색 도구를 호출한다.

그런데 음성 출력 프로그램이 문장 경계를 제대로 인식하지 못한다면 짧은 안내 문장을 아직 음성으로 변환하지 않고 버퍼에 보관할 수 있다.

이 경우 사용자는 아무런 소리도 듣지 못한 채 검색 결과가 도착할 때까지 기다리게 된다.

저자는 이를 해결하기 위해 도구 호출이 시작되는 시점을 별도의 문장 경계로 취급한다.

도구 호출이 발생하면 현재까지 생성된 텍스트를 음성 합성 시스템에 전달하도록 한다.

이렇게 하면 실제 검색이 실행되는 동안 사용자에게 짧은 안내 음성을 제공할 수 있다.

다만 모든 도구 호출에 대해 실제로 안내 음성을 출력해야 하는 것은 아니다.

사용자에게 알릴 필요가 없는 내부 작업도 있을 수 있기 때문이다.

사용자가 중간에 말을 끊으면 어떻게 할까?

실시간 음성 비서에서는 사용자가 AI의 말을 중간에 끊는 상황도 처리해야 한다.

이를 Interruption(중단) 또는 Barge-in(사용자 끼어들기)이라고 한다.

예를 들어 AI가 긴 설명을 하고 있는데 사용자가 다른 질문을 시작할 수 있다.

이 경우 언어모델의 생성만 중단해서는 충분하지 않다.

이미 생성된 음성 데이터가 대기열에 남아 있을 수 있기 때문이다.

저자는 다음 작업들을 함께 처리해야 한다고 설명한다.

현재 생성 중인 답변을 중단해야 한다.

아직 재생되지 않은 음성 데이터를 제거해야 한다.

이전 답변에서 늦게 도착한 음성 합성 결과도 무시해야 한다.

이런 작업이 올바르게 구현되지 않으면 사용자가 새로운 질문을 했는데 이전 질문의 답변이 뒤늦게 재생될 수 있다.

이번 글은 완성된 새로운 음성모델을 소개하는 자료가 아니다.

저자는 기존에 알려진 처리 기법을 실제 애플리케이션에 적용한 엔지니어링 사례라고 명시했다.

또한 제시된 일부 지연시간 설명은 실제 하드웨어 벤치마크가 아니라 가정된 처리 조건을 이용한 분석이다.

그럼에도 모델이 제공하는 기능과 실제 사용자 경험 사이의 차이를 애플리케이션의 실행 구조로 해결할 수 있다는 점에서 음성 AI 개발에 유용한 자료다.

---

AI Video Upscaling With Real-ESRGAN and ffmpeg: A Measured CPU Run

• 저자: Jacob Yang
• 발행: Hugging Face Community / 독립 엔지니어링 블로그
• 게시일: 2026-11-01
• 원문: Hugging Face — AI Video Upscaling With Real-ESRGAN and ffmpeg: A Measured CPU Run

---

AI를 이용해 영상의 해상도를 높이면 일반적인 이미지 확대보다 항상 좋은 결과를 얻을 수 있을까?

이번 글은 실제 영상의 해상도를 네 배로 높이는 실험을 통해 그 질문을 검토한다.

특히 AI 기반 업스케일링 모델 두 종류와 전통적인 이미지 확대 방법 두 종류를 같은 조건에서 비교했다.

단순히 AI 모델의 출력이 더 선명하다는 설명에 그치지 않고 처리 속도와 픽셀 정확도, 선명도와 영상의 깜빡임까지 측정했다는 점에서 읽어볼 가치가 있다.

일반적인 영상 확대와 AI 업스케일링

영상의 해상도를 높이는 작업을 Upscaling(업스케일링)이라고 한다.

예를 들어 240×136 크기의 영상을 960×544 크기로 변환할 수 있다.

가로와 세로를 각각 네 배로 확대하는 것이다.

전통적인 이미지 확대에서는 주변 픽셀의 색상과 위치를 이용해 새로운 픽셀을 계산한다.

대표적인 방법에는 Bicubic과 Lanczos가 있다.

Bicubic은 주변 픽셀의 값을 이용해 부드러운 보간 결과를 생성한다.

Lanczos는 필터 함수를 이용해 기존 이미지의 특징을 유지하면서 새로운 픽셀을 계산한다.

이런 방법은 일반적으로 원본에 존재하지 않는 세부적인 구조를 새롭게 만들어내지는 않는다.

반면 AI 기반 업스케일링은 학습한 이미지 패턴을 바탕으로 새로운 세부 묘사를 생성할 수 있다.

예를 들어 매우 작은 사진에서 나무의 표면이나 동물의 털을 더 자세하게 표현할 수 있다.

하지만 이렇게 생성한 세부 묘사가 실제 원본의 정보와 정확하게 일치한다는 보장은 없다.

두 가지 Real-ESRGAN 모델 비교

저자는 Real-ESRGAN이라는 이미지 업스케일링 모델을 사용했다.

Real-ESRGAN은 저해상도 이미지를 더 높은 해상도로 변환하도록 학습된 모델 계열이다.

이번 실험에서는 두 가지 모델을 비교했다.

첫 번째는 realesr-general-x4v3다.

약 4.9MB 크기의 상대적으로 작은 모델이다.

두 번째는 RealESRGAN_x4plus다.

약 67MB 크기의 더 큰 모델이다.

두 모델 모두 이미지를 가로와 세로 각각 네 배로 확대할 수 있다.

저자는 8개의 가상 CPU를 가진 Intel Xeon 서버에서 두 모델을 실행했다.

GPU는 사용하지 않았다.

평가 영상에는 Blender Foundation의 공개 애니메이션인 Big Buck Bunny를 사용했다.

원본 영상에서 4초 분량을 추출했다.

이후 240×136 해상도로 축소하고 압축한 영상을 입력으로 사용했다.

출력은 다시 960×544 크기로 확대했다.

이렇게 하면 실제 원본과 업스케일링 결과를 같은 크기로 비교할 수 있다.

작은 모델은 30초, 큰 모델은 4분 이상

CPU 환경에서 측정한 실행 결과는 다음과 같다.

FPS(Frames Per Second)는 초당 처리할 수 있는 영상 프레임의 수다.

작은 모델은 초당 약 네 프레임을 처리했다.

반면 큰 모델은 초당 약 0.47프레임을 처리했다.

즉 큰 모델을 사용한 경우 약 8.5배 더 많은 시간이 필요했다.

하지만 큰 모델이 항상 더 좋은 결과를 생성한 것도 아니었다.

이는 모델의 크기와 실행 비용이 실제 작업의 품질을 보장하지 않는다는 점을 보여준다.

AI 모델보다 전통적인 확대 방법의 픽셀 정확도가 높았다

저자는 실제 원본 영상과 업스케일링 결과를 비교했다.

평가에는 PSNR과 SSIM을 사용했다.

PSNR(Peak Signal-to-Noise Ratio)은 두 이미지 사이의 픽셀 차이를 측정하는 지표다.

SSIM(Structural Similarity Index)은 두 이미지의 밝기와 대비, 구조적 유사성을 비교하는 지표다.

일반적으로 두 지표 모두 높을수록 원본과 유사하다는 의미다.

실험 결과는 다음과 같았다.

흥미롭게도 전통적인 Lanczos 방식이 두 지표에서 가장 높은 점수를 기록했다.

가장 큰 AI 모델인 x4plus는 오히려 가장 낮은 점수를 기록했다.

하지만 실제 이미지를 보면 AI 기반 결과가 더 선명하게 느껴질 수 있다.

왜 이런 차이가 발생할까?

AI 모델이 원본에 존재하지 않던 세부적인 묘사를 만들어내기 때문이다.

예를 들어 저해상도 영상에서는 나무의 표면과 동물의 털이 거의 구분되지 않을 수 있다.

AI 모델은 학습한 패턴을 이용해 이러한 세부 묘사를 복원하려 한다.

하지만 실제 원본의 나무 표면과 완전히 같은 위치에 선을 생성하지 않을 수 있다.

사람에게는 자연스럽게 보이더라도 픽셀 단위로 비교하면 차이가 발생한다.

따라서 원본과의 픽셀 정확도는 낮아질 수 있다.

이는 Perceptual Quality(사람이 지각하는 시각적 품질)와 수치적인 유사도가 반드시 일치하지 않는다는 문제다.

선명도를 높이면 깜빡임도 증가

저자는 영상의 시간적 안정성도 평가했다.

일반적인 이미지 업스케일링 모델을 영상에 적용하면 각 프레임을 독립적으로 처리할 수 있다.

하지만 서로 인접한 프레임은 거의 같은 장면을 보여주는 경우가 많다.

예를 들어 카메라가 천천히 이동하는 상황에서 나무 표면의 세부 묘사가 프레임마다 다르게 생성될 수 있다.

이 경우 영상을 재생하면 표면의 질감이 흔들리거나 깜빡이는 것처럼 보일 수 있다.

이를 Temporal Flicker(시간적 깜빡임)라고 한다.

저자는 선명도와 깜빡임을 각각 측정했다.

큰 AI 모델은 Lanczos보다 훨씬 높은 선명도 지표를 기록했다.

하지만 시간적 깜빡임도 증가했다.

즉 하나의 프레임을 보면 더 좋아 보일 수 있지만, 전체 영상을 재생하면 오히려 부자연스러운 움직임이 나타날 수 있다는 것이다.

이 결과는 AI 영상 처리에서 개별 이미지의 품질과 시간에 따른 일관성을 함께 평가해야 한다는 점을 보여준다.

PNG 파일을 수천 개 만들지 않는 처리 구조

저자는 영상 처리 파이프라인도 개선했다.

일반적인 방식에서는 영상을 개별 PNG 파일로 나눌 수 있다.

이후 각 PNG를 AI 모델로 처리하고 다시 영상으로 합친다.

하지만 영상이 길어지면 상당히 많은 중간 파일이 생성된다.

저자는 이를 해결하기 위해 ffmpeg의 파이프(Pipe) 기능을 사용했다.

파이프는 프로그램의 출력을 다른 프로그램의 입력으로 직접 전달하는 방식이다.

첫 번째 ffmpeg 프로세스가 영상을 개별 프레임의 데이터로 변환한다.

Python 프로그램은 그 프레임을 AI 모델에 전달한다.

이후 처리된 결과를 두 번째 ffmpeg 프로세스로 전달해 새로운 영상으로 저장한다.

이렇게 하면 모든 프레임을 별도의 이미지 파일로 저장할 필요가 없다.

하지만 이 방식이 GPU 사용이나 모든 영상 처리 환경에서 최적이라는 의미는 아니다.

실제 고해상도 영상에서는 메모리 관리와 프레임 배치, GPU 활용을 별도로 최적화해야 할 수 있다.

또한 이번 연구는 단일한 4초 영상과 CPU 환경을 기준으로 수행됐다.

따라서 모든 종류의 영상에서 같은 결과가 나타난다는 의미는 아니다.

이번 글은 AI 모델의 성능을 평가할 때 단순한 벤치마크 점수 하나보다 실제 사용자가 느끼는 품질과 처리 비용, 시간적 안정성을 함께 고려해야 한다는 점을 구체적인 실험으로 설명한다.

---

DecisionFormer: Fine-tune Any Hugging Face Model into a Calibrated Decision Model

• 저자: Vishesh Tripathi, Abhay Kumar, Rohit Sali, Ramsha Khan
• 발행: FrontiersMind / Hugging Face
• 게시일: 2026-10-26
• 원문: Hugging Face — DecisionFormer

---

AI 애플리케이션에서 사용자가 입력한 정보를 분류하거나 여러 선택지 가운데 하나를 결정하려면 반드시 언어모델이 문장을 생성해야 할까?

예를 들어 고객지원 시스템을 생각해 보자.

사용자가 다음과 같이 문의했다고 가정할 수 있다.

어제 배송된 상품이 파손돼 있어서 교환하고 싶습니다.

시스템은 이 문의를 어느 부서에 전달할지 판단해야 한다.

일반적인 생성형 AI에서는 모델에게 담당 부서를 질문하고 텍스트 형태의 답변을 받을 수 있다.

하지만 실제 프로그램에서 필요한 것은 긴 설명이 아닐 수 있다.

담당 부서가 반품인지, 결제인지, 기술지원인지 구분하는 값만 있으면 충분할 수 있다.

이런 상황에서는 모델이 자연어 문장을 생성하는 과정 자체가 불필요한 계산일 수 있다.

이번 글은 이런 문제를 해결하기 위한 오픈소스 라이브러리 DecisionFormer를 소개한다.

문장을 생성하지 않고 선택지의 확률 반환

DecisionFormer는 기존 언어모델을 Decision Model(판단 모델)로 변경하도록 돕는다.

판단 모델은 여러 선택지에 대해 확률을 계산하고 가장 적절한 결과를 반환하도록 설계된 모델이다.

예를 들어 고객지원 문의를 분석하는 모델이 다음과 같은 결과를 반환할 수 있다.

이 경우 프로그램은 별도의 자연어 답변을 분석하지 않고 바로 반품·교환 부서를 선택할 수 있다.

일반적인 언어모델은 다음 토큰의 확률을 계산한 뒤 실제 텍스트를 생성한다.

DecisionFormer는 이 과정에서 특정한 선택지에 해당하는 확률만 직접 읽는 방식을 사용한다.

이를 통해 하나의 Forward Pass(순전파)로 판단 결과를 반환할 수 있다.

순전파는 입력 데이터를 모델에 전달하고 여러 신경망 계층의 계산을 수행해 결과를 얻는 과정이다.

텍스트를 여러 토큰에 걸쳐 생성할 필요가 없으므로 일부 분류 작업에서는 계산 비용을 줄일 가능성이 있다.

다만 입력 처리 자체에 필요한 계산까지 사라지는 것은 아니다.

또한 모델의 크기와 실행 환경에 따라 실제 속도 차이는 달라질 수 있다.

세 가지 판단 유형

DecisionFormer는 세 가지 주요 판단 유형을 제공한다.

첫 번째는 Choice다.

여러 선택지 가운데 하나를 선택한다.

예를 들어 고객지원 문의의 담당 부서를 결정할 수 있다.

두 번째는 Noul이다.

참·거짓에 해당하는 판단을 수행한다.

예를 들어 고객이 영수증을 가지고 있는지 확인할 수 있다.

세 번째는 Score다.

정해진 여러 단계의 점수를 계산한다.

예를 들어 문의의 긴급도를 일반·주의·긴급으로 평가할 수 있다.

이런 구조에서는 여러 종류의 판단을 하나의 모델에서 수행할 수 있다.

개발자는 입력 데이터와 질문, 선택지를 구조화된 형태로 전달한다.

모델은 각 질문에 대한 확률과 선택 결과를 반환한다.

특히 모델이 미리 정의된 선택지 가운데 하나를 반환하므로 잘못된 문자열 형식이나 예상하지 못한 자연어 응답을 처리하는 부담을 줄일 수 있다.

확률과 확신도는 다르다

이번 글에서 중요한 부분은 모델이 반환하는 확률의 해석이다.

예를 들어 모델이 반품·교환 부서의 확률을 99%라고 반환했다고 가정해 보자.

이 수치가 실제로 100번 가운데 99번 정답을 맞힌다는 의미는 아닐 수 있다.

언어모델이 계산한 확률은 실제 정답의 발생 빈도와 일치하지 않을 수 있기 때문이다.

이를 Calibration(확률 보정) 문제라고 한다.

모델이 반환한 확률이 실제 정답률과 얼마나 일치하는지에 관한 문제다.

DecisionFormer는 검증 데이터를 이용해 확률의 분포를 조정하는 기능을 제공한다.

대표적으로 Temperature Scaling(온도 조정)을 사용할 수 있다.

온도 조정은 모델이 계산한 점수의 분포를 조절해 실제 정답 빈도와 더 잘 맞도록 만드는 방법이다.

하지만 이러한 보정도 실제 검증 데이터가 충분히 대표성을 가져야 효과를 기대할 수 있다.

예를 들어 학습 데이터에서는 반품 문의가 대부분이었다면 실제 서비스에서 발생하는 드문 유형의 문의에 대해서는 확률이 정확하지 않을 수 있다.

따라서 모델의 확률을 실제 업무의 승인 기준으로 사용할 때는 별도의 검증이 필요하다.

기존 모델을 여러 방식으로 추가 학습

DecisionFormer는 Hugging Face에서 제공되는 여러 모델을 판단 모델로 변경할 수 있도록 설계됐다.

지원하는 학습 방식에는 다음이 포함된다.

Fine-Tuning(미세조정)은 이미 학습된 모델을 특정한 작업에 맞게 추가 학습하는 과정이다.

LoRA(Low-Rank Adaptation)는 모델의 모든 가중치를 수정하지 않고 적은 수의 추가 파라미터를 학습하는 방법이다.

QLoRA는 기반 모델의 가중치를 낮은 정밀도로 저장하면서 LoRA를 적용하는 방식이다.

이런 접근은 대형 모델의 전체 가중치를 다시 학습시키는 것보다 필요한 GPU 메모리를 줄일 수 있다.

또한 개발자는 언어모델의 구조에 따라 Attention 방식을 선택할 수 있다.

Attention(어텐션)은 입력의 여러 부분 사이에서 어떤 정보가 중요한지 계산하는 기술이다.

일반적인 자기회귀 모델에서는 이전 토큰만 참고하는 인과적 어텐션이 사용된다.

반면 분류 작업에서는 전체 입력이 이미 제공돼 있으므로 앞뒤의 정보를 함께 참고하는 양방향 어텐션이 유리할 수 있다.

DecisionFormer는 이런 구조를 설정할 수 있도록 제공한다.

동일한 입력에서 같은 판단을 반환

DecisionFormer의 중요한 특징은 결과를 생성할 때 임의의 토큰 샘플링을 수행하지 않는다는 점이다.

일반적인 생성형 언어모델에서는 같은 질문을 여러 번 전달해도 서로 다른 문장이 생성될 수 있다.

하지만 DecisionFormer는 선택지의 확률을 직접 계산하므로 동일한 모델과 입력, 실행 조건에서 같은 판단 결과를 얻도록 설계됐다.

이를 Deterministic Inference(결정적 추론)라고 한다.

이런 특징은 반복적인 기업 업무에서 중요할 수 있다.

예를 들어 같은 고객지원 문의를 두 번 처리했을 때 담당 부서가 달라진다면 운영상의 혼란이 발생할 수 있다.

하지만 결정적인 판단 결과를 제공하면 같은 입력에 대해 일정한 처리 흐름을 구성하기 쉽다.

다만 모델 자체가 입력을 잘못 이해할 가능성까지 없어지는 것은 아니다.

결정적인 결과를 생성한다는 사실과 실제 판단이 정확하다는 사실은 서로 다르다.

오픈소스와 실제 제공 범위

DecisionFormer는 Apache 2.0 라이선스로 공개됐다.

Python과 PyTorch, Hugging Face Transformers를 기반으로 실행할 수 있다.

또한 LoRA와 QLoRA 학습, 여러 GPU를 사용하는 학습과 평가, HTTP API 제공 기능 등을 지원한다.

학습에 사용할 수 있는 deciformer-15k 데이터셋도 함께 공개됐다.

하지만 DecisionFormer를 설치했다고 해서 아무 모델이나 별도 학습 없이 모든 판단 업무에 정확하게 사용할 수 있다는 의미는 아니다.

실제 업무에 적용하려면 적절한 기반 모델과 학습 데이터를 선택해야 한다.

또한 서비스에서 발생하는 실제 입력을 이용해 정확도와 확률 보정 상태를 검증해야 한다.

이번 글은 생성형 AI의 모든 작업을 자연어 문장 생성으로 해결하려는 접근과 다른 방향을 제시한다.

작업의 결과가 명확한 선택지나 숫자로 표현될 수 있다면, 생성형 모델이 가진 언어 이해 능력을 유지하면서 출력 과정은 더 간단한 판단 모델로 바꿀 수 있다는 것이다.

특히 고객지원 분류와 문서 검토, 콘텐츠 정책 판단처럼 정해진 결과 형식이 중요한 업무에서 참고할 만한 기술 자료다.