매끄러운 AI 데모와 새벽 2시에 문제없이 돌아가는 프로덕션 시스템 사이의 간극은 매우 큽니다. 데모를 만들어본 대부분의 사람들은 이 사실을 알고 있습니다. 다만, 청사진을 팔 때는 항상 솔직하지 않을 뿐입니다. 프로덕션 환경에서 파이프라인이 실패하는 이유는 잘못된 파운데이션 모델을 선택했기 때문이 아닙니다. 프로토타입을 제품처럼 취급하는 시스템 설계 때문입니다.

현재 모든 것이 에이전트라고 불리고 있습니다. 조건이 충족될 때까지 루프를 도는 스크립트도 갑자기 에이전트가 됩니다. 마지막 세 개의 메시지만 메모리에 저장하는 챗봇도 에이전트입니다. 이러한 부정확한 용어 사용은 실제 엔지니어링에 손해를 끼칩니다. 팀들은 단순한 cron job으로 처리할 수 있는 5단계 워크플로우를 자동화하기 위해 무거운 에이전트 프레임워크를 찾습니다. 동시에, 거대 언어 모델(LLM)이 마법처럼 엣지 케이스를 해결해 줄 것이라는 기대 때문에 실제 복잡성을 해결하는 데는 투자를 소홀히 합니다. 하지만 모델은 그렇게 해주지 않습니다.

에이전트의 실제 정의

에이전트는 목표를 가진 시스템입니다. 단순히 사람이 전달한 일련의 지침을 따르는 것이 아닙니다. 에이전트는 세상의 상태를 바탕으로 다음에 무엇을 할지 결정합니다. 도구가 고장 나거나 데이터가 누락되었을 때 실패를 처리합니다. 목표가 완료되었음을 알고 스스로 멈춥니다.

여러분이 만들고 있는 것이 무엇인지 판단하기 위해 다음 세 가지 규칙을 사용하십시오:

  • 만약 사람이 모든 단계를 일일이 알려줘야 한다면, 그것은 채팅 인터페이스입니다. 여러분이 운전하고 있는 것입니다. 시스템은 그저 매우 정중한 스티어링 휠일 뿐입니다.
  • 실패한 툴 호출(tool call)로부터 복구할 수 있다면, 올바른 방향으로 가고 있는 것입니다. 검색 API가 타임아웃되거나 500 에러를 반환한다고 해서 작업이 끝나서는 안 됩니다. 시스템은 재시도하거나, 대기 시간을 갖거나, 폴백 소스로 전환하거나, 도움을 요청해야 합니다.
  • 목표를 하위 작업으로 나누고 이를 위임할 수 있다면, 그것은 진짜 에이전트입니다. "3분기 컴플라이언스 보고서를 준비해줘"와 같은 명령을 내리면, 에이전트는 데이터 소스를 식별하고, 추출 일정을 잡고, 원시 데이터를 계산 모듈에 전달하고, 초안을 검토 단계로 보내며, 언제 멈춰야 할지를 압니다.

여러분의 시스템이 이 기능들을 수행하지 못한다면, 에이전트의 문제가 아닙니다. 스크립팅 문제나 워크플로우 문제입니다. 이를 조기에 인정하면 프레임워크 비대화로 인한 몇 주간의 낭비를 줄일 수 있습니다.

승리하는 팀이 실제로 우선순위를 두는 것

신뢰할 수 있는 시스템을 출시하는 팀은 벤치마크 점수를 몇 점 올리기 위해 최신 모델을 계속 교체하며 시간을 보내지 않습니다. 그들은 지루하지만 효율이 높은 세 가지 영역에 집중합니다.

툴 설계(Tool design). 에이전트의 성능은 여러분이 제공하는 툴의 성능과 같습니다. 만약 검색 함수가 일관성 없는 필드 이름을 가진 중첩된 JSON을 반환한다면, 모델은 내용에 대해 추론하는 대신 구조를 파싱하는 데 귀중한 컨텍스트 윈도우를 낭비하게 됩니다. 툴 설명이 모호하면 모델은 잘못된 인수를 환각(hallucinate)합니다. 툴 인터페이스를 깨끗한 입력, 예측 가능한 출력, 명시적인 에러 상태가 필요한 아주 문자 그대로 행동하는 주니어 개발자를 위한 API처럼 다루십시오.

실패 처리(Failure handling). 검색(retrieval) 단계에서 아무것도 반환하지 않으면 어떻게 될까요? 너무 많은 파이프라인이 빈 컨텍스트를 프롬프트에 슬쩍 밀어 넣고 모델이 학습 데이터에서 답을 환각해 내도록 방치합니다. 그것은 기능이 아니라, 곧 발생할 프로덕션 장애입니다. 제대로 된 시스템은 공백을 감지합니다. 더 넓은 쿼리로 재시도합니다. 사람에게 에스컬레이션하거나, 명확한 설명과 함께 중단합니다. 아무것도 찾지 못했을 때 찾은 척하지 않습니다.

관측 가능성(Observability). 에이전트가 왜 특정 결정을 내렸는지 확인해야 합니다. 최종 출력뿐만 아니라 사고의 사슬(chain of thought), 툴 선택, 검색된 청크(retrieved chunks), 그리고 핸드오프 로그까지 확인해야 합니다. 이러한 추적(trace)이 없다면 디버깅은 추측에 불과합니다. 다음 주에 사용자가 잘못된 답변에 대해 불만을 제기하면, 정확히 어떤 검색 단계에서 쓰레기 데이터가 제공되었고 그 이유가 무엇인지 재현할 수 있어야 합니다.

프레임워크보다 오래 살아남는 아키텍처 패턴

LangChain, CrewAI, 그리고 6개월 뒤에 등장할 또 다른 핫한 프레임워크는 비계(scaffolding)일 뿐입니다. 아키텍처가 실제 건물입니다. 설계가 취약하다면 어떤 프레임워크도 이를 구할 수 없습니다. 검증된 내구성을 가진 패턴을 고수하십시오:

  • 계획을 먼저 세우고, 그 다음 실행하십시오. 모델이 추론과 행동을 동시에 수행하게 하지 마십시오. 먼저 계획을 생성한 다음, 단계를 실행하십시오. 문제가 발생했을 때, 실행과 별개로 계획을 독립적으로 검토할 수 있습니다. 도구 호출과 의식의 흐름에 따른 추론이 뒤섞여 엉망이 된 상황을 해결하는 데 드는 시간을 훨씬 줄일 수 있습니다.
  • 검색과 추론을 분리하십시오. 컨텍스트를 가져오는 것은 I/O 작업입니다. 컨텍스트를 사용하는 것은 추론 작업입니다. 이 둘을 섞으면 검색기(retriever)는 모델의 토큰 제한에 갇히게 되고, 모델은 가공되지 않은 검색 노이즈로 인해 오염됩니다. 검색 레이어는 공격적으로 데이터를 가져오게 하고, 추론 레이어는 가져온 내용을 회의적으로 평가하게 하십시오.
  • 명시적인 핸드오프(handoff)를 사용하십시오. 여러 에이전트가 하나의 작업을 수행한다면, 작업 전달 구조를 설계하십시오. 명확한 출력 스키마, 소유권 경계, 핸드오프 로그를 정의하십시오. 에이전트 간의 모호하고 비공식적인 대화는 작업 누락, 무한 루프 또는 중복 작업으로 이어집니다. 에이전트 간 통신을 단체 채팅방이 아닌, 잘 정의된 API 계약처럼 취급하십시오.

RAG가 쓰레기 같은 결과만 내놓는 진짜 이유

RAG(Retrieval-Augmented Generation) 파이프라인이 계속해서 쓸모없는 결과를 내놓는다면, 임베딩 모델을 튜닝하는 것을 멈추고 청킹(chunking) 전략을 살펴보십시오. 이것은 RAG 시스템에서 가장 간과하기 쉬운 실패 지점입니다.

문서를 경직된 고정 크기 청크로 나누면 아이디어가 고립되는 경우가 많습니다. 예를 들어, "하지만 이 방식은 규제 변화를 고려하지 못했습니다"로 시작하는 문단은 해당 방식을 언급한 이전 문단 없이는 의미가 없습니다. 이렇게 고립된 파편을 모델에 입력하면, 모델은 필요한 컨텍스트를 스스로 지어내게 됩니다. 그것은 검색이 아니라 환각(hallucination) 공장입니다.

다음과 같은 해결책을 시도해 보십시오:

  • 중첩 윈도우(Overlapping windows). 개념이 생각 중간에 끊기지 않도록 인접한 청크의 경계 부분에서 문장 한두 개를 공유하게 하십시오.
  • 시맨틱 청킹(Semantic chunking). 글자 수가 아닌 문단 끝, 섹션 헤더, 또는 주제 전환과 같은 자연스러운 경계에서 나누십시오.
  • 부모 문서 검색(Parent-document retrieval). 시맨틱 매칭을 위해 작고 정밀한 청크를 검색하되, 언어 모델에는 전체 부모 섹션이나 문서를 전달하여 생성 시 주변 컨텍스트를 가질 수 있도록 하십시오.
  • 가공되지 않은 텍스트 대신 구조화된 데이터 저장. 표 데이터, 키-값 쌍, 관계 등은 산문 형태의 텍스트로 임베딩할 때 성능이 떨어지는 경우가 많습니다. 소스 자료가 구조화되어 있다면 그래프 데이터베이스나 관계형 저장소에 구조를 유지한 채로 저장하고, 에이전트가 임베딩된 텍스트 파편을 통해 추측하는 대신 명시적으로 쿼리할 수 있도록 하십시오.

신뢰할 수 있는 시스템 구축하기

벤치마크 점수에 매달리지 마십시오. 리더보드 점수는 실험실 조건일 뿐입니다. 실제 운영 환경은 무질서하고, 적대적이며, 비동기적입니다. 중요한 것은 당신이 잠든 사이, 상위 API가 불안정한 상황, 그리고 사용자가 학습 데이터에 없던 질문을 던졌을 때 시스템이 올바르게 작동하느냐 하는 것입니다.

시스템 설계에 집중하십시오. 검색과 추론 사이에 명확한 경계를 구축하십시오. 오류가 발생했을 때 명확히 알리고 깔끔하게 복구되는 도구를 설계하십시오. 감사를 위해 결정 사항을 로그로 남기십시오. 컨텍스트가 온전하게 유지되도록 문서를 청킹하십시오. 그렇게 한다면, 단순히 데모용으로만 훌륭한 것이 아니라 실제 상황에서도 신뢰할 수 있는 파이프라인을 구축할 수 있을 것입니다.

Source: The Overlooked Reason Your RAG Pipeline Keeps Returning Garbage

Join the learning community: GyaanSetu AI on Telegram