검색 증강 생성은 보통 RAG로 줄여 부르며, 언어 모델이 답변하는 순간에 선별된 정보를 제공합니다. 애플리케이션은 학습에서 얻은 패턴에만 의존하지 않고 문서 모음을 검색해 관련 구절을 요청에 더한 뒤, 그 근거를 바탕으로 답하도록 모델에 요청합니다.
기본 흐름은 세 부분입니다. 검색은 후보 구절을 찾고, 증강은 그 구절들을 지시와 사용자 질문에 묶으며, 생성은 제공된 자료에 근거해야 하는 답변을 만듭니다. 이 패턴은 지식이 비공개이거나 자주 바뀌거나 인용이 필요할 때 유용합니다.
RAG가 모델을 본질적으로 진실하게 만들지는 않습니다. 대신 점검하고 개선할 수 있는 구성 요소의 사슬을 만듭니다. 검색기가 올바른 문서를 놓치거나 오래된 버전을 선택하거나, 키워드는 같지만 의미는 다른 구절을 반환할 수 있습니다. 프롬프트가 근거 제시를 요구하지 않을 수도 있고, 모델은 유효한 발췌를 근거 없는 결론으로 결합할 수도 있습니다.
문서 준비가 결과의 상당 부분을 결정합니다. 파일에는 안정적인 식별자, 유용한 메타데이터, 접근 규칙, 충분한 주변 의미를 보존하는 청크가 필요합니다. 청크가 너무 크면 컨텍스트를 낭비하고 관련성이 흐려집니다. 너무 작으면 주장과 정의, 날짜, 예외, 표 제목이 떨어져 나갑니다.
검색에는 키워드 검색, 벡터 유사도, 의미 순위화 또는 이들의 조합을 쓸 수 있습니다. 키워드 검색은 이름, 코드, 정확한 문구에 강합니다. 벡터 검색은 표현이 달라도 개념적으로 관련된 구절을 찾을 수 있습니다. 하이브리드 검색은 두 신호를 결합하므로 더 나은 기본값인 경우가 많지만, 실제 질문으로 계속 평가해야 합니다.
접근 제어는 생성 뒤의 면책 문구가 아니라 검색에 속해야 합니다. 사용자는 검색 권한이 없는 구절을 절대 받아서는 안 됩니다. 검색된 문서도 신뢰할 수 없는 입력으로 취급해야 합니다. 문서에는 애플리케이션 규칙을 덮어쓰려는 지시가 들어 있을 수 있습니다. 시스템 정책은 분리하고 후속 도구가 할 수 있는 일을 제한하세요.
프롬프트는 모든 원본 청크를 식별하고, 사실 주장에 인용을 요구하며, 근거가 부족할 때의 대안을 정의해야 합니다. 의견이 갈릴 때도 날짜와 인용을 붙여 충돌하는 버전을 제시하도록 하고, 조용히 하나를 선택하지 않게 해야 합니다. 이런 요구사항은 오류를 더 쉽게 진단하게 합니다.
검색과 생성을 따로 측정하세요. 검색 테스트는 뒷받침 구절이 상위 결과에 나타났는지 묻습니다. 생성 테스트는 답변이 근거 있고, 완전하며, 올바르게 인용되고, 적절히 불확실성을 드러내는지 묻습니다. 매끄러운 답변은 약한 검색을 숨길 수 있고, 완벽한 검색 뒤에도 나쁜 종합이 나올 수 있습니다.
컨텍스트가 많다고 항상 좋은 것은 아닙니다. 관련성이 낮은 구절은 토큰을 소비하고 답변을 가장 강한 근거에서 멀어지게 할 수 있습니다. 관련성 임계값을 정하고, 중복을 제거하며, 최신성이 중요할 때는 현재 버전을 우선하고, 답변을 위한 충분한 공간을 남기세요. 복잡한 질문은 여러 개의 집중된 검색으로 나눠야 할 수 있습니다.
사실이 변하는 또는 비공개 코퍼스에 있을 때 RAG가 적합합니다. 최신 지식을 주입하는 대신 행동, 스타일, 과업 수행을 바꾸는 것이 목표라면 보통 파인튜닝이 더 잘 맞습니다. 시스템이 더 큰 워크플로의 일부로 언제 어디서 검색할지 결정해야 할 때는 에이전트 도구가 유용합니다.
신뢰할 수 있는 RAG 인터페이스는 출처를 보여주고, 코퍼스가 답할 수 없을 때 이를 인정하며, 수정할 수 있게 해야 합니다. 진짜 제품은 생성된 단락이 아닙니다. 독자가 그 단락을 신뢰할 만한지 판단하도록 해 주는 근거의 경로입니다.
1차 자료, 제품 문서, 실제 활용 사례를 바탕으로 해당 도구가 여러분의 업무 흐름에 맞는지 더 쉽게 판단할 수 있도록 돕습니다.