검색

• 에이전트의 도구로 연결해 Agentic RAG에서 사용.
• 쿼리하고 검색된 콘텐츠를 LLM의 컨텍스트로 제공 (2-Step RAG).

자세한 내용은 검색 가능한 지식 베이스와 최소 RAG 워크플로를 구축하는 다음 튜토리얼을 참고하세요:

검색에서 RAG로

검색은 LLM이 런타임에 관련 컨텍스트에 접근할 수 있게 합니다. 그러나 대부분의 실제 애플리케이션은 한 단계 더 나아가 검색을 생성과 통합하여 근거 기반의 컨텍스트 인지형 답변을 만듭니다.

이것이 **검색 증강 생성(RAG)**의 핵심 아이디어입니다. 검색 파이프라인은 검색과 생성을 결합하는 더 넓은 시스템의 기반이 됩니다.

검색 파이프라인

전형적인 검색 워크플로는 다음과 같습니다:

flowchart TB
  subgraph ingest[" "]
    direction LR
    S(["Sources (Google Drive, Slack, Notion, etc.)"]) --> L[Document Loaders]
    L --> A([Documents])
  end
  A --> B[Split into chunks]
  B --> C[Turn into embeddings]
  C --> D[(Vector Store)]
  Q([User Query]) --> E[Query embedding]
  E --> D
  D --> F[Retriever]
  F --> G[LLM uses retrieved info]
  G --> H([Answer])

각 구성 요소는 모듈식이라 앱 로직을 다시 작성하지 않고도 로더, 스플리터, 임베딩, 벡터 스토어를 교체할 수 있습니다.

구성 요소

RAG 아키텍처

RAG는 시스템의 요구에 따라 여러 방식으로 구현할 수 있습니다. 아래 섹션에서 각 유형을 설명합니다.

2-step RAG

2-Step RAG에서는 검색 단계가 항상 생성 단계 전에 실행됩니다. 이 아키텍처는 직관적이고 예측 가능하여, 관련 문서의 검색이 답변 생성의 명확한 전제 조건인 많은 애플리케이션에 적합합니다.

graph TB
    A[User Question] --> B["Retrieve Relevant Documents"]
    B --> C["Generate Answer"]
    C --> D[Return Answer to User]

Agentic RAG

**Agentic RAG(에이전트 기반 검색 증강 생성)**는 검색 증강 생성의 강점을 에이전트 기반 추론과 결합합니다. 답하기 전에 문서를 검색하는 대신, (LLM이 지원하는) 에이전트가 단계별로 추론하며 상호작용 중 언제, 어떻게 정보를 검색할지 결정합니다.

graph TB
    A[User Input / Question] --> B["Agent (LLM)"]
    B --> C{Need external info?}
    C -- Yes --> D["Search using tool(s)"]
    D --> H{Enough to answer?}
    H -- No --> B
    H -- Yes --> I[Generate final answer]
    C -- No --> I
    I --> J[Return to user]

import { tool, createAgent } from "langchain";

const fetchUrl = tool(
    (url: string) => {
        return `Fetched content from ${url}`;
    },
    { name: "fetch_url", description: "Fetch text content from a URL" }
);

const agent = createAgent({
    model: "claude-sonnet-4-6",
    tools: [fetchUrl],
    systemPrompt,
});

하이브리드 RAG

하이브리드 RAG는 2-Step RAG와 Agentic RAG의 특성을 결합합니다. 쿼리 전처리, 검색 검증, 생성 후 검사 같은 중간 단계를 도입합니다. 이러한 시스템은 고정된 파이프라인보다 더 많은 유연성을 제공하면서도 실행에 대한 일부 제어를 유지합니다.

일반적인 구성 요소는 다음과 같습니다:

• 쿼리 향상: 검색 품질을 높이기 위해 입력 질문을 수정합니다. 불명확한 쿼리 재작성, 여러 변형 생성, 추가 컨텍스트로 쿼리 확장이 포함될 수 있습니다.
• 검색 검증: 검색된 문서가 관련성 있고 충분한지 평가합니다. 그렇지 않으면 시스템이 쿼리를 개선하고 다시 검색합니다.
• 답변 검증: 생성된 답변의 정확성, 완전성, 소스 콘텐츠와의 정렬을 확인합니다. 필요하면 시스템이 답변을 다시 생성하거나 수정할 수 있습니다.

이 아키텍처는 종종 이러한 단계 사이의 여러 반복을 지원합니다:

graph TB
    A[User Question] --> B[Query Enhancement]
    B --> C[Retrieve Documents]
    C --> D{Sufficient Info?}
    D -- No --> E[Refine Query]
    E --> C
    D -- Yes --> F[Generate Answer]
    F --> G{Answer Quality OK?}
    G -- No --> H{Try Different Approach?}
    H -- Yes --> E
    H -- No --> I[Return Best Answer]
    G -- Yes --> I
    I --> J[Return to User]

이 아키텍처는 다음과 같은 경우에 적합합니다:

• 모호하거나 불충분하게 지정된 쿼리가 있는 애플리케이션
• 검증 또는 품질 관리 단계가 필요한 시스템
• 여러 소스나 반복적 개선이 포함된 워크플로

더 알아보기

• RAG with Deep Agents
• Knowledge base 튜토리얼

출처: 문서