▲

GN⁺: 맥락 검색 기술

 (anthropic.com)
3P by neo 2달전 | favorite | 댓글 1개

Contextual Retrieval 소개

  • AI 모델이 특정 맥락에서 유용하려면 배경 지식이 필요함
  • 고객 지원 챗봇은 특정 비즈니스에 대한 지식이 필요하고, 법률 분석 봇은 과거 사례에 대한 방대한 지식이 필요함
  • 개발자는 일반적으로 Retrieval-Augmented Generation (RAG)을 사용하여 AI 모델의 지식을 향상시킴
  • 전통적인 RAG 솔루션은 정보를 인코딩할 때 맥락을 제거하여 관련 정보를 검색하지 못하는 경우가 많음

Contextual Retrieval 방법

  • Contextual Retrieval은 RAG의 검색 단계를 크게 개선하는 방법임
  • 두 가지 하위 기술인 Contextual Embeddings와 Contextual BM25를 사용함
  • 실패한 검색 횟수를 49% 줄이고, 재랭킹과 결합하면 67%까지 줄일 수 있음
  • Claude를 사용하여 Contextual Retrieval 솔루션을 쉽게 배포할 수 있음

단순히 더 긴 프롬프트 사용

  • 지식 베이스가 200,000 토큰 이하인 경우 전체 지식 베이스를 모델에 제공하는 것이 더 나은 방법일 수 있음
  • Claude의 프롬프트 캐싱 기능을 사용하면 이 접근 방식이 더 빠르고 비용 효율적임
  • 지식 베이스가 커지면 더 확장 가능한 솔루션이 필요함

RAG의 기본 개념

  • RAG는 큰 지식 베이스를 처리하기 위해 사용됨
  • 지식 베이스를 작은 텍스트 조각으로 나누고, 임베딩 모델을 사용하여 의미를 인코딩함
  • 벡터 데이터베이스에 저장하여 의미적 유사성에 따라 검색함
  • BM25는 정확한 단어 또는 구문 일치를 찾는 데 효과적임

전통적인 RAG의 한계

  • 문서를 작은 조각으로 나누는 과정에서 맥락이 파괴될 수 있음
  • 예를 들어, 특정 회사의 재무 정보를 찾는 질문에 대해 충분한 맥락이 없는 조각이 반환될 수 있음

Contextual Retrieval 구현

  • 각 조각에 설명적 맥락을 추가하여 임베딩 및 BM25 인덱스를 생성함
  • Claude를 사용하여 각 조각에 대한 간결한 맥락을 생성함
  • 프롬프트 캐싱을 사용하여 비용을 절감할 수 있음

성능 개선

  • Contextual Embeddings는 검색 실패율을 35% 줄임
  • Contextual Embeddings와 Contextual BM25를 결합하면 검색 실패율을 49% 줄임

구현 고려사항

  • 문서를 조각으로 나누는 방법, 임베딩 모델 선택, 사용자 정의 맥락화 프롬프트 등을 고려해야 함
  • 더 많은 조각을 포함하면 관련 정보를 포함할 가능성이 높아짐

재랭킹을 통한 성능 향상

  • 재랭킹은 가장 관련성이 높은 조각만 모델에 전달하여 응답 품질을 향상시킴
  • 재랭킹된 Contextual Embedding과 Contextual BM25는 검색 실패율을 67% 줄임

결론

  • Embeddings와 BM25를 결합하면 더 나은 결과를 얻을 수 있음
  • Voyage와 Gemini 임베딩이 가장 효과적임
  • 상위 20개의 조각을 모델에 전달하는 것이 가장 효과적임
  • 맥락을 추가하면 검색 정확도가 크게 향상됨
  • 재랭킹은 성능을 더욱 향상시킴

GN⁺의 정리

  • Contextual Retrieval은 AI 모델의 검색 정확도를 크게 향상시킬 수 있는 방법임
  • 특히 큰 지식 베이스를 다룰 때 유용함
  • Claude의 프롬프트 캐싱 기능을 사용하면 비용 효율적으로 구현할 수 있음
  • 다른 유사한 기능을 가진 프로젝트로는 OpenAI의 GPT-3와 Google의 BERT가 있음
▲
neo 2달전  [-]
Hacker News 의견

  • 첫 번째 의견

    • 정부 기관을 위한 기업 RAG 구축 경험 공유
    • RAGAS 지표를 사용한 A/B 테스트 결과:
      • 하이브리드 검색(의미론적 + 벡터)과 LLM 기반 재랭킹은 합성 평가 질문에서 큰 변화 없음
      • HyDE는 합성 평가 질문에서 답변 및 검색 품질을 심각하게 저하시킴
    • 하이브리드 검색은 항상 유용하지만, 한 가지 방법이 항상 우승하지 않음
    • Azure AI Search의 의미론적 검색이 벡터 유사성과 함께 충분히 효과적임
    • 다양한 방법을 테스트할 필요가 있음
    • 다음 시도할 것들:
      • RAPTOR
      • SelfRAG
      • Agentic RAG
      • 쿼리 정제(확장 및 하위 쿼리)
      • GraphRAG
    • 배운 점:
      • 항상 기준선과 실험을 사용하여 귀무 가설을 반박하려고 시도해야 함
      • 세 가지 유형의 평가 질문/답변 사용: 전문가 작성, 실제 사용자 질문, 합성 질문

  • 두 번째 의견

    • 프롬프트 캐싱을 활용하는 방식이 마음에 듦
    • 캐싱 덕분에 프롬프트 비용이 1/10로 줄어듦
    • 캐싱 비용 절감으로 다양한 트릭이 가능해짐
    • 컨텍스추얼 검색과 프롬프트 캐싱에 대한 노트 공유

  • 세 번째 의견

    • RAG 결과를 개선하기 위해 LLM을 사용하여 기본 청크를 확장하는 접근법은 흔함
    • HyDE를 사용한 쿼리 확장은 항상 개선되지 않음
    • Anthropic의 새로운 점은 프롬프트 캐싱 도입
    • 프롬프트 캐싱은 긴 문서를 컨텍스트로 제공하여 비용을 절감함
    • Cohere API가 매우 만족스러움

  • 네 번째 의견

    • 문서를 h1, h2, h3 헤딩을 기준으로 청크로 나누고, 청크 시작 부분에 헤더를 추가하는 방식 사용
    • 예시:
      • 기존 청크: "성인의 일반적인 복용량은 하루에 3번 200mg 정제 또는 캡슐 1~2개"
      • 새로운 청크: "# 열 ## 치료 --- 성인의 일반적인 복용량은 하루에 3번 200mg 정제 또는 캡슐 1~2개"
    • 이 방식은 LLM 없이도 잘 작동함

  • 다섯 번째 의견

    • 이 기술에 반대하는 입장
    • 벡터 임베딩은 첫 번째 줄 바꿈 텍스트 블록에 과도하게 집중할 수 있음
    • IDF 검색이 어느 정도 극복하지만 충분하지 않음
    • "semantic boost"를 사용하여 임베딩을 문서의 제목, 요약 등으로 이동시킬 수 있음
    • Trieve API의 "semantic boost" 설명 공유

  • 여섯 번째 의견

    • "링크드 리스트" 전략을 사용하여 청크가 참조된 항목에 여러 포인터를 가지게 함
    • 각 댓글이 원래 게시물에 대한 포인터가 되는 방식으로 설명
    • 이 기술의 예시 공유

  • 일곱 번째 의견

    • 200k 토큰을 사용하여 작은 데이터셋에서 최상의 답변을 얻는다는 주장은 경험과 다름
    • 프롬프트가 커질수록 출력이 일관되지 않고 지시를 따르기 어려워짐
    • 다른 사람들도 비슷한 경험을 했는지, 이를 피하는 방법이 있는지 궁금함

  • 여덟 번째 의견

    • RAG를 사용하여 지식을 검색하는 대신 규칙을 검색하는 문제에 직면함
    • 특정 규칙이 적용될 수 있는지 판단하기 위해 작은 분류기를 훈련시키는 접근법 제안
    • 예시: 멀티 유저 던전 게임에서 특정 규칙이 적용되는지 여부를 판단하는 방식
    • 규칙이 적용되는지 여부를 결정하는 것이 더 추상적이고 어려운 문제임
    • 이 문제를 해결할 방법을 찾고 있음

  • 아홉 번째 의견

    • 지식 베이스가 200,000 토큰(약 500 페이지)보다 작을 경우
    • Anthropic이 토크나이저를 공개해주길 바람

  • 열 번째 의견

    • AI 산업이 다시 TF-IDF로 돌아가는 날을 기다림
답변달기