AI 에이전트, LangGraph, RAG
핵심 인력이 퇴사하면 그 사람이 갖고 있던 지식도 함께 나간다는 게 조직에서 오래된 고민이다. 문서화를 열심히 해도 해결이 안 되는 이유가 있다. 문서는 텍스트로 저장되지만, 그 텍스트들이 서로 어떻게 연결되는지는 저장이 안 된다. 담당자가 머릿속에서 연결하고 있던 맥락과 관계가 사라지는 거다. AI가 사내 문서를 다루면 이 문제가 더 선명하게 드러난다. RAG를 붙여서 사내 문서를 검색하게 … Read more
pgvector를 RAG에 붙이고 꽤 만족스럽게 쓰고 있었다. 이미 PostgreSQL을 쓰고 있었고, 확장 하나 설치하면 벡터 검색까지 되니까 인프라를 늘리지 않아도 됐다. 문서 수가 수십만 건 수준일 때는 HNSW 인덱스로 응답 속도도 충분했고, BM25 하이브리드 검색까지 붙이니까 검색 품질도 나쁘지 않았다. 그러다 어느 날 질문 하나가 들어왔다. “이 계약서에 등장하는 모든 법인이 서로 어떻게 연결돼 있고, … Read more
RAG를 붙이면 환각이 줄어든다고 했다. 분명히 줄긴 했다. 그런데 없어지지는 않았다. LangGraph 기반 RAG 시스템을 직접 운영하면서 가장 자주 들은 피드백이 “왜 이 질문에는 제대로 답을 못 하지?”였다. 단순한 사실 조회는 잘 됐다. 그런데 조금만 복잡해지면 흔들렸다. 여러 개체의 관계를 엮어서 추론해야 하는 질문, 전체 데이터에서 패턴을 찾아야 하는 질문에서 벡터 검색 기반 RAG는 근본적인 … Read more
RAG를 처음 도입했을 때 기대가 컸다. LLM이 학습하지 않은 사내 데이터를 실시간으로 검색해서 답변에 쓴다는 아이디어는 당시로선 꽤 혁신적으로 들렸다. 실제로 환각이 줄었다. 아무 맥락 없이 LLM에게만 물어보던 때보다는 확실히 나아졌다. 그런데 쓸수록 이상한 게 보이기 시작했다. 단순한 질문에는 잘 답하는데, 조금만 복잡해지면 흔들렸다. “이 프로젝트 담당자가 지난 분기에 진행한 다른 프로젝트와 예산이 겹치는 부분이 … Read more
에이전트가 멈춰야 할 때 멈추지 않거나, 멈추지 말아야 할 때 멈추는 문제를 LangGraph로 멀티에이전트 시스템을 운영하면서 꽤 오래 고민했다. 이론적으로 Human-in-the-Loop는 단순하다. 에이전트가 스스로 판단하기 어려운 지점에서 사람에게 확인을 요청하고, 사람의 입력을 받아서 다시 진행하는 것이다. 그런데 실제로 구현해보면 “어느 노드에 interrupt를 거냐”와 “체크포인터를 어떻게 설계하냐”가 에이전트 전체 흐름을 좌우한다는 걸 알게 된다. 이 글은 … Read more