그래프를 쓸지 말지를 두 가지로 나눈다. 자료가 원래 짜여 있느냐와, 물음이 관계를 여러 칸 건너야 답이 되느냐다. 온톨로지를 바로잡는 데 전체 시간의 80%가 든다는 자백과, 트리플 추출 정확도를 자료 정제와 로라 파인튜닝으로 71%에서 87%까지 올린 실험이 뼈대다. 그 87%는 문서 백 개 기준이라 문서가 늘면 내려간다고 발표자가 먼저 못 박는다.
한줄 코멘트. 온톨로지를 바로잡는 데 전체 시간의 80%가 든다는 자백이 이 발표에서 제일 정직한 대목이다. 그래프 이야기는 대개 다 짜인 그래프를 놓고 시작하는데, 여기는 그것을 짓는 자리에서 시간이 다 나간다고 말한다. 재 본 값도 있다. 다만 87%는 문서 백 개 기준이고 그 점을 발표자가 먼저 못 박는다.
엔비디아에서 개발자 애드보킷 팀을 이끄는 사람이 발표한다. 그 팀이 하는 일은 여러 쓰임에 맞는 작업 흐름과 노트북을 만들어 깃허브에 내놓는 것이라고 밝힌다. 이 발표는 파트너 한 곳, 그리고 사내 동료들과 함께한 프로젝트를 다룬다. 파트너사 이름은 대지 않는다.
지식그래프를 사람·자리·개념·사건 같은 것들 사이의 관계를 나타내는 그물로 정의한다. 자기를 예로 든다. 자기와 이 행사의 관계는 발표자이고, 자기와 청중의 관계는 이 자리에 들어왔다는 것이다.
벡터로 닮은 것을 찾는 방식보다 나은 까닭을 여기서 댄다. 개체 사이에 무엇이 오갔는지를 훨씬 자세히 붙잡고, 여러 곳에서 온 자료를 한 자리에 엮을 수 있다는 것이다.
지식그래프를 짓는 일의 핵심은 *트리플을 뽑아내는 것이라고 말한다.
트리플 하나가 이렇게 생겼다
예로 든 것은 어느 정유 회사의 분기 실적 문서다. 짜여 있지 않은 글에서 이런 것을 뽑아내는 일이 어렵다는 것을 그 자리에서 인정한다. 그래서 거대언어모델에 시켜 글을 트리플 꼴로 바꿔 쌓는다고 말한다.
무엇을 개체로 보고 무엇을 관계로 볼지 미리 정해 둔 틀이 *온톨로지다. 쓰임에 맞게 이것을 먼저 정하고 프롬프트에 넣어 모델에게 뽑으라고 시킨다.
여기서 이 발표에서 가장 값나가는 한 줄이 나온다. 온톨로지가 틀리면 트리플이 틀리고, 트리플이 지저분하면 찾아오는 것도 지저분해진다. 그래서 이 자리를 바로잡는 데 전체 시간의 80%를 쓰게 될 것이라고 말한다.
한 번 해 두는 일과 그때그때 하는 일
벡터 쪽은 비교적 곧고 이미 많이 다뤄진 자리라고 말한다. 문서를 골라 조각으로 자르고 벡터로 바꿔 쌓으면 된다. 자를 때 조각끼리 겹치는 폭을 두는 까닭도 짚는다. 겹치는 데가 없으면 앞 조각과 뒤 조각 사이의 맥락이 사라진다.
그래프 쪽은 손이 훨씬 많이 간다고 말한다. 다 지은 뒤에 남는 물음이 하나 더 있다. 물어볼 때 관계를 몇 칸이나 건너갈 것인가, 곧 *홉을 얼마나 깊이 잡을 것인가다.
홉을 깊이 잡을 때와 얕게 잡을 때
| 얕게 | 깊게 |
|---|---|
| 한 칸에서 끝난다 | 여러 마디를 건너가며 캔다 |
| 그래프를 쓴 값이 안 난다 | 맥락이 좋아진다 |
| 빠르다 | 찾아오는 시간이 는다 |
프로덕션에서는 이 둘 사이에서 자리를 잡아야 한다고 말한다. 그래프를 도는 일 자체를 빠르게 하려고 팀이 라이브러리를 하나 만들었고, 널리 쓰이는 그래프 라이브러리를 통해 쓸 수 있다고 소개한다. 성능을 재 봤더니 전체 걸리는 시간이 크게 줄었다고 말하는데, 얼마나 줄었는지 수는 대지 않는다.
여기서 80과 20을 다시 든다. 그래프 RAG를 처음 굴러가게 하는 데는 시간의 20%면 되고, 쓸 만하게 다듬는 마지막 20%에 시간의 80%가 든다는 것이다. 파트너와 함께한 실험이 그 마지막 20%에서 나왔다.
먼저 자료를 손질했다. 아포스트로피나 괄호처럼 뜻에 보태지 않는 글자를 걷어냈더니 결과가 나아졌다. 답이 길게 늘어지지 않게 줄인 것도 도움이 됐다고 말한다.
그다음이 파인튜닝이다.
트리플 추출 정확도
| 어떻게 | 정확도 |
|---|---|
| 라마 모델을 그대로 | 71% |
| *로라로 파인튜닝하고 자료를 손질해서 | 87% |
이 값을 대면서 바로 단서를 단다. 문서 백 개로 잰 것이라 높게 보이는 것이고, 문서가 늘면 내려갈 거라는 말이다. 그래도 전보다 나아진 것은 분명하다고 덧붙인다.
무엇으로 재느냐도 짚는다. 신뢰도와 답변 관련성, 정밀도와 재현율, 도움이 되는지, 앞뒤가 맞는지 같은 것을 든다. 도구로는 질의와 찾아오기와 답을 한 줄에 걸쳐 재 주는 라이브러리 하나를 소개하고, 다른 길로는 남의 모델이 낸 답을 다섯 항목으로 채점하도록 훈련한 리워드 모델을 든다.
답을 「경우에 따라 다르다」로 열고 두 가지로 나눈다.
하나는 자료다. 소매나 금융이나 사내 인사 자료처럼 원래 짜임새가 좋은 자료가 그래프에 잘 맞는다. 짜여 있지 않은 자료라도 거기서 쓸 만한 그래프를 뽑아낼 수 있다면 해 볼 만하다고 말한다.
다른 하나는 쓰임이다. 물음에 답하려면 얽힌 관계를 알아내야 하는 경우에만 그래프를 쓰는 뜻이 있다는 것이다.
마지막에 단서를 하나 더 단다. 그래프로 짠 것은 연산을 많이 먹는 시스템이고, 그것을 감당할 수 있는지부터 따져야 한다는 말이다.
87%가 무엇을 맞힌 비율인지 없다. 뽑아낸 트리플이 맞았다고 누가 어떻게 판정했는지, 틀린 쪽은 어떻게 틀렸는지가 나오지 않는다.
파트너사 이름이 없다. 함께 실험한 곳이 어디인지, 그쪽 자료가 무엇이었는지가 없다.
가속 라이브러리 수치가 없다. 걸리는 시간이 크게 줄었다고만 하고 얼마에서 얼마로 줄었는지가 없다. 어느 알고리즘에서 그랬는지도 없다.
평가 도구를 이 프로젝트에 실제로 썼는지 없다. 라이브러리와 리워드 모델을 소개하지만, 71%와 87%를 그것으로 잰 것인지는 밝히지 않는다.
그래프를 짓고 다시 짓는 값이 없다. 연산을 많이 먹는다고만 하고, 문서가 늘 때 다시 짓는 품이 얼마인지가 없다.
자막이 이름과 판을 크게 뭉갠다. 팀이 만든 가속 라이브러리 이름이 엉뚱한 낱말로 들리고, 리워드 모델은 이름이 뭉개진 데다 같은 설명 안에서 크기가 3억 4천만과 3400억으로 갈린다. 파인튜닝한 라마 판도 3.3과 3.2와 3.1로 오간다. 정확한 표기는 원문에서 갈린다.
용어