NVIDIA, LLM 에이전트의 '잘못된 숫자' 막는 오픈소스 온톨로지 공개

많은 분들이 형편없이 쓰인 README를 이해하지 못한 것 같아서 설명을 시도해 보려 한다.

"Auto Ontology"는 좀 안 좋은 이름이다.

문제는 이렇다:

여러분 회사의 데이터가 여러 종류의 데이터베이스에 흩어져 있다. 의사결정을 하는 사람들은 그 데이터에 대해 질문하고 싶어 한다.

예전 방식은 데이터 분석가에게 가서 "이런저런 보고서 좀 만들어 줘"라고 말하면, 분석가가 필요한 정보를 생성하기 위해 적절한 쿼리와 일회성 스크립트를 조합하는 일을 맡았다.

이런 시스템에서는 모든 데이터베이스 모델이 인트로스펙션되어 중앙 메타데이터 카탈로그에 저장되어 있다는 것이 기본 아이디어다.

"5월에 가장 많이 팔린 품목은 무엇이었나?" 같은 질문이 들어오면, 메타데이터 카탈로그가 "Products는 FOO_DB에 저장되어 있고" "Product_Sales는 BAR DB에 저장되어 있다"고 알려주므로, 올바른 위치에서 올바른 데이터를 가져와 필요한 인메모리 계산을 수행하면 된다.

이 시스템이 제공하는 구현 코드는 다음과 같다:

- 각 데이터베이스 인트로스펙션

- 모델 + 메타데이터 정보를 중앙 가상 DB(VDB)에 집계

- 자연어 쿼리로부터 방언별 SQL을 생성하고 해당 테이블이 있는 올바른 DB로 라우팅

- 자연어 쿼리가 여러 데이터 소스를 필요로 할 때 결과를 인메모리에서 결합

- 적절한 권한 처리 등

이를 위한 좋은 시스템은 외부 API 소스(OpenAPI, GraphQL, gRPC 등) 및 문서 소스와도 통합된다 […]

https://github.com/ucbepic/DataAgentBench가 여기서 언급되지 않았다는 게 놀랍다. 여러 소스에서 쿼리해야 하는 데이터 에이전트를 벤치마킹하는 것이 UC 버클리의 일부 연구 초점이다. 리더보드를 보면 다양한 클로즈드 및 오픈소스 구현이 온톨로지를 어떻게 구축하는지 알 수 있다. Nvidia의 접근 방식이 어떻게 비교되는지 보고 싶다.

신뢰할 수 없는 에이전트를 더 많은 신뢰할 수 없는 에이전트를 추가해서 고친다고? LLM이 분석 중인 데이터보다 자신의 가중치에 더 큰 비중을 두는 경향을 해결할 수 없다는 게 안타깝다.

결국 그들은 세상에 대해 학습한 데이터, 지시 사항, 분석 중인 데이터 사이에 명확한 구분이 없다는 문제로 귀결되는 것 같다.

앞에 있는 5가지 사실만 고려하라고 요청할 수는 있지만, 그들은 그렇게 하지 않을 것이고, 할 수도 없다.

이게 왜 OWL/RDF와 SparQL보다 나은지 이해하기 어렵다. 말뭉치에 있는 시맨틱 웹 지식의 폭과 깊이를 고려하면, 그들은 잘 확립된 온톨로지를 발견하고 제시된 데이터로 새로운 온톨로지를 구축하며 sparql로 쿼리하는 일을 놀라울 정도로 잘 해낸다. 사실 내가 본 거의 어떤 것보다 낫다. 여러 해가 지난 후 시맨틱 웹이 실제 용도를 찾을 가능성이 크다는 게 참 아이러니하다. 사실 원래의 용도 말이다.

나는 여전히 내가 만든 더 단순하고 함수형에 가까운 CAVE 언어를 선호한다 [0]

[0] https://mirekrusin.com/cave

LLM과 GOFAI 모두에 지식이 있는 분들께 질문이 있다. 데이터에 맞는 만큼의 상징적 규칙을 작성하되 규칙 집합을 검토 가능하고 유지보수 가능하게 유지하도록 LLM을 사용할 수 없는 이유는 무엇인가?

나는 데이터와 온톨로지로 일하며 경력을 보냈지만 이 README를 이해할 수 없었고, 다이어그램은 오히려 더 혼란스럽게 만들 뿐이었다.