RAG란 무엇이며 모든 개발자가 이를 알아야 하는 이유
I 대형 언어 모델(LLM) 그들은 우리가 상호작용하는 방식에 혁명을 일으켰습니다. 정보를 제공하지만 그들은 근본적인 문제를 안고 있습니다. 공전, 훈련 중에 얼어 붙었습니다. LLM에게 문서에 관해 문의할 때 내부적으로 귀하의 제품이나 업데이트된 데이터에 대한 대답은 일반적이거나 발명되었거나 단순히 틀렸어. 이 현상을 환각.
검색 증강 생성(RAG) 전력을 결합하여 이 문제를 해결합니다. 정보 검색 시스템의 정확성을 갖춘 LLM 생성. 의지하는 대신 RAG는 모델 메모리에서만 먼저 지식 기반에서 관련 문서를 검색합니다. 모델이 정확한 데이터 기반 답변을 생성할 수 있는 컨텍스트를 제공합니다.
이 시리즈의 첫 번째 기사에서는 웹 개발자를 위한 AI, RAG를 살펴보겠습니다. 심층적으로: 그것이 무엇인지, 어떻게 작동하는지, 언제 사용하고 언제 피해야 하는지. 결국 당신은 하나를 갖게 될 것입니다 RAG 아키텍처에 대한 확실한 이해가 있으면 다음 기사에서 이를 구현할 준비가 됩니다.
시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 현재 위치 - RAG란? | 기초와 건축 |
| 2 | TypeScript 및 LangChain.js를 사용한 RAG | 실제 구현 |
| 3 | 웹 개발을 위한 벡터 데이터베이스 | 저장 및 유사성 검색 |
| 4 | OpenAI 및 Anthropic API | LLM 통합 |
| 5 | Ollama와 함께하는 LLM 로컬 | 온프레미스 모델 |
| 6 | 미세 조정과 RAG | 언제 무엇을 사용할 것인가 |
| 7 | AI 에이전트: 아키텍처 | 자율 시스템 |
| 8 | CI/CD 파이프라인의 AI | DevOps 자동화 |
무엇을 배울 것인가
- RAG 란 무엇이며 어떤 문제를 해결합니까?
- RAG(검색 + 생성) 시스템의 전체 아키텍처
- 임베딩 및 유사성 검색 작동 방식
- 문서 준비를 위한 청킹 전략
- RAG와 미세 조정의 차이점
- 실제 사용 사례: 챗봇, 의미 검색, Q&A
- RAG의 제한 사항 및 사용하지 말아야 할 경우
1. 문제: LLM과 정적 지식
회사의 고객 지원을 위한 챗봇을 구축하고 싶다고 상상해 보세요. 당신은 수천 개의 문서 페이지, FAQ, 기술 매뉴얼 및 해결된 티켓. GPT-4 또는 Claude와 같은 LLM을 사용합니다. 그러나 결과는 실망스럽습니다. 모델은 귀하의 제품을 모르고 존재하지 않는 기능을 발명합니다. 그리고 절대적인 확실성을 가지고 잘못된 절차를 제공합니다.
LLM의 세 가지 근본적인 문제
| 문제 | 설명 | 영향 |
|---|---|---|
| 지식 차단 | 모델은 훈련 데이터만 알고 있습니다. | 귀하의 독점 데이터에 대해서는 아무것도 모릅니다. |
| 환각 | 그럴듯하지만 잘못된 답변 생성 | 잘못된 정보로 높은 신뢰도 |
| 인용 없음 | 그는 정보의 출처를 밝힐 수 없습니다 | 정확성을 확인할 수 없습니다 |
이러한 문제는 단순히 더 나은 프롬프트로 해결되지 않습니다. 실제 데이터가 필요합니다. 귀하의 도메인에 맞게 업데이트되었습니다. 이것이 바로 RAG가 하는 일입니다.
2. RAG란?: 검색-증강 생성
조각 이는 두 가지 별개의 단계를 결합한 아키텍처입니다. 검색 지식베이스에서 관련 문서를 검색하는 것은 세대 (세대) 해당 문서를 기반으로 한 답변입니다. 이 용어는 연구원들에 의해 2020년에 도입되었습니다. Meta AI의 "지식 집약적 NLP 작업을 위한 검색 증강 생성" 논문.
아이디어는 간단하지만 강력합니다. 모델에 응답 생성을 요청하기 전에, 사용자의 질문과 가장 관련 있는 문서를 검색하여 프롬프트에 삽입합니다. 추가 컨텍스트로. 모델은 더 이상 모든 것을 "기억"할 필요가 없으며 단지 추론만 하면 됩니다. 제공된 정보에 대해.
LLM TRADIZIONALE:
Domanda utente --> [LLM] --> Risposta (basata solo su training data)
^-- Rischio allucinazione alto
RAG:
Domanda utente --> [Retrieval] --> Documenti rilevanti
|
v
Domanda + Documenti --> [LLM] --> Risposta (basata su dati reali)
^-- Rischio allucinazione basso
실용적인 비유
RAG를 하나로 생각하십시오. 오픈북 시험을 치르는 학생. 전통적인 LLM 그는 마음속으로 대답해야 하는 학생입니다. 그는 많은 것을 알고 있지만 혼란스러워하거나 생각해 낼 수 있습니다. RAG를 사용하면 학생은 답변하기 전에 노트와 책을 참고할 수 있습니다. 구체적인 출처를 바탕으로 답변을 드리기 때문에 답변이 더 정확할 것입니다.
3. RAG 시스템의 전체 아키텍처
RAG 시스템은 두 가지 주요 파이프라인으로 구성됩니다. 인덱싱 파이프라인 (오프라인, 일회성 또는 주기적으로 수행됨) 및 쿼리 파이프라인 (사용자 질문별 실시간으로 실행)
3.1 인덱싱 파이프라인(오프라인)
이 단계에서는 연구용 문서를 준비합니다. 단계는 다음과 같습니다.
[Documenti Sorgente]
|
v
[1. Document Loader] -- Carica PDF, HTML, Markdown, CSV, database
|
v
[2. Text Splitter] --- Divide in chunk di dimensione gestibile
|
v
[3. Embedding Model] - Trasforma ogni chunk in un vettore numerico
|
v
[4. Vector Store] ---- Salva i vettori in un database vettoriale
3.2 쿼리 파이프라인(온라인)
이 단계에서는 사용자 요구를 실시간으로 처리합니다.
[Domanda Utente]
|
v
[1. Embedding Model] --- Stessa funzione usata nell'indicizzazione
|
v
[2. Similarity Search] - Cerca i chunk più simili nel vector store
|
v
[3. Context Assembly] -- Assembla i chunk trovati in un contesto
|
v
[4. Prompt Template] --- "Rispondi alla domanda basandoti su: [contesto]"
|
v
[5. LLM Generation] --- Genera la risposta finale
|
v
[Risposta con Citazioni]
임베딩의 일관성에 주의하세요
사용하는 것이 필수적입니다 동일한 임베딩 모델 둘 다 단계에서 쿼리 단계보다 인덱싱이 더 좋습니다. 다른 모델을 사용하는 경우 벡터는 비교 가능하며 유사성 검색이 올바르게 작동하지 않습니다.
4. 임베딩: RAG의 핵심
그만큼 임베딩 이는 캡처하는 텍스트의 숫자 표현(벡터)입니다. 의미론적 의미. 비슷한 의미를 가진 두 문장은 "near" 벡터를 갖습니다. 완전히 다른 단어를 사용하더라도 다차원 공간입니다.
Frase: "Il gatto dorme sul divano"
Embedding: [0.23, -0.45, 0.67, 0.12, -0.89, ...] // vettore a 1536 dimensioni
Frase: "Il felino riposa sul sofa"
Embedding: [0.22, -0.44, 0.68, 0.11, -0.88, ...] // vettore molto simile!
Frase: "Il prezzo dell'oro sale"
Embedding: [-0.56, 0.78, -0.12, 0.91, 0.34, ...] // vettore molto diverso
인기 있는 임베딩 템플릿
| 모델 | 치수 | 공급자 | 비용 |
|---|---|---|---|
text-embedding-3-small |
1536년 | 오픈AI | $0.02 / 100만 토큰 |
text-embedding-3-large |
3072 | 오픈AI | $0.13 / 100만 토큰 |
voyage-3 |
1024 | 항해 AI | $0.06 / 100만 토큰 |
all-MiniLM-L6-v2 |
384 | 포옹얼굴(무료) | 무료(자체 호스팅) |
nomic-embed-text |
768 | 올라마(현지) | 무료(현지) |
La 코사인 유사성 에 대한 가장 일반적인 측정항목입니다. 임베딩을 비교합니다. 두 벡터 사이의 각도를 측정합니다. 값 1.0은 벡터를 나타냅니다. 동일함, 0.0은 관계가 없음을 나타내고, -1.0은 반대 의미를 나타냅니다.
function cosineSimilarity(a: number[], b: number[]): number {
if (a.length !== b.length) {
throw new Error('I vettori devono avere la stessa lunghezza');
}
let dotProduct = 0;
let normA = 0;
let normB = 0;
for (let i = 0; i < a.length; i++) {
dotProduct += a[i] * b[i];
normA += a[i] * a[i];
normB += b[i] * b[i];
}
return dotProduct / (Math.sqrt(normA) * Math.sqrt(normB));
}
// Esempio d'uso
const embedding1 = [0.23, -0.45, 0.67, 0.12];
const embedding2 = [0.22, -0.44, 0.68, 0.11];
const similarity = cosineSimilarity(embedding1, embedding2);
console.log(similarity); // ~0.999 - molto simili!
5. 청킹 전략
Il 청킹 문서를 조각으로 나누는 과정입니다. (덩어리) 관리 가능한 크기입니다. 이 단계는 매우 중요합니다. 너무 큰 덩어리는 분산됩니다. 즉, 너무 작은 청크는 컨텍스트를 잃습니다.
주요 청킹 매개변수
- 청크 크기: 각 조각의 최대 크기(문자 또는 토큰)입니다. 일반적으로 500~2000자
- 청크 오버랩: 연속된 청크 사이의 겹침(청크 크기의 10-20%) 개념을 중간에 자르지 마세요.
- 구분 기호: 잘라내기를 선호하는 지점(문단, 문장, 제목)
FIXED SIZE CHUNKING:
Testo: "AAAA|BBBB|CCCC|DDDD" (ogni | = taglio ogni N caratteri)
Pro: Semplice e veloce
Contro: Può tagliare a meta frasi e concetti
RECURSIVE CHARACTER SPLITTING:
Testo diviso per: "\n\n" -> "\n" -> "." -> " " -> ""
Pro: Rispetta la struttura del testo
Contro: Chunk di dimensioni variabili
SEMANTIC CHUNKING:
Usa embeddings per trovare i "punti di rottura" semantici
Pro: Chunk coerenti semanticamente
Contro: Più lento e costoso (richiede embeddings)
DOCUMENT-AWARE CHUNKING:
Rispetta la struttura del documento (titoli, sezioni, tabelle)
Pro: Mantiene il contesto strutturale
Contro: Richiede parsing specifico per formato
Documento originale (600 caratteri):
"Angular è un framework TypeScript per applicazioni web.
Supporta il rendering lato server (SSR) per migliorare
le performance. I componenti standalone eliminano la
necessità di NgModule. I Signals offrono reattività
fine-grained senza Zone.js."
Con chunk_size=200, overlap=50:
Chunk 1: "Angular è un framework TypeScript per applicazioni web.
Supporta il rendering lato server (SSR) per migliorare
le performance."
Chunk 2: "per migliorare le performance. I componenti standalone
eliminano la necessità di NgModule."
Chunk 3: "eliminano la necessità di NgModule. I Signals offrono
reattività fine-grained senza Zone.js."
청킹의 일반적인 실수
- 청크가 너무 큼(>4000개 토큰): 모델이 컨텍스트의 일부를 무시하거나 토큰 제한을 초과할 수 있습니다.
- 청크가 너무 작음(토큰 100개 미만): 맥락 상실, 단편적인 답변
- 제로 오버랩: 개념이 절반으로 줄어들고 복구가 완료되지 않음
- 메타데이터 무시: 문서의 제목, 작성자, 날짜 등의 정보 손실
6. RAG 대 미세 조정: 언제 무엇을 사용해야 할까요?
가장 일반적인 질문 중 하나는 "RAG를 사용해야 할까요, 아니면 모델을 미세 조정해야 할까요?"입니다. 대답은 추가하려는 지식의 유형과 사용 방법에 따라 다릅니다.
RAG 대 미세 조정 - 세부 비교
| 나는 기다린다 | 조각 | 미세 조정 |
|---|---|---|
| 지식의 종류 | 특정 사실, 데이터, 문서 | 스타일, 형식, 동작 |
| 업데이트 | 즉시(문서 업데이트) | 재교육 필요 |
| 초기비용 | 낮음(인프라 + 임베딩) | 높음(GPU, 레이블이 지정된 데이터, 시간) |
| 쿼리당 비용 | 중간(검색 + 생성) | 낮음(세대만 해당) |
| 추적성 | 높음(출처 인용 가능) | 없음(통합지식) |
| 환각 | 감소(컨텍스트에 따른 실제 데이터) | 가능(지식 학습) |
| 데이터 확장성 | 수백만 개의 문서 | 훈련 세트에 의해 제한됨 |
| 복잡성 | 미디어(파이프라인 + 벡터 DB) | 높음(교육, 평가, 배포) |
실제 규칙
미국 조각 모델이 특정 정보를 "알도록" 하려는 경우 (문서, FAQ, 매뉴얼). 미국 미세 조정 원하는 모델이 있을 때 특정 방식(어조, 형식, 응답 스타일)으로 "행동"합니다. 많은 경우, 두 가지 접근 방식을 결합하면 최상의 결과를 얻을 수 있습니다.
7. RAG의 실제 사용 사례
RAG는 단순한 이론이 아닙니다. 이는 우리가 매일 사용하는 많은 제품의 기초입니다. 가장 일반적인 사용 사례와 RAG가 이를 지원하는 방법은 다음과 같습니다.
7.1 기업 챗봇
가장 인기 있는 사용 사례입니다. 고객의 질문에 답변하는 챗봇 회사의 실제 문서: 매뉴얼, FAQ, 해결된 티켓, 내부 정책.
// Pseudocodice di un chatbot RAG
async function handleUserQuery(query: string): Promise<string> {
// 1. Cerca documenti rilevanti
const relevantDocs = await vectorStore.similaritySearch(query, 5);
// 2. Costruisci il contesto
const context = relevantDocs
.map(doc => `[Fonte: ${doc.metadata.source}]\n${doc.pageContent}`)
.join('\n\n');
// 3. Genera la risposta con contesto
const response = await llm.invoke(`
Sei un assistente del supporto clienti.
Rispondi SOLO basandoti sulle informazioni fornite.
Se non trovi la risposta nei documenti, dillo esplicitamente.
DOCUMENTI DI RIFERIMENTO:
${context}
DOMANDA DEL CLIENTE:
${query}
RISPOSTA:
`);
return response;
}
7.2 의미 검색
기존의 키워드 기반 검색과 달리 RAG를 사용한 의미 검색 다음을 포함합니다 의미 쿼리의. "비밀번호를 재설정하는 방법" 검색 결과 문서에 "자격 증명 복구 절차"라고 나와 있는데도 말이죠.
7.3 문서에 대한 Q&A
사용자가 대규모 문서 컬렉션에 대해 자연어로 질문할 수 있습니다. 법적 계약, 기술 문서, 과학 논문, 내부 지식 기반.
7.4 코드 어시스턴트
특정 코드베이스를 아는 코드 도우미입니다. 소스 코드를 색인화하고, 상황에 맞는 제안을 제공하기 위한 API 문서, 주석 및 테스트입니다.
사용 사례 비교
| 사용 사례 | 데이터 소스 | 업데이트 빈도 | 복잡성 |
|---|---|---|---|
| 챗봇 지원 | FAQ, 매뉴얼, 티켓 | 주간 | 평균 |
| 의미 검색 | 제품 카탈로그, 기사 | 일일 | 낮은 |
| Q&A 문서 | PDF, 계약서, 보고서 | 주문형 | 평균 |
| 코드 어시스턴트 | 소스 코드, API 문서 | 커밋할 때마다 | 높은 |
8. 완전한 RAG 파이프라인 분석
기술적 선택과 함께 파이프라인의 각 구성요소를 자세히 살펴보겠습니다. 구현 과정에서 직면하게 될 문제입니다.
+------------------+--------------------------------------------+
| Componente | Opzioni Tecnologiche |
+------------------+--------------------------------------------+
| Document Loader | LangChain loaders, Unstructured, custom |
| Text Splitter | RecursiveCharacter, Semantic, Markdown |
| Embedding Model | OpenAI, Voyage, HuggingFace, Ollama |
| Vector Store | Pinecone, Chroma, Weaviate, pgvector |
| Retriever | Similarity, MMR, Self-Query, Ensemble |
| Prompt Template | LangChain templates, custom |
| LLM | GPT-4, Claude, Llama, Mistral |
| Post-processing | Citation extraction, confidence scoring |
+------------------+--------------------------------------------+
8.1 문서 로더
문서 로더는 다양한 소스에서 텍스트를 추출합니다. 추출의 품질 답변의 품질에 직접적인 영향을 미칩니다.
Formato | Loader Consigliato | Note
-----------------+---------------------------+---------------------------
PDF | PDFLoader, PyPDFLoader | Attenzione a tabelle/immagini
HTML/Web | CheerioWebBaseLoader | Rimuove tag, estrae testo
Markdown | MarkdownTextSplitter | Preserva la struttura
CSV/Excel | CSVLoader | Una riga = un documento
JSON | JSONLoader | Configura il percorso dati
Database SQL | Custom loader | Query -> documenti
Confluence/Notion| API-based loader | Richiede autenticazione
Codice sorgente | TextLoader + filtri | Splitta per funzione/classe
8.2 리트리버: 유사성 검색을 넘어서
리트리버는 가장 유사한 덩어리만을 찾는 것이 아닙니다. 고급 전략이 있습니다 회복의 질을 향상시키는 것입니다.
검색 전략
- 유사성 검색: 유사성 점수가 가장 높은 k개의 청크입니다. 간단하지만 효과적이다
- MMR(최대 한계 관련성): 관련성과 다양성의 균형을 유지하세요. 서로 너무 유사한 청크는 피하세요.
- 셀프 쿼리: 모델은 질문에서 필터를 추출합니다(예: 날짜별 "2024 문서" 필터).
- 앙상블: 더 나은 적용 범위를 위해 여러 검색기(예: 키워드 + 의미 체계)의 결과를 결합합니다.
- 상위 문서: 관련 청크를 검색하지만 전체 컨텍스트를 위해 상위 문서를 반환합니다.
9. RAG의 제한 사항 및 사용하지 말아야 할 경우
RAG는 마법의 솔루션이 아닙니다. 다른 아키텍처와 마찬가지로 알아야 할 제한 사항이 있습니다. 채택하기 전에.
RAG가 올바른 선택이 아닌 경우
- 복잡한 추론: RAG는 추론이 아닌 사실을 제공합니다. 다단계 분석이나 복잡한 논리적 추론을 위해서는 모델에 자체 기능이 있어야 합니다.
- 구조화된 데이터: SQL 집계, 계산 또는 테이블 간 조인이 필요한 경우 RAG가 아닌 관계형 데이터베이스를 사용하세요.
- 초고속 실시간 응답: 검색 파이프라인은 지연 시간(100~500ms)을 추가합니다. 50ms 이내에 응답이 필요한 경우 캐싱을 고려하세요.
- 기술 자료가 너무 작음: 적은 수의 문서(10페이지 미만)로 검색할 필요 없이 모든 내용을 프롬프트에 맞출 수 있습니다.
- 매우 역동적인 데이터: 데이터가 매초 변경되면(예: 주식 시장 가격) RAG의 업데이트 속도가 충분히 빠르지 않습니다.
일반적인 문제 및 해결 방법
| 문제 | 원인 | 해결책 |
|---|---|---|
| 관련 없는 답변 | 청킹이 너무 큼 | 청크 크기 감소, 중복 증가 |
| 그는 "모른다"고 너무 자주 대답한다 | 검색이 너무 제한적입니다. | k(결과 수) 증가, MMR 사용 |
| 지속적인 환각 | 불충분하거나 모호한 맥락 | 프롬프트 개선, 명시적인 지침 추가 |
| 높은 대기 시간 | 컨텍스트에 청크가 너무 많습니다. | k를 줄이고 재순위 사용 |
| 높은 비용 | 쿼리당 토큰이 너무 많습니다. | 청크를 압축하고 더 저렴한 모델을 사용하세요. |
10. RAG 평가 지표
RAG 시스템이 제대로 작동하는지 확인하려면 이를 측정해야 합니다. 주요 지표는 다음과 같습니다.
RAG 측정항목
| 미터법 | 측정 대상 | 목표 |
|---|---|---|
| 맥락 관련성 | 검색된 문서가 신청서와 관련이 있나요? | > 0.8 |
| 충실 | 답변은 제공된 문서를 기반으로 합니까? | > 0.9 |
| 답변 관련성 | 답변이 질문과 관련이 있나요? | > 0.85 |
| 숨어 있음 | 응답하는 데 걸린 총 시간 | < 3초 |
| 환각률 | 문서로 뒷받침되지 않는 주장의 비율 | < 5% |
Tool di Valutazione:
- RAGAS (Retrieval Augmented Generation Assessment)
- LangSmith (by LangChain) - tracing e valutazione
- Phoenix (by Arize) - osservabilità LLM
- DeepEval - framework di testing per LLM
- TruLens - valutazione feedback-driven
Metriche Composite:
RAG Score = (Context Relevance + Faithfulness + Answer Relevance) / 3
다음 단계
이 글에서 당신은 RAG가 무엇인지, 어떻게 작동하는지에 대한 확실한 이해를 얻었습니다. 아키텍처의 주요 구성 요소와 이를 사용하는 경우(또는 사용하지 않는 경우) 역할을 이해하셨군요 임베딩, 청킹 전략 및 평가 측정항목의 기본 사항입니다.
에서 다음 기사 우리는 이론에서 실천으로 나아갈 것입니다. 다음을 사용하는 완전한 RAG 시스템 TypeScript 및 LangChain.js, 벡터로 실제 매장과 메모리를 갖춘 대화형 인터페이스입니다.
추가 리소스
- 원본 RAG 용지: “지식 집약적 NLP 작업을 위한 검색 증강 생성”(Lewis et al., 2020)
- LangChain.js 문서: TypeScript 구현을 위한 공식 문서
- OpenAI 요리책: OpenAI API를 사용한 RAG의 실제 예
- 솔방울 학습 센터: 벡터 데이터베이스 및 임베딩에 대한 안내
- 라가스: RAG 시스템 평가를 위한 오픈 소스 프레임워크