안녕하세요 여러분 - 배경을 설명하자면, 저는 1인 창업자로서 몇 년 동안 "기업의 두뇌(company brain)"(즉, Drive/SharePoint/내부 문서 전반에 걸쳐 쿼리가 가능하고 동기화 상태를 유지할 수 있는 지식 베이스)의 변형 모델을 연구해 왔습니다. QX Labs에서의 저의 시행착오를 통해 얻은 몇 가지 배움을 공유하고자 합니다. 진지한 시스템을 구축하려면 지식 그래프(Knowledge Graph)가 필요하다는 것이 공통된 의견이지만, 솔직히 말해서 GraphRAG나 Neo4j와 같은 본격적인 그래프 데이터베이스(Graph Database)를 사용하는 것은 대부분의 경우 완전히 과합니다(overkill). 저는 결국 GraphRAG의 이면에 있는 아이디어를 가져와 더 단순하고 저렴한 방식으로 구현한, 더 실용적이고 달성 가능한 솔루션을 구축하게 되었습니다. 비슷한 작업을 하고 계신다면 여러분의 고충을 덜어드릴 수 있기를 바랍니다! 여러분에게는 일반적인 DB(Postgres, MongoDB, 혹은 이미 사용 중인 무엇이든)와 검색 인덱스(Azure AI Search, Elastic, Qdrant - 하이브리드 벡터 + 텍스트 검색을 처리하기 위한 용도)만 있으면 됩니다.

왜 일반적인 RAG를 사용하지 않나요?
Top-k RAG 검색은 "이 특정 사실을 찾아줘"와 같은 쿼리(저는 이를 '바늘(needle)' 질문이라고 부릅니다)를 잘 처리합니다. 하지만 구조적으로 실제 상황에서 정기적으로 발생하는 다른 두 가지 질문 형태를 처리할 수 없습니다:
"X에 대해 모든 것을 말해줘" (엔티티에 대한 전체 문서 세트가 필요하며, 상위 k개의 구절만으로는 부족합니다)
"우리가 평가한 핀테크 기업은 어디인가요?" / "계약서 중 X를 언급하는 것이 몇 개인가요?" (코퍼스 전체에 대한 정확한 목록/개수가 필요하며, k 값을 조정하는 것으로는 해결되지 않습니다)

왜 GraphRAG를 사용하지 않나요?
인덱싱 비용. Microsoft가 GraphRAG를 처음 제안한 곳이지만, 현재는 해당 솔루션 액셀러레이터(solution accelerator)를 아카이브(archive)했습니다. 그들의 연구에 따르면, 벡터-RAG(vector-RAG) 인덱싱 비용은 전체 GraphRAG 인덱싱 비용의 0.1% 미만입니다. 또한 Azure AI Search가 여전히 그래프를 중심으로 구축되지 않았다는 점도 시사하는 바가 큽니다. 연구 문헌(예: "RAG vs GraphRAG", arXiv:2502.11371) 역시 엇갈린 결과를 보여줍니다: 그래프는 멀티 홉(multi-hop)/전역 요약(global summarization)에 도움이 되지만, 일반적인 RAG는 직접적인 조회(direct lookup)에서 승리하며, 이 둘 사이를 라우팅(routing)하는 것이 어느 한 쪽보다 뛰어난 성능을 보입니다. 엔티티 해상도(Entity resolution)는 어렵고 많은 도구가 이를 잘 처리하지 못합니다. 만약 "Acme"와 "ACME Holdings Inc."가 병합되지 않는다면, 그래프는 파편화됩니다.

만약 이들이 잘못 병합된다면, 오류는 이행적(transitively)이고 은밀하게 누적됩니다. 그래프 DB(graph DB)에서는 이러한 실수를 수정하는 데 많은 컴퓨팅 자원이 소모됩니다. 또한 그래프 DB는 테넌트(tenant)별로 실행, 보안, 백업 및 일관성을 유지해야 하는 또 다른 시스템이 됩니다. 대신 제가 구축한 것(일반 DB 내부의 그래프와 유사한 시스템)은 다음과 같습니다: 엔티티(Entities)와 엣지(edges)가 우리가 이미 운영 중인 검색 인덱스(search index) + 문서 DB(document DB) 내의 일반적인 레코드로 존재합니다. 그래프 데이터베이스는 없습니다. 우리는 모두에게 동일한 작은 고정 온톨로지(ontology)를 사용합니다: 조직(organization), 사람(person), 제품(product), 프로젝트(project), 이벤트(event), 위치(location) 등과 레이블 필드(label fields, 산업/카테고리/주제)를 포함합니다. 우리의 경우, 이를 셀프 서비스(self-serve, 즉 사람들이 커스텀 온톨로지를 설정할 필요가 없는 방식)로 만들고자 했기에, 구체성(specificity)을 위해 단순성(simplicity)을 일부 희생하는 것을 기꺼이 수용했습니다. 엔티티 해상도(Entity resolution)는 비용을 최소화하기 위해 폭포수(waterfall) 방식을 따릅니다: 먼저 별칭 테이블(alias table, 과거에 엔티티를 위해 사용된 단어/구절의 모든 변형 - 무료이며 빠름)을 대상으로 조회합니다. 다음으로, 단어/구절을 임베딩(embed)하고 유사도 조회(similarity lookup)를 수행합니다. 마지막으로, 모호한 후보들에 대해서만 저렴한 LLM을 사용하여 판정합니다. 병합(Merges)은 단순히 허브 레코드(hub record)를 가리키는 별칭의 재지정일 뿐이므로, 모든 병합은 쉽게 되돌릴 수 있습니다(우리는 상태를 바로잡기 위해 매일 정리 작업(cleanup job)을 실행합니다). 또한 우리는 과도한 병합(over-merging)을 방지하는 방향으로 편향을 두었습니다. 잘못된 병합은 다운스트림(downstream)을 오염시키지만, 병합 누락은 매일 실행되는 작업이 수정할 때까지 데이터를 파편화할 뿐이기 때문입니다. 우리 시스템의 엣지(Edges)는 노드(nodes) 사이의 실제 엣지가 아니라, 공기(co-occurrence) 횟수(즉, 이 엔티티들이 함께 자주 나타나는 정도)입니다. 이는 각 엔티티 레코드의 Top-N 리스트로 표현됩니다. 이는 타입이 지정된 관계(typed relations)가 아니며, 우리가 의도적으로 선택한 트레이드오프(trade-off)입니다. 엔티티 요약(Entity summaries)은 LazyGraphRAG의 교훈을 그대로 따라 지연(lazy) 방식(첫 요청 시 생성 및 캐싱)으로 처리됩니다. 비용은 코퍼스(corpus) 크기가 아니라 사람들이 무엇을 질문하느냐에 따라 확장됩니다.

에이전트는 다양한 유형의 검색 시나리오를 처리하기 위해 네 가지 도구에 접근할 수 있습니다: 하이브리드 구절 검색 (hybrid passage search, 기본값), resolve (필터가 적용된 'X에 관한 모든 것' 추출), expand (공동 출현 (co-occurrence)을 따른 1-hop 확장), 그리고 facet (검색 엔진의 집계 (aggregations)를 통한 정확한 수치/목록 제공). top-k 방식으로는 절대 답할 수 없는 카운팅 질문들이 결정론적인 facet 쿼리가 됩니다. 일일 통합 (Daily consolidation) 과정은 모든 것을 바로잡으며 (불확실한 병합을 재판정하고, 엣지 (edge)를 정확하게 재계산하며, 삭제된 문서를 제거함), 변경되지 않은 코퍼스 (corpus)에 대해서는 비용이 발생하지 않도록 게이트가 설정되어 있습니다.

외관상 모습: 그래프처럼 보이지만, 내부적으로는 실제 그래프 DB (graph DB)가 없습니다. 우리는 엔티티 (entity) 레코드를 저장하기 위해 MongoDB를 사용할 뿐입니다. 사람들은 이에 거부감을 느낄 수도 있지만, 이는 단순하고 확장 가능하며 이 설정에 놀라울 정도로 잘 맞습니다. [IMG:1]

효과가 있었나요? 우리는 성능을 추적하기 위해 평가 하네스 (evaluation harness)를 구축했습니다 (~1,000개 문서 코퍼스, needle/entity/multipart/aggregation/thematic 클래스 전반에 걸친 등급별 질문 포함 - 시간이 나면 이에 대해 별도로 작성할 예정입니다). Needle 질문은 기존의 vanilla RAG로도 이미 매우 잘 수행되었지만, 다른 모든 질문 클래스들은 이 의사-그래프 (pseudo-graph) 접근 방식과 함께 의미 있게 개선되었습니다.

이 방식의 한계:

• 멀티-홉 경로 추론 (multi-hop path reasoning) 불가. 에이전트가 깊이를 원할 경우 한 번에 한 홉씩 루프를 돌지만, 이는 컨텍스트 (context)를 팽창시킬 수 있습니다. 그래프 DB는 컨텍스트를 폭발시키지 않으면서 여러 홉에 걸친 미약한 연결을 더 안정적으로 찾아낼 수 있습니다.
• 공동 출현 (co-occurrence)은 유형화된 관계 (typed relationships)와 동일하지 않습니다. 우리는 두 엔티티가 함께 나타난다는 것은 알지만, 그 이유는 모릅니다. 일반적인 그래프 DB에서는 예를 들어 WORKS_FOR, INVESTED_IN, CUSTOMER_OF 등을 가질 수 있습니다. 문제는 관계 유형이 사용 사례에 따라 매우 다양할 수 있다는 점입니다.
• 보수적인 병합 (Conservative merging)은 가끔 일시적인 중복을 발생시킵니다.
• 진정한 "전체 코퍼스의 테마를 요약하라"와 같은 글로벌 질문은 제가 의도적으로 구축하지 않은 커뮤니티 탐지 (community-detection) 접근 방식에 의해 여전히 더 잘 처리됩니다.

전체 GraphRAG는 여전히 그 부분에서 더 높은 품질을 제공할 것입니다. 만약 GraphRAG를 성공적으로 구현하셨고 본문의 접근 방식에 동의하지 않으신다면, 의견을 나누고 싶습니다. /u/TheRedfather 제출 [link] [comments]