RAG: 검색 증강 생성 설명
I 대형 언어 모델(LLM) 그들은 기술 혁신 중 하나를 나타냅니다 최근 몇 년간 가장 파괴적인 변화: GPT-4, Claude, Gemini 및 Llama는 코드를 작성할 수 있습니다. 문서를 요약하고, 복잡한 질문에 답하고, 추상적인 문제에 대해 추론할 수도 있습니다. 그러나 적용 가능성을 크게 제한하는 구조적 결함이 있습니다. 전문적인 맥락: 환각.
LLM이 답을 모를 때 "모르겠어요"라고 말하지 않습니다. 대신 그럴듯한 텍스트를 생성하세요. 그러나 검증 가능한 사실을 제시하는 만큼 자신있게 완전히 거짓입니다. 비즈니스, 법률 또는 의료 환경에서 이러한 행동은 용납될 수 없습니다. 해결책 이 문제에 대해 더 효과적이고 성숙한 것이 호출됩니다. 검색 증강 생성(RAG).
이 시리즈의 첫 번째 기사에서는 AI 엔지니어링 및 고급 RAG, 우리는 떠날 것이다 기본부터: RAG가 무엇인지, 어떻게 작동하는지, 왜 환각 문제를 해결하는지 작동하는 RAG 시스템을 처음부터 구축하는 방법을 알아보세요. 끝나면 이해가 될 것입니다. 전체 아키텍처에 대한 확실한 지식이 있으면 각 개별 구성 요소를 더 깊이 파고들 준비가 됩니다. 후속 기사에서.
시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 현재 위치 - RAG 설명 | 기본 및 전체 아키텍처 |
| 2 | 임베딩 및 의미 검색 | 텍스트가 벡터가 되는 방법 |
| 3 | 심층적인 벡터 데이터베이스 | 저장, 인덱싱, 유사성 검색 |
| 4 | LangChain과 Python을 사용한 RAG | 실용적인 엔드투엔드 구현 |
| 5 | 하이브리드 검색 및 순위 재지정 | 하이브리드 키워드 + 의미 검색 |
| 6 | 컨텍스트 창 및 프롬프트 엔지니어링 | LLM에 대한 컨텍스트 최적화 |
| 7 | 생산 중인 RAG | 확장, 모니터링, 평가 |
| 8 | 지식 그래프 및 RAG | 지식 그래프 + 검색 |
| 9 | 다중 에이전트 시스템 | 협업 AI 에이전트 |
| 10 | RAG의 미래 | 동향, 연구 및 다음 단계 |
무엇을 배울 것인가
- RAG는 무엇이며 LLM을 위해 해결되는 근본적인 문제는 무엇입니까?
- 전체 아키텍처: 문서 준비부터 응답 생성까지
- 임베딩, 벡터 스토어, 유사성 검색 작동 방식
- 청킹 전략과 그 장단점
- Python을 사용하여 최소한으로 작동하는 RAG 시스템을 구축하는 방법
- Naive RAG와 Advanced RAG의 차이점
- RAG를 사용하는 경우, 미세 조정 및 신속한 엔지니어링을 사용하는 경우
1. LLM의 환각 문제
RAG가 필요한 이유를 이해하려면 먼저 RAG가 해결하는 문제를 이해해야 합니다. 대규모 언어 모델은 본질적으로 언어의 확률적 모델: 입력 텍스트가 주어지면 가장 가능성이 높은 토큰 시퀀스를 연속으로 예측합니다. 이 아키텍처는 메커니즘을 기반으로 합니다. 주목 트랜스포머의 생산 특별한 결과가 나오지만 본질적인 한계가 있습니다. 모델은 인간의 감각으로 아무것도 "알지" 못합니다. 용어의. 학습된 패턴을 기반으로 통계적으로 그럴듯한 텍스트 생성 훈련.
LLM의 세 가지 구조적 문제
| 문제 | 설명 | 실질적인 영향 |
|---|---|---|
| 지식 차단 | 교육 날짜에 지식이 동결됩니다. | 최근 사건이나 독점 데이터에 대한 정보가 없습니다. |
| 환각 | 그럴듯하지만 완전히 조작된 답변 생성 | 높은 신뢰도로 거짓 정보 제시 |
| 따옴표 없음 | 그는 자신의 진술의 출처를 밝힐 수 없습니다 | 답변의 정확성 확인이 불가능함 |
| 개인 데이터 없음 | 그는 회사의 내부 문서를 모릅니다 | 컨텍스트가 없는 특정 사용 사례에는 쓸모가 없습니다. |
환각은 일회성 버그가 아닙니다. 아키텍처의 직접적인 결과입니다. 모델에 응답할 만큼 충분한 정보가 없으면 오류를 반환하지 않습니다. 대신, 텍스트의 가장 가능성 있는 연속을 생성합니다. 발명. 모델은 유창하고 일관된 텍스트를 생성하도록 훈련되었습니다. 실제로 정확해야 합니다.
환각의 구체적인 예
문제의 심각성을 이해하기 위해 환각이 나타나는 실제 시나리오를 고려해 보겠습니다. 중대한 결과를 초래합니다:
- 법적 범위: LLM은 존재하지 않는 판결이나 제정되지 않은 법률을 신뢰할 수 있지만 발명된 항목 번호로 인용할 수 있습니다.
- 의료 분야: 이는 잘못된 약물 복용량이나 문서화되지 않은 약물 상호 작용을 시사할 수 있습니다.
- 기술 문서: 존재하지 않는 매개변수나 구현되지 않은 기능이 포함된 API를 설명할 수 있습니다.
- 고객 지원: 그들은 회사 정책, 반품 절차 또는 존재하지 않는 보증을 고안할 수 있습니다.
통계는 문제의 규모를 확인합니다. 환각의 비율은 다양합니다. 의학, 법률 등 전문 분야를 포함하여 도메인별로 크게 가장 진보된 모델에서도 10~20%의 비율을 기록합니다. RAG는 기술을 나타냅니다. 최대 71%의 감소가 문서화되어 이 문제를 완화하는 데 가장 효과적입니다.
2. RAG란 무엇인가: 정의와 유래
검색 증강 생성(RAG) 건축 패러다임이다 의 시스템을 결합합니다. 정보 검색 (문서 복구) 템플릿 포함 생성(LLM)은 실제 데이터를 기반으로 답변을 생성합니다. 개념이 공식화되었습니다. 2020년에는 Patrick Lewis와 Meta AI의 동료들이 세미나 논문에서 발표했습니다. "지식 집약적인 NLP 작업을 위한 검색 증강 생성".
핵심 통찰력은 간단합니다. 모델에게 모든 정보를 "기억"하도록 요청하는 대신 훈련을 통해 얻은 정보를 바탕으로 훈련 시 관련 문서를 제공합니다. 세대. 이 과정을 접지: 앵커 생성 구체적이고 검증 가능한 출처를 참조하세요.
LLM TRADIZIONALE:
Domanda utente ──────────────────> [LLM] ──> Risposta
|
Basata SOLO su training data
Rischio allucinazione: ALTO
RAG (Retrieval-Augmented Generation):
Domanda utente ──> [RETRIEVAL] ──> Documenti rilevanti
| |
| v
└───────> [LLM + Contesto] ──> Risposta con citazioni
|
Basata su DATI REALI recuperati
Rischio allucinazione: BASSO
비유: 오픈북 시험
대학 시험을 상상해 보세요. 전통적인 LLM은 답을 해야 하는 학생과 같습니다. by heart: 많은 것을 알고 있지만 혼란스럽거나 세부적인 내용을 생각해 낼 수 있습니다. RAG는 마치 시험 펼쳐진 책: 학생은 자신의 노트와 책을 참고할 수 있습니다. 대답하기 전에. 답변은 근거가 있기 때문에 더 정확하고 검증 가능합니다. 구체적인 출처에 대해.
접지 개념은 매우 중요합니다. 생성된 응답의 모든 진술은 지식 베이스의 특정 문서로 역추적됩니다. 이는 다음을 의미합니다.
- 대답은 다음과 같습니다 증명할 수 있는: 원본 문서를 확인할 수 있습니다.
- 대답은 다음과 같습니다 업데이트 가능: 문서를 업데이트하면 답변이 자동으로 변경됩니다.
- 대답은 다음과 같습니다 통제할 수 있는: 시스템이 참조할 수 있는 문서를 결정합니다.
- 대답은 다음과 같습니다 추적 가능: 출처를 참고하여 인용문을 포함할 수 있습니다.
3. RAG 작동 방식: 전체 파이프라인
RAG 시스템은 두 개의 매크로 단계로 구성됩니다. 인덱싱 파이프라인, 일회성(또는 주기적으로)으로 문서를 준비하는 쿼리 파이프라인, 사용자 쿼리를 실시간으로 처리합니다.
3.1 인덱싱 파이프라인(오프라인 단계)
인덱싱 단계에서는 원시 문서를 최적화된 구조로 변환합니다. 의미 검색을 위해. 이는 네 가지 순차적 단계로 구성됩니다.
[Documenti Sorgente]
| PDF, HTML, Markdown, CSV, database, API, email...
v
[1. DOCUMENT LOADING]
| Estrazione del testo grezzo dai formati sorgente
| Preservazione dei metadati (autore, data, titolo)
v
[2. CHUNKING (Text Splitting)]
| Divisione in frammenti di dimensione gestibile
| Strategie: fixed-size, semantic, recursive
| Overlap tra chunk per preservare contesto
v
[3. EMBEDDING]
| Trasformazione di ogni chunk in un vettore numerico
| Modelli: OpenAI, Sentence Transformers, Cohere
| Dimensioni tipiche: 384, 768, 1536, 3072
v
[4. VECTOR STORE]
| Salvataggio dei vettori in un database specializzato
| Indexing per ricerca veloce (HNSW, IVF)
| ChromaDB, Pinecone, Weaviate, Milvus, Qdrant
v
[Knowledge Base Pronta per le Query]
3.2 쿼리 파이프라인(온라인 단계)
사용자가 질문을 하면 쿼리 파이프라인이 작동하여 다음을 찾습니다. 가장 관련성이 높은 문서를 찾아 근거가 충분한 답변을 생성합니다.
[Domanda dell'Utente]
| "Come configuro l'autenticazione OAuth nella nostra app?"
v
[1. QUERY EMBEDDING]
| La domanda viene trasformata in vettore
| Stesso modello usato nell'indicizzazione!
v
[2. SIMILARITY SEARCH]
| Ricerca dei chunk più simili nel vector store
| Metriche: cosine similarity, L2, dot product
| Restituisce i top-k risultati (tipicamente k=3..10)
v
[3. CONTEXT ASSEMBLY]
| I chunk recuperati vengono assemblati in un contesto
| Ordinamento per rilevanza, deduplicazione
v
[4. PROMPT CONSTRUCTION]
| Costruzione del prompt con contesto + domanda
| Template: "Basandoti sui seguenti documenti, rispondi..."
v
[5. LLM GENERATION]
| Il modello genera la risposta basandosi sul contesto
| Può includere citazioni ai documenti sorgente
v
[Risposta Fondata + Citazioni]
기본 규칙: 임베딩의 일관성
E' 의무적인 두 가지 모두에서 동일한 임베딩 모델을 사용합니다. 쿼리 단계보다 인덱싱이 더 좋습니다. 다양한 모델이 벡터 공간을 생성합니다. 호환되지 않음: 모델에 의해 생성된 벡터가 해당 벡터와 비교할 수 없습니다. 다른 것. 임베딩 모델을 변경하려면 완전한 재인덱싱이 필요합니다. 모든 문서의.
4. 문서 처리: 청킹 및 준비
Il 청킹 이는 전체 RAG 파이프라인에서 가장 중요한 단계 중 하나입니다. 결과의 품질은 문서를 어떻게 분할하느냐에 따라 크게 달라집니다. 너무 큰 청크는 의미 신호를 희석시키고 컨텍스트 창에서 공간을 낭비합니다. LLM의. 너무 작은 청크는 이해하는 데 필요한 컨텍스트를 잃습니다.
4.1 고정 크기 청킹
가장 간단한 전략: 텍스트를 고정된 크기의 블록(예: 토큰 500개)으로 나눕니다. 연속된 청크 사이에 선택적으로 겹치는 부분이 있습니다.
고정 크기 청킹 매개변수
| 매개변수 | 설명 | 일반적인 값 |
|---|---|---|
| 청크_크기 | 토큰 또는 문자의 각 청크의 최대 크기 | 300-500 토큰 |
| 덩어리_겹침 | 연속된 청크 사이의 겹침 | Chunk_size의 10~20% |
| 분리 기호 | 나누는 데 사용되는 문자/문자열 | "\n\n", "\n", " " |
Documento originale (1500 token):
"Lorem ipsum dolor sit amet... [1500 token di testo]"
Con chunk_size=500 e overlap=50:
Chunk 1: token 1-500 ────────────┐
Chunk 2: token 451-950 ──┐ overlap │
Chunk 3: token 901-1400 ──┘ │
Chunk 4: token 1351-1500 │
────────────┘
L'overlap garantisce che il contesto ai bordi non venga perso.
4.2 재귀적 문자 분할
문서의 구조를 존중하면서 분할하려는 보다 정교한 전략입니다. 구분 기호 계층을 사용하세요. 먼저 단락("\n\n")으로 나누어 보세요. 다음은 줄("\n"), 문장(". "), 마지막으로 단어(" ")입니다. 이는 고정 크기보다 의미적 컨텍스트를 더 잘 보존합니다.
4.3 의미적 청킹
가장 발전된 전략: 임베딩 자체를 사용하여 분할할 위치를 결정합니다. 연속된 문장 간의 유사성을 계산하고, 유사성이 있을 때 새로운 청크를 생성합니다. 임계값 아래로 떨어지면 주제가 변경되었음을 나타냅니다. 크기의 덩어리를 생성합니다. 가변적이지만 의미적으로 일관성이 있습니다.
청킹 전략 비교
| 전략 | 품질 | 복잡성 | 언제 사용하는가 |
|---|---|---|---|
| 고정 크기 | 기초적인 | 최소한의 | 프로토타이핑, 동질적인 문서 |
| 재귀적 | 좋은 | 낮은 | 일반 목적의 구조화된 문서 |
| 의미론 | 훌륭한 | 높은 | 고품질이 요구되는 이기종 문서 |
메타데이터의 중요성
각 덩어리에는 신이 함께 있어야 합니다. 메타데이터: 문서 제목, 작성자, 날짜, 섹션, 페이지. 이 메타데이터는 필터링에 중요합니다. 귀하가 검색하는 동안 귀하의 응답에서 정확한 인용을 생성하기 위해. 없는 덩어리 메타데이터는 맥락이 없는 단락과 같습니다.
5. 임베딩: 텍스트를 벡터로 변환
그만큼 임베딩 이는 RAG의 수학적 핵심입니다. 임베딩은 다음을 포착하는 숫자 표현(십진수의 벡터) 의미론적 의미 텍스트의. 비슷한 의미를 가진 두 문장은 사용된 단어에 관계없이 다차원 공간의 "인근" 벡터입니다.
INPUT: Frase di testo
OUTPUT: Vettore di numeri decimali (es. 1536 dimensioni)
Esempio:
"Il gatto dorme sul divano" --> [0.23, -0.45, 0.67, 0.12, -0.89, ...]
"Il felino riposa sul sofa" --> [0.22, -0.44, 0.68, 0.11, -0.88, ...]
^^ Vettori molto SIMILI (stesso significato)
"Il prezzo dell'oro sale" --> [-0.56, 0.78, -0.12, 0.91, 0.34, ...]
^^ Vettore molto DIVERSO (significato diverso)
임베딩 모델은 엄청난 양의 텍스트에 대해 훈련된 신경망입니다. 단어, 문장, 개념 간의 의미론적 관계를 학습합니다. 단순히 생산하는 것이 아니다 구문적 표현(예: Bag-of-words 또는 TF-IDF)이지만 의미를 포착합니다. 텍스트의 깊이.
주요 임베딩 모델(2025-2026)
| 모델 | 치수 | 공급자 | 표시 비용 |
|---|---|---|---|
text-embedding-3-small |
1536년 | 오픈AI | ~$0.02 / 100만 토큰 |
text-embedding-3-large |
3072 | 오픈AI | ~$0.13 / 100만 토큰 |
voyage-3-large |
1024 | 항해 AI | ~$0.06 / 100만 토큰 |
all-MiniLM-L6-v2 |
384 | 포옹얼굴 | 무료(자체 호스팅) |
nomic-embed-text |
768 | 올라마(현지) | 무료(현지) |
embed-v4 |
1024 | 코히어 | ~$0.10 / 100만 토큰 |
임베딩 모델 선택은 사용 사례에 따라 다릅니다. 가장 큰 모델(3072 차원)은 더 풍부한 표현을 제공하지만 비용이 더 많이 듭니다. 저장 및 계산. 많은 사용 사례에서 768-1536 크기 모델은 다음을 제공합니다. 품질과 비용 사이의 탁월한 절충안.
6. 벡터 저장소: 임베딩을 위한 데이터베이스
Un 벡터 저장소 (또는 벡터 데이터베이스)는 다음에 대한 전문적인 데이터베이스입니다. 고차원 벡터를 저장, 색인화 및 검색합니다. 와 달리 정확한 일치를 찾는 기존 데이터베이스(SQL WHERE), 벡터 저장소 더 많은 운송업체를 검색해 보세요 비슷한 쿼리에 대한 것입니다.
6.1 유사성 측정
벡터 매장 검색은 벡터 간의 거리/유사성 측정항목을 기반으로 합니다. 가장 일반적인 세 가지 지표는 다음과 같습니다.
유사성 측정항목 비교
| 미터법 | 범위 | 설명 | 언제 사용하는가 |
|---|---|---|---|
| 코사인 유사성 | [-1, 1] | 두 벡터 사이의 각도를 측정하고 크기는 무시합니다. | 대부분의 경우 기본값(권장) |
| 유클리드 거리(L2) | [0, +inf) | 크기에 민감한 공간의 기하학적 거리 | 벡터의 크기가 중요한 경우 |
| 내적 | (-inf, +inf) | 스칼라 곱은 방향과 크기를 결합합니다. | 이미 정규화된 벡터, 최대 내부곱 검색 |
6.2 벡터 데이터베이스 개요
RAG의 도입으로 벡터 데이터베이스 시장이 폭발적으로 성장했습니다. 개요는 다음과 같습니다. 사용 가능한 주요 도구 중:
벡터 데이터베이스 비교
| 데이터베이스 | 유형 | 언어 | 이상적인 대상 |
|---|---|---|---|
| 크로마DB | 임베디드/서버 | 파이썬 | 프로토타입 제작, 로컬 개발, 소규모 데이터 세트 |
| 솔방울 | 클라우드 관리 | 다중 언어 | 프로덕션, 자동 확장, 무운영(Zero-Ops) |
| 위비에이트 | 자체 호스팅/클라우드 | Go | 하이브리드 검색, 멀티 테넌시, GraphQL |
| 밀부스 | 자체 호스팅/클라우드 | 이동 / C++ | 대용량, 고성능, 엔터프라이즈 |
| Qdrant | 자체 호스팅/클라우드 | Rust | 성능, 고급 필터링, REST API |
| pg벡터 | PostgreSQL 확장 | C | 기존 PostgreSQL 스택, 관계형 + 벡터 데이터 |
| FAISS | 인메모리 라이브러리 | C++/파이썬 | 연구, 벤치마크, 최대 최적화 |
시작하려면, 크로마DB 가장 간단한 선택입니다. pip로 설치됩니다. 메모리 내에서 또는 디스크에서 지속적으로 작동하며 기본적으로 LangChain과 통합됩니다. 프로덕션의 경우 Pinecone(관리형) 및 Qdrant(자체 호스팅)가 옵션 중 하나입니다. 가장 인기가 있습니다.
7. 검색: 관련 문서 검색
단계 검색 사용자의 질문이 들어오는 순간입니다 벡터로 변환하고 벡터 저장소의 모든 벡터와 비교하여 다음을 찾습니다. 가장 관련성이 높은 덩어리. 이 프로세스는 수백만 달러라도 밀리초 안에 발생합니다. HNSW와 같은 대략적인 인덱싱 알고리즘 덕분에 인덱싱된 문서 (계층적으로 탐색 가능한 작은 세계).
Query: "Come configuro OAuth nella nostra app?"
|
v
[1] Embedding della query ──> [0.34, -0.21, 0.56, ...]
|
v
[2] Similarity Search nel Vector Store
| Confronta il vettore della query con tutti i vettori salvati
| Usa cosine similarity come metrica
|
v
[3] Top-K Results (es. k=5)
|
| Score: 0.92 - "Configurazione OAuth 2.0 per applicazioni web..."
| Score: 0.87 - "Guida ai flussi di autenticazione OAuth..."
| Score: 0.83 - "Impostazione dei redirect URI per OAuth..."
| Score: 0.76 - "Confronto tra OAuth e SAML per SSO..."
| Score: 0.71 - "Sicurezza delle API con token JWT..."
|
v
[4] Filtering e Reranking (opzionale)
| Filtra per metadati (data, categoria, fonte)
| Reranking con modello cross-encoder
|
v
[Chunk Rilevanti Pronti per il Prompt]
7.1 Top-K 매개변수
매개변수 탑케이 복구되는 청크 수를 결정합니다. 선택 그것은 절충안입니다.
- K가 너무 낮음(1-2): 관련 정보 누락 위험
- K가 너무 높음(20+): 컨텍스트에 노이즈가 너무 많음, 토큰 낭비, 모델 혼동 위험
- 최적의 K(3-7): 적용 범위와 정밀도 사이의 적절한 균형
7.2 관련성 점수
각 결과에는 관련성 점수 (관련성 점수). 덩어리 점수가 낮으면 쓸모 없는 노이즈를 추가하므로 필터링해야 합니다. 코사인 유사성의 일반적인 임계값은 0.7입니다. 아래의 모든 항목은 삭제됩니다. 실제로 최적의 임계값은 도메인에 따라 다르며 실험적으로 보정되어야 합니다.
8. 세대: LLM을 통한 대응 구축
RAG 파이프라인의 마지막 단계: 검색된 청크는 구조화된 컨텍스트 LLM 프롬프트에 다음과 함께 삽입됩니다. 사용자 질문. 모델은 전적으로 (또는 주로) 제공된 맥락에 따라 결정됩니다.
8.1 프롬프트 템플릿
좋은 RAG 프롬프트 템플릿은 모델에 다음을 지시해야 합니다.
- 사용 홀로 제공된 컨텍스트의 정보
- 문서에서 답을 찾을 수 없으면 인정하십시오.
- 가능하다면 출처를 인용하세요.
- 맥락에 맞지 않는 정보를 만들어내지 마세요.
Sei un assistente tecnico. Rispondi alle domande SOLO basandoti
sul contesto fornito. Se la risposta non è presente nel contesto,
rispondi "Non ho trovato informazioni sufficienti nei documenti
disponibili."
CONTESTO:
---
{context}
---
DOMANDA: {question}
ISTRUZIONI:
1. Rispondi in modo chiaro e conciso
2. Cita il documento sorgente tra parentesi quadre [Fonte: nome_doc]
3. Se il contesto non contiene la risposta, dillo esplicitamente
4. Non inventare informazioni non presenti nel contesto
RISPOSTA:8.2 인용 추적
RAG의 가장 중요한 기능 중 하나는 인용 추적 기능입니다. 컨텍스트의 각 청크에는 식별자(예: [DOC-1], [DOC-2])로 레이블이 지정될 수 있습니다. 모델은 응답에서 이러한 식별자를 참조하도록 지시받습니다. 이 사용자는 원본 문서를 참조하여 각 명세서를 확인할 수 있습니다.
컨텍스트 창 및 제한
삽입할 수 있는 컨텍스트의 양은 다음으로 제한됩니다. 컨텍스트 창 LLM 모델의 복구된 청크가 제한을 초과하는 경우 해당 청크만 선택해야 합니다. 가장 관련성이 높거나 요약합니다. GPT-4o(128K 토큰) 및 Claude 3.5와 같은 최신 모델 (200K 토큰)은 매우 큰 컨텍스트 창을 가지고 있지만 그럼에도 불구하고 너무 많은 컨텍스트를 삽입합니다. 관련성이 없는 경우 답변의 품질이 저하됩니다(소위 "중간 손실" 문제).
9. 완전한 RAG 아키텍처: 개요
이제 각 구성 요소를 개별적으로 살펴보았으므로 아키텍처를 조립해 보겠습니다. 엔드투엔드 RAG 시스템으로 완성:
FASE OFFLINE (Indicizzazione)
┌──────────────────────────────────────────────────────┐
│ │
│ [Documenti] ──> [Loader] ──> [Chunker] │
│ PDF, HTML Estrazione Divisione │
│ MD, CSV testo in frammenti │
│ │ │
│ v │
│ [Embedding Model] │
│ Testo ──> Vettore │
│ │ │
│ v │
│ [Vector Store] │
│ ChromaDB, Pinecone │
│ Weaviate, Qdrant │
│ │
└──────────────────────────────────────────────────────┘
FASE ONLINE (Query)
┌──────────────────────────────────────────────────────┐
│ │
│ [Domanda Utente] │
│ │ │
│ v │
│ [Query Embedding] ──> [Similarity Search] │
│ Stesso modello Top-K chunk │
│ dell'indicizzazione │ │
│ v │
│ [Context Assembly] │
│ Chunk + Metadati │
│ │ │
│ v │
│ [Prompt Template + Contesto + Domanda] │
│ │ │
│ v │
│ [LLM] │
│ GPT-4, Claude │
│ Llama, Gemini │
│ │ │
│ v │
│ [Risposta con Citazioni] │
│ │
└──────────────────────────────────────────────────────┘
회원 및 책임
| 요소 | 책임 | 일반적인 도구 |
|---|---|---|
| 문서 로더 | 다양한 소스의 문서 업로드 | LangChain 로더, 비구조화, LlamaIndex |
| 텍스트 분할기 | 문서를 최적의 청크로 분할 | RecursiveCharacterTextSplitter, SemanticChunker |
| 임베딩 모델 | 텍스트를 의미론적 벡터로 변환 | OpenAI 임베딩, 문장 변환기, Cohere |
| 벡터 스토어 | 벡터 저장 및 인덱스 | ChromaDB, 솔방울, Qdrant, pgVector |
| 리트리버 | 가장 관련성이 높은 청크 검색 | 유사성 검색, MMR, 하이브리드 검색 |
| 법학대학원 | 컨텍스트에서 최종 응답 생성 | GPT-4o, 클로드 3.5, 라마 3, 제미니 프로 |
10. 실제 예: Python을 사용한 최소 RAG
최소한의 코드로 작동하는 RAG 시스템을 구축해 보겠습니다. 우리는 사용할 것이다 랭체인 오케스트레이션 프레임워크로서 오픈AI 임베딩 및 생성의 경우 e 크로마DB 지역 벡터 상점으로.
10.1 프로젝트 설정
# Crea un ambiente virtuale
python -m venv rag-env
source rag-env/bin/activate # Linux/Mac
# Installa le dipendenze
pip install langchain langchain-openai langchain-community
pip install chromadb
pip install pypdf # Per caricare PDF10.2 인덱싱 파이프라인
import os
from langchain_community.document_loaders import (
PyPDFLoader,
TextLoader,
DirectoryLoader
)
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
# Configura la API key
os.environ["OPENAI_API_KEY"] = "sk-..."
# 1. DOCUMENT LOADING
# Carica tutti i PDF da una cartella
loader = DirectoryLoader(
"./documenti/",
glob="**/*.pdf",
loader_cls=PyPDFLoader
)
documents = loader.load()
print(f"Caricati {len(documents)} documenti")
# 2. CHUNKING
# Divisione ricorsiva con overlap
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500, # 500 caratteri per chunk
chunk_overlap=50, # 50 caratteri di overlap
length_function=len,
separators=["\n\n", "\n", ". ", " ", ""]
)
chunks = text_splitter.split_documents(documents)
print(f"Creati {len(chunks)} chunk")
# 3. EMBEDDING + 4. VECTOR STORE
# Crea gli embeddings e salvali in ChromaDB
embedding_model = OpenAIEmbeddings(
model="text-embedding-3-small"
)
vectorstore = Chroma.from_documents(
documents=chunks,
embedding=embedding_model,
persist_directory="./chroma_db",
collection_name="documenti_aziendali"
)
print("Vector store creato e salvato su disco")10.3 쿼리 파이프라인
import os
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate
os.environ["OPENAI_API_KEY"] = "sk-..."
# Carica il vector store esistente
embedding_model = OpenAIEmbeddings(
model="text-embedding-3-small"
)
vectorstore = Chroma(
persist_directory="./chroma_db",
embedding_function=embedding_model,
collection_name="documenti_aziendali"
)
# Configura il retriever
retriever = vectorstore.as_retriever(
search_type="similarity",
search_kwargs={"k": 5} # Recupera i 5 chunk più simili
)
# Definisci il prompt template
prompt_template = PromptTemplate(
template="""Sei un assistente tecnico esperto.
Rispondi alla domanda basandoti SOLO sul contesto fornito.
Se non trovi la risposta nel contesto, dillo esplicitamente.
CONTESTO:
{context}
DOMANDA: {question}
RISPOSTA (con citazioni ai documenti fonte):""",
input_variables=["context", "question"]
)
# Crea la chain RAG
llm = ChatOpenAI(
model="gpt-4o",
temperature=0 # Deterministic per risposte fattuali
)
rag_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff", # Inserisci tutti i chunk nel prompt
retriever=retriever,
return_source_documents=True,
chain_type_kwargs={
"prompt": prompt_template
}
)
# Esegui una query
result = rag_chain.invoke(
{"query": "Come configuro l'autenticazione OAuth?"}
)
# Stampa la risposta
print("RISPOSTA:")
print(result["result"])
print("\nFONTI:")
for doc in result["source_documents"]:
print(f" - {doc.metadata.get('source', 'N/A')}"
f" (pagina {doc.metadata.get('page', 'N/A')})")예상 출력
RISPOSTA:
Per configurare l'autenticazione OAuth nella nostra applicazione,
segui questi passaggi:
1. Registra l'app nel provider OAuth (Google, GitHub, etc.)
2. Configura i redirect URI nel file config.yaml [Fonte: guida-oauth.pdf]
3. Implementa il flusso Authorization Code [Fonte: architettura-auth.pdf]
...
FONTI:
- documenti/guida-oauth.pdf (pagina 12)
- documenti/architettura-auth.pdf (pagina 5)
- documenti/faq-sicurezza.pdf (pagina 3)
10.4 프로젝트 구조
rag-project/
├── documenti/ # I tuoi documenti sorgente
│ ├── guida-oauth.pdf
│ ├── architettura.pdf
│ └── faq.pdf
├── chroma_db/ # Vector store persistente (generato)
├── indexing.py # Script di indicizzazione
├── query.py # Script di query
├── requirements.txt # Dipendenze
└── .env # API keys (mai committare!)
11. 순진한 RAG 대 고급 RAG
지금까지 우리가 구축한 시스템은 커뮤니티에서 부르는 것입니다. 순진한 RAG: 많은 사용 사례에서 놀라울 정도로 잘 작동하는 간단하고 간단한 구현입니다. 그러나 기술에는 한계가 있습니다. 고급 RAG 그들은 추구한다 극복하다.
11.1 단순 RAG의 한계
- 쿼리-문서 불일치: 귀하의 질문에는 문서와 다른 용어가 사용될 수 있습니다. "비밀번호를 재설정하는 방법은 무엇입니까?" vs 문서 "자격 증명 복구 절차"
- 청크 경계 문제: 관련 정보는 두 개의 연속된 청크 사이에서 깨질 수 있습니다.
- 중간에 길을 잃다: LLM은 중앙 부분을 무시하고 컨텍스트의 시작과 끝 부분에 더 많은 가중치를 부여하는 경향이 있습니다.
- 단일 홉 제한: 여러 문서의 요약이 필요한 질문에는 답변할 수 없습니다.
11.2 고급 RAG 기술
순진한 RAG에서 고급 RAG로의 진화
| 기술 | 문제 해결 | 작동 방식 |
|---|---|---|
| 쿼리 재작성 | 모호하거나 잘못된 표현의 쿼리 | LLM은 검색에 더 적합한 형식으로 쿼리를 다시 작성합니다. |
| 하이드 | 쿼리-문서 불일치 | 쿼리에서 가상 문서를 생성한 후 유사한 문서를 검색합니다. |
| 순위 재지정 | 결과가 최적으로 정렬되지 않음 | 크로스 인코더 모델은 관련성에 따라 결과를 재정렬합니다. |
| 다중 쿼리 | 단일 연구 관점 | 적용 범위를 넓히기 위해 쿼리 변형 생성 |
| 셀프랙 | 검색이 필요하지 않은 경우 | 모델은 검색 여부와 시기를 자율적으로 결정합니다. |
| 멀티홉 RAG | 복잡한 다단계 질문 | 복합 추론을 구축하기 위한 반복 검색 체인 |
| 하이브리드 검색 | 의미 검색만으로는 한계 | 의미론적(벡터) 검색과 키워드 결합(BM25) |
| 그래프 RAG | 엔터티 간의 복잡한 관계 | 지식 그래프를 사용하여 구조화된 관계 및 컨텍스트 탐색 |
NAIVE RAG:
Query ──> Embedding ──> Search ──> Top-K ──> LLM ──> Risposta
ADVANCED RAG:
Query ──> [Query Analysis]
│
├──> Query Rewriting ──> Embedding ──> Search ─┐
├──> HyDE Generation ──> Embedding ──> Search ─┤
└──> Multi-Query ──────> Embedding ──> Search ─┘
│
[Merge + Deduplica]
│
[Reranker Model]
│
[Context Compression]
│
[LLM + Citazioni]
│
[Risposta Verificata]
우리는 시리즈의 후속 기사에서 이러한 각 기술에 대해 더 자세히 알아볼 것입니다. 특히 기사에서 하이브리드 검색 및 순위 재지정.
12. RAG를 사용해야 하는 경우: 의사결정 프레임워크
RAG가 모든 문제에 대한 답은 아닙니다. 세 가지 주요 접근 방식이 있습니다. 각각 뚜렷한 장점과 제한 사항이 있는 LLM의 동작을 사용자 정의합니다. 선택은 특정 사용 사례에 따라 다릅니다.
RAG vs 미세 조정 vs 프롬프트 엔지니어링
| 표준 | 신속한 엔지니어링 | 조각 | 미세 조정 |
|---|---|---|---|
| 초기비용 | 최저한의 | 중간 | 높은 |
| 필요한 데이터 | 아무도 | 지식 기반 | 훈련 데이터세트 |
| 업데이트 | 즉시(즉시 변경) | 신속(문서 업데이트) | 느림(재훈련) |
| 숨어 있음 | 낮은 | 미디어(검색 + 생성) | 낮은 |
| 사실적 정확성 | 모델에 따라 다릅니다. | 높음(문서 기반) | 평균(훈련에 따라 다름) |
| 인용 가능 | 없음 | 높음(트랙 소스) | 없음 |
| 복잡성 | 낮은 | 평균 | 높은 |
12.1 실제 의사결정나무
Hai bisogno di personalizzare un LLM?
│
├── I dati cambiano frequentemente? (documenti, policy, catalogo)
│ └── SI ──> RAG
│ (I dati si aggiornano senza re-training)
│
├── Serve citare le fonti?
│ └── SI ──> RAG
│ (Tracciabilita delle risposte)
│
├── Il dominio è stabile e ben definito?
│ ├── Hai un grande dataset di training?
│ │ └── SI ──> Fine-Tuning
│ │ (Personalizzazione profonda del comportamento)
│ └── NO ──> RAG oppure Prompt Engineering
│
├── Serve solo cambiare tono/formato/stile?
│ └── SI ──> Prompt Engineering
│ (Nessuna infrastruttura aggiuntiva)
│
└── Serve ragionamento complesso su dati proprietari?
└── SI ──> RAG + Fine-Tuning (Approccio Ibrido)
(Il meglio di entrambi i mondi)
황금률
AI 엔지니어링 커뮤니티에서 권장하는 접근 방식은 복잡성의 정도를 따릅니다. 오름차순: 엔지니어링 프롬프트로 시작, 다음으로 이동합니다. 조각 외부 데이터나 인용이 필요한 경우 미세 조정 오직 언제 처음 두 가지 접근 방식으로는 충분하지 않습니다. 이 진행으로 인해 비용이 최소화됩니다. 복잡성을 최소화하여 ROI를 극대화합니다.
12.2 RAG의 이상적인 사용 사례
- 비즈니스 챗봇: 내부 문서를 기반으로 응답합니다.
- 의미 검색: 키워드뿐만 아니라 의미와 관련된 문서 찾기
- 기술 자료 Q&A: 문서로 업데이트되는 동적 FAQ
- 법률 보조원: 규정 및 법리에 근거한 답변
- 기술 지원: 이전 티켓과 수동 티켓을 기반으로 한 해결 방법
- 다큐멘터리 분석: 보고서, 계약서, 과학 논문에서 인사이트 추출
12.3 RAG를 사용하지 말아야 할 경우
- 창의적인 작업: 문예창작, 브레인스토밍, 아이디어 창출(템플릿은 무료여야 함)
- 일반적인 대화: 특정 데이터가 필요하지 않은 소셜 챗봇
- 데이터가 거의 없는 작업: 문서가 몇 개밖에 없다면 신속한 엔지니어링만으로도 충분할 수 있습니다.
- 긴밀한 실시간 응답: 검색 지연 시간이 허용되지 않는 경우(50ms 미만)
13. RAG 시장: 수치 및 동향
RAG는 더 이상 학문적 개념이 아닙니다. 채택된 프로덕션 아키텍처가 되었습니다. 대규모로. 시장 수치는 전략적 중요성을 확증해 줍니다.
숫자로 보는 RAG(2024-2030)
| 미터법 | 주어진 |
|---|---|
| 글로벌 RAG 시장(2024년) | ~12억 달러 |
| 시장 전망(2030년) | ~110억 달러 |
| 연간 성장률(CAGR) | 49.1% (2025~2030) |
| 기업 채택 | LLM 사용 사례의 30~60%가 RAG를 사용합니다. |
| 환각 감소 | 잘 구현된 RAG를 사용하면 최대 71% |
| 주요 프레임워크 | 80.5%가 FAISS 또는 Elasticsearch를 사용합니다. |
채택을 주도하는 산업은 법률, 의료, 고객 지원 및 서비스입니다. 금융, 즉 사실적 정확성과 인용 가능성이 있는 모든 영역 소스는 협상할 수 없는 요구 사항입니다. 2025~2026년 트렌드는 전환되고 있다 실험에서 대규모 생산에 이르기까지 점점 더 강조되고 있습니다. 규정 준수, 모니터링 및 데이터 품질.
14. 결론 및 다음 단계
이 기사에서 우리는 RAG에 대한 포괄적인 이해를 구축했습니다. (LLM의 환각)을 엔드투엔드 아키텍처로 해결하여 파이프라인의 모든 단일 구성 요소. 우리는 실제로 작동하는 구현을 보았습니다. 그리고 RAG를 대안(미세 조정, 신속한 엔지니어링)과 비교했습니다.
주요 개념 요약
- 조각 검색과 생성을 결합하여 실제 데이터를 기반으로 답변 생성
- La 인덱싱 파이프라인 문서를 벡터로 변환: 로딩, 청킹, 임베딩, 저장
- La 쿼리 파이프라인 관련 문서 검색 및 사용: 임베딩, 검색, 어셈블리, 생성
- Il 청킹 이는 가장 중요한 결정 중 하나입니다. 검색 품질에 직접적인 영향을 미칩니다.
- 그만큼 임베딩 숫자 벡터로 텍스트의 의미론적 의미를 포착합니다.
- I 벡터 저장소 수백만 개의 문서에 대한 유사성 검색이 가능합니다.
- 고급 RAG Naive RAG의 한계를 극복하기 위해 reranking, HyDE, multi-hop과 같은 기술을 도입합니다.
- RAG는 필요할 때 이상적입니다. 업데이트되고 검증 가능하며 인용 가능한 답변
다음 글: 임베딩 및 의미 검색
시리즈의 다음 기사에서는 RAG의 가장 매력적인 구성 요소에 대해 더 자세히 살펴보겠습니다. 그 사람 임베딩. 내부적으로 어떻게 작동하는지, 어떻게 선택하는지 살펴보겠습니다. 올바른 모델, 품질을 평가하는 방법 및 의미 검색을 최적화하는 방법. 또한 측정을 위한 평가 지표와 벤치마킹 기법도 살펴보겠습니다. 검색 시스템의 성능.
AI 엔지니어링 시리즈 및 고급 RAG
| Articolo | 주제 |
|---|---|
| 01 - 당신은 여기에 있습니다 | RAG: 검색 증강 생성 설명 |
| 02 - 다음 | 임베딩 및 깊이 의미 검색 |
| 03 | 벡터 데이터베이스: 아키텍처 및 모범 사례 |
| 04 | LangChain과 Python을 사용하여 RAG 시스템 구축 |
| 05 | 하이브리드 검색: 키워드 + 의미 + 재순위 |
| 06 | RAG를 위한 컨텍스트 창 및 프롬프트 엔지니어링 |
| 07 | 생산 중인 RAG: 모니터링, 평가, 확장 |
| 08 | 지식 그래프 및 구조화된 검색 |
| 09 | 다중 에이전트 시스템 및 오케스트레이션된 RAG |
| 10 | RAG의 미래: 동향 및 연구 |