주방 가전을 만드는 작은 회사가 사내 문서를 읽고 답하는 AI 챗봇을 들였습니다. 영업팀장이 물었습니다. “부품 공급사 가람전자의 납품이 늦어지면, 우리 고객 중 누구에게 연락해야 하나요?” 챗봇은 가람전자가 적힌 구매 계약서와 지연 안내 메일을 빠짐없이 찾아왔습니다. 그런데 답은 “해당 부품이 들어간 제품의 고객에게 연락하세요”라는 일반론이었고, 고객 이름은 하나도 없었습니다. 이 장면은 설명을 위해 만든 가상의 이야기입니다.
이 글이 던지는 말은 하나입니다. 답이 문서 안에 있으면 RAG가 찾고, 답이 문서 사이에 있으면 검색으로는 못 찾습니다. 그때는 문서 사이의 관계를 따로 적어 두어야 하고, 그것이 지식그래프입니다.
챗봇은 문서를 찾았고, 답은 문서 사이에 있었습니다
RAG(검색 증강 생성, Retrieval-Augmented Generation)는 질문과 닮은 문서 조각을 찾아 읽고 답을 쓰는 방식입니다. 질문에 ‘가람전자’가 있었으니 가람전자가 적힌 문서는 다 찾았습니다. 그런데 고객 이름은 가람전자라는 말이 나오지 않는 두 문서를 이어야 나옵니다.
| 어디에 적혀 있나 | 가람전자가 나오나 | 검색에 걸렸나 | |
|---|---|---|---|
| 가람전자가 모터를 납품한다 | 구매 계약서 | 나온다 | 걸렸다 |
| 그 모터가 믹서기 두 모델에 들어간다 | 제품 부품표 | 안 나온다 | 안 걸렸다 |
| 그 믹서기를 호텔 체인과 온라인몰이 주문했다 | 주문 메일 | 안 나온다 | 안 걸렸다 |
사람 담당자라면 계약서를 보며 “그 모터는 믹서기에 들어가지”를 기억으로 잇고 주문 메일을 열었을 겁니다. RAG는 찾고 읽는 일은 대신하지만, 그 사이를 잇던 기억까지 대신하지는 않습니다.
문서 사이의 답은 관계를 적어 두면 따라갈 수 있습니다
지식그래프는 그 기억을 문서 밖으로 꺼내 ‘무엇이, 어떻게, 무엇에’ 세 칸으로 적어 둔 것입니다.
가람전자 ─ 납품한다 → 모터 M
모터 M ─ 들어간다 → 믹서기 A, 믹서기 B
호텔 체인 ─ 주문했다 → 믹서기 A
온라인몰 ─ 주문했다 → 믹서기 B
이렇게 적혀 있으면 질문은 검색이 아니라 따라가기가 됩니다. 가람전자에서 출발해 화살표를 따라 믹서기에 닿고, ‘주문했다’를 거꾸로 짚으면 고객 둘이 나옵니다.
챗봇에 붙이면 따라가는 일은 AI와 그래프 저장소가 나눠 맡습니다. AI가 질문에서 출발점인 가람전자를 찾아 그래프에 묻는 말로 바꾸고, 그래프 저장소가 선을 따라간 결과인 호텔 체인과 온라인몰을 돌려주면, AI가 그 결과로 답을 씁니다. 그래프에 묻는 말의 문법을 질의 언어라고 하고, 뒤에서 볼 표준이 그 문법을 정해 둔 것입니다.
문서 안의 답이라면 RAG가 더 낫습니다
지식그래프가 RAG의 윗단계는 아닙니다. “지난달 호텔 체인에 납기를 연장해 준 이유가 뭐였죠?”의 답은 회의록 한 문장 안에 있습니다. RAG는 그 문장을 찾아 그대로 인용하고, 그래프는 이유까지 칸으로 적어 두지 않았다면 답하지 못합니다.
| RAG | 지식그래프 | |
|---|---|---|
| 답이 있는 자리 | 문서 안 | 문서 사이 |
| 답하는 방식 | 닮은 조각을 찾아 읽는다 | 관계를 따라간다 |
| 잘하는 질문 | 왜 그렇게 정했나, 규정에 뭐라고 적혔나 | 누구에게 이어지나, 몇 곳인가, 바뀌면 어디까지인가 |
| 만들 때 드는 일 | 문서를 나누고 검색할 수 있게 정리한다 | 무엇을 관계로 둘지 정하고, 자료가 바뀔 때마다 고친다 |
실무에서는 RAG로 시작하고, 사이에 있는 답만 관계로 적습니다
처음부터 회사 지식 전체를 그래프로 만들 필요는 없습니다. 문서는 이미 있으니 RAG가 먼저이고, 그래프는 RAG가 반복해서 틀리는 자리에만 작게 붙입니다.
| 답이 있는 자리 | 쓸 것 | 사람이 볼 것 | |
|---|---|---|---|
| 영업: 공급사가 늦으면 연락할 고객 | 계약서, 부품표, 주문 사이 | 지식그래프 | 연락 순서와 문구 |
| 구매: 부품을 바꾸면 영향받는 제품 | 부품표 여러 장 사이 | 지식그래프 | 대체 승인 |
| 품질: 불량 로트가 나간 출하처 | 생산 기록, 출하 기록 사이 | 지식그래프 | 회수 범위 결정 |
| 고객 응대: 개봉한 제품의 반품 규정 | 반품 규정 한 문서 안 | RAG | 규정에 없는 예외 |
| 경영 지원: 출장비 정산 기준 | 사내 규정 한 문서 안 | RAG | 규정에 없는 경우 |
위 장면이라면 둘을 함께 쓰는 순서는 단순합니다. 그래프로 대상을 먼저 좁히고, 그 대상에 대한 문서는 RAG로 읽습니다. 위 장면이라면 그래프가 호텔 체인과 온라인몰을 찾고, RAG가 두 고객의 계약서에서 납기 조항을 읽어 연락 문구 초안을 씁니다. 연락 순서와 최종 문구는 영업팀장이 정합니다.
관계 칸에는 주인을 정해 둡니다. 부품표가 바뀌면 그래프의 ‘들어간다’ 선도 같이 바뀌어야 합니다. 부품표가 바뀌었는데 그래프가 그대로면, 그래프는 틀린 답을 자신 있게 냅니다. 그래서 갱신을 맡을 부서를 정해 둡니다.
표준은 관계를 적는 법을 이미 정해 두었습니다
세 칸 적기는 개인의 요령이 아닙니다. 웹 표준 기구 W3C의 RDF는 정보를 주어, 술어, 목적어 세 칸짜리 트리플로 적고 그 모음을 그래프라고 부릅니다. 2024년에는 그래프를 만들고 묻고 고치는 질의 언어 GQL이 ISO/IEC 39075로 국제 표준이 되었습니다. 지식관리 표준 ISO 30401은 조직이 지식관리를 관리 체계로 세우고 개선하도록 요구합니다. 다만 공개된 적용 범위 문장은 지식을 문서로 둘지 관계로 둘지까지 적지 않고, 그 빈자리는 앞 장면의 담당자처럼 사람의 기억이 메워 왔습니다. 일하는 쪽이 AI로 바뀌면 그 기억을 관계로 적어 두어야 합니다.
| 사람에게 맡길 때 | AI에게 맡길 때 | |
|---|---|---|
| 문서 찾기 | 폴더와 검색으로 찾는다 | RAG가 대신한다 |
| 문서 사이 잇기 | 담당자가 기억으로 잇는다 | 관계를 적어 두지 않으면 잇기 어렵다 |
마치며: 사이에 있는 답은 검색이 아니라 관계로 고칩니다
답이 문서 사이에 있으면 검색으로는 못 찾습니다. 챗봇이 틀릴 때 검색부터 고치기 전에, 그 답이 문서 안에 있는지 문서 사이에 있는지 보아야 합니다. 문서 안이면 검색을 고치고, 사이에 있으면 관계를 적습니다.
하지 말 것은 하나입니다. 문서 사이에 답이 있는 질문이 틀릴 때 검색 조각 수만 늘리는 것입니다. 더 많이 찾아와도, 이름이 나오지 않는 문서가 걸린다는 보장은 없습니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- ISO 30401:2018 Knowledge management systems, Requirements: https://www.iso.org/standard/68683.html
- W3C, RDF 1.1 Concepts and Abstract Syntax (2014): https://www.w3.org/TR/rdf11-concepts/
- W3C, SPARQL 1.1 Query Language (2013): https://www.w3.org/TR/sparql11-query/
- ISO/IEC 39075:2024 Information technology, Database languages, GQL: https://www.iso.org/standard/76120.html
- Patrick Lewis 외, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020): https://arxiv.org/abs/2005.11401
- Darren Edge 외, From Local to Global: A Graph RAG Approach to Query-Focused Summarization (2024): https://arxiv.org/abs/2404.16130