AI 에이전트, LangGraph, RAG
pgvector를 RAG에 붙이고 꽤 만족스럽게 쓰고 있었다. 이미 PostgreSQL을 쓰고 있었고, 확장 하나 설치하면 벡터 검색까지 되니까 인프라를 늘리지 않아도 됐다. 문서 수가 수십만 건 수준일 때는 HNSW 인덱스로 응답 속도도 충분했고, BM25 하이브리드 검색까지 붙이니까 검색 품질도 나쁘지 않았다. 그러다 어느 날 질문 하나가 들어왔다. “이 계약서에 등장하는 모든 법인이 서로 어떻게 연결돼 있고, … Read more
어느 순간부터 RAG 파이프라인을 짜는 것보다 운영하는 게 더 어렵다는 걸 알게 됐다. 처음에는 임베딩 모델을 골라서 벡터 DB에 인덱싱하고, 유사도 검색으로 컨텍스트를 뽑아서 LLM에 넘기면 끝이라고 생각했다. 실제로 돌려보기 전까지는 그렇게 생각했다. 그런데 막상 프로덕션에 올리면 다른 세계가 펼쳐진다. 검색 정확도가 쿼리 유형마다 들쭉날쭉하고, FastAPI 서버는 동시 요청 몇 개에 응답이 뭉개지고, 벡터 DB … Read more
얼마 전에 새 RAG 파이프라인을 설계할 일이 있었다. 기존에 운영하던 시스템은 PostgreSQL에 pgvector를 얹어서 벡터 검색까지 한 곳에서 처리하는 구조였다. 그런데 이번에는 검색 정확도 요구사항이 더 높았고, 팀 내부에서 “Qdrant로 가야 하지 않냐”는 의견이 나왔다. 그래서 결국 둘 다 직접 붙여보고 비교하게 됐다. 이 글은 그 과정에서 겪은 걸 정리한 글이다. 어느 쪽이 “더 좋다”는 … Read more
RAG 시스템을 처음 만들 때 나는 LLM 선택과 프롬프트 튜닝에 거의 모든 시간을 쏟았다. 어떤 임베딩 모델이 좋은지, 청크 크기를 얼마로 할지, 리랭커를 붙일지 말지. 그런데 막상 프로덕션에 올리고 나니 진짜 골치 아픈 건 전혀 다른 데 있었다. “어제 인사팀이 게시판에 올린 새 규정, 챗봇이 왜 모르지?” 이 한마디가 모든 걸 말해준다. RAG의 답변 품질은 … Read more
주요 기사 요약 2026년 벡터 DB 벤치마크에서는 단순 성능 비교를 넘어 운영 복잡도와 비용 효율성이 중요한 요소로 떠올랐다. Pinecone은 관리 부담이 거의 없지만 월 $3,300(10M 벡터 기준), Qdrant는 50M 벡터에서 QPS 41.47(99% recall)로 강력하지만 자체 관리 필요, PGvector는 pgvectorscale로 50M 벡터에서 471 QPS를 달성하며 AWS 대비 75% 비용 절감이 가능하다. 실제 스타트업과 엔터프라이즈의 선택 기준은 … Read more