[OSCCA]Ontology based RAG 스터디 1, 2주차 — OT, LightRAG 코드 리뷰와 인사이트

---

안녕하세요 OSCCA 오픈소스 커뮤니티 컨트리뷰션 Ontology based RAG 멘티로 선정되어 활동한 후기로 돌아왔습니다.

약 한 달 동안 감사하게도 Ontology 전문가이신 정이태 멘토님과 온톨로지와 RAG에 진심이신 멘티님들과 활동을 하게 되었습니다.

그저 흘려보내기 아까운 시간이기에 매주 일요일마다 멘티의 시선으로 간단한 기록을 해보고자 합니다.

(멘토님께서 글을 너무 잘 써주셔서 자세한 기록은 아래 링크를 참고해 주세요)

https://www.graphusergroup.com/25-may-1week-graphomakase/?ref=graphomakase-newsletter)

25년 5월 1주차 그래프 오마카세

 

1주차 - OT(4월 19일)

귀여운 굿즈부터 피자챗까지 준비되었던 최고의 오티

 

설레는 마음을 품고 갔던 OT, 더할 나위 없는 멘토님과 Ontology와 RAG에 진심인 분들만 모여있었기에 앞으로의 시간들이 매우 뜻깊은 시간이 될 것 같다는 생각을 했습니다.(신청하길 잘했다)

놀랍게도 이전에 했던 대외활동인 데보션 영 2기를 같이 했던 영 분도 저와 같은 스터디여서 반가웠습니다 ㅎㅎ

잠깐의 시간 동안 피자챗을 했었는데 나눈 이야기들이 되게 재미있었고 정말 다양한 분들이 이 분야에 관심을 가지고 계신다는 생각이 들었습니다.

✨ 주제 소개

Ontology based RAG는 워낙 방대한 주제이다 보니까 각각의 Task에 집중할 수 있게 총 3개의 팀으로 나누어주셨습니다.

 

Team1 (Ontology 만들기)

Team2 (GDBMS에 1의 결과물 적재하고 RAG엔진으로 Light RAG 활용하기)

Team3 (그래프 기획 및 그래프 평가) 

 

모든 팀이 너무나 중요해서 고민이 되었지만 현재는 "Graph RAG를 어떻게 잘할 것인가?"에 좀 더 관심이 많았기에 Team2에 지원하였습니다.

---

 

2주차 - LightRAG 코드 리뷰와 인사이트

구축, 검색, 평가까지 정말 많은 것을 이야기해 주셨지만 우선 저는 Team2(Graph RAG)니까 되도록 Graph RAG에 초점을 맞춰서 기록을 해보도록 하겠습니다.

 

이번 스터디에서는 LightRAG의 구조를 살펴보고, 코드와 이슈를 분석하며,

Ontology 기반 RAG의 방향성과 관련하여 다양한 아이디어를 나누었습니다.

 

스터디가 있기전에 멘토님께서 재료로써 생각해와 달라고 해주신 것을 나름대로 생각을 해보았습니다.

 

말씀 주신 질문들을 생각해보며 더욱더 Graph RAG에 대해 이해하는 시간이 되었습니다.

1️⃣ LightRAG 코드 중 재밌었던 부분

class QueryParam:
    """Configuration parameters for query execution in LightRAG."""

    mode: Literal["local", "global", "hybrid", "naive", "mix", "bypass"] = "global"
    """Specifies the retrieval mode:
    - "local": Focuses on context-dependent information.
    - "global": Utilizes global knowledge.
    - "hybrid": Combines local and global retrieval methods.
    - "naive": Performs a basic search without advanced techniques.
    - "mix": Integrates knowledge graph and vector retrieval.
    """

top_k: int = int(os.getenv("TOP_K", "60"))
"""Number of top items to retrieve. Represents entities in 'local' mode and relationships in 'global' mode."""

 

• base.py에서 다양한 mode를 지원하는 구조가 흥미로웠습니다.
• local 모드일 때는 엔티티 top-k, global 모드일 때는 관계 top-k를 각각 설정한다는 점이 특히 재미있었어요.

 

다른 mode는 이해가 갔는데 저는 hybrid와 mix가 좀 헷갈리더라고요 그래서 알아보았습니다.

💬 의문: Hybrid와 Mix의 차이점

- local(KG/벡터) 중 하나 먼저 검색- 이어서 다른 쪽을 추가 조회- 결과를 조합(combination)

- 벡터와 그래프를 한 번의 파이프라인에서 결합(fusion)- 가중치 기반으로 질의 적합성 최적화

 

🧠 언제 사용하면 좋을까?

• Hybrid: 단계적으로 “텍스트 → KG” 결과를 보고 싶을 때
• Mix: 텍스트와 KG를 동시에 고려해 더 풍부하고 정밀한 답변이 필요할 때

이렇게 우선 이해를 해보았는데 자세한 내용은 직접 코드를 다음주차까지 확인을 해보아야겠습니다.

 

Q: LightRAG에서는 querying 모드가 크게 5가지가 있다고 하는데, 위 그림에서는 mode를 어디에서 판별하고 어떻게 플로우가 달라지는지 이해가 되지 않는다.

라는 질문을 드렸었는데 

https://www.graphusergroup.com/25-may-1week-graphomakase/?ref=graphomakase-newsletter

25년 5월 1주차 그래프 오마카세

멘토님께서 답변까지 위 포스팅에 담아 공유해 주셔서 너무 도움이 되었습니다.

 

 

---

 

2️⃣ LightRAG 이슈 중 재밌었던 부분

 

문제: 다른 도메인의 KG 삽입 시 엔티티 중복 문제

 

LightRAG에 여러 도메인별 커스텀 KG를 삽입할 때,

같은 엔티티가 있으면 source_id가 덮어써져 이전 엔티티의 정보가 사라지는 문제가 생깁니다.

 

 

생각해 본 해결책:

• 기존 노드를 조회해 source_id를 누적 병합
• 각 KG별 file_path를 별도로 관리
• 여러 청크에 동일 엔티티를 연결

기회가 된다면 Light RAG에 기여도 해봐야겠습니다.

---

 

3️⃣ Neo4j에 대한 개인적인 생각(얼마나 알고 있는지)

 

현재 neo4j 상에서 800 여개의 entity와 relationship을 직접 구축해 본 경험이 있음

구축, 검색 측면에서 다양한 시도들은 해보려고 하는 중

앞으로 해보아야 할 것은 대규모의 KG가 구축이 되었을 때

• 효과적으로 검색
• 운용
• 평가
• 비용

에 대한 고민을 해보아야할 때라고 생각하였습니다.

neo4j 같은 GDBMS에 대한 개인적인 생각은 많이 알수록, 창의적인 다양한 시도를 할수록 활용 가능성, 경우의 수가 천차만별로 가능해지는 것으로 보고 앞으로는 개인적으로 Knowledge graph 아키텍처를 어떻게 “디자인”하는지가 중요해질 것이라고 생각되었습니다.

 

---

Light RAG demo

Pydantic AI 공식문서를 넣었을 때 Light RAG demo를 돌린 결과입니다.

 

개인적인 생각으로는 활용한 샘플 데이터셋을 간단히 찾아 Light RAG 검색 결과를 본 후에 문제점을 찾아 남은 시간 동안 개선하고 통합하여 궁극적인 Ontology based RAG 한판을 만들어보아야겠습니다!

 

🧠 마무리

 

이번 스터디를 통해 배운 점:

• 왜 온톨로지를 만들어야 하는가?, 온톨로지를 구축할 때 고려해야 하는 것들
• Graph RAG & Light RAG 에 대하여
• 평가를 할 때 어떤 관점으로 해야하는지

이외에도 너무너무 많지만 우선 3줄 요약..

---

 

✍️ 끝!