Rag3 프롬프트 캐싱 실전 경험 (캐시 프리워밍, TTL 변경, 비용절감) 솔직히 저는 처음에 프롬프트 캐싱을 그냥 "비용 조금 아끼는 기능" 정도로 생각했습니다. 그런데 RAG 시스템에 직접 붙여보고 나서 생각이 완전히 바뀌었습니다. 하루 120달러짜리 API 비용이 13달러로 줄어드는 걸 직접 보고서야, 이게 단순한 최적화 옵션이 아니라 서비스 운영 방식 자체를 바꾸는 기능이라는 걸 실감했습니다.그런데 이 경험을 공유하면 사람들이 "그냥 cache_control 붙이면 되는 거 아닌가요?"라고 묻습니다. 그렇지 않습니다. 선언하는 것과 제대로 활용하는 것 사이에는 생각보다 큰 간격이 있습니다. 그 간격에서 비용 절감이 생기기도 하고 사라지기도 합니다.캐시 프리워밍, 알고 쓰는 것과 모르고 쓰는 것의 차이제가 운영하던 RAG 시스템은 50,000 토큰 규모의 지식 베이스를 시.. 2026. 5. 30. RAG 토큰 관리 - 검색 최적화, 재순위화, 컨텍스트 사내 Q&A 시스템을 처음 만들 때 저도 이 질문 앞에서 한참 멈췄습니다. 많이 넣으면 더 좋은 답이 나올 것 같은데, 실제로 해보면 꼭 그렇지만은 않더군요. 이 글은 그 시행착오를 정리한 기록이자, 제가 직접 부딪히면서 생긴 비판적 시각을 함께 담은 글입니다.검색 결과를 많이 넣으면 정말 더 좋아질까요처음에 저는 top_k=10으로 설정해 검색된 문서 청크 10개를 모두 컨텍스트에 넣었습니다. 청크란 긴 문서를 LLM이 처리할 수 있도록 일정 크기로 잘라낸 조각입니다. 답변이 길고 풍성해 보이니 잘 되는 것 같았습니다. 적어도 그렇게 느꼈습니다.그런데 실제 사용자 피드백을 받아보니 상황이 달랐습니다. 핵심 답변이 여러 청크 사이에서 희석되거나, 서로 약간씩 다른 내용을 담은 문서들이 동시에 주입되면서 .. 2026. 5. 22. RAG 청킹 전략 - 고정 크기, 계층적 청킹, 컨텍스트 창 사내 계약서 분석 자동화 프로젝트를 맡았을 때, 저도 처음엔 청킹(chunking)을 그냥 텍스트 자르는 작업 정도로 봤습니다. 그런데 실제로 서비스를 돌려보니, 임베딩 모델이나 벡터 DB보다 청킹 전략이 결과 품질을 훨씬 크게 좌우했습니다. 청킹이란 긴 문서를 LLM이 처리할 수 있는 크기의 조각으로 나누는 작업으로, RAG 파이프라인 전체의 성능을 결정짓는 핵심 단계입니다.고정 크기 청킹이 실패한 날처음에 적용한 방식은 고정 크기(fixed-size) 청킹이었습니다. 고정 크기 청킹이란 문서의 내용이나 구조를 고려하지 않고 일정한 글자 수나 토큰 수 단위로 텍스트를 잘라내는 방식입니다. 구현이 단순하고 직관적이라 많은 RAG 튜토리얼에서 첫 번째 예시로 등장하는 방법이기도 합니다.결과는 솔직히 예상 .. 2026. 5. 21. 이전 1 다음
