HN 공개: FastGraphRAG – 전통적인 PageRank를 활용한 개선된 RAG 기술

 (github.com/circlemind-ai)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Fast GraphRAG는 해석 가능하고 고정밀인 에이전트 기반 검색 워크플로를 위한 간소화된 GraphRAG 프레임워크로, 복잡한 에이전트 워크플로를 직접 구축하지 않고 고급 RAG를 검색 파이프라인에 붙이는 데 초점을 둠
  • 지식 그래프를 사람이 탐색 가능한 형태로 만들고, 쿼리·시각화·업데이트가 가능하게 하며, 도메인과 온톨로지 요구에 맞춰 그래프를 자동 생성·정제함
  • 쿼리 응답에는 personalized PageRank 기반 그래프 탐색을 사용해 관련 정보를 찾으며, README는 이 접근의 개요로 HippoRAG 논문을 연결함
  • 예시 비용에서 The Wizard of Oz 기준 fast-graphrag는 $0.08, graphrag는 $0.48로 제시되며, 데이터 크기와 삽입 횟수가 늘수록 6배 비용 절감이 더 개선된다고 함
  • Python 3.10.1 이상에서 동작하고, 소스 설치와 PyPI 설치를 지원하며, OpenAI API 키 설정 후 문서 삽입과 질의를 수행하고 같은 작업 디렉터리에서 지식을 자동 유지함

Fast GraphRAG가 제공하는 검색 프레임워크

  • Fast GraphRAG는 해석 가능하고 디버깅 가능한 지식을 목표로 하는 GraphRAG 프레임워크임
  • 그래프는 지식을 사람이 탐색할 수 있는 형태로 제공하며, 다음 작업을 지원함
    • 쿼리
    • 시각화
    • 업데이트
  • 고급 RAG 기능을 제공하면서도 에이전트 워크플로를 직접 구축하고 설계하는 부담을 줄이는 데 초점을 둠

주요 기능

  • 빠르고 저비용으로 대규모 실행이 가능하도록 설계됐으며, 무거운 리소스나 비용 요구를 줄이는 방향을 가짐
  • 동적 데이터를 지원해 도메인과 온톨로지 요구에 맞게 그래프를 자동 생성하고 정제함
  • 데이터가 변할 때 증분 업데이트를 지원해 실시간 업데이트가 가능함
  • PageRank 기반 그래프 탐색을 활용해 정확도와 신뢰성을 높이는 지능형 탐색을 제공함
  • 전체적으로 비동기 방식이며, 완전한 타입 지원을 통해 견고하고 예측 가능한 워크플로를 지향함

비용 예시

  • The Wizard of Oz를 사용한 예시에서 fast-graphrag 비용은 $0.08, graphrag 비용은 $0.48로 제시됨
  • README는 이를 6배 비용 절감으로 설명하며, 데이터 크기와 삽입 횟수가 늘어나면 절감 효과가 더 개선된다고 함

설치와 실행 흐름

  • 권장 설치 방식은 성능을 위한 소스 설치와 안정성을 위한 PyPI 설치로 나뉨
    • 소스 설치: 저장소를 클론한 뒤 poetry install
    • PyPI 설치: pip install fast-graphrag
  • 빠른 시작 예시는 먼저 OPENAI_API_KEY 환경 변수를 설정함
  • A Christmas Carol 텍스트를 내려받은 뒤 Python 코드에서 GraphRAG를 초기화함
  • 예시 초기화에는 다음 값이 포함됨
    • working_dir="./book_example"
    • 이야기의 등장인물, 상호작용, 장소, 관계를 분석하는 domain
    • 예시 질의 목록
    • ["Character", "Animal", "Place", "Object", "Activity", "Event"] 엔티티 타입
  • grag.insert(f.read())로 문서를 삽입하고, grag.query("Who is Scrooge?").response로 질의 결과를 출력함
  • 같은 작업 디렉터리에서 다시 초기화하면 지식이 자동으로 유지됨
  • 로컬 모델 사용 등에서 LLM 동시 처리 작업 수를 제어하려면 CONCURRENT_TASK_LIMIT=8 같은 환경 변수를 선택적으로 설정할 수 있음

예제와 구성 옵션

  • examples 폴더는 라이브러리의 일반적인 사용 사례 튜토리얼을 제공함
  • custom_llm.py는 OpenAI API 호환 언어 모델과 임베더를 다르게 설정하는 간단한 예시임
  • checkpointing.ipynb는 되돌릴 수 없는 데이터 손상을 피하기 위한 체크포인트 사용법을 다룸
  • query_parameters.ipynb는 다양한 쿼리 매개변수를 다루며, with_references=True로 답변에 사용 정보의 참조를 포함하는 방법을 보여줌

설계 철학과 탐색 방식

  • 목표는 성공적인 GenAI 애플리케이션 수를 늘리는 것이며, 이를 위해 LLM 앱이 복잡한 에이전트 워크플로 설정과 유지 없이 특화된 검색 파이프라인을 활용하도록 하는 메모리와 데이터 도구를 만든다고 함
  • Fast GraphRAG는 현재 쿼리에 답하는 데 가장 관련 있는 정보를 찾기 위해 personalized PageRank 알고리듬으로 그래프를 탐색함
  • 이 접근이 작동하는 이유의 개요로 HippoRAG paper를 참고 자료로 제시함

오픈소스와 관리형 서비스

  • 저장소는 MIT License로 제공되며, 자세한 내용은 LICENSE.txt에 있음
  • 빠르고 신뢰성 있게 시작하는 방법으로 관리형 서비스를 제공함
  • 관리형 서비스는 매달 첫 100개 요청이 무료이며, 이후에는 사용량 기반으로 과금됨
  • 관리형 서비스에 대해 더 알아보려면 demo를 예약하거나 docs를 볼 수 있음
  • 기여 안내는 CONTRIBUTING.md에 있으며, 질문은 Discord에서 할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • PageRank 외에도 구조적 데이터에서 RAG에 영향을 줄 수 있는 흥미로운 중심성 지표가 몇 가지 있음
    그중 Triangle Centrality는 노드 주변의 삼각형을 세어 중심성을 계산하는데, 삼각형이 관계를 강하게 닫아 주고 열린 연결은 중심에서 가중치를 빼앗아 중심성을 희석한다는 개념에 기반함
    https://arxiv.org/abs/2105.00110
    논문에서는 PageRank 같은 다른 중심성보다 효율이 높다고 하지만, GraphBLAS를 사용한 연구에서는 18억 간선 규모까지 여러 희소 그래프에서 TC가 우리의 희소 PageRank 구현보다 느렸음
    다만 그래프가 더 커질수록 TC가 더 잘 확장되는 듯하고, 조 단위 간선 영역에서는 더 효율적일 가능성이 큼
    https://fossies.org/linux/SuiteSparse/GraphBLAS/Doc/The_Grap...

    • 여기서는 노드/간선이 수백만 규모라 효율이 큰 문제는 아님
      어차피 답변 생성은 LLM이 파싱하는 부분이 병목이 될 것임
      PageRank가 첫 단계지만 더 정확한 대안도 테스트해 보고 싶음
      여기서는 개인화 PageRank를 쓰고 있어서, 특정 노드 집합에 초기 가중치를 주는데, Triangle Centrality도 이것을 지원하는지 궁금함
      또한 간선 가중치도 보고 있어서 그 부분도 가능한지 알고 싶음
    • PageRank 대체로 Authority Rank를 시도해 봤는지 궁금함
      https://link.springer.com/content/pdf/10.1007/978-3-030-6097...

  • 이 영역에서 꽤 많은 작업을 해 봤고, 몇 가지 배운 점이 있음

    1. 수집 시점에 LLM으로 약간의 작업을 할 수 있다면 BM25 기반 어휘 검색만으로도 매우 관련성 높은 결과가 나옴
    2. 임베딩은 질의 크기가 임베딩 저장소에 넣는 대상과 대략 같은 차수일 때만 잘 작동함
    3. 질의로부터 LLM이 가상 답변을 생성하게 하고, 그 가상 답변으로 임베딩 검색을 하면 매우 잘 작동함
      이 세 가지를 합쳐서 비슷한 지식 분해/추출 단계를 만들었고, 여기에 메타 프롬프터를 붙여 도메인/엔티티 타입을 사실상 자동 생성하게 했음
      LLM은 기본적으로 분해된 지식의 올바른 세분화 수준을 잘 못 잡음
      한 가지 요령은 LLM에게 mermaid.js 마인드맵을 출력하게 해서 입력을 계층적 트리로 나누게 하고, 마지막에 어느 수준이 지식 노드의 적절한 루트인지 말하게 하는 것임
      이후 그 노드 안의 지식으로 답할 수 있는 질문들을 생성하고, 이 질문 텍스트를 색인하고 임베딩도 함
      사용자 질의를 이 질문들과 순수 BM25로 직접 매칭해도 좋은 결과가 나오며, 하이브리드 접근은 더 좋지만 차이가 아주 크지는 않음
      질의 시점에 LLM을 쓰지 않으면 임베딩 유사도를 순회 비용 함수로 삼아 루트에서 더 깊은 노드로 계층적으로 내려갈 수도 있음
    • 예전에 비슷한 트리 구조를 실험했을 때 좋은 결과가 나왔음
      결국 트리의 일반화로서 그래프로 옮기기로 했음
      그래프를 “걷는” 데 임베딩 유사도를 쓰는 개념이 핵심이라고 보고 있으며, FastGraphRAG에도 질의에 따라 간선 가중치를 주는 방식으로 적극 통합 중임
      여러 해법이 비슷한 설계로 수렴하는 것을 보니 흥미로움
    • “수집 시점에 LLM으로 약간의 작업”이 무엇이고 목적이 무엇인지 더 설명해 주면 좋겠음
      질의에서 가상 답변 생성 후 그 답변으로 임베딩 검색하는 아이디어는 흥미롭고, 실험 목록에 추가해 보려 함
    • 질의에서 가상 답변을 만든 뒤 RAG 흐름에 쓰는 방식이 실제로 잘 된다는 얘기를 들으니 반가움
      이제는 말뭉치에 맞춰 미세조정한 LLM으로 가상 답변을 생성하면 더 잘 작동할지도 궁금함
    • BM25 색인에 들어가는 텍스트를 청크로 나누는지 궁금함
      가상 답변을 만들 때도 “청크 크기”에 맞춘 응답을 프롬프트하는지 알고 싶음

  • 더 나은 중심성을 위해 PageRank를 쓰는 건 좋아 보이지만, RAG의 아마도 해결 불가능한 결함, 즉 RAG가 기본적으로 작동하기 어려운 이유는 여전히 해결하지 못함
    모든 RAG DB가 기대보다 낮은 성능을 내는 이유는 RAG가 사용자가 원하는 정보를 찾는 데 필요한 단어 간 관계를 근본적으로 찾지 못하기 때문임
    이상하게 들리겠지만, 원래 “어텐션” 메커니즘이 이런 걸 잘해야 하는 것 아닌가 싶어도 실제로는 충분하지 않음
    예를 들어 어떤 글에서 ‘Sharon’이라는 사람이 여러 물리화학 학회에 참석했다는 내용은 있지만 직업이 명시되지 않았다고 하자
    “Sharon의 직업이 무엇인가?”를 찾으면 거의 모든 RAG 접근은 ‘직업’, 학회 참석, 학회 종류를 연결해 ‘화학자’라고 추론하지 못할 가능성이 큼
    이런 오류는 RAG로 정보를 검색할 때 여러 유형의 정보 전반에 퍼져 있음
    결국 위와 같은 해법은 SQL, PageRank 같은 다른 질의 방법을 더 많은 단계로 재발명하는 것처럼 보이고, 그 지점에서는 벡터화의 의미가 별로 없음

    • 그 추론은 LLM의 역할 아닌가 싶음
      RAG 구성요소는 큰 데이터셋에서 Sharon 관련 글을 찾아 전체를 문맥으로 LLM에 넘기기만 하면 됨
    • 오히려 이런 예시가 바로 이 접근법의 핵심임
      원글에서 인용한 HippoRAG 논문을 보면 동기 예제가 거의 동일하고, 평가도 대체로 이런 종류의 다중 홉 질의응답에 맞춰져 있음
    • 지식 그래프를 쓰면 불가능하지 않아 보임
      Sharon이라는 엔티티를 가져오고, 추가 문맥으로 Sharon과 가까운 노드와 간선을 받으면 됨
      그다음은 LLM의 역할이고, 주어진 문맥에 직업이 없다면 “주어진 문맥에서는 Sharon의 직업을 찾을 수 없습니다”라고 알려야 함

  • 흥미로워서 가입하고 대시보드에 PDF 문서 몇 개를 올려 봤음
    사용 사례는 AI 스타트업에서 제조 관련 컴플라이언스 문서를 분석하는 작업인데, 이게 우리에게 유용하려면 어느 정도 규모까지 동작하고 비용 모델이 어떤지 이해해야 함
    클라이언트당 약 30만 개 PDF가 있고, 매달 문서 집합의 약 10%가 바뀔 것으로 예상함
    어떤 GraphRAG 시스템이든 문서를 대규모로 처리해야 하며, S3를 수집 메커니즘으로 쓸 수는 있지만 다음 시점에 시스템이 사용 가능해지기까지 비용과 처리 시간을 알아야 함

    1. 초기 적재
    2. 정기 업데이트 — 예를 들어 시스템에서 데이터를 어떻게 삭제하는지
    • 도와줄 수 있을 것 같음
      더 자세히 이야기해 보고 싶으니 antonio [at] circlemind.co로 연락해 주면 좋겠음

  • 흥미로운데, 유용한 지식 그래프를 얻으려면 도메인 특화 텍스트 말뭉치가 어느 정도 커야 하는지 궁금함
    Aider는 예전부터 코드 저장소의 호출 그래프에 PageRank를 적용해 왔음
    사소하지 않은 코드는 모두 PageRank를 뒷받침할 그래프 구조가 많아서, 현재 작업과 관련된 프로젝트 내 가장 관련성 높은 문맥을 찾는 데 매우 잘 작동함
    https://aider.chat/docs/repomap.html#optimizing-the-map

    • 짧은 소설부터 수백만 토큰짜리 전체 문서까지 시도해 봤고, 둘 다 흥미로운 그래프를 만드는 듯함
      더 많은 사람이 써 보기 시작하면 피드백을 듣고 싶음
    • Aider는 잘 쓰고 있지만, 코드베이스가 Python이든 JS든 TS든 repo map을 성공적으로 만든 적이 없음
      repo map을 강제로 생성하고 검사할 수 있게 할 계획이 있는지 궁금함

  • 멋짐
    그래프가 어떻게 저장되고 질의되는지 궁금함
    그래프 데이터베이스에는 익숙한데, 의존성으로 보이지는 않음
    추출에는 sciphi triplex 모델을 시도해 봤는지도 궁금함
    예전에 추출을 해 봤을 때 같은 청크를 여러 번 연속으로 추출하면 결과가 일관되지 않았음

    • 그래프는 현재 python-igraph로 저장함
      코드베이스는 가벼운 래퍼를 작성하면 어떤 그래프 DB든 쉽게 통합할 수 있도록 설계되어 있고, 가까운 미래에 neo4j 같은 것들을 지원할 예정임
      triplex는 아직 시도하지 않았는데, gpt4o-mini가 지금은 충분히 빠르고 정확했기 때문임
      엔티티와 관계 추출뿐 아니라 설명 생성과 충돌 해결에도 gpt4o-mini를 쓰고 있음
      미세조정을 하면 결과는 확실히 더 좋아질 것임
      그래프 질의는 주어진 질의와 관련 있는 초기 노드 집합을 찾은 뒤, 그 노드들에서 개인화 PageRank를 실행해 다른 관련 구절을 찾는 방식임
      현재는 전체 질의와 질의에서 추출한 엔티티 모두에 대해 의미 검색으로 초기 노드를 고르지만, 이 방식에 몇 가지 흥미로운 추가 기능도 계획 중임

  • 좋은 아이디어임
    개인적으로 RAG에는 전통적인 정보 검색이 갈 길이라고 봄
    벡터 검색은 좋지만 느리고 비싸며, 사람들이 마법 가루처럼 쓰는 경향이 있음
    비정형 데이터에는 잘 작동하지만 구조적 데이터에는 반드시 그렇게 잘 맞지는 않음
    아주 잘 튜닝하지 않는 한 벡터 검색이 잘 튜닝된 전통적 질의보다 훨씬 나은 것도 아님
    구조적 데이터를 비정형 데이터로 바꾼 뒤 벡터 검색이나 프롬프트 엔지니어링을 하려는 실무를 본 적이 있는데, 전체적으로는 좀 거꾸로 가는 느낌임
    어느 정도 작동은 하지만 같은 결과를 얻는 더 똑똑한 방법이 있을 가능성이 큼
    Graph RAG의 본질은 데이터 구조를 활용하는 것임
    그게 SQL 조인이든 그래프 DB 질의든 크게 중요하지 않음
    LLM에게 질의 방법을 가르치거나 기존 검색/질의 API와 인터페이스하게 하는 데도 가치가 있을 것임
    순위가 좋지 않은 것은 더 큰 문맥 크기로 보완하고, 여러 질의로 수백 개 이상의 결과를 가져오면 됨
    그렇게 확장하는 편이 벡터 검색보다 훨씬 빠르고 저렴할 것임

  • 좋아 보이지만 LangChain 같은 다른 추상화 계층에 데인 적이 있어서 과도한 단순화가 걱정됨
    같은 실수를 반복하지 않으려면 어떻게 할 계획인지 궁금함

  • 검색과 생성에 대한 평가지표 점수가 있는지 궁금함
    예를 들어 KILT나 NQ 데이터셋 같은 것임
    벤치마크 데이터셋이 전부는 아니지만, 어느 정도 괜찮은 점수와 추론 시간을 보여 주면 프레임워크를 설득하거나 엔지니어가 선택하는 데 큰 도움이 될 것임
    프리랜서 자연어 처리 엔지니어로 RAG 파이프라인을 많이 만들어 봤고, 이 작업은 직접 써 볼 예정임

  • 현재 Q&A 챗봇을 만들고 있는데 다음 시나리오를 처리하는 데 어려움을 겪고 있음
    사용자가 “방금 말한 이전 문장에서 무슨 뜻이야?”라고 물을 때, 이 프레임워크는 올바른 작은 하위 집합의 원시 지식을 어떻게 검색하고 LLM에 통합해 관련성 있는 응답을 만들 수 있는지 궁금함
    외부 프레임워크에 의존하지 않고는 이 문제를 해결하기 어려웠음
    https://www.reddit.com/r/LocalLLaMA/comments/1gtzdid/d_optim...
    이 프레임워크가 이 문제를 어떻게 해결하고 과정을 단순화할 수 있는지 알고 싶음

    • 여러 실험 끝에 채팅 스타일 애플리케이션에서 유일하게 잘 된 것은 최근 4~5개 메시지를 넘기고, 가능하면 전체 대화 기록을 넘긴 뒤 LLM에게 대화 문맥 안에서 질문을 요약하게 하는 방식이었음
      이게 없으면 사용자가 “2번 항목을 더 자세히 설명해줘”나 “위 내용의 자세한 예시를 줘” 같은 질문을 할 때 자주 실패했음
      현재 구현은 색인 3개를 두고, 질의와 과거 메시지를 제공한 뒤 LLM에게 다음으로 분해하게 함
      전체 요청, BM25 최적화 질문, 키워드, 의미 검색 최적화 질문
      이후 RAG와 재순위를 수행하고, 상위 N개 구절을 전체 요청과 함께 두 번째 LLM 호출에 넘김
    • 사용자가 그런 질문을 하면 에이전트는 RAG를 호출하지 말고 대화 기록만으로 답해야 함
      오케스트레이션 단계에 집중해야 함
      ReAct 에이전트를 찾아보면 되고, LangGraph나 Bedrock Agents로 만들 수 있음
    • 도구 사용이나 직접 질의를 통해 LLM이 지식 검색 사용 여부를 결정하게 해 봤는지 궁금함
답변달기