그런데 검색 성능을 개선했다고 해서 항상 좋은 답변이 만들어지는 것은 아니다.

관련 문서를 잘 찾았더라도 LLM이 내용을 잘못 해석하거나, 검색된 자료에 없는 내용을 답변에 포함할 수도 있기 때문이다.

그렇다면 RAG가 제대로 동작하고 있는지는 어떻게 확인할 수 있을까?

이번 글에서는 RAG의 성능을 평가하는 방법인 RAG Evaluation에 대해 알아보려고 한다.

1. RAG Evaluation이란?

RAG Evaluation(평가)은 RAG 시스템이 사용자의 질문에 대해 얼마나 적절한 정보를 검색하고, 그 정보를 바탕으로 얼마나 좋은 답변을 생성하는지 평가하는 과정이다.

RAG는 크게 두 단계로 나눌 수 있다.

• Retrieval(검색) : 질문과 관련된 문서를 잘 찾았는가?
• Generation(생성) : 검색한 문서를 바탕으로 적절한 답변을 만들었는가?

따라서 RAG를 평가할 때도 검색 품질과 답변 품질을 구분해서 살펴보는 것이 중요하다.

사용자 질문
    ↓
Retrieval ── 검색 품질 평가
    ↓
Context
    ↓
LLM
    ↓
최종 답변 ── 답변 품질 평가

2. Faithfulness란?

Faithfulness(충실도)는 LLM이 생성한 답변이 검색된 Context에 얼마나 충실한지 평가하는 지표다.

쉽게 말하면,

"LLM이 참고 자료에 없는 내용을 마음대로 만들어내지는 않았을까?"

를 확인하는 것이다.

예를 들어 검색된 문서에 다음과 같은 내용이 있다고 해보자.

검색된 Context

미사용 연차는 최대 5일까지 다음 연도로 이월할 수 있다.

그런데 LLM이 다음과 같이 답변했다면?

LLM 답변

미사용 연차는 최대 5일까지 다음 연도로 이월할 수 있으며, 별도의 승인 절차는 필요하지 않습니다.

여기서 '별도의 승인 절차는 필요하지 않습니다'라는 내용은 검색된 문서에 존재하지 않는다.

즉, LLM이 근거 없는 내용을 추가한 것이다.

이러한 경우 Faithfulness가 낮아질 수 있다.

반대로 검색된 자료에서 확인할 수 있는 내용만으로 답변했다면 Faithfulness가 높게 평가될 수 있다.

다만 Faithfulness는 답변이 참고 자료에 근거하고 있는지를 평가하는 것이지, 참고 자료 자체가 사실인지까지 보장하는 것은 아니다.

3. Context Precision이란?

Context Precision(검색 문맥 정밀도)은 검색된 문서 중 질문과 관련 있는 문서가 얼마나 상위에 잘 배치되어 있는지 평가하는 지표다.

예를 들어 사용자가 다음과 같이 질문했다고 해보자.

"남은 연차를 내년으로 넘길 수 있어?"

검색 결과가 다음과 같다면?

질문과 관련 있는 문서들이 상위에 배치되어 있다.

반대로 관련 없는 문서가 상위에 많이 등장한다면 Context Precision이 낮아질 수 있다.

즉,

"검색된 결과에서 관련 있는 정보가 얼마나 앞쪽에 잘 배치되어 있을까?"

를 평가하는 지표다.

Context Precision은 단순히 관련 문서의 개수뿐 아니라 검색 결과의 순서도 중요하게 본다.

4. Context Recall이란?

Context Recall(검색 문맥 재현율)은 답변에 필요한 정보를 검색 단계에서 얼마나 빠짐없이 가져왔는지 평가하는 지표다.

예를 들어 회사의 연차 이월 규정이 다음과 같다고 해보자.

실제 규정

미사용 연차는 최대 5일까지 다음 연도로 이월할 수 있으며, 이월 신청은 연말까지 완료해야 한다.

그런데 검색된 Context에는 다음 내용만 포함되어 있다.

미사용 연차는 최대 5일까지 다음 연도로 이월할 수 있다.

연차를 이월할 수 있다는 내용은 찾았지만, 연말까지 신청해야 한다는 조건은 검색하지 못했다.

이처럼 답변에 필요한 정보가 일부 누락되면 Context Recall이 낮아질 수 있다.

쉽게 말하면,

"답변에 필요한 정보를 빠뜨리지 않고 잘 찾아왔을까?"

를 확인하는 것이다.

Context Precision과 Context Recall은 비슷해 보이지만 차이가 있다.

• Precision : 검색한 결과가 얼마나 적절한가?
• Recall : 필요한 정보를 얼마나 빠짐없이 찾았는가?

5. Answer Relevancy란?

Answer Relevancy(답변 관련성)는 LLM이 생성한 답변이 사용자의 질문에 얼마나 적절하게 대응하는지 평가하는 지표다.

예를 들어 사용자가 다음과 같이 질문했다고 해보자.

"남은 연차를 내년으로 넘길 수 있어?"

그런데 LLM이 다음과 같이 답변했다면?

연차는 근로자가 휴식을 취하기 위해 사용하는 유급휴가입니다. 연차는 근속기간과 근무 조건에 따라 발생할 수 있습니다.

틀린 설명은 아닐 수 있지만, 사용자가 궁금해하는 연차 이월 가능 여부에 대한 답변은 아니다.

따라서 Answer Relevancy가 낮게 평가될 수 있다.

반대로,

네. 미사용 연차는 최대 5일까지 다음 연도로 이월할 수 있습니다.

처럼 질문에 직접적으로 답한다면 Answer Relevancy가 높게 평가될 수 있다.

6. RAG 평가 지표 한눈에 보기

지금까지 살펴본 네 가지 지표를 정리하면 다음과 같다.

이러한 지표들은 RAG 평가 프레임워크인 RAGAS 등에서 활용된다.

RAGAS는 검색 결과와 생성된 답변을 다양한 기준으로 평가할 수 있도록 지원하는 프레임워크다.

평가 지표에 따라 정답 데이터나 LLM 기반 평가가 필요할 수 있으며, 실제 평가 방식은 사용하는 프레임워크와 설정에 따라 달라진다.

7. 평가 결과는 어떻게 활용할까?

RAG Evaluation은 단순히 점수를 확인하는 데서 끝나지 않는다.

어느 단계에서 문제가 발생했는지 파악하고 개선하는 것이 더 중요하다.

예를 들어,

물론 하나의 지표가 낮다고 해서 반드시 특정 단계에만 문제가 있는 것은 아니다.

하지만 평가 결과를 분석하면 검색 과정과 답변 생성 과정 중 어디를 우선적으로 개선해야 할지 판단하는 데 도움이 된다.

정리

RAG는 관련 문서를 검색하고 LLM이 답변을 생성하는 구조지만, 단순히 답변이 만들어졌다는 이유만으로 잘 동작한다고 판단할 수는 없다.

관련 정보를 정확하게 찾았는지, 필요한 정보가 누락되지는 않았는지, 답변이 검색된 자료에 근거하고 있는지 등을 함께 확인해야 한다.

이번 글에서 살펴본 핵심 용어를 정리하면 다음과 같다.

• Faithfulness (충실도) LLM이 생성한 답변이 검색된 자료에 근거하고 있는지 평가하는 지표

• Context Precision (검색 문맥 정밀도) 질문과 관련된 문서가 검색 결과 상위에 잘 배치되어 있는지 평가하는 지표

• Context Recall (검색 문맥 재현율) 답변에 필요한 정보를 검색 과정에서 얼마나 빠짐없이 가져왔는지 평가하는 지표

• Answer Relevancy (답변 관련성) 생성된 답변이 사용자의 질문에 얼마나 적절하게 대응하는지 평가하는 지표

• RAGAS RAG의 검색 품질과 답변 품질을 다양한 지표로 평가할 수 있도록 지원하는 프레임워크

결국 RAG Evaluation의 핵심은 검색 품질과 답변 품질을 각각 평가하고, 문제가 발생한 부분을 찾아 개선하는 것이다.

다음 글에서는 RAG를 실제 서비스에 적용할 때 발생할 수 있는 문제점과 한계, 그리고 개선 방법에 대해 알아보려고 한다.

그런데 여기서 한 가지 궁금한 점이 생긴다.

의미가 비슷한 문서를 검색한다고 해서 항상 정확한 정보를 찾을 수 있을까?

정답은 아니다.

실제로 RAG에서는 질문과 관련 없는 문서가 검색되거나, 정작 필요한 문서가 검색 결과에서 누락될 수도 있다.

이러한 문제를 개선하기 위해 사용하는 대표적인 방법이 Hybrid Search와 Reranking이다.

1. Vector Search의 한계

앞서 살펴본 Vector Search는 텍스트를 Embedding하여 의미적으로 비슷한 문서를 찾는 검색 방식이다.

예를 들어 사용자가 다음과 같이 질문했다고 해보자.

"남은 연차를 내년으로 넘길 수 있어?"

Vector Search는 다음과 같은 관련 문서를 찾아낼 수 있다.

사용자 질문
"남은 연차를 내년으로 넘길 수 있어?"

        ↓

     Vector Search

        ↓

"미사용 연차 이월 규정"

질문과 문서에 사용된 단어가 완전히 같지 않더라도 의미가 비슷하기 때문에 검색할 수 있다.

하지만 Vector Search에도 한계가 있다.

예를 들어 다음과 같은 질문이라면 어떨까?

"HR-2026-015 규정에 대해 알려줘."

HR-2026-015는 특정 문서를 구분하는 고유한 코드다.

이처럼 문서 번호, 상품 코드, 정확한 명칭 등이 중요한 경우에는 의미 중심의 Vector Search만으로 원하는 결과를 찾지 못할 수 있다.

이때 활용할 수 있는 것이 Keyword Search다.

2. Keyword Search란?

Keyword Search(키워드 검색)는 사용자의 질문에 포함된 단어나 문자열을 기반으로 관련 문서를 찾는 방식이다.

예를 들어,

사용자 질문
"HR-2026-015 규정에 대해 알려줘."

        ↓

     Keyword Search

        ↓

"HR-2026-015 휴가 및 연차 관리 규정"

특정 코드나 명칭이 포함된 문서를 검색할 때 유용하다.

대표적인 키워드 기반 검색 알고리즘으로는 BM25가 있다.

BM25는 단어가 문서에 등장하는 빈도와 해당 단어의 희소성, 문서 길이 등을 고려하여 검색 결과의 관련성을 계산한다.

그렇다면 Keyword Search만 사용하면 될까?

그것도 아니다.

Keyword Search는 검색어와 문서의 표현이 다르면 관련 문서를 놓칠 수 있다.

예를 들어 "남은 휴가를 다음 해에 쓸 수 있나요?"라는 질문과 "미사용 연차 이월 규정"이라는 문서는 의미가 비슷하지만 사용하는 단어가 다르다.

이런 경우에는 Vector Search가 더 유리할 수 있다.

3. Hybrid Search란?

Hybrid Search(하이브리드 검색)는 서로 다른 검색 방식을 결합하여 검색 결과를 개선하는 방법이다.

RAG에서는 주로 Keyword Search와 Vector Search를 결합한다.

              사용자 질문
                  |
          ┌───────┴───────┐
          ↓               ↓
    Keyword Search    Vector Search
          |               |
          ↓               ↓
    키워드 기반 검색    의미 기반 검색
          |               |
          └───────┬───────┘
                  ↓
             검색 결과 통합
                  ↓
              관련 문서

각 검색 방식의 장점을 함께 활용하는 것이다.

Hybrid Search에서는 두 검색 결과를 합치는 방법도 중요하다.

대표적인 방법으로 RRF(Reciprocal Rank Fusion)가 있다.

RRF는 서로 다른 검색 결과의 순위를 활용하여 하나의 통합 순위를 만드는 방식이다.

즉, Keyword Search와 Vector Search가 각각 찾아온 문서를 종합하여 더 적절한 검색 결과를 얻도록 돕는다.

4. Reranking이란?

Hybrid Search로 관련 문서를 검색했다고 해서 모든 과정이 끝나는 것은 아니다.

검색된 문서 중에는 질문과 관련성이 높은 문서도 있고, 상대적으로 낮은 문서도 있다.

이때 사용하는 것이 Reranking(재순위화)이다.

Reranking은 1차 검색으로 가져온 문서들의 관련성을 다시 평가하고 순서를 조정하는 과정이다.

예를 들어 사용자가 다음과 같이 질문했다고 해보자.

"미사용 연차는 다음 연도로 얼마나 이월할 수 있어?"

1차 검색 결과가 다음과 같다고 가정해보자.

질문에 가장 적합한 문서는 3번째 문서지만, 검색 결과에서는 3위에 위치하고 있다.

Reranking을 적용하면 문서와 질문의 관련성을 다시 평가하여 순서를 조정할 수 있다.

[1차 검색 결과]

1. 연차 사용 신청 절차
2. 휴가 및 연차 지급 기준
3. 미사용 연차 이월 규정

          ↓

       Reranking

          ↓

[재정렬된 결과]

1. 미사용 연차 이월 규정
2. 휴가 및 연차 지급 기준
3. 연차 사용 신청 절차

물론 Reranking을 적용한다고 항상 올바른 순서로 정렬되는 것은 아니다.

하지만 검색된 문서 중 질문에 더 적합한 문서를 상위에 배치하도록 개선할 수 있다.

5. Hybrid Search와 Reranking의 차이

두 기술은 모두 검색 품질을 개선하기 위해 사용하지만 역할이 다르다.

Hybrid Search는 여러 검색 방식을 결합하여 관련 문서를 더 잘 찾아내는 데 집중한다.

반면 Reranking은 이미 검색된 문서의 관련성을 다시 평가하여 순서를 개선한다.

전체 흐름을 보면 다음과 같다.

사용자 질문
    ↓
Hybrid Search
    ├─ Keyword Search
    └─ Vector Search
    ↓
검색 결과 통합
    ↓
Reranking
    ↓
관련성이 높은 문서 선택
    ↓
Context 구성
    ↓
LLM
    ↓
최종 답변

여기서 중요한 점은 Hybrid Search와 Reranking이 반드시 함께 사용되어야 하는 것은 아니라는 것이다.

서비스의 요구사항이나 데이터 특성에 따라 하나만 사용하거나 둘 다 사용하지 않을 수도 있다.

또한 Reranking은 검색 결과를 재정렬하는 기술이므로, 1차 검색에서 필요한 문서를 아예 찾지 못했다면 그 문서를 새롭게 찾아내지는 못한다.

정리

이번 글에서 살펴본 개념을 정리하면 다음과 같다.

Keyword Search
단어나 키워드를 기반으로 관련 문서를 검색하는 방식

Vector Search
Embedding을 활용하여 의미적으로 비슷한 문서를 검색하는 방식

Hybrid Search
여러 검색 방식을 결합하여 검색 결과를 개선하는 방법

Reranking
검색된 문서의 관련성을 다시 평가하여 순서를 재정렬하는 과정

결국 두 기술의 핵심적인 차이는 다음과 같다.

Hybrid Search는 더 잘 찾기 위한 방법이고, Reranking은 찾은 결과를 더 잘 정렬하기 위한 방법이다.

RAG에서는 단순히 많은 문서를 검색하는 것보다 사용자의 질문에 적합한 정보를 정확하게 찾아서 LLM에게 전달하는 것이 중요하다.

다음 글에서는 RAG가 실제로 얼마나 정확하게 동작하는지 확인하기 위한 RAG 평가(Evaluation)에 대해 알아보려고 한다.

문서를 작은 단위로 나누고, 각 Chunk를 벡터로 변환하여 Vector DB에 저장하는 과정까지 살펴봤다.

그렇다면 이제 사용자가 실제로 질문을 입력하면 어떻게 될까?

이번 글에서는 사용자의 질문이 들어온 순간부터 LLM이 최종 답변을 생성하기까지의 과정을 정리해보려고 한다.

전체 흐름 먼저 보기

사용자가 질문하면 RAG에서는 대략 다음과 같은 과정을 거친다.

사용자 질문
    ↓
질문 Embedding
    ↓
Vector DB 검색
    ↓
관련 Chunk 검색 (Retrieval)
    ↓
검색 결과 + 사용자 질문
    ↓
LLM
    ↓
최종 답변

지난 글에서 문서를 Vector DB에 저장해두었던 이유가 바로 여기서 나온다.

사용자의 질문과 의미적으로 비슷한 문서를 빠르게 찾기 위해서다.

1. 사용자 질문도 Embedding한다

사용자가 다음과 같이 질문했다고 해보자.

*"남은 연차를 내년에 사용할 수 있어?"*

Vector DB에 저장되어 있는 문서들은 이미 Embedding을 통해 벡터로 변환되어 있다.

따라서 질문과 문서를 비교하려면 사용자의 질문 역시 같은 방식으로 벡터로 변환해야 한다.

"남은 연차를 내년에 사용할 수 있어?"

↓

Embedding

↓

[-0.11, 0.62, 0.33, ...]

이제 질문과 문서가 모두 벡터로 표현되었기 때문에 서로 얼마나 비슷한지 비교할 수 있다.

2. 비슷한 문서를 찾는다

질문의 벡터가 만들어지면 Vector DB에서 질문과 가까운 벡터를 가진 Chunk를 찾는다.

예를 들어 Vector DB에 다음과 같은 내용들이 저장되어 있다고 해보자.

Chunk 1
"미사용 연차는 최대 5일까지 다음 연도로 이월할 수 있다."

Chunk 2
"연차 사용 신청은 최소 3일 전에 제출한다."

Chunk 3
"출장비는 출장 종료 후 7일 이내에 정산한다."

질문은 남은 연차의 이월에 관한 내용이다.

따라서 의미적으로 가장 비슷한 Chunk 1이 높은 유사도를 가지게 된다.

이처럼 질문과 의미적으로 비슷한 데이터를 찾는 것을 Similarity Search(유사도 검색)라고 한다.

3. Retrieval

이렇게 검색을 통해 질문과 관련된 정보를 가져오는 과정을 Retrieval이라고 한다.

RAG에서 R이 바로 이 Retrieval이다.

사용자 질문

"남은 연차를 내년에 사용할 수 있어?"

↓

Vector DB 검색

↓

관련 Chunk 발견

"미사용 연차는 최대 5일까지
다음 연도로 이월할 수 있다."

즉, LLM에게 질문을 보내기 전에 답변에 필요한 근거 자료를 먼저 찾아오는 과정이다.

4. Top-K란?

실제로 검색할 때는 관련 문서를 하나만 가져오는 것보다 유사도가 높은 여러 개의 Chunk를 가져오는 경우가 많다.

이때 자주 등장하는 것이 Top-K다.

예를 들어 Top-K = 3으로 설정했다면,

질문과 가장 유사한 Chunk 상위 3개를 가져온다.

라는 의미다.

검색 결과 (Top-K = 3)

1. 미사용 연차 이월 규정       유사도 0.82
2. 연차 사용 절차             유사도 0.71
3. 연차 지급 기준             유사도 0.68

여기서 K는 가져올 검색 결과의 개수를 의미한다.

무조건 많이 가져온다고 좋은 것은 아니다.

관련 없는 정보까지 너무 많이 전달하면 오히려 LLM의 답변 품질에 영향을 줄 수 있기 때문에 필요한 만큼의 관련 정보를 가져오는 것이 중요하다.

5. 검색한 정보를 LLM에게 전달한다

관련 Chunk를 찾았다고 끝나는 것은 아니다.

이제 검색한 내용을 사용자의 질문과 함께 LLM에게 전달해야 한다.

예를 들어 실제로는 프롬프트가 다음과 비슷한 형태로 구성될 수 있다.

[참고 자료]

미사용 연차는 최대 5일까지
다음 연도로 이월할 수 있다.

[사용자 질문]

남은 연차를 내년에 사용할 수 있어?

[지시]

참고 자료를 바탕으로 사용자의 질문에 답변하세요.

이처럼 LLM에게 전달되는 참고 정보를 보통 Context(컨텍스트)라고 한다.

LLM은 이제 자신이 학습한 지식에만 의존하는 것이 아니라 검색된 Context를 참고하여 답변을 생성할 수 있다.

6. LLM이 최종 답변을 생성한다

마지막으로 LLM이 전달받은 질문과 Context를 바탕으로 답변을 생성한다.

검색된 Context

"미사용 연차는 최대 5일까지
다음 연도로 이월할 수 있다."

+

사용자 질문

"남은 연차를 내년에 사용할 수 있어?"

↓

LLM

↓

"미사용 연차는 최대 5일까지
다음 연도로 이월할 수 있습니다."

이제 RAG의 전체 흐름이 연결된다.

LLM이 회사의 연차 규정을 원래 알고 있었던 것이 아니다.

RAG가 관련 문서를 찾아서 LLM에게 전달했고, LLM은 그 정보를 바탕으로 답변을 생성한 것이다.

전체 과정 다시 보기

지금까지의 과정을 한 번에 정리하면 다음과 같다.

① 사용자 질문

"남은 연차를 내년에 사용할 수 있어?"

        ↓

② 질문 Embedding

텍스트 → Vector

        ↓

③ Similarity Search

Vector DB에서
질문과 비슷한 Chunk 검색

        ↓

④ Retrieval

관련 Chunk 가져오기

        ↓

⑤ Context 구성

검색 결과 + 사용자 질문

        ↓

⑥ LLM

Context를 참고하여 답변 생성

        ↓

⑦ 최종 답변

결국 RAG에서 사용자의 질문이 들어온 이후의 핵심은

질문을 벡터로 바꾸고 → 비슷한 자료를 찾고 → LLM에게 전달하고 → 답변하게 한다.

라고 정리할 수 있다.

정리

이번 글에서 등장한 용어들을 다시 정리하면 다음과 같다.

Similarity Search
질문과 의미적으로 비슷한 데이터를 찾는 과정

Retrieval
검색을 통해 질문과 관련된 정보를 가져오는 과정

Top-K
검색 결과 중 유사도가 높은 상위 K개의 데이터를 가져오는 설정

Context
LLM이 답변을 생성할 때 참고하도록 함께 전달하는 정보

앞선 글에서 살펴본 Chunking → Embedding → Vector DB가 데이터를 검색할 수 있도록 준비하는 과정이었다면,

이번 글에서 살펴본 Embedding → Retrieval → Context → LLM은 실제 사용자의 질문을 처리하는 과정이라고 볼 수 있다.

여기까지 이해하면 기본적인 RAG의 전체 흐름은 거의 완성된다.

하지만 실제 RAG에서는 단순히 Vector DB에서 비슷한 문서를 가져오는 것만으로 항상 좋은 결과가 나오지는 않는다.

검색 결과의 정확도를 높이기 위해 Hybrid Search, Reranking 같은 방법도 함께 사용된다.

다음 글에서는 이러한 RAG의 검색 품질을 높이는 방법에 대해 정리해보려고 한다.

RAG의 핵심은 사용자의 질문과 관련된 정보를 찾아서 LLM에게 전달하는 것이다.

그런데 여기서 궁금한 점이 생긴다.

수많은 문서 중에서 사용자의 질문과 관련된 내용을 어떻게 찾아낼까?

이를 이해하려면 RAG에서 자주 등장하는 Chunking, Embedding, Vector DB를 알아야 한다.

전체 흐름 먼저 보기

문서를 RAG에서 활용하려면 보통 다음과 같은 과정을 거친다.

문서
 ↓
Chunking
 ↓
Embedding
 ↓
Vector DB 저장

예를 들어 회사의 여러 규정이 담긴 문서가 있다고 해보자.

문서 전체를 그대로 저장하고 검색하는 것이 아니라,

문서를 작은 단위로 나누고 → 각 내용을 숫자로 변환하고 → 검색할 수 있도록 저장한다.

하나씩 살펴보자 .. !

Chunking이란?

Chunking(청킹)은 긴 문서를 작은 단위(Chunk)로 나누는 과정이다.

예를 들어 하나의 사내 규정 문서에 다음과 같은 내용이 있다고 해보자.

사내 규정.pdf

- 근무시간 규정
- 휴가 및 연차 규정
- 복지제도
- 출장 규정
- 경비 처리 규정
...

이 문서를 하나의 거대한 데이터로 사용하는 것이 아니라 일정한 크기의 조각으로 나눈다.

Chunk 1 → 근무시간 관련 내용

Chunk 2 → 휴가 및 연차 관련 내용

Chunk 3 → 복지제도 관련 내용

Chunk 4 → 출장 관련 내용

왜 굳이 나눌까?

사용자가

"남은 연차를 내년으로 넘길 수 있어?"

라고 질문했는데 수십, 수백 페이지의 문서 전체를 가져올 필요는 없다.

질문과 관련 있는 연차 규정 부분만 찾아오면 된다.

즉, Chunking은 문서를 검색하고 활용하기 좋은 크기로 나누는 과정이라고 볼 수 있다.

Embedding이란?

문서를 나눴다면 이제 각각의 Chunk를 검색할 수 있는 형태로 만들어야 한다.

이때 등장하는 것이 Embedding(임베딩)이다.

Embedding은 텍스트의 의미를 컴퓨터가 비교할 수 있도록 숫자로 이루어진 벡터(Vector)로 변환하는 과정이다.

예를 들어 실제 값은 아니지만,

"미사용 연차 이월 규정"

↓

Embedding

↓

[0.21, -0.53, 0.87, 0.14, ...]

와 같은 형태로 변환된다.

그런데 굳이 왜 이렇게 숫자로 바꾸는 걸까?

우리가 검색하고 싶은 것은 단순히 같은 단어가 들어간 문장이 아니라 의미가 비슷한 문장이기 때문이다.

예를 들어,

"남은 연차를 내년에 사용할 수 있나요?"

와

"미사용 연차 이월 규정"

은 사용된 단어가 완전히 같지는 않다.

하지만 사람이 읽으면 두 문장이 비슷한 내용을 의미한다는 것을 쉽게 알 수 있다.

Embedding을 사용하면 이러한 텍스트의 의미적 유사성을 벡터를 통해 비교할 수 있다.

Vector DB란?

Embedding을 통해 만들어진 벡터는 어딘가에 저장해야 한다.

이때 사용하는 것이 Vector Database(Vector DB)다.

전체 과정을 다시 보면,

문서
 ↓
Chunking
 ↓
각 Chunk를 Embedding
 ↓
Vector DB에 저장

Vector DB에는 문서의 Chunk와 해당 Chunk를 표현하는 벡터가 저장된다.

그리고 사용자의 질문이 들어오면 질문 역시 Embedding을 통해 벡터로 변환한다.

"남은 연차를 내년에 사용할 수 있어?"

↓

Embedding

↓

질문의 Vector

그다음 Vector DB에서 질문의 벡터와 가까운 벡터를 가진 문서 Chunk를 찾는다.

쉽게 말하면,

"이 질문과 의미가 가장 비슷한 내용이 어디 있지?"

를 찾는 것이다.

어떻게 관련 문서를 찾는 걸까?

전체 과정을 연결해보면 조금 더 이해하기 쉽다.

[미리 준비]

사내 규정 문서
      ↓
   Chunking
      ↓
   Embedding
      ↓
   Vector DB


[사용자 질문]

"남은 연차를 내년에 사용할 수 있어?"
      ↓
   Embedding
      ↓
질문과 비슷한 Vector 검색
      ↓
"미사용 연차 이월 규정" 발견

이렇게 질문과 의미가 비슷한 문서를 찾는 것을 유사도 검색(Similarity Search)이라고 한다.

결국 RAG는 이 과정을 통해 사용자의 질문과 관련된 정보를 찾아낸다.

찾아낸 정보는 이후 LLM에게 질문과 함께 전달되고, LLM은 해당 내용을 참고하여 최종 답변을 생성한다.

정리

지금까지의 내용을 간단하게 정리하면 다음과 같다.

Chunking
긴 문서를 검색하기 좋은 작은 단위로 나누는 과정

Embedding
텍스트의 의미를 숫자로 이루어진 Vector로 변환하는 과정

Vector DB
만들어진 Vector를 저장하고, 비슷한 Vector를 검색할 수 있는 데이터베이스

그리고 이 과정을 연결하면,

문서를 나누고 → 의미를 숫자로 바꾸고 → 저장하고 → 비슷한 내용을 찾는다.

라는 흐름이 된다.

여기까지 이해하면 RAG에서 관련 문서를 어떻게 찾아오는지에 대한 기본적인 구조를 이해할 수 있다.

다음 글에서는 이렇게 찾아온 정보를 실제로 어떻게 LLM에게 전달하는지, Retrieval부터 최종 답변 생성까지의 RAG 동작 과정을 조금 더 자세히 살펴보려고 한다.

처음에는 단순히 *"AI가 검색해서 답하는 건가?"* 정도로 생각했는데, 전체적인 구조를 알고 나니 생각보다 어렵지 않은 개념이었다.

이번 글에서는 우선 RAG가 무엇이고, 왜 필요한지부터 간단하게 정리해보려고 한다.

RAG란?

RAG(Retrieval-Augmented Generation), 검색 증강 생성이라고 한다.

단어를 나눠보면 조금 더 이해하기 쉽다.

• Retrieval : 필요한 정보를 검색
• Augmented : 검색한 정보로 보강
• Generation : LLM이 답변 생성

LLM이 자신이 학습한 지식만으로 답하는 것이 아니라, 외부에서 필요한 정보를 먼저 찾아본 뒤 그 정보를 참고해서 답변을 생성하는 방식

쉽게 생각하면 LLM에게 오픈북 시험을 보게 하는 것과 비슷하다.

기억에만 의존해서 답하는 것이 아니라, 필요한 자료를 찾아본 다음 그 내용을 참고해서 답하는 것이다.

RAG는 왜 필요할까?

ChatGPT 같은 LLM은 이미 많은 데이터를 학습하고 있다.
하지만 그렇다고 해서 모든 정보를 알고 있는 것은 아니다.

특히 회사 내부 문서나 사내 규정, 최근 변경된 정보처럼 LLM이 학습하지 못한 데이터는 정확하게 답하기 어렵다.

예를 들어 회사에서 사용하는 AI에게 다음과 같이 질문했다고 해보자.

*"우리 회사 연차는 최대 며칠까지 이월할 수 있어?"*

해당 내용이 회사 내부 규정에만 존재한다면 LLM은 정확한 답을 알 수 없다.

이때 RAG를 사용하면 관련 사내 문서를 먼저 검색한 뒤, 찾은 내용을 LLM에게 전달해서 답변하도록 만들 수 있다.

일반 LLM과 무엇이 다를까?

일반적인 LLM의 흐름은 단순하다.

사용자 질문 → LLM → 답변 생성

LLM이 기존에 학습한 지식을 기반으로 답변을 생성하는 구조다.

반면 RAG에서는 중간에 검색 과정이 추가된다.

사용자 질문 → 검색 → 관련 자료 → LLM → 답변 생성

즉,

질문 → LLM

이었던 구조가

질문 → 검색 → 관련 자료 → LLM

구조로 바뀌는 것이다.

이 중간의 Retrieval(검색) 과정이 RAG의 핵심이다.

RAG의 전체적인 흐름

실제 RAG에서는 대략 다음과 같은 과정을 거친다.

① 데이터 준비

문서
 ↓
문서를 작은 단위로 나누기 (Chunking)
 ↓
Embedding
 ↓
Vector DB 저장

② 사용자 질문 처리

사용자 질문
 ↓
관련 정보 검색 (Retrieval)
 ↓
검색 결과 + 사용자 질문
 ↓
LLM
 ↓
최종 답변

여기서 갑자기 새로운 단어들이 등장한다.

Chunking, Embedding, Vector DB...

지금은 각각의 기술을 자세히 알 필요 없이,

문서를 검색할 수 있는 형태로 미리 저장해두고 → 질문이 들어오면 관련 내용을 찾아서 → LLM에게 전달한다.

정도로만 이해해도 충분하다.

각각의 개념은 다음 글에서 하나씩 살펴볼 예정이다.

정리

RAG를 처음 접하면 여러 기술 용어 때문에 복잡해 보이지만 핵심은 생각보다 간단하다.

RAG는 사용자의 질문과 관련된 외부 정보를 먼저 검색하고, 검색한 정보를 LLM에게 참고자료로 제공하여 답변을 생성하는 방식이다.

한마디로 정리하면,

찾고 → 넣어주고 → 답하게 한다.

그리고 이 과정에서 등장하는 Chunking, Embedding, Vector DB가 각각 어떤 역할을 하는지는 다음 글에서 이어서 정리해보려고 한다 . ..🤓

nvm(Node version Manager)은 여러 버전의 node js를 설치하고 버전 변경을 관리해주는 도구이다.

강의를 들으며 실습하거나 개발을 할때 node.js버전이 달라서 에러가 날 경우가 많은데 ! 이때 nvm을 사용하면 다양한 버전으로 변경이 가능해서 문제를 손쉽게 해결할 수 있다 ❕

2. NVM 설치

🔗 nvm 다운로드: https://github.com/coreybutler/nvm-windows

3. NVM 사용하기

PowerShell에서 작업하는걸 추천합니다 😂

• 원하는 버전 설치 nvm install 16.19.0
• 원하는 버전 사용 nvm use 16.19.0
  • 내 pc에 설치된 node.js버전 확인 nvm list

아이콘은 png파일인데 색상을 변경하고 싶다면, 이미지 편집없이 간단하게 filter 속성을 추가하면 된다 !

input[type="radio"]:checked + label {
  color: #228b22;
  border: 2px solid #228b22;
  filter: opacity(0.5) drop-shadow(0 0 0 #228b22);
}

색상변경 성공 . . ✨

📢 참고

• https://developer.mozilla.org/ko/docs/Web/CSS/filter
• CSS filter generator https://codepen.io/sosuke/pen/Pjoqqp

2. 원하는 폰트를 선택

   1. 언어를 선택할 수 있음

   2. 스타일을 선택해서 + 버튼 클릭

   3. 왼쪽 사이드바 'Use on the web'에 있는 <Link>코드를 html <head>에 붙여넣기 하고 css에 아래코드를 추가하면 끝 🤓

1._ AWS콘솔에 접속하고, EC2_ 서비스에 들어가서 인스턴스 시작

2. Amazon Machine Image(AMI) 선택

• 우분투 리눅스 선택

3. 인스턴스 선택 후, 검토 및 시작을 클릭

4. 키 페어 생성하고 다운로드 받기

다운로드받은 키 페어는 잃어버리지 말고 잘 갖고있어야 한다. _.ssh 파일로 옮기기 ! _

RSA와 ED25519가 뭘까... 🙄💭 참고사이트 : https://naleejang.tistory.com/218

☁️ EC2 인스턴스 접속하기

1. 인스턴스 선택 후, 연결을 클릭하여 ssh클라이언트 확인하기

2. 인스턴스 생성할때 다운로드 받은 키 페어의 속성에서 [보안] -> [고급] -> [상속사용 안함] 버튼 클릭

3. 명령프롬프트를 관리자모드로 실행하고, 키 페어 파일이 있는 폴더로 이동

4. 1번 단계에서 봤던 SSH 명령어로 서버에 접속 ✔️

SSH 명령어 입력 후, 'Are you sure you want to continue connecting?'이 출력될 때 ! 💁 참고사이트 : https://not-to-be-reset.tistory.com/431

5. 서버에 접속하여 'python3' 입력 후 제대로 접속됐는지 확인

💁‍♀️ 아래 사이트를 참고하여 작성했습니다 : ) https://ndb796.tistory.com/250 [안경잡이개발자] https://deepmal.tistory.com/6

아나콘다(Anaconda)는 패키지 관리와 디플로이를 단순케 할 목적으로 과학 계산(데이터 과학, 기계 학습 애플리케이션, 대규모 데이터 처리, 예측 분석 등)을 위한 파이썬과 R 프로그래밍 언어의 자유-오픈 소스 배포판이다. 패키지 버전들은 패키지 관리 시스템 conda를 통해 관리된다. 📢 자주쓰는 파이썬 패키지가 설치되어있어서 그냥 파이썬만 사용하는 것 보다 편한건가 보다..🙄

1. 아나콘다 홈페이지 (https://www.anaconda.com/products/individual)에 들어가서 다운로드 받기.

3. 아나콘다 설치완료

💡 환경변수 단축키

window + r 을 누르고, 실행창이 나타나면 sysdm.cpl ,3을 입력하면 환경변수로 이동함 🤓

아나콘다 설치과정에서 path 설정을 체크해둬서 자동으로 환경변수에 path 추가가 되었다 !

💡 명령 프롬프트에서 python을 쳤을 때 에러 해결 !

💁 참고사이트 : https://devpad.tistory.com/42

-- creating a customers table
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    email VARCHAR(150),
    age INT
);

-- *은 모든 컬럼
SELECT * FROM customers;

▪️ INSERT

INSERT문을 사용하여 테이블에 행을 삽입할 수 있다.

INSERT INTO table_name(column1, column2, …)
VALUES (value1, value2, …);

-- insert data into a table
INSERT INTO customers(first_name, last_name, email, age)
VALUES 
('Shin', 'Zzanggu', 'cd.com', 5),
('Shin', 'Zzanga', 'abcd.com', 2),
('Bong', 'Bongsun', 'zz.com', 29);


INSERT INTO customers(first_name)
VALUES ('Bill''o Sullivan');

▶️ customer_id는 자동부여 되고, first_name 이외의 값은 null로 삽입된다. ▶️ '를 사용하려면 ''두 번 적으면 된다.

-- 값을 insert한 후 그 값의 행만 return 함! *는 컬럼모두
INSERT INTO customers (first_name)
VALUES ('Tom') RETURNING *; 

-- customer_id 만 return
INSERT INTO customers (first_name)
VALUES ('Elsa') RETURNING customer_id;

▶️ INSERT문 마지막에 RETURNING키워드를 사용하면 새로 넣은 값의 행을 반환해서 보여준다. RETURNING키워드 뒤에 *이면 모든 컬럼을 반환하고, 특정 컬럼이 적혀있으면 그 컬럼만 반환한다.

▪️ CREATE TABLE

SERIAL은 아이디를 순서대로 증가시켜준다. PRIMARY KEY는 기본키

-- 테이블 생성
-- CREATE TABLE 'table_name' (column...);

CREATE TABLE actors (
    actor_id SERIAL PRIMARY KEY, 
    first_name VARCHAR(150),
    last_name VARCHAR(150) NOT NULL,
    gender CHAR(1),
    date_of_birth DATE,
    add_date DATE,
    update_date Date
);

CREATE TABLE directors (
    director_id SERIAL PRIMARY KEY,
    first_name VARCHAR(150),
    last_name VARCHAR(150) NOT NULL,
    date_of_birth DATE,
    nationality VARCHAR(20),
    add_date DATE,
    update_date DATE
);

👀 테이블 생성 후, 구조 확인하기 SELECT * FROM directors;

▪️ CREATE TABLE (참조)

REFERENCES 키워드를 사용하여 movie 테이블의 director_id는 directors 테이블의 director_id를 참조한다.

-- 'column_name' 'dataType' REFERENCES 'table_name(column_name)'
director_id INT REFERENCES direcors (director_id)

CREATE TABLE movies (
    movie_id SERIAL PRIMARY KEY,
    movie_name VARCHAR(100) NOT NULL,
    movie_length INT,
    movie_lang VARCHAR(20),
    age_certificate VARCHAR(10),
    release_date DATE,
    director_id INT REFERENCES direcors (director_id)
);

CREATE TABLE movies_revenue (
    revenue_id SERIAL PRIMARY KEY,
    movie_id INT REFERENCES movies (movie_id),
    revenues_domestic NUMERIC (10,2),
    revenues_international NUMERIC (10,2)
);

▪️ 연결테이블

-- creating a movies_actor junction table

CREATE TABLE movies_actors (
    movie_id INT REFERENCES movies (movie_id),
    actor_id INT REFERENCES actors (actor_id),
    PRIMARY KEY (movie_id,actor_id)
);

📌 강의를 듣고 복습을 위해 작성한 공부기록용 포스팅입니다. :D 잘못된 정보가 있으면 알려주세요 !

1. 데이터베이스 유저등록

- login/group roles 마우스 오른쪽 클릭 후, create 
  패스워드 설정과 권한부여 설정함.

2. 데이터베이스 생성

- 데이터베이스에서 마우스 오른쪽 클릭 후, create -> owner 선택 -> save 

- ⚡️ 번개모양을 클릭하면 해당데이터베이스의 쿼리를 작성할 수 있는 에디터가 뜸.

💡 코드 💡

-- CREATE DATABASE '데이터베이스명'
CREATE DATABASE db_test;

-- DROP DATABASE '데이터베이스명'
DROP DATABASE db_test;

1. PostgreSQL 홈페이지 접속

https://www.postgresql.org/download/ 자신의 PC 운영체제에 맞게 설치파일을 다운로드 받습니다.

💁 설치에러해결 참고사이트 (감사합니다🙇‍♀️)

1. https://heeonii.tistory.com/8?category=929658
2. https://bug41.tistory.com/148

2. 계속 next 클릭 후 다운로드 완료 ❗️

- 경로 디폴트로 설정, 지역은 korea로 하고 next ⇒
- ⭐️이때 설정한 패스워드는 까먹지 말기⭐️
- 포트번호 5432

-'pgAdin4'를 검색해서 뜨면 다운로드 성공 😆

3. pgAdmin4 접속

- Servers -> PostgreSQL11 클릭한 후

- 2번 단계에서 설정한 패스워드를 입력 !

- 서버연결 성공 😆