[MS] GraphRAG 사용하기📊 (3) 공식 문서 이해하기

포스팅을 읽기 전에 아래 포스팅을 먼저 보고 직접 실행해보는 것을 추천한다. 어떻게 실행하는지 몸소 체험해보고 그 다음에 개념을 알아보는게 좀 더 이해가 잘 될 것 같다.

https://chaechaecaley.tistory.com/17

[MS] GraphRAG 사용하기📊 (1)

이 글은 한성대학교의 황기태 교수님의 지도를 받아 진행하는 지식 그래프를 활용한 프로젝트 준비 과정을 담은 글이다. 정확한 주제가 정해진 것은 아니지만, Microsoft의 GraphRAG를 활용할 것으로

chaechaecaley.tistory.com

GraphRAG에 대한 MS 공식 문서가 너무 어려워서 좀 더 쉬운 말들로 정리해 보았다. 혹시 틀린 부분들이 있다면, 댓글로 알려주길 바란다.

The GraphRAG Process 🤖

인덱싱 (Index)
- 입력 코퍼스를 일련의 TextUnit으로 나눈다. 이 TextUnit은 이후에 분석 단위로 사용되며, 결과에서 세밀한 참조를 제공한다.
- LLM을 사용하여 TextUnit에서 모든 엔티티, 관계, 주요 주장을 추출한다.
- Leiden 기법을 사용하여 그래프를 계층적으로 클러스터링한다. 그림 1과 같이 각 원은 엔티티(예: 사람, 장소, 조직)를 나타내며, 크기는 엔티티의 정도를, 색상은 커뮤니티를 나타낸다.
- 각 커뮤니티와 그 구성원에 대한 요약을 아래에서 위로 생성한다. 이는 데이터 세트에 대한 전체적인 이해를 돕는다.
쿼리 (Query)
- 쿼리 시, 이러한 구조는 질문에 답할 때 LLM의 *컨텍스트 창을 제공하는 데 사용된다. 주요 쿼리 모드는 다음과 같다:
  - 전역 검색 (Global Search): 커뮤니티 요약을 활용하여 코퍼스에 대한 포괄적인 질문을 추론한다.
  - 지역 검색 (Local Search): 특정 엔티티에 대해 이웃과 연관된 개념으로 확장하여 추론한다.

*컨텍스트 창(Context Window): 모델이 한 번에 처리할 수 있는 입력 텍스트의 범위를 의미

프롬프트 튜닝 (Prompt Tuning)
- 기본 설정으로 GraphRAG을 데이터와 함께 사용하면 최상의 결과를 얻지 못할 수 있다. 문서의 프롬프트 튜닝 가이드를 참조하여 프롬프트를 세밀하게 조정하는 것을 권장한다.

1. Running the Indexer

1.1 Ready for Dataset

`ragtest`라는 root 디렉토리를 만들고 `input` 디렉토리를 만들어 Charles Dickens의 Christmas Carol을 `txt`파일로 가져온다.

mkdir -p ./ragtest/input

curl -o ./ragtest/input/book.txt https://www.gutenberg.org/cache/epub/24022/pg24022.txt

MS 공식 문서에는 `curl https://www.gutenberg.org/cache/epub/24022/pg24022.txt > ./ragtest/input/book.txt`라고 소개하지만, 위와 같이 코드를 작성해야 txt 파일 내용을 온전히 다 가져올 수 있다.

1.2 Set Up My Workspace Variables

먼저 필요한 환경 변수를 설정해야 한다. GraphRAG indexing engine을 위한 옵션을 설정하는 단계로, 이 단계를 Configuring GraphRAG Indexing 이라고 지칭하는 것 같다. 작업 공간을 초기화시키기 위해 다음 명령어를 실행한다.

python -m graphrag.index --init --root ./ragtest

명령어를 실행하면 `./ragtest` 디렉토리에 `.env`파일과 `settings.yaml`파일이 만들어진다.

`.env` - GraphRAG 파이프라인을 실행시키기 위한 환경 변수를 담고 있다. `init` 명령어를 실행하고 나면 이 파일 안에 `GRAPHRAG_API_KEY=<API_KEY>`라는 환경 변수가 생긴 것을 볼 수 있다. 이 변수는 본인의 OpenAI API key나 Azure OpenAI endpoint를 넣으면 된다.
`settings.yaml` - 파이프라인 설정들을 담고 있다. 사용자는 이 파일에서 파이프라인 설정을 수정할 수 있다.

📌Configuring GrapRAG Indexing

옵션을 설정하기 위해서는 간단히 말하자면, 총 3가지 방법이 있다.

1) 기본 옵션만 설정하기: Init Command (권장) 🔗

2) 환경 변수 사용해서 커스텀하기: Purely using environment variables 🔗

3) 아예 모든 것을 커스텀하기: Using JSON or YAML for deeper control 🔗

1) 기본 옵션만 설정하기: Init Command (권장) ⭐

`init` 명령어는 가장 쉽게 시작할 수 있는 명령어다. 이 명령을 실행하면 필요한 옵션들이 설정된 `.env`파일과 `settings.yaml`파일이 지정해준 디렉토리에 생성된다.

python -m graphrag.index [--init] [--root PATH]

`--init` - 필요한 옵션 파일들과 함께 디렉토리를 초기화한다.
`--root PATH` - 루트 디렉토리를 설정한다. 기본값은 현재 디렉토리이다.

Example

python -m graphrag.index --init --root ./ragtest

Output

`init` 명령어는 지정한 디렉토리에 다음과 같은 파일들을 생성한다.

`settings.yaml` - 이 파일은 옵션 파일로, GraphRAG에 대한 모든 설정을 담고 있다.
`.env` - 이 파일은 환경 변수 파일로 `settings.yaml`에서 참조한다.
`prompts/` - 이 디렉토리는 LLM 프롬프트에 대한 디렉토리로 GraphRAG가 사용하는 기본 프롬프트를 생성하고, 사용자 데이터에 맞는 새로운 프롬프트를 만드려면 Auto Prompt Tuning 명령을 실행해서 수정해야 한다.

2) 환경 변수 사용해서 커스텀하기: Purely using environment variables

사용자가 원하는대로 환경 변수를 커스텀 할 수 있다. LLM 설정, 텍스트 생성 설정, 텍스트 임베딩 설정, 입력 설정, 데이터 매핑 설정 등 하나하나 커스터마이징 할 수 있다. 설정에 대한 내용이 광범위한 관계로 OpenAI API를 사용한다는 가정 하에 간단한 설명만 기재한다.

⚙️Base LLM Settings

LLM 연결에 대한 설정들이다.

`GRAPHRAG_API_KEY` - OpenAI API 를 사용할 경우 key 입력

⚙️Text Generation Settings

텍스트 생성 모델을 관리하는 설정들이다.

`GRAPHRAG_LLM_TYPE` - LLM 설정 값으로, OpenAI를 사용한다면 `openai_chat`을, Azure의 AI를 사용한다면 `azure_openai_chat`을 쓴다.
`GRAPHRAG_LLM_API_KEY` - 본인의 OpenAI API key
`GRAPHRAG_LLM_MODEL` - LLM 모델명
`GRAPHRAG_LLM_MODEL_SUPPORTS_JSON` - 해당 모델이 JSON 출력 모드를 지원하는지 여부

⚙️Text Embedding Settings

텍스트 임베딩 모델을 관리하는 설정들이다.

`GRAPHRAG_EMBEDDING_TYPE` - 임베딩 클라이언트 설정, `openai_embedding` 혹은 `azure_openai_embedding`
`GRAPHRAG_EMBEDDING_API_KEY` - 본인의 API key
`GRAPHRAG_EMBEDDING_MODEL` - 임베딩 모델. Default는 `text-embedding-3-small`

⚙️Input Settings

데이터에 대한 설정으로 `text`파일이나 `csv`파일을 넣을 수 있다.

⚙️Plaintext Input Data

`GRAPHRAG_INPUT_FILE_PATTERN` - 입력 파일을 읽을 때 사용할 파일 패턴 정규 표현식, Default 값은 `.*\\.txt$`

⚙️CSV Input Data (`GRAPHRAG_INPUT_FILE_TYPE` = csv)

`GRAPHRAG_INPUT_TYPE` - 입력 파일을 읽을 때 저장되어 있는 형식(`file` 혹은 `bolb`), Default 값은 `file`
`GRAPHRAG_INPUT_FILE_PATTERN` - 입력 파일을 읽을 때 사용할 파일 패턴 정규 표현식, Default 값은 `.*\\.txt$`
`GRAPHRAG_INPUT_TEXT_COLUMN` - CSV 파일을 읽을 때 사용할 `text`
`GRAPHRAG_INPUT_TIMESTAMP_COLUMN` - CSV 파일을 읽을 때 사용할 `timestamp` 열
`GRAPHRAG_INPUT_SOURCE_COLUMN` - CSV 파일을 읽을 때 사용할 `source` 열
`GRAPHRAG_INPUT_TITLE_COLUMN` - CSV 파일을 읽을 때 사용할 `title` 열
`GRAPHRAG_INPUT_DOCUMENT_ATTRIBUTE_COLUMNS` - `document` 필드로 포함할 CSV 열의 목록을 쉼표로 구분하여 작성, Default 값은 `id`

csv 파일에 대한 내용으로 다음과 같이 공식 문서에 적혀있다.

In general, CSV-based data provides the most customizeability. Each CSV should at least contain a text field (which can be mapped with environment variables), but it's helpful if they also have title, timestamp, and source fields. Additional fields can be included as well, which will land as extra fields on the Document table.

내가 이해한대로 해석하자면, CSV 파일 안에는 `title`, `timestamp`, `source`와 같은 필드를 포함해야 하고 추가적인 필드를 포함할 경우에는 `Document` 테이블에 넣어야 한다고 한다. 자세하게는 잘 모르겠지만, CSV 파일로 만들 때, 3개의 필드를 필수는 아니지만 포함해야 하고 나머지 필드는 Document로 처리되는 것 같다.

찾다보니 csv를 사용한 예제가 있다! 아래와 포스팅을 같이 참고해서 진행하면 될 것 같다.

input:
  type: file
  file_type: csv
  base_dir: ../data/csv # the directory containing the CSV files, this is relative to the config file
  file_pattern: '.*[\/](?P<source>[^\/]+)[\/](?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})_(?P<author>[^_]+)_\d+\.csv$' # a regex to match the CSV files
  # An additional file filter which uses the named groups from the file_pattern to further filter the files
  # file_filter:
  #   # source: (source_filter)
  #   year: (2023)
  #   month: (06)
  #   # day: (22)
  source_column: "author" # the column containing the source/author of the data
  text_column: "message" # the column containing the text of the data
  timestamp_column: "date(yyyyMMddHHmmss)" # optional, the column containing the timestamp of the data
  timestamp_format: "%Y%m%d%H%M%S" # optional,  the format of the timestamp
  post_process: # Optional, set of steps to process the data before going into the workflow
    - verb: filter
      args:
        column: "title",
        value: "My document"

input:
  type: file
  file_type: csv
  base_dir: ../data/csv # the directory containing the CSV files, this is relative to the config file
  file_pattern: '.*[\/](?P<source>[^\/]+)[\/](?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})_(?P<author>[^_]+)_\d+\.csv$' # a regex to match the CSV files
  # An additional file filter which uses the named groups from the file_pattern to further filter the files
  # file_filter:
  #   # source: (source_filter)
  #   year: (2023)
  #   month: (06)
  #   # day: (22)
  post_process: # Optional, set of steps to process the data before going into the workflow
    - verb: filter
      args:
        column: "title",
        value: "My document"

3) 아예 모든 것을 커스텀하기: Using JSON or YAML for deeper control

위의 내용을 아예 처음부터 사용자가 커스터마이징 하는 것으로 공식문서의 포스팅을 참고하여 만들기를 바란다. 이 내용은 2번의 내용과 비슷하다고 생각되기 때문에 생략하겠다.

📌 Prompt Tuning

Default 프롬프트는 GraphRAG 시스템을 시작하기에 가장 쉬운 방법이다. 최소한의 설정으로 바로 사용할 수 있게 설계되었다. 기존에 제공하는 프롬프트는 다음과 같다.

1) Auto Templating

Auto Templating은 입력 데이터와 LLM 상호작용을 활용해서 지식 그래프 생성를 생성하여 도메인에 맞는 템플릿을 만든다. Index를 실행할 때, 더 나은 결과를 얻을 수 있기 때문에 강력히 권장된다.

템플릿은 입력 데이터를 로드 → 청크(텍스트 단위)로 분할 → 일련의 LLM 호출 및 템플릿 대체 작업 수행 → 최종 프롬프트를 생성하는 방식으로 만들진다. 스크립트에서 제공하는 기본값을 사용하는 것이 좋지만, 템플릿 생성 알고리즘을 더 탐구하고 조정하고자 하는 경우를 위해 각 세부 사항을 설명한다.

Prerequisites

Automatic template을 실행하기 전에 작업 공간은 `graphrag.index --init` 명령을 통해 초기화하길 바란다. 이 명령은 필요한 옵션 파일과 기존에 제공하는 프롬프트를 생성한다.

Usage

다양한 옵션을 통해 명령을 실행할 수 있다.

python -m graphrag.prompt_tune [--root ROOT] [--domain DOMAIN]  [--method METHOD] [--limit LIMIT] [--language LANGUAGE] [--max-tokens MAX_TOKENS] [--chunk-size CHUNK_SIZE] [--no-entity-types] [--output OUTPUT]

`--config` (필수): 설정 파일의 경로다. 데이터를 로드하고 모델 설정을 불러오기 위해 필요하다.
`--root`: 설정 파일(YML, JSON, 또는 .env)을 포함한 데이터 프로젝트의 루트 디렉터리이다. 기본값은 현재 디렉토리이다.
`--domain`: 입력 데이터와 관련된 도메인이다. 예를 들어 '우주 과학', '미생물학', '환경 뉴스'와 같은 도메인을 지정할 수 있다. 비워두면 도메인은 입력 데이터에서 추론된다.
`--method`: 문서를 선택하는 방법이다. 옵션은 all, random, 또는 top이며, 기본값은 random이다.
`--limit`: random 또는 top 선택 방법을 사용할 때 로드할 텍스트 유닛의 제한 수이다. 기본값은 15다.
`--language`: 입력 처리를 위해 사용할 언어이다. 입력 언어와 다를 경우, LLM이 번역합니다. 기본값은 ""로, 입력에서 자동으로 감지된다.
`--max-tokens`: 프롬프트 생성 시 최대 토큰 수이다. 기본값은 2000이다.
`--chunk-size`: 입력 문서에서 텍스트 유닛을 생성하기 위해 사용할 토큰 크기이다. 기본값은 200이다.
`--no-entity-types`: 타입이 없는 엔티티 추출 생성을 사용한다. 데이터가 다양한 주제를 다루거나 매우 무작위적일 때 사용하는 것을 권장한다.
`--output`: 생성된 프롬프트를 저장할 폴더이다. 기본값은 "prompts"이다.

Example 1

python -m graphrag.prompt_tune --root /path/to/project --config /path/to/settings.yaml --domain "environmental news" --method random --limit 10 --language English --max-tokens 2048 --chunk-size 256 --no-entity-types --output /path/to/output

Example 2 : 최소한의 설정 (권장)

python -m graphrag.prompt_tune --root /path/to/project --config /path/to/settings.yaml --no-entity-types

Document Selection Methods

Auto Template 기능은 입력 데이터를 받아온 후, 이를 청크 크기(chunk size) 파라미터에 따라 텍스트 유닛으로 나눈다. 그런 다음, 템플릿 생성을 위해 샘플을 선택할 때 다음과 같은 선택 방법 중 하나를 사용합니다:

`random` : 텍스트 유닛을 무작위로 선택한다. 기본값이자 추천되는 옵션이다.
`top` : 처음 n개의 텍스트 유닛을 선택한다.
`all` : 모든 텍스트 유닛을 사용하여 템플릿을 생성한다. 작은 데이터셋에만 사용해야 하며, 일반적으로는 추천되지 않는 옵션이다.

2) Manual Configuration

각 프롬프트는 평문으로 작성된 사용자 지정 프롬프트 파일을 작성하여 오버라이드할 수 있다. 토큰 대체는 `{token_name}` 형식으로 사용되며, 사용 가능한 토큰에 대한 설명은 아래에서 확인할 수 있다.

⚙️Entity/Relationship Extraction

`{input_text}` : 처리할 입력 텍스트
`{entity_types}` : 엔티티 유형의 목록
`{tuple_delimiter}` : 튜플 내의 값을 구분하는 구분자. 튜플 하나는 개별 엔티티 또는 관계를 나타낸다.
`{record_delimiter}` : 튜플 인스턴스를 구분하는 구분자
`{completion_delimiter}` : 생성이 완료되었음을 나타내는 표시

Example : entity_extraction.txt

`init`하면 자동으로 생성되는 프롬프트 중 하나이다. (./prompts 디렉토리에서 확인할 수 있다.) 내용을 해석하자면 다음과 같다.

-목표-

주어진 텍스트 문서와 엔티티 유형 목록을 바탕으로 텍스트에서 해당 유형의 모든 엔티티를 식별하고, 식별된 엔티티 간의 모든 관계를 파악합니다.

-단계-

[1] 모든 엔티티를 식별한다. 식별된 엔티티에 대해 다음 정보를 추출한다.

`entity_name` : 엔티티의 이름(대문자로 표기)
`entity_type` : 다음 유형 중 하나 `[{entity_types}]` → settings.yaml에서 확인
`entity_description` : 엔티티의 속성과 활동에 대한 포괄적인 설명

각 엔티티는 다음과 같은 형식으로 표기한다.

`"entity"{tuple_delimiter}<entity_name>{tuple_delimiter}<entity_type>{tuple_delimiter}<entity_description>`

[2] 이전 단계에서 구분된 엔티티들로부터, 서로 명확히 관련된 엔티티 쌍인 `(source_entity, target_entity)`를 찾는다.

관련된 엔티티 쌍 각각에 대해 다음 정보를 추출한다.

`source_entity` : 출발 엔티티 이름, 1단계에서 식별된 대로
`target_entity` : 목표 엔티티 이름, 1단계에서 식별된 대로
`relationship_description` : 출발 엔티티와 목표 엔티티가 관련된 이유에 대한 설명
`relationship_strength` : 출발 엔티티와 목표 엔티티 간의 관계 강도를 나타내는 숫자 점수

각 관계를 다음과 같은 형식으로 표기한다.

`"relationship"{tuple_delimiter}<source_entity>{tuple_delimiter}<target_entity>{tuple_delimiter}<relationship_description>{tuple_delimiter}<relationship_strength>`

[3] 1,2단계에서 식별된 모든 엔티티와 관계를 영어로 단일 목록으로 반환한다. 목록 구분자로는 `{record_delimiter}`를 사용한다.

[4] 작업이 끝나면 `{completion_delimiter}`를 출력한다.

⚙️Summarize Entity/Relationship Descriptions

`{entity_name}` : 엔티티의 이름 또는 source/target 쌍
`{description_list}` : 엔티티 또는 관계에 대한 설명 목록

#######
-Data-
Entities: {entity_name}
Description List: {description_list}
#######
Output:

💭 내가 생각하기에 이전에 `entity_extraction.txt`에서 식별된 모든 엔티티와 관계를 영어로 단일 목록으로 반환한다고 했는데 그 목록에 있는 `entity_name`을 Data로 가져오고 ` entity_description`를 Description List로 가져오는 것 같다.

⚙️Claim Extraction

`{input_text}` : 처리할 입력 텍스트
`{tuple_delimiter}` : 튜플 내 값들을 구분하기 위한 구분자, 각 튜플은 개별 엔티티나 관계를 나타내는데 사용
`{record_delimiter}` : 튜플 인스턴스를 구분하는 구분자
`{completion_delimiter}` : 생성 작업이 완료되었음을 나타내는 표시
`Claim Description` : 클레임 추출에 사용되는 추가적인 파라미터, 기본값은 "Any claims or facts that could be relevant to information dicovery."

Example : claim_extraction.txt

-목표-
텍스트 문서와 엔티티 사양, 클레임 설명이 주어졌을 때, 엔티티 사양에 맞는 모든 엔티티와 그 엔티티에 대한 모든 클레임을 추출한다.

-단계-

[1] 사전 정의된 엔티티 사양에 맞는 모든 명명된 엔티티를 추출한다. 엔티티 사양은 엔티티 이름 목록 또는 엔티티 유형 목록일 수 있습니다.

[2] 이전 단계에서 식별된 각 엔티티에 대해 해당 엔티티와 관련된 모든 클레임을 추출한다. 클레임은 지정된 클레임 설명과 일치해야 하며, 엔티티는 클레임의 주체여야 한다.

각 클레임에 대해 다음 정보를 추출한다:

`Subject`
클레임의 주체가 되는 엔티티의 이름(대문자로 작성). 주체 엔티티는 클레임에서 설명된 행동을 수행한 엔티티다. 주체는 단계 1에서 식별된 명명된 엔티티 중 하나여야 한다.
`Object`
클레임의 객체가 되는 엔티티의 이름(대문자로 작성). 객체 엔티티는 클레임에서 설명된 행동을 보고하거나 처리하거나 영향을 받는 엔티티다. 객체 엔티티가 알려지지 않은 경우 `NONE`을 사용한다.
`Claim Type`
클레임의 전체 카테고리(대문자로 작성). 이 카테고리는 여러 텍스트 입력에서 반복될 수 있는 방식으로 이름을 지정한다. 비슷한 클레임이 동일한 클레임 유형을 공유할 수 있도록 한다.
`Claim Status`
`TRUE`, `FALSE`, 또는 `SUSPECTED`. TRUE는 클레임이 확인된 경우, FALSE는 클레임이 거짓으로 판명된 경우, SUSPECTED는 클레임이 검증되지 않은 경우를 의미한다.
`Claim Description`
클레임의 이유를 자세히 설명하고 관련된 모든 증거와 참조를 포함한다.
`Claim Date`
클레임이 제기된 기간 (`start_date`, `end_date`). start_date와 end_date 모두 ISO-8601 형식으로 작성해야 한다. 클레임이 단일 날짜에 제기된 경우, start_date와 end_date를 동일한 날짜로 설정한다. 날짜가 알려지지 않은 경우 `NONE`을 반환한다.
`Claim Source Text`
클레임과 관련된 원본 텍스트의 모든 인용문 목록입니다.

각 클레임을 다음 형식으로 작성한다:

`<subject_entity>{tuple_delimiter}<object_entity>{tuple_delimiter}<claim_type>{tuple_delimiter}<claim_status>{tuple_delimiter}<claim_start_date>{tuple_delimiter}<claim_end_date>{tuple_delimiter}<claim_description>{tuple_delimiter}<claim_source>`

[3] 영어로 모든 클레임의 목록을 반환한다. `{record_delimiter}`를 목록 구분자로 사용한다.

[4] 작업이 완료되면 `{completion_delimiter}`를 출력한다.

⚙️Generation Community Reports

`{input_text}` : Report를 생성할 때 사용할 입력 텍스트이다. 이 텍스트에는 엔티티와 관계의 테이블이 포함된다.

Example : community_report.txt

-목표-

커뮤니티에 대한 종합 report를 작성한다. 이 report는 커뮤니티에 속한 엔티티 목록과 그들의 관계, 선택적으로 연관된 주장들을 포함한다. Report는 의사 결정자들에게 커뮤니티와 그 구성원들에 대한 정보를 제공하고 그들의 잠재적 영향을 평가하는 데 사용된다. 보고서의 내용에는 커뮤니티의 주요 엔티티, 법적 준수, 기술적 능력, 평판, 주목할 만한 주장들이 포함된다.

-Report 구조-

`TITLE`
커뮤니티의 이름을 나타내는 제목. 제목은 짧지만 구체적이어야 하며, 가능하다면 대표적인 명명된 엔티티를 포함해야 한다.
`SUMMARY`
커뮤니티의 전반적인 구조, 엔티티 간의 관계, 및 엔티티와 관련된 중요한 정보에 대한 총괄 요약이다.
`IMPACT SEVERITY RATING(영향 심각도 평가)`
커뮤니티 내 엔티티가 미치는 영향의 심각도를 나타내는 0-10 사이의 실수 점수다. IMPACT는 커뮤니티의 중요성을 점수로 나타낸 것이다.
`RATING EXPLANATION(평가 설명)`
IMPACT 심각도 평가에 대한 한 문장 설명이다.
`DETAILED FINDINGS(상세 발견 사항)`
커뮤니티에 대한 5-10개의 주요 인사이트 목록이다. 각 인사이트는 짧은 요약과 함께 여러 문단의 설명이 포함되어야 하며, 아래의 Grounding Rules에 따라 근거가 제공되어야 한다.

-Output-

Output은 JSON 포맷으로 다음과 같다.

{{
    "title": <report_title>,
    "summary": <executive_summary>,
    "rating": <impact_severity_rating>,
    "rating_explanation": <rating_explanation>,
    "findings": [
        {{
            "summary":<insight_1_summary>,
            "explanation": <insight_1_explanation>
        }},
        {{
            "summary":<insight_2_summary>,
            "explanation": <insight_2_explanation>
        }}
    ]
}}

-Grounding Rules-

데이터로 지원되는 포인트들은 다음과 같은 데이터 참조 목록을 따라야 한다:

"This is an example sentence supported by multiple data references [Data: <dataset name> (record ids); <dataset name> (record ids)]."

단일 참조에서 5개 이상의 기록 ID를 나열하지 말고, 가장 관련성이 높은 상위 5개의 기록 ID를 나열하고, 추가 데이터가 있다는 것을 나타내기 위해 "+more"를 추가해야 한다.

"Person X is the owner of Company Y and subject to many allegations of wrongdoing [Data: Reports (1), Entities (5, 7); Relationships (23); Claims (7, 2, 34, 64, 46, +more)]."

여기서 1, 5, 7, 23, 2, 34, 46, 64는 관련 데이터 레코드의 ID를 나타낸다. 지원 증거가 제공되지 않은 정보는 포함하지 마라.

1.3 Running the Indexing pipeline

앞에 설명한 모든 내용을 이해하고 나면, GraphRAG의 Indexing Pipeline이 어떻게 동작하는지 알게 됐을 것이다!

이제 파이프라인을 다음 명령어로 실행해보자.

python -m graphrag.index --root ./ragtest

파이프라인이 완료되면, `./ragtest/output/<timestamp>/artifacts`라는 새로운 폴더가 생성되고, 그 안에 일련의 파케이 파일들이 저장될 것이다. 또한, `./ragtest/cache`에 LLM 호출 결과를 캐시한 정보가 담겨있다. 읽기는 다소 복잡하지만, 위에를 잘 읽고 이해했다면 어느정도 눈에 구조가 보이게 될 것이다.

'Knowledge Graph' 카테고리의 다른 글

[MS] GraphRAG 사용하기📊 (5) Indexing Dataflow 이해하기 (0)	2024.09.02
[MS] GraphRAG 사용하기📊 (4) Indexing Architecture 이해하기 (0)	2024.09.01
[논문 리뷰] Domain-specific Knowledge Graphs: A survey (2)	2024.08.21
[MS] GraphRAG 사용하기📊 w. Ollama (2) (0)	2024.08.19
[MS] GraphRAG 사용하기📊 (1) (0)	2024.08.16

낭만적 여름

[MS] GraphRAG 사용하기📊 (3) 공식 문서 이해하기

'Knowledge Graph' 카테고리의 다른 글

티스토리툴바

[MS] GraphRAG 사용하기📊 (3) 공식 문서 이해하기

'Knowledge Graph' 카테고리의 다른 글

관련글

티스토리툴바