RAG 어렵다고요? PDF 하나로 5분 만에 시작하는 법
📺 원본 영상: RAG 어렵다고요? PDF 하나로 5분 만에 시작하는 법 (feat. 공원나연님) 🎙️ 채널: 빌더 조쉬 Builder Josh 📅 정리 일자: 2026-02-23 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 영상은 빌더 조쉬 채널의 호스트가 AI 엔지니어이자 유튜버인 공원나연을 초대하여, RAG(Retrieval-Augmented Generation)와 Graph RAG의 개념, 그래프 데이터베이스(Graph Database), 온톨로지(Ontology), 그리고 LangGraph 프레임워크에 대해 깊이 있는 대화를 나누는 인터뷰 형식의 영상이다. 일반인도 이해할 수 있도록 비유와 시각 자료를 곁들여 설명하며, 마지막에는 Graph RAG를 처음 시작하는 사람들을 위한 실전 가이드와 공원나연의 패스트캠퍼스(FastCampus) 강의 소개까지 이어진다.
게스트 소개: 공원나연
공원나연은 그래프 데이터베이스와 Graph RAG를 전문으로 다루는 AI 엔지니어이자 유튜버다. 처음에는 회사를 다니면서 공부한 내용을 스스로 정리하는 용도로 기술 블로그를 시작했다. 그러다 글보다 영상으로 전달했을 때 더욱 직관적으로 이해할 수 있는 기술 주제들이 있다는 것을 깨닫고 유튜브 채널을 개설하게 되었다고 한다. 현재는 AI 에이전트와 RAG 관련 콘텐츠를 유튜브에 업로드하는 한편, 패스트캠퍼스와 기업·기관 대상 강의를 진행하고 있으며, 프리랜서 AI 엔지니어로서 RAG 시스템과 AI 에이전트 개발 프로젝트도 병행하고 있다.
특히 Graph RAG, 온톨로지, Neo4j 같은 주제는 레퍼런스 자료가 부족하고 개념 자체가 생소하다는 점 때문에, 이를 쉽게 풀어서 전달하는 지식 공유자로서의 역할에 집중하고 있다.
그래프 데이터베이스란 무엇인가?
RDB와의 차이: 관계를 중심으로 저장한다
공원나연은 그래프 데이터베이스(Graph Database)를 한 문장으로 정리하면 “데이터 안의 관계를 중심으로 저장하는 데이터베이스”라고 설명한다. 이를 이해하기 위해서는 우리에게 익숙한 관계형 데이터베이스(RDB, Relational Database)와 비교하는 것이 가장 빠르다.
RDB에서는 데이터를 테이블(Table) 형태로 저장하며, 서로 다른 테이블 간의 관계를 조회할 때는 조인(JOIN) 연산을 사용한다. 예를 들어 “특정 사용자가 어떤 영화에 높은 평점을 부여했는가?”라는 질문에 답하기 위해서는 사용자 테이블과 평점 테이블, 영화 테이블을 여러 차례 조인해야 하며, 이 과정에서 연산 시간과 복잡성이 증가한다.
반면 그래프 데이터베이스에서는 이 관계 자체를 화살표(엣지, Edge)로 표현하여 처음부터 데이터 구조 안에 내재시킨다. “사용자 A가 영화 B를 평가했다”는 관계가 곧바로 노드(Node)와 엣지(Edge)의 형태로 저장되기 때문에, 조인 연산 없이 관계를 따라 탐색하듯 데이터를 조회할 수 있다. 공원나연은 이것이 “사람이 생각하는 과정을 그대로 시각화한 구조”라고 표현했는데, 실제로 “사용자가 높은 평점을 준 액션 영화는?”이라는 질문이 문장 그대로 그래프의 엣지를 따라 탐색하는 경로로 변환된다는 점에서 직관적이다.
💡 [영상 참조] 강연자는 이 시점에서 RDB 테이블 구조와 그래프 데이터베이스 구조를 나란히 비교한 시각 자료를 화면에 표시하며 설명합니다. 상세 내용은 원본 영상을 확인하세요.
RAG(Retrieval-Augmented Generation)란 무엇인가?
LLM의 한계를 극복하는 오픈북 시험
RAG는 단어 자체에 이미 그 정의가 담겨 있다. Retrieval(검색) + Augmented(증강) + Generation(생성)의 합성어로, 말 그대로 답변을 생성하기 전에 관련 정보를 먼저 검색한 다음, 그 검색 결과를 바탕으로 LLM이 답변을 생성하는 방식이다. 공원나연은 이를 “오픈북 시험”에 비유했는데, ChatGPT나 Gemini 같은 LLM이 순수하게 학습된 지식만으로 답변할 때 발생할 수 있는 Hallucination(환각, 즉 잘못된 정보를 사실인 것처럼 답변하는 현상)을 줄이는 데 핵심적인 역할을 한다.
그렇다면 웹 검색과 RAG는 어떻게 다른가? 가장 큰 차이는 “내가 가진 데이터”의 유무다. 웹 검색은 인터넷에 공개된 정보를 대상으로 하지만, 내부 RAG 시스템은 특정 조직이나 개인이 보유한 비공개 문서, 사내 매뉴얼, 업무 데이터베이스 등을 검색 대상으로 삼는다. 공원나연은 이를 “사내 전문가만이 가지고 있는 암묵지(Tacit Knowledge)와 파일들을 언제든지 꺼내서 쓸 수 있게 해주는 시스템”에 비유했다. 이 비유는 RAG의 핵심 가치를 명확하게 보여준다. 단순한 검색 엔진을 넘어, 특정 도메인의 전문 지식을 AI가 실시간으로 참조하며 답변할 수 있게 만드는 것이 RAG의 역할이다.
Graph RAG - 맥락(Context)을 연결하는 검색의 진화
벡터 RAG의 한계: 문맥이 끊어진 청크
기존의 벡터(Vector) 기반 RAG는 문서를 일정한 크기로 잘라낸 텍스트 조각, 즉 청크(Chunk)로 저장한다. 긴 문서를 그대로 저장하기 어렵기 때문에, 의미 단위 혹은 고정 길이로 분할하여 벡터 데이터베이스에 저장하는 방식이다. 검색 시에는 사용자의 질문과 의미적으로 유사한 청크를 찾아 LLM에 전달한다.
그러나 이 방식에는 근본적인 한계가 있다. 문서를 청크로 잘라내는 과정에서 원래의 문맥(Context)과 구조적 연결이 끊어진다는 것이다. 예를 들어 어떤 기술 문서의 본문과 부록이 상호 참조 관계에 있더라도, 벡터 RAG는 질문과 유사도가 높은 청크만 가져올 뿐, 그 청크와 논리적으로 연결된 다른 청크들을 함께 고려하지 못한다.
Graph RAG의 해결책: 청크 간 관계를 그래프로 표현
Graph RAG는 이 문제를 그래프 구조로 해결한다. 각각의 청크를 그래프의 노드(Node)로 표현하고, 청크 간의 의미적·구조적 연결을 엣지(Edge)로 명시적으로 저장한다. “청크 A와 청크 B가 서로 연관되어 있다”는 관계가 데이터베이스 안에 직접 기록되기 때문에, 검색 시 하나의 청크를 찾으면 그와 연결된 청크들도 함께 끌어올 수 있다.
이렇게 되면 LLM은 단순히 하나의 분절된 텍스트 조각만 보는 것이 아니라, 해당 정보의 계층적 맥락, 관련 문서와의 연결 관계, 상위·하위 개념까지 함께 고려하여 답변을 생성할 수 있다. 공원나연은 이를 두고 “훨씬 더 설득력 있는 답변이 가능해지는 Graph RAG의 핵심”이라고 강조했다.
💡 [영상 참조] 강연자는 이 시점에서 벡터 RAG와 Graph RAG의 데이터 구조를 시각적으로 비교한 다이어그램을 화면에 표시합니다. 왼쪽은 분절된 청크들이 나열된 벡터 DB 구조, 오른쪽은 청크 노드들이 엣지로 연결된 그래프 구조를 보여줍니다. 상세 내용은 원본 영상을 확인하세요.
시각화를 통한 설명 가능성(Explainability)
Graph RAG의 또 다른 장점은 답변의 근거를 시각적으로 확인할 수 있다는 점이다. 공원나연이 시연한 데모에서는 “정치 카테고리의 최신 뉴스 알려줘”라는 질문을 입력하면, 그래프 데이터베이스에서 ‘정치’ 카테고리 노드를 중심으로 연결된 기사 노드들이 검색되고, 그 탐색 경로가 우측 패널에 그래프로 시각화되어 표시되었다. 사용자는 LLM이 어떤 기사들을 근거로 답변을 생성했는지 직접 눈으로 확인할 수 있으며, 이는 단순한 성능 향상을 넘어 AI 시스템의 신뢰도를 높이는 중요한 요소다. 각 뉴스 기사 노드에는 실제 기사 내용을 텍스트 청크 단위로 쪼개어 저장한 콘텐츠 노드들이 연결되어 있어, 벡터 기반 의미 검색과 그래프 기반 관계 탐색을 동시에 활용할 수 있는 구조가 된다.
온톨로지(Ontology) - AI에게 구조화된 지식을 전달하는 뼈대
온톨로지란 무엇인가?
온톨로지(Ontology)는 특정 도메인에서 사용하는 개념, 관계, 규칙들을 체계적으로 정의한 명세서(Specification)다. 공원나연은 이를 “업무나 일상에서 암묵적으로 이해하고 있는 언어들이나 매뉴얼 같은 것들을 개념적으로 표현하기 위한 명세서”라고 설명했다. AI가 특정 도메인의 지식을 올바르게 이해하고 추론(Inference)에 활용하기 위한 표준 규칙 체계라고 볼 수 있다.
예시로 소개된 것은 교육 분야의 온톨로지다. 공원나연은 이전에 교육 회사에서 근무하면서 입과서(교육 커리큘럼 문서) 기반의 온톨로지를 자동으로 추출하는 POC(Proof of Concept)를 수행했다. 수학 교육을 예로 들면, “2차 함수를 이해하기 위해서는 방정식의 개념이 선행되어야 한다”는 개념 간의 선후 관계가 그래프로 표현된다. 이 구조가 완성되면 AI는 2차 함수에 취약한 학생에게 단순히 2차 함수 문제만 반복적으로 제공하는 것이 아니라, 선행 개념인 방정식 문제를 함께 추천하는 방식으로 개인화된 학습을 지원할 수 있다.
💡 [영상 참조] 강연자는 이 시점에서 개념 간 선후 관계가 그래프로 표현된 교육 온톨로지의 시각 자료를 화면에 표시합니다. 학생의 취약 개념과 선행 개념이 노드와 엣지로 연결된 형태입니다. 상세 내용은 원본 영상을 확인하세요.
온톨로지가 중요한 이유
온톨로지의 중요성은 Graph RAG를 구현하는 과정에서 더욱 명확해진다. Graph RAG를 구현하기 위해서는 먼저 지식 그래프(Knowledge Graph)가 필요하고, 지식 그래프를 만들기 위해서는 어떤 개념들이 있고 그 사이에 어떤 관계가 존재하는지를 정의하는 그래프 스키마(Graph Schema)를 설계해야 한다. 이 스키마 설계 과정이 곧 온톨로지 설계다.
결국 온톨로지는 특정 도메인의 지식을 그래프로 표현하기 위한 청사진이다. 이 청사진이 없으면 그래프 자체를 올바르게 구성할 수 없고, 잘못 구성된 그래프를 기반으로 한 RAG는 원하는 답변을 생성하지 못한다. 인터뷰에서 빌더 조쉬가 언급한 것처럼, 이는 데이터 분석 도구에서의 택소노미(Taxonomy, 분류 체계) 설계와 유사한 개념이다. 어떤 이벤트가 어떤 페이지, 어떤 행동과 연관되는지를 정의하는 작업처럼, 온톨로지도 도메인 내 개념들의 계층과 관계를 명시적으로 정의하며, 이것이 AI 추론의 핵심 뼈대가 된다.
LangGraph - AI 에이전트의 설계 언어
LangGraph란 무엇인가?
LangGraph는 LLM(Large Language Model) 기반의 에이전트 시스템, 특히 Agentic 워크플로우를 설계하기 위한 Python 프레임워크다. LangChain 생태계의 연장선에 있으며, 복잡한 AI 에이전트의 실행 흐름을 그래프 구조로 표현하고 관리할 수 있도록 설계되었다.
사용자의 질문을 받은 AI 에이전트가 단순히 바로 답변을 생성하는 것이 아니라, “질문 의도 분석 → 관련 정보 검색 → 검색 결과 평가 → 답변 생성”과 같은 여러 단계를 거친다고 생각해보자. LangGraph에서는 이 각각의 작업 단계를 노드(Node)로 정의하고, 노드들이 어떤 순서와 조건으로 실행될지를 그래프의 엣지(Edge)로 표현한다. 이를 통해 복잡한 에이전트의 실행 로직을 선언적이고 시각적으로 설계할 수 있다.
개발자가 Python으로 구현한 LangGraph 에이전트를 실행하고 내부 흐름을 확인할 수 있는 도구로는 LangGraph Studio가 있다. 코드만으로는 파악하기 어려운 에이전트의 상태 변화와 노드 간 전환 과정을 UI로 시각화하여 모니터링할 수 있으며, 비개발자도 에이전트가 어떤 순서로 작업을 수행하는지 직관적으로 파악할 수 있다.
Graph RAG의 실전 활용 사례
제조 분야: 고장 원인 추적과 스마트 팩토리
공원나연이 Graph RAG의 실제 산업 적용 사례로 가장 먼저 언급한 것은 제조(Manufacturing) 분야다. 제조 공정에서는 설비의 고장 이력, 증상, 원인, 해결 방법 등 방대한 데이터가 로그 형태로 쌓인다. 이 데이터를 일반적인 데이터베이스에 저장하면, 엔지니어가 특정 증상의 원인을 찾기 위해 복잡한 쿼리를 작성해야 한다.
그러나 “어떤 설비의 어떤 부위에서 어떤 증상이 발생했고, 그 증상의 원인은 무엇이며, 그 원인에 대한 해결 방법은 무엇인가”라는 관계 연쇄를 그래프로 표현하면, 에이전트가 이 경로를 따라가며 연관 정보를 자동으로 추적하고 종합할 수 있다. 스마트 팩토리(Smart Factory) 환경에서 이러한 지식 그래프 기반의 RAG 시스템은 엔지니어의 의사결정 지원 도구로 점점 더 많이 활용되고 있으며, 다중 에이전트 워크플로우에서 발생하는 로그 이상을 빠르게 특정하는 데에도 강점을 발휘한다.
교육 분야: 개인화 학습 경로 추천
앞서 온톨로지 설명에서 언급된 교육 분야의 사례도 실전 활용의 좋은 예다. 학습자의 성취도 데이터와 개념 간 선행-후행 관계가 지식 그래프로 표현되면, AI는 단순한 반복 학습이 아니라 학습자의 취약한 선행 개념부터 단계적으로 보완하는 개인화된 학습 경로를 추천할 수 있다. 이는 그래프의 관계를 따라 “2차 함수가 부족하다면, 그 선행 개념인 방정식을 먼저 보완하라”는 형태의 연쇄 추론이 자동화되는 것으로, 온톨로지와 Graph RAG가 만나는 지점이다.
좋은 에이전트를 만드는 법: 데이터 품질이 핵심이다
공원나연이 제시하는 좋은 에이전트의 정의는 명확하다. “데이터의 품질을 높이면 에이전트의 답변 품질도 자연스럽게 올라간다.” 이 철학이 그녀가 Graph RAG를 연구하는 근본적인 이유다.
LLM 모델 자체의 성능을 향상시키는 것은 일반 개발자와 엔지니어가 직접 제어하기 어려운 영역이다. 반면 모델에게 전달하는 컨텍스트(Context)의 품질, 즉 “어떤 정보를, 어떤 형태로, 얼마나 풍부하게 제공하느냐”는 설계자가 직접 개선할 수 있는 영역이다. Graph RAG는 바로 이 지점에서 가장 큰 효과를 발휘한다. 벡터 RAG가 질문과 유사한 하나의 청크만 가져온다면, Graph RAG는 그 청크와 연결된 맥락 전체를 구조적으로 함께 가져오기 때문이다.
공원나연은 또한 AI가 올바른 추론을 하기 위해서는 “에이전트가 생각을 잘 하게끔 경로를 잘 닦아주는 것”이 중요하다고 강조했다. 이는 단순히 문서를 벡터 DB에 넣는 것을 넘어, 도메인의 관계 구조를 그래프로 명확히 표현하고, 사용자의 요청 유형에 따라 적합한 검색 전략(벡터 유사도 검색, 그래프 순회 탐색, 하이브리드 검색 등)을 선택하는 에이전트를 설계하는 것을 포함한다.
나아가 그녀는 온톨로지가 중요한 또 다른 이유로 “인간과 AI의 지식 싱크(Sync) 맞추기”를 언급했다. 인간이 암묵적으로 이해하고 있는 도메인 지식을 AI도 동일하게 이해하게 하려면, 그 지식을 명시적인 구조(온톨로지, 지식 그래프)로 표현해주어야 한다. 이것이 완성될 때 비로소 초개인화(Hyper-personalization) 수준의 에이전트, 즉 특정 조직이나 개인의 고유한 지식과 맥락에 기반하여 작동하는 에이전트를 구현할 수 있다.
Graph RAG 시작하기: 실전 가이드
Step 1: 그래프와 친해지기 - arrows.app
공원나연은 Graph RAG를 처음 시작하는 사람들에게 우선 “그래프라는 구조 자체에 친숙해지는 것”을 가장 먼저 권장한다. 이를 위해 추천하는 도구는 Neo4j에서 제공하는 그래프 시각화 도구인 arrows.app이다. 화살표(Arrow, 즉 엣지)를 그리듯이 노드와 관계를 직접 손으로 그려볼 수 있는 웹 기반 도구로, 별도의 개발 환경 없이도 그래프 구조를 직관적으로 설계하고 탐색할 수 있다.
💡 [영상 참조] 강연자는 이 시점에서 arrows.app을 직접 시연하며, “빌더 조쉬”라는 노드를 생성하고 그 노드에서 “채널을 운영하고 있다”는 관계 엣지를 연결하는 과정을 보여줍니다. 상세 내용은 원본 영상을 확인하세요.
활용 방법은 간단하다. 자동화하고 싶은 업무, 관리하고 싶은 데이터, 혹은 머릿속에 있는 아이디어를 그대로 노드와 엣지로 표현해보는 것이다. 마인드맵처럼 생각나는 개념들과 그 관계를 자유롭게 그려보는 과정에서, 자신의 데이터가 어떤 구조를 가져야 하는지 자연스럽게 파악하게 된다. 나아가 arrows.app에서 설계한 그래프 구조는 Cypher 쿼리 언어 형태로 추출할 수도 있어, 비개발자도 그래프 구조 설계에서 실제 데이터베이스 구축까지의 연결을 경험해볼 수 있다.
Step 2: Neo4j GraphRAG 패키지로 PDF를 지식 그래프로 변환하기
실제 Graph RAG 구현을 위해 공원나연이 주로 사용하는 도구는 Neo4j와 Neo4j의 GraphRAG 패키지다. 이 패키지는 Graph RAG의 주요 기능들을 모듈화하여 제공하며, 가장 인상적인 기능 중 하나는 PDF 문서를 자동으로 지식 그래프로 변환하는 기능이다. 문서를 어떻게 그래프로 변환해야 할지 막막한 초보자라면, 이 패키지에 PDF를 입력하는 것만으로도 노드와 엣지로 구성된 지식 그래프가 자동 생성되는 기능부터 시작할 수 있다.
💡 [영상 참조] 강연자는 이 시점에서 몇 줄의 Python 코드로 PDF 파일을 Neo4j 지식 그래프로 변환하는 코드를 화면에 표시합니다. 코드 실행 결과로 PDF의 내용이 노드와 엣지로 구성된 그래프로 자동 변환된 결과가 Neo4j 화면에 표시됩니다. 상세 내용은 원본 영상을 확인하세요.
Step 3: 에이전트 설계와 시나리오 정의
그래프 구조와 지식 그래프가 준비되면, 이를 기반으로 Graph RAG 에이전트를 설계하는 단계로 넘어간다. 이 단계에서는 사용자의 다양한 요청 시나리오를 정의하고, 각 시나리오에 맞는 검색 전략(벡터 유사도 검색, 그래프 순회 탐색, 하이브리드 접근 등)을 선택하며, 최종적으로 LangGraph를 활용해 에이전트의 실행 흐름을 그래프로 설계한다. 공원나연은 이 과정에서 “그래프를 어느 범위까지 가져와서 쓸 것인가”를 결정하는 것이 Graph RAG 에이전트 설계의 핵심이라고 강조했다.
공원나연의 패스트캠퍼스 강의: Graph RAG의 모든 것
공원나연은 최근 패스트캠퍼스(FastCampus)에서 “Graph RAG의 모든 것”이라는 이름의 강의를 런칭했다. 강의는 Neo4j 그래프 데이터베이스의 기초 사용법부터 시작하여, 그래프 데이터 조회를 위한 전용 쿼리 언어인 Cypher(사이퍼)를 처음부터 단계적으로 학습한다. RDB에서 SQL을 사용하듯, 그래프 데이터베이스에서는 Cypher를 사용하여 데이터를 조회하고 조작한다는 점을 이해하는 것이 출발점이다.
이후 원하는 도메인의 데이터를 그래프로 모델링하고 변환하는 실습을 거쳐, 구축된 지식 그래프를 기반으로 Graph RAG 시스템을 실제로 구현해본다. 특히 공원나연이 강조한 것은 평가(Evaluation) 단계의 중요성인데, “RAG를 만들고 끝이 아니라, 원하는 답변이 잘 나오는지 평가하는 과정이 실무에서 매우 중요하다”고 밝혔다. 평가 방법론을 익힌 후, 마지막에는 영상에서 시연된 것과 같은 뉴스 Graph RAG 데모를 수강생이 직접 구현해보는 실습으로 강의가 마무리된다. Graph RAG를 처음 접하는 입문자부터, 벡터 RAG까지는 구현해봤지만 성능 고도화를 원하는 실무자까지 모두를 대상으로 설계된 올인원 강의다. 빌더 조쉬 채널 구독자를 위한 할인 쿠폰이 별도로 제공된다고 하니, 관심 있는 독자는 원본 영상 또는 공원나연 유튜브 채널에서 관련 정보를 확인하기 바란다.
마무리: 인간의 사고 구조를 닮은 AI 시스템
이 인터뷰를 통해 Graph RAG는 단순한 기술적 도구가 아니라, AI가 인간처럼 맥락을 이해하고 근거를 추적하며 추론할 수 있도록 만드는 방법론임을 알 수 있다. 벡터 RAG가 “유사한 정보를 찾는 것”에 집중한다면, Graph RAG는 “연관된 지식 구조 전체를 이해하는 것”을 목표로 한다. 옵시디언(Obsidian)의 그래프 뷰가 노트와 노트 사이의 연결을 직관적으로 보여주듯, Graph RAG도 정보와 정보 사이의 연결을 AI가 활용할 수 있도록 명시적으로 저장하는 것이 핵심이다.
요즘처럼 많은 기업이 범용 SaaS 솔루션보다 자체 AI 시스템을 구축하려는 초개인화(Hyper-personalization) 흐름 속에서, 조직의 암묵지와 도메인 지식을 온톨로지와 지식 그래프로 명시화하고 이를 AI 에이전트와 연결하는 Graph RAG의 가치는 더욱 높아질 것이다. 막막하게 느껴진다면, arrows.app에서 머릿속의 개념들을 그래프로 그려보는 것부터 시작하면 된다. 그것이 Graph RAG 여정의 첫걸음이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | RAG 어렵다고요? PDF 하나로 5분 만에 시작하는 법 (feat. 공원나연님) |
| 채널 | 빌더 조쉬 Builder Josh |
| 게스트 | 공원나연 (유튜버, AI 엔지니어, 패스트캠퍼스 강사) |
| 리포트 작성 | 2026-02-23 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
Related Reports
- Why your agents need decision traces, not just documents — Zach Blumenfeld, Neo4j
- Connecting the Dots with Context Graphs — Stephen Chin, Neo4j
- Thinner Agents on a Smarter Substrate - The Ontology-based Semantic Layer - Emil Eifrem, Neo4j
- CrabRAG - Why Automated Assistants Need Graph Memory, Not More Tokens — Stephen Chin, Neo4j
- RAG가 이렇게 쉬웠다고? File Search API로 RAG 에이전트 한 번에 끝내기!