아프니까 개발자다 아프니까 개발자다

LLM이 틀린 답을 내놓는 이유는 크게 두 가지다. 첫째, 학습 데이터에 없는 내용(특정 도메인 지식, 사내 문서, 개인 기록). 둘째, 학습한 내용과 현실 사이의 시간 차. 두 경우 모두 "모델이 모르는 내용"이라는 공통점이 있다. 이때 쓰는 패턴이 RAG(Retrieval-Augmented Generation) — 검색해서 가져온 문서를 LLM 프롬프트에 끼워 넣어 답변 품질을 높이는 방식이다.이 글에서는 영화 정보 파일을 벡터 데이터베이스에 저장하고, 그 검색기를 에이전트 도구로 등록하는 전체 파이프라인을 순서대로 살펴본다.RAG 파이프라인 전체 흐름문서가 에이전트 도구로 동작하기까지 여섯 단계를 거친다.RAG 파이프라인 전체 구조. 파이프라인은 "준비 단계"와 "실행 단계"로 나뉜다. 준비 단계(..

ChatGPT의 고급 분석(Advanced Data Analysis) 기능을 써 본 사람이라면 한 가지 낯선 경험을 했을 것이다. 프롬프트에 "이 CSV를 분석해줘"라고 하면 LLM이 직접 계산 결과를 내놓는다. 정확한 수치다. 환각이 아니다. 어떻게 가능한 걸까?비밀은 간단하다. LLM이 직접 계산한 게 아니다. LLM은 코드를 생성하고, 별도의 Python 실행기가 그 코드를 실제로 실행한 다음 결과를 LLM에 돌려준다. LLM은 텍스트 생성 기계다 — 코드도 텍스트다. 실행은 다른 존재의 몫이다.LLM이 코드를 "실행"할 수 없는 이유LLM의 내부를 생각해보면 이건 당연하다. 모델은 입력 토큰에서 다음 토큰 확률을 계산해 텍스트를 생성한다. 어떤 수학 연산도, 어떤 메모리 읽기도, 어떤 파일 접근도..

이전 글에서는 LLM 구조화 출력을 구현하는 두 전략 — ProviderStrategy와 ToolStrategy — 중 어떤 것을 선택해야 하는지 다뤘다. 전략을 정했다면 다음 질문은 스키마를 어떻게 설계하느냐다. 스키마가 부실하면 전략이 무엇이든 LLM이 잘못된 값을 채운다. 그 스키마의 도구가 Pydantic이다.Pydantic이란Pydantic은 Python 타입 어노테이션을 그대로 검증 규칙으로 쓰는 데이터 검증 라이브러리다. 2017년 Samuel Colvin이 만들었고, FastAPI가 요청/응답 스키마를 Pydantic으로 선언하면서 폭발적으로 보급됐다. 2023년에 v2로 재작성되면서 내부 엔진이 Rust로 바뀌었고 검증 속도가 v1 대비 5~10배 빨라졌다.Pydantic이 LLM 생태계..

LLM에게 "JSON으로 줘"라고 말하는 것과, 스키마를 강제로 씌워 정확한 타입으로 받는 것은 전혀 다른 이야기다. 구조화 출력(Structured Output)은 후자다. 모델 응답을 미리 정의한 Pydantic 스키마 형태로 돌려받아, 이후 코드가 타입 안전하게 처리할 수 있도록 보장한다. 그런데 이 구조화 출력을 구현하는 방법이 하나가 아니다. LangChain에는 두 가지 전략이 존재한다 — ProviderStrategy와 ToolStrategy. 두 전략은 모양은 비슷하지만 내부 동작이 전혀 다르고, 잘못 선택하면 성능 저하나 예상치 못한 실패로 이어진다.구조화 출력이란 무엇인가보통 LLM의 응답은 자유 형식 텍스트다. 그러나 에이전트나 파이프라인에서는 모델 출력을 다음 단계 코드가 바로 소비..

LangChain 도구를 작성하다 보면 곧 이런 질문에 부딪힌다. "이 비서 에이전트가 현재 응대 중인 사용자의 이름을 알아야 하는데, 어디서 받아오지?" 함수 인자로 넘기면 에이전트가 LLM에게 인자를 생성하게 하므로, 사용자가 이름을 직접 말하지 않는 이상 값을 알 방법이 없다. 하드코딩하면 도구가 재사용 불가능해진다. ToolRuntime은 이 문제를 "LLM이 채우는 인자"와 "실행 시점에 주입되는 컨텍스트"를 구분하는 방식으로 해결한다.문제: 실행 시점 데이터를 어떻게 전달하나일반적인 도구 함수는 LLM이 인자를 생성한다. 사용자 ID나 이름처럼 "호출하는 쪽에서 미리 알고 있는" 데이터는 LLM이 생성하는 게 적절하지 않다 — LLM이 이 값을 모르기 때문이다. 그렇다고 전역 변수나 클로저를 ..

LangChain 에이전트에게 도구를 건네줄 때 "함수만 넘기면 되겠지"라고 생각하기 쉽다. 실제로 함수 하나가 에이전트에게 제대로 인식되려면 세 가지 요소가 맞물려야 한다. 하나라도 빠지면 에이전트는 그 도구를 아예 사용하지 않거나, 엉뚱한 인자를 집어넣는다. 이 글은 그 세 요소가 무엇이고 각각이 왜 필요한지를 구체적인 실패 사례와 함께 설명한다.에이전트가 도구를 고르는 방법에이전트는 도구 목록을 텍스트 설명으로 전달받는다. LLM 입장에서 "도구를 안다"는 것은 그 설명을 읽을 수 있다는 뜻이다. 함수 로직을 직접 보는 게 아니라, 메타데이터 — 이름, 파라미터 타입, 용도 설명 — 를 보고 판단한다.위 흐름에서 핵심은 LLM이 도구 목록의 description을 읽는 단계다. LLM이 descri..

LLM마다 코드를 따로 써야 했던 시절OpenAI GPT를 쓰다가 Anthropic Claude로 바꾸려면 얼마나 손봐야 할까? 2023년 초까지만 해도 대답이 단순했다. "코드를 거의 다시 써야 한다." 각 LLM 제공사(provider)가 저마다 다른 SDK, 다른 함수 이름, 다른 요청 형식을 썼기 때문이다.LLM provider별로 완전히 다른 코드가 필요한 상황. 위 다이어그램은 동일한 "AI에게 질문하기"라는 목적을 달성하기 위해 provider마다 함수 이름, 매개변수 이름, 메시지 포맷이 모두 다른 현실을 보여 준다. OpenAI는 client.chat.completions.create(), Anthropic은 client.messages.create(), Google은 generate_c..

2022년 말 ChatGPT가 공개된 이후, 개발자들 사이에서 한 가지 공통된 질문이 등장했다."LLM을 내 서비스에 어떻게 집어넣지?"답은 간단해 보였다. API를 호출하면 된다. 그런데 실제로 해보면 달랐다. 대화 이력을 직접 관리해야 하고, 외부 검색 기능을 붙이려면 연결 코드를 따로 짜야 하고, LLM이 여러 번 판단을 반복하도록 루프를 구현해야 했다. 강력한 언어 모델을 손에 쥐었는데, 정작 그것을 "쓸 수 있는 형태"로 만드는 데 시간의 대부분을 써야 했다.LangChain은 그 반복을 없애려는 시도로 2022년 10월에 등장했다.1. 배경 — GPT 등장 이후 개발자들이 맞닥뜨린 문제LLM(Large Language Model, 거대 언어 모델) API는 사실 단순하다. 텍스트를 보내면 텍스..