[3주차, 4주차] 배움과 설계, 문제 해결을 위한 고민들 | OSSCA Ontology based RAG | Graph RAG

Light RAG 리뷰, 그이후

어느정도 Light RAG의 리뷰를 하고나서 이제는 실제 문제를 해결해야하는 주차였습니다.

제가 속한 team 2에서는 아래 2가지 데이터에서 Graph RAG를 하고자 하였습니다.

1. USTR(미국무역대표부) 발언 데이터(2023.01~08)

 

2. 방글라데시 Supplychain(공급망) Ontology(2023.01~08)

이태님께서 구축하신 supply chain 온톨로지

이 데이터를 가지고 "USTR 발언이 Supply chain Data에 미치는 영향"을 분석해보고자 하였고

초기 아키텍처는 이태님께서 그려주신 방향이었지만

Supply chain data의 경우에는 해당 데이터 스키마를 이해해야 쿼리할 수 있는 구조이기 때문에

Document RAG에 최적화된 Light RAG와는 맞지 않는 부분이 있었습니다.

 

 

Q: 왜 Light RAG가 Document RAG에 최적화되어있는가?

Light RAG의 구조 

위 그림처럼 Light RAG는 문서와 같은 텍스트 집합을 벡터, 그래프 방식으로 의미화하는 구조에 최적화되어있기 때문에

supplychain task에는 적절하지 않습니다. 아래는 그 이유가 되는 것들입니다.

 

1. 정형 Ontology 스키마와의 통합 난이도
- 공급망 Ontology는 OWL 기반으로 구축됨.LightRAG는 자연어 중심에서 자동 추출된 엔티티-관계 기반 그래프이기 때문에, 정형 Ontology와의 정렬(alignment) 이 어렵거나 스키마 통합 작업이 추가로 필요할 수 있음.
2. 정밀 추론이 필요한 경우 한계
- 예를 들어, OWL2 규칙 기반 추론, 서브클래스/서브속성 추론 등 형식 논리 기반 추론이 중요한 Ontology 환경에서는 LightRAG는 단순한 탐색 중심이므로 부족함.이런 경우에는 별도의 Ontology Reasoner (e.g., HermiT, FaCT++)이나 Text to Cypher 모듈 과의 연동 필요.
3. 스파클(SPARQL) 등 구조 질의에 최적화된 성능은 아님
- 복잡한 구조 질의를 SQL/SPARQL처럼 정확히 처리해야 한다면, LightRAG보다는 전통적인 KG 기반 시스템이 더 적합할 수 있음

 

따라서, Light RAG는 USTR 데이터를 잘이해하는 USTR 에이전트로 표현하고

Supply(supply chain) agent는 Neo4j cypher query를 통해 공급망의 변화를 가져와야겠다고 생각하는 것이 실제 문제 해결에 더 가까워 지는 방법이라고 생각하였습니다.

 

이러한 생각을 다음과 같이 디스코드로 보내 소통을 하였습니다.

discord에 보냈던 메세지의 일부

Light RAG의 적합한 Task는 무엇인지, 왜 Supply chain Ontology를 검색하기 어려운지를 말하기 위해 위 메세지를 보냈었습니다.

이에 대한 대안은 "Text to Cypher를 처리하는 로직을 별도로 구현해야한다"가 되었습니다.

이후 팀과 의논하여 Light RAG DB 관점에서 문제를 해결하고 기여하는 Task와 전체적인 RAG를 위한 Task 2가지 Task로 쪼개서 진행하기로하였습니다.

저는 Task2에 해당하는 전체적인 RAG 아키텍처를 설계하고 구현하

 

Task 2에서 구현 난이도는

1. 하나의 Cypher 템플릿(+-7일의 데이터 가져오기)

2. 여러개의 Cypher 템플릿(여러가지 시나리오에 대비한 Cypher 템플릿을 마련하고 상황에 맞게 활용)

3. Text to Cypher(LLM 기반 Text to Cypher)

이라고 가정하고 시작하였는데 과연 어떻게 구현했을 지는 다음 포스팅을 살펴주세요!!:D

생각했던 시나리오

시나리오 1. Light RAG에 supplychain ontology를 쿼리하는 새로운 mode를 만들어 Light RAG에 기여

시나리오 2. Light RAG와 별도로 움직이는 Text to Cypher Agent를 만들어 상호작용(채택)

 

크게 시나리오는 아래 2가지로 나뉜다고 생각했습니다. 위 메세지는 시나리오 1을 한다면 어떻게 할 것인지에 대해 생각을 공유했었습니다.

하지만 생각을 해보니 구조 상 Langgraph 기반 Multi-Agent 아키텍처를 구축하는 것이 더 확장성있고 유연한 구조라고 생각하였습니다.

 

다음 5,6 주차에서는 시나리오 2에 대한 구현을 시작하였고 그 결과를 공유할 예정입니다.

3, 4주차 정리

이번 3,4 주차에서는 USTR, Supply chain 각각의 데이터의 특성을 이해하고 그에 알맞는 RAG 기법은 무엇일지 고민해볼 수 있었던 시간이었습니다. 이를 통해 USTR과 같은 Document 형식의 데이터는 Light RAG가, 노드와 관계로 이루어져있는 Supply chain과 같은 Ontology 형식의 데이터는 Graph RAG를 직접적으로 해주는 것이 사용자의 복합적인 질문을 처리할 수 있겠다라는 인사이트를 얻게 되었습니다. 또한 스스로 데이터의 흐름을 생각해보면서 왜 그렇게 결론이 나는지 생각해보고 이를 정리해서 공유해보는 경험은 앞으로 문제를 해결할 때 더 논리적으로 사고하도록 돕는 경험이 되었습니다.

 

5,6 주차에서 뵙겠습니다!