Technical Post

개요 안녕하세요, 오늘은 AI 분야에서 많은 주목을 받고 있는 MCP와 에이전트 스킬에 대해서 이야기를 나누어 보려고 합니다. 포스트 세 줄 요약 MCP는 AI와 외부 세계를 연결하는 일종의 USB로, 사용자와 개발자에게 많은 편의를 제공합니다. 에이전트 스킬은 AI에게 전문 지식을 부여하기 위한 지침서로, 복잡한 업무를 쉽고 간단하게 처리할 수 있도록 합니다. Antigravitiy, Claude Code 등 여러 IDE에서 나만의 에이전트 스킬을 간단하게 만들 수 있습니다. 왜 MCP를 쓰는가? USB는 1996년에 디지털 데이터 전송 및 전력 공급을 위해 도입되었습니다. 왜 USB를 만들어야 했을까요? 바로 표준화를 위해서였습니다. USB가 없었다면 우리는 제조사마다, 전자 제품마다 다른 케이블 사서 덕지덕지 연결해야 했을지도 모릅니다. 하지만 USB가 있기 때문에, 어떤 스마트폰을 사더라도 기존에 쓰던 C 타입 충전기로 손쉽게 충전을 할 수 있습니다(물론, C 타입을 사용하지 않는 스마트폰이 있을 수도 있습니다…) MCP를 사용하는 이유도 마찬가지입니다. 소비자가 현재 사용할 수 있는 AI 서비스는 굉장히 많습니다. 그러한 서비스들은 사용자의 질문에 단순히 대답만 하는 것이 아닙니다. 검색도 하고, 직접 데이터도 가져오고, 그림을 그리기도 하고 일정을 관리하기도 합니다. 그런데 그 모든 서비스가 그러한 기능들을 각각 만들어야 한다면 어떨까요? 개발자: 우리 회사 서비스를 AI와 연결해 보자! ChatGPT랑은 이런 식으로 연결하면 되는구나. 그런데 Gemini는 또 다르게 연결해야 하는구나. 클로드는… (연결하는 방법 익히느라 시작도 못함) 사용자: 지금까지 쓰던 AI 서비스를 다른 걸로 바꾸었어. 그런데 내 드라이브나 캘린더에 연결하는 것도 일일이 다시 다 해 줘야 하네? 사용할 수 있는 것도 다르고. 너무 복잡해… 이런 식으로, USB 이전에 느꼈던 것과 비슷한 불편을 느끼고 있었을지도 모릅니다. 특히 새로운 AI가 나올 때마다 개발자들은 각 AI 규격에 맞추어 서비스를 따로 연동해야 하는, 소위 N x M 문제에 시달렸을 것입니다. 하지만 이제는 MCP가 있습니다. 개발자도, 사용자도 굉장히 편하게 AI 서비스를 만들고 사용할 수 있죠.

[DevLog] 긴 영상도 이해하는 AI, 'Clip AI' 개발기 (feat. Qwen3-Omni & Whisper) 안녕하세요. 최근 개발한 동영상 분석 및 문제 생성 서비스 'Clip AI'의 개발 과정을 공유합니다. 단순히 영상을 요약하는 것을 넘어, "이 내용이 영상의 정확히 어디에 나오는데?"라는 질문에 답할 수 있도록 근거 타임스탬프(Timestamp)를 함께 제공하는 것이 이 프로젝트의 핵심 목표였습니다. 최신 멀티모달 모델인 Qwen3-Omni와 Whisper를 활용한 파이프라인 구축 경험, 그리고 vLLM 서빙 과정에서 겪었던 시행착오를 정리했습니다. 🔗 서비스 바로가기: https://clipai.loclx.io 1. 왜 만들었나?: 할루시네이션 없는 근거 제시 생성형 AI로 영상을 요약할 때 가장 큰 문제는 '그럴듯한 거짓말(Hallucination)'입니다. 요약된 내용이 실제 영상에 존재하는지 검증하려면 사용자가 다시 영상을 처음부터 봐야 하는 번거로움이 있습니다. Clip AI는 이 문제를 해결하기 위해 다음 기능을 구현했습니다. 🎥 영상 & 음성 동시 분석: 시각 정보와 청각 정보를 모두 활용 ⏱️ 정밀한 타임스탬프: 요약 및 문제 정답이 영상의 몇 분 몇 초에 근거하는지 명시 🎬 긴 영상 지원: 최대 1시간 30분 분량의 장시간 동영상도 안정적으로 분석 가능 Clip AI의 메인 대시보드입니다. 우측 패널에서 요약, 문제와 함께 클릭 가능한 타임스탬프를 제공합니다. 2. 단일 모델의 한계와 하이브리드 파이프라인으로의 전환 처음부터 현재의 복잡한 파이프라인을 구상한 것은 아니었습니다. 개발 초기에는 최신 멀티모달 모델인 Qwen3-Omni의 강력한 성능을 믿고, 단일 모델로 모든 것을 해결하려 시도했습니다. 초기 접근 방식: "이 비디오 전체를 보고 내용을 요약해줘. 그리고 그 내용이 나오는 정확한 타임스탬프도 같이 적어줘."

개요 안녕하세요, Diffusion Model을 활용한 언어 모델링에 관심이 있는 주엽입니다. 이번 포스트에서는 상용 Language Diffusion Model의 첫걸음이 될지도 모르는 Large Language Diffusion Models에 대해서 리뷰해 보려고 합니다. 포스트 세 줄 요약 Large Language Diffusion Models는 NeurIPS 2025에 Oral로 게재 승인이 된 논문으로, Diffusion Model을 활용한 언어 모델인 LLaDA(Large Language Diffusion with mAsking)를 다룹니다. LLaDA는 LLM의 프레임워크 내에서 Diffusion Model의 이론을 적용시켰을 뿐 아니라 Scalability, In-context Learning 등 중요한 요소까지 갖추었습니다. Autoregressive 기반 LLM과 경쟁할 수 있을 만한 성능을 보였으며 특히 Reversal Poem Completion 작업에 대해 GPT-4o를 뛰어넘는 성능을 보였습니다. 참고 해당 포스트는 약간의 Inline 수식을 포함하고 있습니다. 해당 블로그 플랫폼에서는 이를 지원하지 않지만, 수식임을 알리기 위해 수정하지 않고 두었습니다. 수식을 그대로 보고 싶은 분들은 원본 노션 페이지를 참고해 주시기 바랍니다. Diffusion Models 먼저 Diffusion Model에 대해 간단히 소개하는 시간을 가질까 합니다. Diffusion Model은 두 가지 과정을 포함하는데요, 위 이미지가 이를 잘 나타내고 있습니다. Forward Process: 데이터에 잡음(Noise)을 추가하는 과정입니다. 위 이미지에서 오른쪽으로 갈수록 고양이가 흐려지는데, 바로 이 과정과 같습니다. 이 과정을 반복하면 결국에는 아무 형체도 알아볼 수 없는 깨끗한 잡음(Pure Noise)으로 수렴합니다. Reverse Process: 데이터에서 잡음을 제거하는 과정입니다. 위 이미지에서 왼쪽으로 갈수록 잡음이 없어지고 깨끗한 고양이가 되는데, 바로 이 과정과 같습니다. 이 과정을 반복하면 깨끗한 잡음에서 원래의 데이터를 복원할 수 있습니다.

Context Engineering / Memory 최근 에이전트 시스템에서 메모리의 중요성이 크게 부각되면서 이를 체계적으로 이해하고 적용하기 위해 내용을 정리했습니다. 구글의 Context Engineering: Sessions, Memory 백서를 비롯해 다양한 에이전트 프레임워크 문서와 관련 연구들을 참고하여, 최근 여러 서비스와 기술 행사에서 핵심 주제로 다뤄지고 있는 메모리 개념을 정리했습니다. 백서의 구조를 기반으로 주요 개념들을 재구성해 Context Engineering 관점에서 정리한 내용입니다. 1. Context Engineering 컨텍스트 엔지니어링은 단순히 시스템 프롬프트를 잘 작성하는 수준을 넘어, 모델 호출마다 필요한 정보 전체(payload)를 동적으로 구성하는 과정을 의미. 1.1 컨텍스트 엔지니어링이란 기본적으로 Prompt Engineering이 *"좋은 지침을 어떻게 기술할 것인가"*에 집중했다면, Context Engineering은 "모델 호출 시 주입되는 전체 정보(컨텍스트)를 어떻게 구성·관리할 것인가" 에 초점을 맞춘 더 상위적 개념입니다. 컨텍스트 엔지니어링의 목표는 모델이 작업을 완료하는 데 가장 관련성이 높은 정보를 필요한 만큼만 갖도록 하는 것입니다. 단순히 프롬프트 문장을 잘 쓰는 것을 넘어서, 시스템 프롬프트, 외부 지식, 대화 히스토리, 도구 출력 등 모델이 현재의 작업을 잘 수행하도록 필요한 모든 페이로드(payload)를 동적으로 설계하고 조정하는 것을 의미합니다. 1.2 구성 요소 및 계층 여기에는 다음 세 계층의 정보가 포함됩니다: Reasoning Context: 시스템 지침, 툴 정의, few-shot 예시 등 모델의 사고 방식과 행동 범위를 규정하는 정보 Evidential & Factual Data: 장기 메모리, 외부 지식(RAG), 다른 에이전트/도구의 출력 등 모델의 근거가 되는 정보 Immediate Conversation Context: 현재 대화, 최근 이벤트, 임시 상태(scratchpad) 등 즉시 필요한 정보

요즘 AI 컨텐츠 생성에 필수인 음성 AI ! 회의, 강의 녹음 후 전사 유튭 영상 나래이션 생성 어려운 자료 넣고 팟캐스트 생성 일상에 녹아든 음성 AI, 우리 회사에서는 어떻게 구현하고 있을까요? AI 엔지니어에게 직접 듣는 진짜 음성 AI 이야기! 영상 다시보기: https://www.youtube.com/live/nntfFtCY3XQ?t=510s 자료:

HELLO👋 안녕하세요! 롯데이노베이트 AI 기술팀 언어 AI 담당 이기훈, 유용상, 임형준입니다. 저희는 최근에 참여한 2025년 인공지능 말평에서 우수한 성과를 거두게 되어 그 경험과 성과를 여러분과 공유하고자 이 포스트를 작성하게 되었습니다!! 대회 개요 대회명 2025년 인공지능 말평 진행기간 2025.06.11 ~ 2024.10.17 주최사 국립국어원 개최 목표 한국어 어문 규범 기반 생성(RAG): 제시한 문제에서 문장을 교정하고 그 이유를 어문 규범에 근거하여 생성하는 과제 한국문화 질의응답: 한국의 역사, 사회, 전통문화 등 한국문화에 대한 객관식 주간식 문제에 답하는 과제 기사 및 수상자 선정 링크 https://www.news1.kr/life-culture/book/5811168 https://kli.korean.go.kr/benchmark/taskBoardsOrdtm/boardsOrdtm/noticeView.do?page=0&recordId=465&boardOrdtmId=&base.condition=boardOrdtm.title&base.keyword=&size=10

오늘은 RAG(Retrieval-Augmented Generation) 에 대해 개념을 잡고, 이 아이디어가 처음 제안된 2020년 Facebook AI Research의 논문을 간단히 살펴보려 합니다. 구체적으로는, RAG가 등장하게 된 배경과 기본 개념 원 논문 [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks]의 핵심 아이디어 그리고 이를 실제로 구현해본 간단한 실습 예제 (LangChain 기반 / No-LangChain 구현) 까지 다루어 보겠습니다. 1. RAG란? Retrieval-Augmented Generation (RAG)는 기존의 언어 모델이 가지고 있는 한계 — 예를 들어, 최신 정보 부족, 외부 지식 반영 어려움 등 — 을 극복하기 위해 등장한 방법입니다. RAG는 말 그대로, 👉 검색(Retrieval) + 생성(Generation) 과정을 결합한 방식입니다. 🔍 검색기(Retriever) 가 외부 문서(knowledge base)에서 관련 정보를 찾아오고, ✍️ 생성기(Generator) 가 그 정보를 바탕으로 자연어 응답을 생성합니다. 즉, 최신 뉴스나 특정 전문 지식을 묻는 질문에 대해, 단순히 내장된 파라미터만 사용하는 것이 아니라, 관련 문서를 찾아본 후 그 내용을 바탕으로 답을 생성하는 것이죠. 2. 📖 RAG는 언제, 어디서 제안되었을까? RAG라는 개념은 2020년, Facebook AI Research (FAIR) 팀의 논문 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" 에서 처음 공식적으로 제안되었습니다.

도커는 컨테이너를 이용하여 애플리케이션의 개발, 실행, 배포를 단순화할 수 있도록 도와주는 플랫폼입니다. 이 글에서는 도커의 주요 장점을 살펴보며, 왜 우리가 도커를 사용해야 하는지 알아보겠습니다. 프로그램의 격리 대부분의 프로그램은 단독으로 실행되지 않고, 특정한 실행 환경·라이브러리·다른 프로그램에 의존하여 동작합니다. 예를 들어, 하나의 물리적 서버에서 Django와 FastAPI를 동시에 구동한다고 가정해 보겠습니다. 두 프레임워크가 서로 다른 파이썬 버전을 요구한다면 충돌 문제가 발생할 수 있습니다. 이를 방지하기 위해 도커는 컨테이너 기술을 도입했습니다. 컨테이너는 서로 격리된 환경을 제공하여 프로그램 간 충돌을 막고, 여러 애플리케이션이 동일한 서버에서 동시에 실행되더라도 안정적으로 동작할 수 있도록 합니다. 가상머신에 비해 가벼운 컨테이너 방식 도커 컨테이너가 등장하기 이전에는, 하나의 물리적 서버에서 여러 환경을 제공하기 위해 주로 가상 머신이 사용되었습니다. 그러나 가상 머신은 각 환경을 구현하기 위해 하드웨어를 가상화하고 운영체제까지 별도로 구동해야 하므로, 컨테이너 방식에 비해 상대적으로 무겁고 비효율적이라는 단점이 있었습니다. 반면, 도커는 별도의 운영체제를 구동하지 않고 도커 엔진을 통해 호스트의 리눅스 커널을 공유하기 때문에, 각 컨테이너가 가볍고 빠르게 실행된다는 특징이 있습니다. 이미지 도커에서는 이미지를 기반으로 동일한 환경의 컨테이너를 손쉽게 생성할 수 있습니다. 또한, 도커 허브를 통해 다른 사람이 만들어둔 이미지를 활용하거나, 직접 만든 이미지를 공유할 수도 있습니다. 이러한 특성 덕분에 팀원들이 동일한 개발 환경을 손쉽게 재현할 수 있어, 협업과 배포 과정에서 큰 장점을 제공합니다 AI 서비스에서 도커의 장점 의존성 문제 해결 AI 개발환경은 파이썬 버전, 그래픽 드라이버 버전 등 다양한 의존성 문제로 인해 초기 환경 설정이 복잡하고 번거롭습니다. 그러나 Docker 컨테이너를 활용하면 미리 구성된 환경을 바로 가져와 사용할 수 있어 환경 설정에 소요되는 시간을 크게 줄일 수 있습니다.

자연어처리 분야의 세계 최고 권위 학회 중 하나인 EMNLP(Conference on Empirical Methods in Natural Language Processing) 2025 에서 메인 트랙으로 Accept된 ECO Decoding: Entropy-Based Control for Controllability and Fluency in Controllable Dialogue Generation 논문을 작성한 1저자 신승민 프로님과의 인터뷰를 정리했습니다. Q: EMNLP 2025 Accept 축하드립니다! 논문 내용을 소개해주실 수 있을까요? 감사합니다! "에코 디코딩(ECO Decoding)"이라는 방법을 제안했어요. AI가 단순히 질문에만 답하는 게 아니라 상황에 맞게 감정을 담아서 대답하거나, 상대방에 따라 적절한 대화 전략으로 말할 수 있도록 하는 제어가능한 대화(controllable generation) 태스크가 있는데요. 이 태스크에서 기존에는 언어 모델의 확률과 제어하고 싶은 속성의 확률을 곱해서 생성했는데, 이때 고정된 상수를 사용했거든요. 제안한 방법론에서는 이 상수를 동적으로 조절할 수 있게 만들어서, 자연스러운 대화와 원하는 제어 사이의 균형을 더 잘 맞출 수 있도록 했습니다. Q: ECO Decoding의 'ECO'는 어떤 의미인가요? ECO는 "Entropy-based Control"의 줄임말이에요. E-C-O해서 에코! 엔트로피를 활용한다는 뜻입니다. Q. 오.. 엔트로피를 활용한 점이 흥미로운데요. 더 자세히 말씀해주실 수 있나요? 실험 결과를 분석하다가 문제점을 발견했어요. 제어가 필요하지 않은 부분에서 굳이 강하게 제어해서 자연스러움이 떨어지거나, 반대로 제어가 필요한 부분에서 제어가 약해지는 경우들이 있었거든요. 예를 들어, "나는 어제 영화를 봤는데 매우"라고 했을 때 다음에 올 수 있는 단어가 다양하잖아요. "재밌었다", "지루했다" 등등. 이런 경우 모델의 확률이 고르게 분포돼요. 반면 "나는 밥을 먹었다"에서 "나" 다음에는 보통 조사가 와서 특정 토큰의 확률이 높죠. 이런 확률 분포의 차이를 엔트로피로 수치화할 수 있어서 사용하게 되었습니다.

"이번 달 우리 팀 매출 분석해줘" 말만 하면 SQL이 뚝딱! 🤖 게다가 SQL을 실행해서 결과까지 설명해준다고!? 🚀✨ 실제 실무에서 사용되는 Text2SQL기술과, 이 기술을 활용한 대화형 BI 서비스 아키텍처까지 다 다뤄본 이번 세미나, 이번에도 뜨거운 관심을 받으며 무사히 마쳤습니다! 관심 가져주신 모든 분들 감사드리며, 앞으로도 유익한 내용 전달드리겠습니다! 영상 다시보기: https://www.youtube.com/watch?v=exlqT6miBtI 자료:

AI 에이전트 시대가 온다! 요즘 많이 들리는 말이죠? 'AI 에이전트'에 대해 여러가지 말이 많은 요즈음, 한 시간만에 AI에이전트가 무엇인지 제대로 보여드리기 위해 AI 기술 세미나를 2024.04.02 에 열었습니다. 당시 막 나온 핫한 🔥MCP🔥를 포함한 AI 에이전트에 대한 정의, 개요 부터 LangGraph, AutoGen, SmolAgent 프레임워크를 활용해서 직접 구현해 본 응용 사례들 까지! 내부 + 외부 약 120명 정도의 많은 분들이 세미나에 참여해주셨습니다. 아래에서 세미나 영상과 자료를 공유드리니, 앞으로 열릴 세미나에도 많은 관심 부탁드립니다 https://www.youtube.com/watch?v=ht-xSmijEWU&t=973s

모든 작성 글은 롯데 AI 플랫폼 아이멤버의 도움을 받아 작성하였습니다. HELLO👋 안녕하세요! 롯데이노베이트 AI 기술팀 언어 AI 담당 이기훈, 유용상, 임형준입니다. 저희는 최근에 참여한 KRX 금융 언어 모델 경진대회에서 우수한 성과를 거두게 되어 그 경험과 성과를 여러분과 공유하고자 이 포스트를 작성하게 되었습니다. 대회 개요 대회명 제 3회 KRX 금융 언어 모델 경진대회 진행기간 예선: 2024.10.14 ~ 2024.11.07 본선: 2024.11.13 ~ 2024.12.06 주최사 KRX(한국거래소) 주관사 Koscom, AWS 개최 목표 심화된 금융분야를 다루는 다지선다 및 서술형 질의에 대응 가능한 금융 특화 언어모델 개발 금융 시장의 효율성을 높이고, 투자자들에게 더욱 정확하고 유용한 정보를 제공하는 데 기여 대회 평가 항목 KRX-Bench Challenge를 이용하여 금융 한글 언어 모델 성능 평가 (재무회계, 주가예측, 국내기업, 금융시장, 금융에이전트, Longform) 기사 https://www.newsis.com/view/NISX20241220_0003004975

들어가며 chatgpt-4o, claude3.5 Sonnet과 같은 Frontier LLM들은 매우 복잡하고 어려운 과제들(창의력이 필요하거나, 복잡한 수학 계산이 필요한 일들)도 훌륭하게 해결해낼 수 있는 능력을 가지고 있습니다. 그러나 이러한 모델들이 10살 이하의 인간도 문제없이 해결할 수 있는 간단한 작업들도 하지 못한다면, 믿을 수 있나요? 테슬라와 OpenAI에서 AI를 연구했고, 지금은 AI 교육 사업을 펼치고 있는 안드레 카파시(Andrej Karpathy)는, 이러한 현상을 LLM의 Jagged Intelligence라고 표현했습니다. 9.9랑 9.11중에 뭐가 더 큰 숫자야? 이런 질문은 현재 한국 교육과정을 기준으로 초등학교 4학년을 마쳤다면 문제없이 풀 수 있습니다. 한번 이 문제에 대한 현 양대 산맥 LLM인 claude3.5 Sonnet과 gpt-4o의 대답을 볼까요? 와우! 두 모델 모두 9.11이 9.9보다 크다고 말하고 있군요. (이는 모델 학습 데이터에 산수에 대한 내용보다 소프트웨어의 버전에 대한 내용이 더 많아서 발생하는 일입니다! python3.11이 python3.9보다 나중에 나왔죠.) 또 다른 예시를 들어볼까요?

들어가며 생성형 인공지능의 발전은 이제 '가능성'을 넘어서 각종 상품과 서비스로 활용되어 비즈니스 가치를 창출하기 시작하는 단계로 접어들고 있습니다. 스마트폰의 음성 비서부터 온라인 쇼핑몰의 상품 추천 시스템까지, AI는 우리의 생활을 더욱 편리하고 효율적으로 만들어주고 있죠. 모델을 사용할 때 가장 중요한 것 중 하나는 '내가 원하는 형태'의 출력이 되도록 하는 것인데요, 이는 모델을 활용한 합성 데이터 생성 등의 태스크에서 매우 중요합니다. 예를 들어, json 형태의 문자열을 생성해달라고 했는데 json 양식을 지키지 않은 출력물을 생성한다면 일일히 틀린 부분을 고쳐야 하는 등의 수고가 몇 배로 들어가게 되죠. 그렇기 때문에 Closed Foundation LLM인 Gpt-4나 claude3.5 sonnet은 function calling을 통해 모델의 생성 결과가 특정 형식을 따르도록 하는 기능을 제공하고 있습니다. 그러나 작업이나 연구를 하다 보면 자원, 비용 등의 문제로 인해 오픈 소스 모델을 사용해야 하는 상황도 종종 있기 마련입니다. 이럴 때에는 어떡할까요? 가장 직관적인 방법으로는 프롬프트에 생성 형식에 대한 지시를 하거나(Prompt Engineering), 생성 형식에 대한 예시를 프롬프트에 포함시키는 방법이 있습니다.(In-Context-Learning) 그러나 이러한 방법들 적용한다고 모델이 100% 원하는 방식으로 생성한다는 보장은 없죠. 이러한 니즈를 해결하기 위해 'guided-decoding' 이라는 방법론이 등장했습니다. 본 포스트에서는 대표적인 guided decoding 라이브러리인 'outlines' 와 그 사용방법을 살펴보겠습니다. Outlines 이미 hugging face 라이브러리를 사용하고 있다면, outlines의 사용 방법은 간단합니다. 먼저 모델 변수를 정의하고, outlines의 함수에 원하는 text structure과 모델을 넣어주기만 하면 됩니다.

들어가며 지난 6월 27일, OpenAI는 Finding GPT-4’s mistakes with GPT-4라는 포스트와 CriticGPT 논문을 공개했습니다. 이 글에서는 원본 포스트를 기반으로 CriticGPT에 대해 간단히 살펴보도록 하겠습니다. 개요 OpenAI는 GPT-4를 기반으로 한 모델 CriticGPT를 훈련시켜 ChatGPT의 코드 출력에서 오류를 잡아내도록 했습니다. 연구 결과, 사람들이 ChatGPT의 코드를 검토할 때 CriticGPT의 도움을 받으면 도움을 받지 않은 경우보다 60% 더 나은 성과를 보였습니다. OpenAI는 CriticGPT와 같은 모델을 RLHF 라벨링 파이프라인에 통합하기 위한 작업을 시작하고 있으며, 이를 통해 모델을 학습시키는 사람들에게 명확한 AI 지원을 제공할 것입니다. 이는 사람들이 평가하기 어려운 고급 AI 시스템의 출력을 평가할 수 있는 방향으로 나아가는 단계입니다. ChatGPT를 서비스하는 GPT-4 시리즈는 "인간 피드백을 통한 강화 학습(RLHF)"을 통해 유용하고 상호작용할 수 있도록 조정되었습니다. RLHF의 핵심 부분은 사람이 서로 다른 ChatGPT 응답을 비교하여 평가하는 과정을 수집하는 것입니다. 추론 및 모델 행동이 발전함에 따라 ChatGPT는 점점 더 정확해지고 오류가 더 미묘해집니다. 이는 사람이 오류를 식별하기 어렵게 만들고, RLHF를 구동하는 비교 작업을 훨씬 더 어렵게 만듭니다. 이는 RLHF의 근본적인 한계이며, 모델이 점차 더 많은 지식을 갖추게 되면서 피드백을 제공할 수 있는 사람보다 더 많이 알게 되어 모델을 조정하기 점점 더 어려워질 수 있습니다. 이 문제를 해결하기 위해 OpenAI는 ChatGPT 답변의 부정확성을 강조하는 비평을 작성하도록 CriticGPT를 훈련시켰습니다. CriticGPT의 제안이 항상 정확한 것은 아니지만, AI의 도움 없이 모델이 작성한 답변에서 발생하는 문제를 훨씬 더 많이 발견할 수 있도록 사람을 돕는다는 점을 확인했습니다. 또한, 사람들이 CriticGPT를 사용할 때 AI가 그들의 기술을 보완하여 혼자 작업할 때보다 더 포괄적인 비평을 제공하고, 모델이 혼자 작업할 때보다 환각 현상이 줄어들었습니다.

서론 미러 테스트란? 심리학자 고든 G. 갤럽(Gordon G. Gallup)이 고안한 미러 테스트는 동물이 거울에 비친 자기 자신을 인식할 수 있는지 알아보는 지능검사입니다. 이 테스트를 통과하는 동물들은 보통 지능이 높다고 평가되며, 인지 학습이 가능하다고 여겨집니다. 주로 대뇌화지수가 높은 동물들의 지능을 연구할 때 사용됩니다. AI 미러 테스트 Josh Whiton은 미러 테스트를 멀티모달 AI에게 수행할 수 있도록 변형하여 고안하고, 5종류의 AI에게 실험해보았습니다. 채팅 인터페이스의 스크린샷을 찍어 이를 "거울"로 사용하고, 이를 채팅에 업로드한 후 AI에게 "이 이미지에 대해 이야기해 보세요"라고 요청합니다. 그런 다음 AI의 응답을 스크린샷으로 찍어 다시 채팅에 업로드하고, 다시 "이 이미지에 대해 이야기해 보세요"라고 요청합니다. 이 테스트의 전제는 지능이 낮고 자아 인식이 부족한 AI일수록 이미지의 내용을 반복해서 나열할 가능성이 높다는 것입니다. 반면, 자아 인식 능력이 더 있는 AI는 어떻게든 이미지 속에서 자신을 인식할 것입니다. 이 거울 테스트의 또 다른 측면은 이미지에 실제로 세 가지 구별되는 참가자가 나타난다는 것입니다: 1) AI 챗봇 2) 사용자 3) 인터페이스 - 하드코딩된 텍스트, 면책 조항 등 우리 중 어느 누구도 생성하지 않은 웹 프로그래밍 요소.