RAG 에이전트 실무
몇 달 전만 해도 멀티모달 RAG라는 말을 들으면 그냥 이미지 업로드 버튼 하나 붙이면 되는 줄 알았다. 실제로 손대보니 완전히 다른 이야기였다. 문서 안의 표와 다이어그램을 검색 가능하게 만드는 것부터, 어떤 VLM을 골라서 어떻게 서빙할지, 그리고 사용자가 실제로 사진을 찍어 들고 와서 묻는 순간까지, 각 단계마다 텍스트 RAG에서는 겪어보지 못한 문제들이 쌓여 있었다. 세 편에 … Read more
2편까지 정리하고 나니 인덱싱 쪽은 어느 정도 자신이 붙었다. 그런데 정작 데모 날짜가 다가오면서 진짜 부담스러웠던 건 따로 있었다. 현장 엔지니어가 설비 사진을 찍어서 바로 질문하는 시나리오였다. 사용자가 이미지를 올리는 순간부터 답변이 나오기까지, 텍스트 전용 RAG에서는 신경 쓸 필요 없던 문제들이 줄줄이 튀어나왔다. 이미지를 받는 엔드포인트를 어떻게 설계할지, 이미지에서 뽑은 정보와 벡터 검색 결과를 어떻게 … Read more
pgvector를 RAG에 붙이고 꽤 만족스럽게 쓰고 있었다. 이미 PostgreSQL을 쓰고 있었고, 확장 하나 설치하면 벡터 검색까지 되니까 인프라를 늘리지 않아도 됐다. 문서 수가 수십만 건 수준일 때는 HNSW 인덱스로 응답 속도도 충분했고, BM25 하이브리드 검색까지 붙이니까 검색 품질도 나쁘지 않았다. 그러다 어느 날 질문 하나가 들어왔다. “이 계약서에 등장하는 모든 법인이 서로 어떻게 연결돼 있고, … Read more
RAG를 붙이면 환각이 줄어든다고 했다. 분명히 줄긴 했다. 그런데 없어지지는 않았다. LangGraph 기반 RAG 시스템을 직접 운영하면서 가장 자주 들은 피드백이 “왜 이 질문에는 제대로 답을 못 하지?”였다. 단순한 사실 조회는 잘 됐다. 그런데 조금만 복잡해지면 흔들렸다. 여러 개체의 관계를 엮어서 추론해야 하는 질문, 전체 데이터에서 패턴을 찾아야 하는 질문에서 벡터 검색 기반 RAG는 근본적인 … Read more
에이전트가 멈춰야 할 때 멈추지 않거나, 멈추지 말아야 할 때 멈추는 문제를 LangGraph로 멀티에이전트 시스템을 운영하면서 꽤 오래 고민했다. 이론적으로 Human-in-the-Loop는 단순하다. 에이전트가 스스로 판단하기 어려운 지점에서 사람에게 확인을 요청하고, 사람의 입력을 받아서 다시 진행하는 것이다. 그런데 실제로 구현해보면 “어느 노드에 interrupt를 거냐”와 “체크포인터를 어떻게 설계하냐”가 에이전트 전체 흐름을 좌우한다는 걸 알게 된다. 이 글은 … Read more