Tech

기술 블로그

MDX로 기록한 글과 작업 로그를 한 곳에 모아두는 공간입니다.

언제 RAG를 쓰지 말아야 하나: 검색을 붙이는 게 항상 정답은 아니다

RAG 파이프라인을 걷어내고 롱컨텍스트로 바꿨더니 더 정확해진 기능이 있었습니다. 문서 수·변경 빈도·질문 유형으로 RAG와 대안을 가르는 기준을 정리했습니다.

LLM 호출 비용이 예상보다 컸는데 원인은 모델이 아니라 프롬프트 구성 순서였습니다. 고정 블록을 앞으로 모아 캐시를 살리고, 무엇이 캐시를 깨뜨리는지 정리했습니다.

붙일 시스템이 늘 때마다 도구 정의와 스키마를 새로 쓰는 일이 반복됐습니다. MCP를 표준 인터페이스로 두고 연동 비용이 곱셈에서 덧셈으로 바뀌는 지점을 정리했습니다.

같은 모델인데 어떤 에이전트는 일을 해내고 어떤 건 계속 헛돕니다. 도구를 몇 개 쥐어줄지, 권한을 어디까지 열지, 실패했을 때 어떻게 되돌릴지를 설계한 과정을 정리했습니다.

RAG 파이프라인을 붙이고도 답변 품질이 들쭉날쭉했던 이유는 검색이 아니라 컨텍스트 구성에 있었습니다. 토큰을 예산으로 보고 도구 정의·대화 히스토리·검색 결과를 재배분한 과정을 정리했습니다.

@Tool 어노테이션으로 Java 메서드를 LLM이 호출 가능한 도구로 등록해, LLM이 사내 API와 DB를 직접 조회하도록 만든 함수 호출(Function Calling) 구현 과정을 예제 기반으로 정리했습니다.