개발/Dify

[Dify] 지식 생성

말하는 알감자 2025. 12. 10. 15:44

RAG를 구축하기 위한 사전 단계: 지식베이스 구축이 필요

→ dify에서는 지식베이스 구축을 쉽게 할 수 있도록 지원합니다.

1) 지식 메뉴에서 새 지식 생성

  • 상단 메뉴 [지식] → [지식 생성] 으로 들어갑니다.
  • 여기서 만드는 하나의 지식(knowledge base)이 나중에 RAG에서 사용할 “문서 저장소”가 됩니다.

2) step1 : 데이터 소스 선택

  • 첫 번째 단계에서 지식베이스에 저장할 데이터 소스를 선택합니다.
  • Dify는 공식 문서 기준으로:
    • 로컬 문서(문서 업로드)
    • Notion 동기화
    • 웹사이트 동기화(Jina / Firecrawl 사용) 를 지원합니다.
  • 한 지식베이스를 “온라인 데이터 전용”으로 만들면, 나중에 로컬 문서를 섞어 넣을 수 없으니 처음에 구조를 잘 정하는 것이 좋습니다.

3) 예시 문서 업로드 (SPRI AI Brief PDF)

4) step2 : 문서를 어떻게 지식베이스에 저장할 지 설정

  • 청크 설정(Chunk Settings)
    • 문서를 어떤 규칙으로 잘라서 “청크(Chunk)”라는 작은 단위로 만들지 결정합니다.
  • 인덱스 모드(Indexing Mode)
    • 어떻게 사용자가 업로드한 문서를 AI가 효율적으로 이해하고 활용할 수 있도록 변환할지
    • 업로드된 청크를 어떤 방식으로 인덱싱(벡터/키워드) 할지 선택합니다.
  • 임베딩 모델 (Embedding model)
    • 텍스트를 숫자 벡터로 변환하는 AI 모델입니다.
  • 검색 설정(Retrieval Setting)
    • AI가 문서에서 정보를 찾을 때 어떻게 찾을지
    • 실제 질문이 들어왔을 때 벡터 검색 / 전체 텍스트 검색 / 하이브리드 검색 중 어떤 방식을 쓸지,
    • TopK·점수 임계값·재랭크 모델 등을 어떻게 사용할지 정합니다.

5) 청크 설정

 

  • Dify는 문서를 RAG에 적합한 단위로 분할하기 위해 두 가지 청크 모드를 제공합니다.
  • → 일반(General) 모드, 부모-자식(Parent-Child) 모드
  • 두 모드의 핵심은 “문서를 어떤 단위로 잘라서 검색에 쓸 것인가” 이며,
  • 검색 정확도와 답변 품질에 직접적인 영향을 줍니다.

청크 (Chunk)

긴 문서를 AI가 효율적으로 처리를 할 수 있도록 나눈 작은 텍스트 단위입니다.

AI 모델은 한 번에 처리할 수 있는 텍스트 길이(ContextWindow)에 제한이 있기 때문에, 수십 페이지에 달하는 긴 문서를 통째로 입력할 수 없습니다.

→ 문서를 의미있는 단위로 잘게 나누어 각각을 독립적으로 처리할 수 있도록 만드는데, 이렇게 나뉜 각각의 텍스트 조각이 바로 청크

청크의 크기와 나누는 방식은 검색 정확도와 답변 품질에 직접적인 영향을 미치기 때문에, 문서의 특성에 맞게 적절히 설정하는 것이 중요합니다.

청크 설정이 중요한 이유

  • LLM은 입력 가능한 길이(Context Window)에 한계가 있어 긴 문서를 그대로 넣을 수 없습니다.
  • 따라서 문서를 정교하게 잘라서 검색과 답변 품질이 모두 살아있는 형태로 분할해야 합니다.
  • 청크 크기와 중첩은
    • 검색 결과 정확도
    • 문맥 전달력
    • 최종 답변의 자연스러움
    • 이 세 가지에 직접적인 영향을 줍니다.

① 일반 모드(General Mode)

: 가장 기본적이고 직관적인 청크 분할 방식

  • 문서를 세그먼트 식별자, 최대 청크 길이, 청크 중첩 등 사용자가 설정한 규칙에 따라 일정한 크기의 청크로 나눕니다.
  • 일반 PDF, 보고서, 블로그 글처럼 구조가 단순한 문서에 적합합니다.
  • 만들어진 하나의 청크가
    • 검색 대상이면서 동시에
    • LLM에 넘겨지는 컨텍스트
    • 역할을 둘 다 수행합니다.
  • 설정 요소
    • 세그먼트 식별자 (Segment Identifier / Chunk Delimiter)
      • 문서를 “어디서 잘라서 청크를 만들지”를 정하는 구분자입니다.
      • 예시
        • \\n\\n : 두 번 줄바꿈을 기준으로 문단 단위 분할
        • \\n : 줄 단위 분할
        • \\n\\n,\\n 처럼 여러 패턴을 조합해서 문단·줄 혼합 분할도 가능합니다.
      • 문서가 문단 구분이 잘 되어 있다면 \\n\\n 기반 설정이 많이 사용됩니다.
    • 최대 청크 길이 (Maximum chunk length)
      • 하나의 청크에 들어갈 수 있는 최대 텍스트 길이입니다.
      • 지정한 길이를 넘으면 자동으로 다음 청크로 잘립니다.
      • 값이 너무 크면
        • 하나의 청크 안에 정보가 너무 많이 들어가서 질문과 직접 관련 없는 내용까지 함께 전달될 수 있습니다.
      • 값이 너무 작으면
        • 문장이 여러 청크로 쪼개져 문맥이 끊기고 LLM이 정확한 의미를 파악하기 어려워질 수 있습니다.
    • 청크 중첩 (Chunk overlap)
      • 인접한 청크들이 일정 길이만큼 겹치도록 만드는 옵션입니다.
      • 목적
        • 문장이 청크 경계에서 잘려 나가도 앞뒤 청크 모두에 포함되게 해서 문맥 손실을 줄입니다.
      • 값이 너무 작으면
        • 일부 문장이 앞 청크에만 들어가거나, 뒤 청크에만 들어가 연결이 자연스럽지 않을 수 있습니다.
      • 값이 너무 크면
        • 중복된 텍스트가 많아져 불필요한 토큰 사용량이 늘어납니다.
    • 텍스트 전처리 규칙 (Text preprocessing)
      • “연속된 공백, 줄바꿈, 탭을 대체합니다”
        • 문서 안의 불필요한 공백·줄바꿈을 정리해 깨끗한 텍스트로 만듭니다.
      • “모든 URL과 이메일 주소를 제거합니다”
        • 링크/이메일이 검색 품질에 방해가 될 경우 체크하면 됩니다.
      • 전처리를 통해 노이즈를 줄이고 검색 정확도를 높일 수 있습니다.
  • 장점
    • 설정이 단순해서 이해·튜닝이 쉽습니다.
    • 대부분의 일반 문서에서 충분한 성능을 보여줍니다.
  • 단점
    • 청크를 너무 작게 나누면 → 맥락이 부족해 답변이 단편적이 될 수 있습니다.
    • 너무 크게 나누면 → 검색은 쉬워도, 질문과 덜 관련된 내용까지 함께 넘어가 정확도가 떨어질 수 있습니다.

② 부모-자식 모드(Parent-Child Mode)

: “검색은 작은 조각으로, 참고는 큰 덩어리로” 하는 청크 방식

  • 문서를 두 가지 크기로 동시에 나눕니다.
    • 자식 청크(Child Chunk) → 검색에 쓰이는 작은 조각
    • 부모 청크(Parent Chunk) → LLM에 넘기는 넓은 컨텍스트
  • 검색 단계에서는 자식 청크로 질문과 가장 관련 있는 위치를 찾고,
  • 답변 생성 시에는 그 자식 청크가 속한 부모 청크 전체를 함께 참고합니다.
  • 정책 문서, 기술 매뉴얼, 논문처럼 구조가 깊고 문맥 의존성이 큰 문서에 유리합니다.
  • 장점
    • 검색 정확도(자식)와 맥락 전달력(부모)을 동시에 확보합니다.
    • 긴 문서에서 답변 품질이 크게 좋아집니다.
  • 단점
    • 일반 모드보다 구조·설정이 조금 더 복잡합니다.
  • 주의사항
    • 공식 동작 기준, 지식 생성 시 선택한 청크 모드는 나중에 변경할 수 없습니다.
    • (새 지식을 다시 만들어야 함)
    • 문서 구조가 복잡한 경우에는 Parent-Child 모드 사용이 권장됩니다.

6) ‘프리뷰 청크 (Preview Chunk)’를 누르면 어떻게 분할되었는지 미리 확인해볼 수 있습니다.

프리뷰 청크 (Preview Chunk)

  • 현재 설정이 적용된 상태에서 문서를 어떻게 나누는지 미리 보여주는 기능입니다.
  • 여기서
    • 청크 하나의 길이
    • 문장 단위가 잘 유지되는지
    • 문단/섹션이 알맞게 나뉘는지
    • 를 확인하면서 세그먼트/길이/중첩 값을 다시 조정하면 됩니다.

7) 부모-자식 모드

  • 부모-자식 모드는 실제로는 문서를 두 가지 크기로 나누어 사용합니다.
    • 자식 청크: 검색 전용 / 비교적 작은 단위
    • 부모 청크: LLM에 전달하는 참고 컨텍스트 / 더 큰 단위
  • 검색 시에는 자식 청크 단위로 “어디 부분이 질문과 가장 관련 있는지”를 찾고, 답변 생성 시에는 그 자식이 속한 부모 청크 전체를 함께 LLM에 전달합니다.

① 컨텍스트에 대한 Parent-chunk 영역

  • 단락 모드
    • 세그먼트 식별자 + 최대 청크 길이에 따라
    • 문서를 단락·섹션 단위의 부모 청크로 나눕니다.
    • 예: \\n\\n 기준, 최대 청크 길이 1024 등
    • 장점
      • 한 부모 청크가 너무 크지 않아,
      • LLM에 넘기는 컨텍스트가 적당한 크기로 유지됩니다.
  • 전체 문서 모드
    • 문서 전체를 하나의 부모 청크로 간주합니다.
    • 상위 구조를 크게 나누지 않고,
    • “문서 하나 = 하나의 큰 컨텍스트”로 취급합니다.
    • 문서가 짧거나, 한 파일이 하나의 논리 단위로 쓰일 때 사용할 수 있습니다.

이 Parent-chunk는 검색 결과에서 선택된 자식 청크가 속한 상위 덩어리로,

최종 답변 생성에 사용되는 “큰 문맥”이라고 이해하시면 됩니다.

② 검색을 위한 자식 청크 영역 (Child chunk for search)

  • 이 영역에서 자식 청크의 분할 규칙을 설정합니다.
    • 세그먼트 식별자
      • \\n 등 줄 단위로 보다 촘촘하게 나누는 경우가 많습니다.
    • 최대 청크 길이
      • 부모보다 작은 값으로 설정해 세밀한 검색이 가능하도록 합니다.
  • 검색 단계 흐름
    1. 사용자의 질문을 임베딩 혹은 키워드로 변환
    2. 자식 청크들 중에서 질문과 가장 관련성이 높은 조각을 찾음
    3. 그 자식 청크가 속한 부모 청크 전체를 LLM 컨텍스트로 전달

③ 부모-자식 모드를 쓰면 좋은 경우

  • 기술 매뉴얼, API 문서, 사내 규정, 정책 문서, 연구 보고서 등
    • 섹션/장/절 구조가 있고
    • 섹션 간 의존도가 높은 긴 문서
  • 질문이 특정 한 줄·한 문장에 꽂히지만,
    • 예: “이 API 에러 코드가 발생했을 때 전체 처리 흐름을 설명해줘”
    • 예: “이 조항 예외 규정을 포함해서 전체 규정을 설명해줘”
  • 답변은 상위 섹션 전체를 참고해야 정확한 경우

8) 인덱스 모드

Dify는 문서를 어떻게 저장하고 검색할지에 따라 두 가지 인덱스 모드를 제공합니다.

이 선택은 지식베이스의 정확도와 비용을 크게 결정합니다.

① 고품질 모드 (High-Quality Indexing) — 추천

임베딩 모델을 사용하여 문서를 의미 기반(Vector)으로 저장하는 방식입니다.

  • 문서를 임베딩 모델이 **숫자 벡터(Embedding Vector)**로 변환
  • 질문도 벡터로 변환해 의미적으로 가까운 문장을 찾아냄
  • 표현이 달라도 의미가 비슷하면 매칭됨 (Semantic Search)

예시:

  • 질문: “비용 줄이는 방법 알려줘”
  • 문서: “경비 절약 전략 소개”
  • → 단어가 달라도 의미가 같기 때문에 매칭됨

특징

  • 검색 정확도가 가장 높음
  • 자연어 질문 처리에 강함
  • Gemini 모델 기준, 한국어 의미 검색에서도 우수
  • RAG를 제대로 활용하려면 가장 추천되는 방식
  • 단, 임베딩 생성 비용이 발생
  • 한 번 고품질 모드로 인덱싱하면 경제적 모드로 되돌릴 수 없음

② 경제적 모드 (Economical Indexing)

키워드 중심의 역색인(Inverted Index) 방식입니다.

  • 문서의 단어들을 색인하여 질문에 포함된 단어가 그대로 들어 있는 청크를 빠르게 찾아냄
  • 임베딩 비용이 없어 매우 경제적

예시:

  • 질문: “error code 500”
  • 문서에 동일한 키워드가 있을 경우 최적

특징

  • 빠르고 비용 없음
  • 하지만 표현이 조금만 달라지면 검색 실패

예:

  • “비용 절감” ↔ “경비 절약” → 매칭 실패
  • “고도 제한” ↔ “비행고도 규칙” → 매칭 실패

→ 자연어 기반 Q&A에는 부적합

→ 키워드 중심의 로그/매뉴얼에만 적합

임베딩 모델(Embedding Model)

고품질 모드를 선택하면 임베딩 모델을 반드시 선택해야 합니다.

(Dify는 모델 공급자에 따라 임베딩 모델 목록이 달라집니다.)

처음부터 Gemini를 선택했기 때문에 임베딩 목록도 Gemini를 기준으로 살펴보겠습니다.

Gemini 임베딩 모델 종류

모델명 설명 특징 추천 여부

embedding-001 Gemini 기본 임베딩 모델 구세대, 성능 무난 보통
gemini-embedding-001 Gemini 공식 embedding 라인 의미 검색 정확도 개선, 다국어 향상 좋음
text-embedding-004 Google 최신 임베딩 모델 높은 성능·효율·한국어 우수 가장 추천

임베딩이 필요한 이유

AI는 텍스트 의미를 직접 이해하지 못하므로 문장을 **벡터(숫자 목록)**로 변환하여 의미적 유사도를 계산합니다.

예시:

  • “사과” ↔ “바나나” → 의미가 비슷해 벡터도 비슷
  • “사과” ↔ “자동차” → 의미가 달라 벡터가 멀어짐
  • “비용 절감” ↔ “경비 절약” → 같은 의미로 분류됨

즉, 임베딩을 사용하면

  • 표현이 다르더라도 의미가 비슷하면 검색됨
  • 자연어 질문에 강함
  • 문서 문맥 기반 검색이 가능해짐

9) 검색 설정

Dify는 지식베이스에서 문서를 어떻게 검색할지 결정하기 위해

벡터 검색 / 전체 텍스트 검색 / 하이브리드 검색

세 가지 방식을 제공합니다.

각 방식은 문서 유형, 검색 정확도, 비용에 따라 장단점이 달라집니다.

그 중 벡터 검색 (Vector Search)은 RAG 시스템에서 가장 많이 사용되는 핵심 방식입니다.

벡터 검색은 임베딩 모델이 생성한 벡터(숫자 표현)를 기반으로

사용자의 질문과 의미적으로 가장 가까운 청크를 찾아내는 방식입니다.

동작 방식

  1. 사용자의 질문을 임베딩 모델로 벡터(숫자 리스트)로 변환
  2. 지식베이스에 저장된 각 청크도 벡터로 저장되어 있음
  3. 두 벡터의 유사도(cosine similarity 등)를 계산
  4. 의미적으로 가장 가까운 청크를 상위 K개 찾아 반환

특징

  • 표현이 달라도 의미가 비슷하면 매칭됨
  • 한국어·영어 등 다국어 문서에서 매우 유효
  • 자연어 기반 질문에 가장 강함
  • RAG에서 가장 널리 쓰이는 방법

예시

질문: 비용 절감 방법 알려줘

문서에 있는 표현: 경비 절약 전략

→ 단어는 다르지만 의미가 같으므로 벡터 검색에서는 정상적으로 매칭됨

  • 상위 K (Top-K)
    • K 값이 크면
      → 하지만 관련성이 낮은 내용도 섞일 수 있음
      → 더 많은 정보를 참고
    • K 값이 작으면
      → 하지만 정보가 충분하지 않을 수 있음
      → 최대한 핵심적인 내용만 참고
    권장값: 5 ~ 10
    (문서가 길거나 복잡한 경우 K를 늘리면 답변 품질이 개선됨)

  • 점수 임계값 (Score Threshold)
    청크 유사도 점수가 이 값보다 낮으면
    → 검색 결과에서 제외하는 기능입니다.
    • 높게 설정하면
      → 정확도 ↑, 하지만 검색 결과가 너무 적어질 수 있음
      → 매우 관련성 높은 청크만 선택
    • 낮게 설정하면
      → 불필요한 정보 포함 가능
      → 더 넓은 범위의 정보를 가져옴
    처음에는 0.0 ~ 0.2로 두고 테스트하는 것이 안정적

10) 재랭크(Rerank) 모델 설정

재랭크 모델은 초기 검색 단계에서 가져온 여러 문서 청크들을 사용자의 질문과 다시 비교하여, 관련성이 높은 순서로 재정렬하는 역할을 합니다.

벡터 검색은 의미적으로 유사한 후보를 빠르게 찾아오지만, 항상 가장 적합한 순서로 정렬되지는 않습니다.

재랭크 모델을 사용하면 이러한 초기 검색 결과를 더 정밀하게 평가하여 최종적으로 더 정확한 검색 품질을 기대할 수 있습니다.

재랭크 모델의 특징

  • 검색된 청크들을 문장 단위에서 다시 평가하여 순위를 재정렬합니다.
  • 질문과 문서의 미세한 의미 차이를 판단하는 데 강점이 있습니다.
  • 문서가 길거나 유사한 문맥의 텍스트가 많은 자료에서 효과적입니다.

사용 시 고려사항

  • 재랭크 모델을 사용하면 추가 비용이 발생합니다.
  • 검색 과정에 한 단계가 추가되므로 응답 속도가 다소 느려질 수 있습니다.
  • Top-K 값이 너무 낮으면 재랭크의 효과가 제한됩니다. 일반적으로 Top-K를 5 이상으로 설정하는 것이 추천됩니다.

재랭크 모델은 필수 요소는 아니지만, 검색 품질을 높이고 싶은 경우 유용하게 활용할 수 있습니다. 특히 긴 기술 문서나 유사한 내용이 반복되는 보고서 기반의 RAG에서는 체감 효과가 큽니다.

Dify에서는 Cohere의 rerank 계열 모델을 사용할 수 있으며, Cohere 웹사이트에서 회원 가입 후 API 키 발급이 가능합니다.

rerank-v3.5 모델은 한국어를 포함한 다국어 성능이 향상되어, 한국어 문서 기반 RAG에서도 안정적인 성능을 제공합니다.

① https://cohere.com/ 접속

② 회원가입

③ 회원가입 후 옆의 API Keys 클릭

④ Create Trial Key 선택 후 Key name 입력

⑤ api key 발급 완료

⑥ 재랭크 모델 on > 모델 제공자 선택

⑦ 설정 클릭 후 아까 만든 API KEY 입력

⑧ 다시 돌아와서 다국어 모델인 rerank-v3.5 선택

11) 검색 설정 - 전체 텍스트 검색(Full-Text Search)

전체 텍스트 검색은 문서 내 모든 단어를 인덱싱해, 사용자가 입력한 키워드와 정확히 일치하는 용어가 포함된 청크를 검색하는 방식입니다.

가장 전통적인 형태의 키워드 기반 검색이며, 의미 기반 분석 없이 문자열 매칭만으로 검색이 이루어집니다.

특징

  • 검색 속도가 매우 빠름
  • 임베딩 비용이 발생하지 않음
  • 문서에 포함된 단어가 정확히 일치할 때 높은 정확도 제공
  • 기술 용어·오류 코드·고유명사처럼 표현이 고정된 콘텐츠에서 효과적

제한 사항

  • 표현이 조금만 달라져도 검색이 실패할 수 있음
  • (예: “비용 절감” ↔ “경비 절약” → 의미는 같지만 검색 불가)
  • 자연어 기반 질문이나 문맥적 해석이 필요한 질의에는 적합하지 않음
  • 한국어의 형태소 다양성 때문에 단순 키워드 검색이 부정확해지는 경우가 있음

사용이 적합한 경우

  • 로그 파일 분석
  • 시스템 경고 메시지 검색
  • 코드 매뉴얼(함수명, 오류 코드, 고유 키워드 등)
  • 특정 문구가 정확히 포함된 위치를 찾는 작업
  • 대규모 문맥 분석이 필요하지 않은 단순 질의

요약

전체 텍스트 검색은 비용·속도 측면에서 가장 가볍지만, 자연어 기반 RAG에는 한계가 있습니다.

따라서 정확한 키워드 기반 검색이 필요한 문서에 적합한 보조 검색 방식으로 활용됩니다.

12) 검색 설정 - 하이브리드 검색(Hybrid Search)

하이브리드 검색은 벡터 검색(의미 기반)과 전체 텍스트 검색(키워드 기반)을 동시에 수행한 뒤,

두 검색 결과를 하나로 합쳐 가장 관련성 높은 순서로 재정렬하는 방식입니다.

Dify 공식 문서에서도 가장 추천되는 검색 방식으로 소개됩니다.

동작 방식 요약

  1. 사용자의 질문을 임베딩하여 의미적으로 가까운 청크를 벡터 검색으로 찾고
  2. 동시에 문서 내에서 정확하게 키워드가 일치하는 청크를 전체 텍스트 검색으로 찾습니다
  3. 두 검색 결과를 합쳐
  4. 재랭크 모델 또는 가중치 방식을 사용해 최종 순위를 정합니다
  5. 상위 K개의 청크만 LLM에게 전달됩니다

즉, 의미 검색 + 키워드 검색 + 재랭킹

세 가지를 모두 결합한 고급 검색 방식입니다.

특징

  • 단순 벡터 검색보다 정확한 키워드 매칭 능력이 강화됨
  • 단순 전체 텍스트 검색보다 표현이 다른 문장도 잘 찾아냄
  • 문서가 다양한 형태로 구성되어 있을 때 가장 균형 잡힌 성능을 제공
  • RAG 품질이 가장 안정적으로 나오는 검색 모드

장점

  • 키워드 매칭과 의미 매칭을 동시에 활용 → 검색 누락이 줄어듦
  • 표현이 다르더라도 정확히 찾을 수 있음
  • (“비용 절감” ↔ “경비 절약” 같은 경우)
  • 긴 PDF·정책 문서·기술 문서처럼 데이터 구조가 복잡한 문서에 특히 효과적
  • LLM에게 전달되는 청크 품질이 매우 높아져 답변 정확도 상승

주의점

  • 재랭크 모델(CoHere 등) 사용 시 비용이 추가될 수 있음
  • 재랭크 모델을 설정하지 않으면 기본 가중치 방식으로 통합
  • 검색 단계가 2개이므로 전체 텍스트 검색 또는 벡터 검색 단일 모드보다 처리 과정이 조금 더 복잡함

하이브리드 검색이 적합한 경우

  • PDF·논문·매뉴얼처럼 구조가 복잡한 문서를 다루는 RAG
  • 키워드도 중요하지만 의미 기반 검색도 놓칠 수 없는 상황
  • 사용자 질의가 다양하고, 단순 키워드 매칭으로는 정확도가 낮을 때
  • “정확한 사실 기반 답변”이 반드시 필요한 서비스

13) 지식베이스를 어떻게 설정하는 것이 좋은지에 대한 추천 설정

청크 설정

  • 일반 모드를 선택하는 것이 좋습니다. 부모-자식 모드는 고급 기능으로 구조가 복잡한 문서에서 유리하지만, 처음에는 일반 모드만으로도 충분히 좋은 성능을 냅니다.
  • 세그먼트 식별자는 \n\n,\n 조합을 추천합니다. 문단 단위로 우선 분할하고, 문단이 너무 길면 줄 단위로 보조 분할이 이루어져 균형이 좋습니다. \n\n만 사용할 경우 문단이 과도하게 길어지는 문제가 생길 수 있습니다.
  • 최대 청크 길이는 800~1200자 수준이 안정적입니다. 기본값 500자는 문맥이 지나치게 잘려 답변 품질이 떨어질 수 있고, 반대로 너무 길면 핵심 정보가 묻힐 수 있습니다.
  • 청크 중첩은 100~150자를 추천합니다. 청크 사이에 연결성이 생겨 문장이 분리되는 문제를 줄일 수 있고, 검색 품질도 높아집니다.
  • 텍스트 전처리에서는 연속된 공백, 줄바꿈, 탭 정리 옵션을 켜두는 것이 좋습니다. URL과 이메일 제거는 문서 성격에 따라 선택하면 됩니다.

이 기본 설정은 대부분의 PDF, 보고서, 기사 문서에서 안정적인 검색 품질을 제공합니다. 이후 문서 유형에 따라 세부 값을 조정해도 됩니다.

인덱스 모드

  • 고품질 모드를 추천합니다. 임베딩 기반 의미 검색이 가능해 표현이 달라도 관련된 정보를 찾아낼 수 있습니다. 자연어 질문이 많은 환경에서는 고품질 모드가 훨씬 유리합니다.
  • 임베딩 모델은 OpenAI 기준에서는 text-embedding-004 또는 text-embedding-3-small처럼 비용 대비 성능이 좋은 모델을 선택하는 것이 좋습니다. 한국어 문서에서도 안정적으로 작동합니다. Gemini를 사용하는 경우에는 embedding-001, gemini-embedding-001, text-embedding-004 모델 중 하나를 선택하면 됩니다. 세 모델 모두 한국어 문서에서 안정적으로 작동하며, RAG 시스템을 구축할 때 무난한 품질을 제공합니다.

검색 방식

  • 하이브리드 검색을 선택하면 가장 안정적인 품질을 얻을 수 있습니다. 벡터 검색과 전체 텍스트 검색을 동시에 수행하기 때문에 의미적 연관성과 키워드 정확도를 모두 확보할 수 있습니다.
  • 비용을 부담할 수 있다면 재랭크 모델 사용을 권장합니다. 한국어를 지원하는 다국어 재랭크 모델(rerank-multilingual-v3.0 또는 rerank-v3.5 등)을 선택하면 검색된 청크의 순위를 더 정교하게 재정렬해 답변 품질이 올라갑니다. 재랭크 비용이 부담된다면 초기에는 비활성화한 뒤 필요할 때 활성화해도 됩니다.
  • 매개변수 설정에서 상위 K 값은 10 이상을 추천합니다. 참고할 문서가 많을수록 답변 품질이 좋아집니다. 질문이 복잡하거나 여러 관점이 필요한 경우 특히 도움이 됩니다.
  • 점수 임계값은 처음에는 설정하지 않거나 0.0에 가깝게 두는 것이 안정적입니다. 임계값을 너무 높이면 관련 있는 청크도 필터링되어 오히려 답변 품질이 떨어질 수 있습니다. 필요할 때만 점차 조정하는 방식이 좋습니다.

14) step3 : 실행 및 완료 단계

모든 설정을 마치고 [다음]을 누르면 3단계 – 실행 및 완료 화면으로 이동합니다.

15) 문서 탭에서 업로드 결과 확인

  • [문서로 이동]을 클릭하면, 방금 업로드한
    SPRI AI Brief_2025_3월호.pdf 가 지식베이스에 실제로 등록된 것을 확인할 수 있습니다.
  • 지식 > 문서 화면에서는:
    • 새 파일 추가
    • 문서 비활성화/보관/삭제
    • Notion·웹사이트 동기화
    • 등의 작업을 관리할 수 있습니다.

16) 검색 테스트로 품질 점검

  • 검색 테스트 기능에서는 사용자가 실제로 입력할 만한 질문(쿼리)을 넣고,
    • 어떤 청크가 검색되는지
    • 점수는 어떻게 나오는지
    • 재랭크 결과 순서는 어떤지
    • 를 확인할 수 있습니다.
  • 이 화면을 보면서 청크 설정, 인덱스 모드, 검색 방식을 다시 미세 조정하는 것이 공식 문서에서도 권장하는 워크플로우입니다.

 

17) 지식 설정에서 후속 조정

  • [지식 설정] 메뉴에서는 이미 생성된 지식베이스에 대해:
    • 검색 모드(벡터/전체 텍스트/하이브리드)
    • 재랭크 모델
    • TopK·Score Threshold
    • 멀티-패스 리트리벌 옵션
    • 등을 수정할 수 있습니다.
  • 다만, 청크 모드와 인덱스 모드 일부(High-Quality → Economical)는 생성 후 변경이 불가능하니 처음 만들 때 구조를 신중히 선택하시는 것이 좋습니다.

 

 

저작자표시 (새창열림)

'개발 > Dify' 카테고리의 다른 글

[Dify] RAG 실습 (2) - 인사 관련 법령 RAG  (0) 2025.12.11
[Dify] RAG 실습 (1) - 지식 기반 RAG  (0) 2025.12.10
[Dify] RAG (Retrieval Augmented Generation)  (0) 2025.12.09
[Dify] 챗봇 실습 - 변수를 활용한 챗봇 만들기  (0) 2025.12.09
[Dify] 챗봇 실습 - 프롬프트를 사용한 간단한 챗봇 만들기  (0) 2025.12.09

'개발/Dify'의 다른글

  • 현재글[Dify] 지식 생성

관련글

티스토리툴바