Rag
Filed under
7 posts
벡터 데이터베이스는 먼저 깨지는 지점을 보고 골라라
대부분의 RAG 시스템은 pgvector로 시작하는 것이 맞다. 유용한 질문은 어느 벡터 데이터베이스가 가장 빠른가가 아니라, 어떤 실패 모드가 먼저 닥치는가다.
모델로 가는 하나의 문, 7부. Azure AI Search인가 벡터 데이터베이스인가
Azure AI Search는 벡터 수가 아니라 SKU로 용량이 정해지고 vector index는 티어 메모리에 묶인다. 7부는 retrieval을 기능이 아니라 한도로 결정한다.
당신의 문서를 통한 프롬프트 인젝션: RAG의 공격 표면
지식 베이스는 신뢰할 수 없는 입력이다. 검색은 공격자가 작성한 텍스트를 모델에 그대로 전달하므로, 통제는 수집 시점의 스캔이 핵심이다.
컨텍스트 윈도우는 당신 편이 아니다
거대한 컨텍스트 윈도우는 검색을 대체하지 못한다. 프롬프트가 길어질수록 재현율은 떨어지고 비용은 토큰마다 늘어나며 중간 부분은 대충 읽힌다.
에이전틱 RAG는 대부분 필요 없는 지연 시간이다
에이전틱 RAG는 검색 홉을 반복하며, 각 홉은 모델 왕복이다. 대부분의 질문에는 잘 만든 쿼리 하나가 이긴다. 지연을 감수할 가치가 있을 때만 루프를 써라.
파인튜닝을 멈춰라. 필요한 건 RAG, 캐시, 그리고 더 나은 프롬프트다
파인튜닝과 프로비저닝된 처리량은 대부분의 LLM 문제에 대한 값비싼 답이다. 더 저렴한 길은 검색, 프롬프트 캐싱, 더 나은 프롬프트다.
Knowledge Base 청킹, RAG 품질이 무너지는 지점
대부분의 잘못된 RAG 답변은 모델 문제가 아니라 검색 문제다. Bedrock Knowledge Bases의 고정, 시맨틱, 계층형 청킹이 품질을 결정하는 방식.