NASA는 어떻게 Knowledge Graph를 통해 핵심 데이터를 찾아낼까?

편집자 주: 이 프레젠테이션은 David Meza가 다음에서 제공했습니다.그래프커넥트 샌프란시스코2016년 10월. 그가 다룬 내용에 대한 간단한 검토는 다음과 같습니다.

• 지식 아키텍처란 무엇인가?
• 지식 아키텍처의 이점은 무엇입니까?
• 데이터를 지식으로 바꾸는 힘
• NASA가 문서를 Knowledge Graph로 변환한 방법
• 대화형 그래프 시각화
• NASA의 다음 단계는 무엇입니까?
• 귀사는 지식 그래프 아키텍처를 통해 어떤 이점을 얻을 수 있습니까?

–

오늘 우리가 이야기할 것은 지식 아키텍처와 이를 그래프에 사용하는 방법이에요. NASA의특수 저장소:

지식 아키텍처란 무엇인가?

지식 아키텍처는 지식 관리, 정보학 및 데이터 과학의 다양한 분야를 결합하여 "배운 교훈” 데이터베이스를 만들죠. 제가 이 프레젠테이션을 마칠 때쯤에는 지식 아키텍처가 왜 중요한지 이해하고, 이를 조직(관리자, 투자자, 자금 제공자)에 설명할 수 있는 프레임워크를 갖추게 되기를 바라요. 그리고 이것이 조직 내에서 어떻게 구현될 수 있는지도 보여줄 수 있으면 좋겠네요.

1999년 피터 드러커(Peter Drucker)는 “21세기 경영에 있어 가장 중요한 기여는 지식 근로자의 지식 작업 생산성을 높이는 것”이라고 말했어요. 그 이후로 소셜 미디어가 폭발적으로 성장하고 사물 인터넷(IoT)이 발전했으며, 우리는 지속적으로 더 많은 데이터를 사용할 수 있게 되었죠. 이로 인해 지식 근로자의 생산성을 높이는 것이 그 어느 때보다 중요해졌어요. 어떻게 해야 할까요?

 

먼저 조직이 극복해야 할 몇 가지 과제를 살펴볼게요.

NASA에는 약 18~20개의 서로 다른 위치에 총 80,000명의 직원이 근무하고 있으며 1950년대 후반/1960년대 초반부터 데이터를 수집해 왔어요. 이 데이터에는 수억 개의 문서, 보고서, 프로젝트 데이터, 학습한 교훈, 과학 연구, 의료 분석 등이 전국 데이터베이스에 저장되어 있죠. 그리고 이러한 데이터의 양은 다양성, 속도, 양, 가치 및 진실성 측면에서 계속 증가하고 있어요.

하지만 가장 큰 어려움은 부서 간, 그리고 개별 그룹, 제품, 프로그램 내의 사일로 때문에 정보에 접근하기 어렵다는 점이에요. 이런 사일로를 허물어야 하는데, Graph Database가 도움이 될 수 있죠.

데이터에서 지식을 얻는 방법

데이터를 지식으로 바꾸려면 지식 관리, 정보학, 데이터 과학의 융합이 필요해요. 지식 관리는 전략 수립에 사용되고, 정보학은 저장된 위치에서 최종 사용자에게 데이터를 전송하는 애플리케이션으로 스토리지 기능을 만드는 파이프라인을 제공하죠. 그리고 데이터 과학은 해당 데이터를 최종 사용자를 위해 실행 가능한 지식으로 변환할 수 있는 알고리즘과 방법론을 제공해요.

이 세 가지를 결합하면 데이터 기반 시각화라는 결과가 나오는 거죠. 여기서 중요한 건 데이터를 시각화에 억지로 맞추려고 하지 않는 거예요. 데이터가 정보를 시각화하는 방식을 주도하도록 해야 해요.

방금 살펴본 내용을 간략하게 요약한 슬라이드가 여기 있어요.

왜 Knowledge Architecture일까요?

저는 약 5년 전에 조직 내 지식 관리를 조사하는 업무로 NASA에서 처음 일을 시작했어요. 제가 가장 먼저 한 일은 사람들을 인터뷰하고 회의에 참석하는 것이었죠. 분류학자와 IT 개발자 간의 회의에서 우리는 분류학을 통해 검색을 개선하는 방법에 대해 논의했는데, 두 사람은 이전에 여러 번 논의한 적이 있었어요.

분류학자는 메타데이터를 보고 싶어 했지만 개발자는 거부했어요. 그래서 분류학자는 메타데이터에 액세스하면 분류 목적으로 분류법을 검토하는 데 도움이 된다고 설명했고, 개발자는 이미 메타데이터 저장소가 포함되어 있다고 설명했죠.

그들은 둘 다 메타데이터의 정의에는 동의했지만, 실제로는 서로 다른 두 가지에 대해 이야기하고 있었어요. 분류학자는 문서의 메타데이터(제목, 문서를 만든 사람, 문서가 언제 만들어졌는지 등)에 대해 이야기하고 있었고, 개발자는 데이터베이스 자체의 메타데이터에 대해 이야기했던 거죠.

데이터를 지식으로 변환하는 힘

Knowledge Architecture는 실제로 전략, 정보학, 아키텍처 및 데이터 과학을 위한 지식 관리 연락 담당자 역할을 할 수 있는 조직 내 개인 그룹이에요. 이 모든 기능을 통해 조직은 사일로 전반에 걸쳐 동일한 언어로 말하고 정보를 공유하여 회사가 앞으로 나아갈 수 있죠.

이게 왜 중요할까요? Google의 전 CEO인 Eric Schmidt는 "우리에게는 전 세계 모든 사람이 세상의 모든 정보에 접근할 수 있는 기회가 있습니다. 이전에는 불가능했습니다. 유비쿼터스 정보가 왜 그토록 심오한가요? 엄청난 균형 장치입니다. 정보는 힘입니다."라고 말했어요.

저는 의미론을 조금 가지고 놀면서 정보가 힘이 아니라 지식이 힘이라고 말하고 싶어요. 세상의 모든 정보를 가질 수 있지만 이를 실행 가능한 지식으로 변환할 수 없다면 실제로는 아무것도 없는 것과 같죠.

볼테르는 “큰 힘에는 큰 책임이 따른다”고 말했어요. 최종 사용자를 위해 정보를 실행 가능한 지식으로 전달하고, 그들이 다시 돌아올 수 있도록 실제로 사용할 수 있는 무언가를 제공하기 위해 이 힘을 사용해야 해요. 최종 사용자에게 유용하지 않은 애플리케이션을 구축하면 해당 애플리케이션은 금방 사라질 거예요.

엔지니어를 위해 이 애플리케이션을 만든 이유에 대한 이야기를 하나 공유할게요. 저희 젊은 엔지니어들이 가장 먼저 배우는 것 중 하나는 Lessons Learned 데이터베이스로 이동해서 다양한 과거 프로젝트에 대한 정보를 얻는 거예요. 여기에는 해당 프로젝트 중에 발생한 일, 실수나 성공에서 얻은 교훈, 취한 조치 등이 포함되죠. 목표는 과거로부터 배우고, 미래에 동일한 실수를 예방하며, 프로젝트 시간을 줄이는 것이에요.

이 엔지니어 중 한 명은 검색하고 싶은 23개의 핵심 용어를 가지고 있었기 때문에, 당시 유명했던 PageRank 시스템이었던 표준 검색 애플리케이션을 사용해서 2천만 개의 문서 전체에서 이러한 다양한 핵심 용어를 찾았어요. 하지만 Lessons Learned 데이터베이스는 2천만 개의 문서 중 1% 미만으로 구성되어 있었죠. 이는 그가 원하는 것을 찾기 위해 엄청난 양의 정보 목록을 검토해야 했다는 것을 의미했고, 이는 매우 비효율적이었어요.

그는 해결책을 찾기 위해 저에게 왔고, 엔지니어가 핵심 용어를 이에 대해 실행할 수 있도록 IT 부서에서 Lessons Learned Database를 인덱싱하도록 했어요. 며칠 후 IT 부서는 엔지니어가 자신에게 가치 있는 정보가 있는지 확인하기 위해 살펴봐야 했던 수천 개의 문서 목록이 포함된 23개의 탭(각 키워드당 하나씩)이 포함된 Excel 스프레드시트를 가지고 돌아왔죠.

우리는 더 나은 방법이 있어야 한다는 것을 알았어요.

저는 Lessons Learned Database를 살펴보는 것부터 시작했어요. (이 프레젠테이션의 목적을 위해 저는 민감한 데이터를 공유할 수 없기 때문에 공개 데이터베이스인 LLISDB(Lessons Learned Information System)를 사용하고 있어요.)

이 데이터베이스는 현장에 있는 것과 거의 비슷하지만, 날짜와 센터별로만 필터링할 수 있다는 단점이 있었어요. 검색 결과를 CSV 파일로 내보낸 다음 로 가져왔죠. 물론 도움이 되긴 했지만, 계속 검색해야 해서 시간이 꽤 걸렸어요. 그래서 최종 사용자들이 이 정보에 더 쉽게 접근할 수 있는 방법이 필요했답니다.

문서를 Knowledge Graph로 변환

그래서 제가 뭘 했을까요? 문서를 가져와서 그래프로 변환하는 방법을 알아보기 시작했어요.

지금은 두 번째인지 세 번째인지 잘 기억 안 나지만, MongoDB에 학습한 내용을 저장하고, Neo4j 커넥터를 사용해서 자동으로 그래프를 생성하고 있어요.

원래는 CSV 파일에서 메타데이터를 직접 가져와서 문서 데이터베이스로 변환하는 방식으로 시작했었죠. 이렇게 시각화를 하니까 데이터가 훨씬 이해하기 쉬운 방식으로 제공되더라구요. 두뇌가 패턴을 더 쉽게 파악할 수 있게 말이죠.

아래 그래프는 우리 온톨로지를 나타내는데, 패턴이 얼마나 빨리 눈에 띄는지 보여주기 위해 준비했어요.

잠깐 되돌아가 볼까요? 우리는 지식 관리 전략의 일부로 Lessons Learned 데이터베이스를 가지고 있어요. 정보를 수집, 저장, 공유하는 방법에 대한 전략인데, 스토리텔링과 정보 접근 능력의 중요한 부분이죠.

저는 수업에서 모든 텍스트를 가져와서 약 27개의 주제를 반환하는 주제 모델링 알고리즘인 LDA(Latent Dirichlet Allocation)를 통해 실행했어요. 이제 강의에 다시 추가할 수 있는 추가 메타데이터, 즉 주제가 생긴 거죠.

게다가 이러한 유형의 수업과 관련된 메타데이터가 많기 때문에 자체 할당된 카테고리를 기반으로 주제를 연관시킬 수 있었어요. 이제는 주제에 대한 교훈을 얻을 수 있을 뿐만 아니라 주제 간의 상관관계도 파악해서 한 주제가 다른 주제와 어떻게 관련되어 있는지 쉽게 확인할 수 있게 되었죠.

그렇게 하면 다양한 주제와 그 상관관계를 보여주고 이를 데이터베이스에 다시 넣고 열에 추가할 수 있어요. 이를 통해 추세를 살펴볼 수도 있는데, NASA에서 저지르는 실수는 생사의 문제가 될 수 있기 때문에 매우 중요하죠.

다음은 몇 가지 주제 동향 차트입니다. 재료, 열, 초과, 오염 및 온도에 대해 이야기하는 주제 14를 살펴보세요. 이 모든 내용은 셔틀 아래의 열 타일을 나타내고 있어요.

우리는 1990년쯤부터 레슨을 추가하기 시작했고, 2003년쯤에 이 타일 때문에 셔틀 재해가 발생할 때까지 레슨이 오르락내리락했어요. 이런 정보를 미리 갖고 동향을 더 잘 이해했다면, 재난이 발생하는 것을 막을 수 있었을 거예요. 이는 구조화되지 않은 데이터에 데이터 과학을 다시 적용함으로써 얻을 수 있는 매우 강력한 결과 중 하나랍니다.

다음 단계: 대화형 그래프 시각화

R 패키지를 사용하여 수행한 주제를 시각화할 수도 있어요. LDAvis(Latent Dirichlet Allocation visualization):

이는 생성된 다양한 주제와 해당 주제 내의 용어를 모두 보여주는 대화형 데이터 시각화에요. 분석가에게는 정말 도움이 되지만 최종 사용자에게는 별로 도움이 되지 않죠.

우리는 최종 사용자에게 데이터를 보여줄 수 있는 모델을 개발해야 했어요. 다음은 우리가 개발한 간단한 그래프 모델이에요.

이것은 특정 저장소를 참조하는 간단한 그래프 데이터 모델이에요. NASA에는 각각 고유한 관련 데이터 세트가 있는 매우 다양한 그룹이 있기 때문에 이에 중점을 두죠. 특정 센터(녹색 node)에서 제출자(빨간색 node)가 작성한 강의(보라색 node)가 있어요. 이는 특정 카테고리(노란색 node)에 속하며 다른 주제와 상호 연관되어 있고 여러 용어(파란색 node)를 포함하는 주제(주황색 node)에 포함되어 있답니다.

저는 엔지니어들이 신속하게 검색을 수행하고 필요한 정보를 가져올 수 있도록 일을 매우 단순하게 유지하고 싶었어요. 제가 이것을 설정하고 재현하는 방법에 대해 더 자세히 알고 싶으시면 제가 작성한 글을 확인하세요..

데이터 세트를 Neo4j로 가져온 후의 모습은 다음과 같아요.

감사드리고 싶은 분은 니콜 화이트님이에요. 그녀의 비디오를 통해 CSV 파일을 Neo4j로 가져오는 방법에 대해 많은 것을 배웠거든요. 그녀의 많은 작업을 활용해서 CSV 파일에서 해당 데이터 세트를 가져올 수 있었고, 이렇게 빠르고 작은 데이터베이스를 만들 수 있었답니다.

위의 데이터 세트에는 연료 밸브라는 주제가 있고, 카테고리와 관련된 녹색 교훈이 있어요. 이 특정 분야에 대해 JSC에서 많은 교훈이 있었다는 것을 알 수 있죠. 이는 관리 관점에서 이러한 문제를 더 완전하게 조사해야 함을 나타낼 수 있는 몇 가지 패턴을 보여주는 것 같아요.

하지만 이는 우리가 이것으로 할 수 있는 일의 시작일 뿐이에요. 또한 개별 주제 내의 강의를 살펴볼 수도 있답니다.

이런 주제들은 각각 특정 교훈이 있는 특정 카테고리와 연결되어 있어요. 엔지니어로서 저는 시스템이나 하위 시스템의 한 부분에서 다른 부분으로 이동하면서 하위 시스템 간의 연결을 확인할 수 있어야 하죠.

프로젝트 관리자로서 저는 서로 다른 팀원이 있더라도 전체 시스템을 이해해야 해요. 배터리 하위 시스템 담당, 연료 탱크 하위 시스템 담당, 조명 하위 시스템 담당이 있을 수 있지만, 그들은 모두 자신만의 세계에 살고 일반적으로 서로 소통하지 않죠. 관리자는 이 정보를 살펴보고 모든 정보를 종합할 수 있어야 하고요.

그러기 위해서는 최종 사용자에게 유용한 애플리케이션을 개발해야 했어요. 약 3년 전 처음으로 Neo4j를 사용하기 시작했을 때 다양한 그래프 시각화 애플리케이션에 대한 여러 책을 읽기 시작했죠. 이 프로젝트에서 제가 선택한 건 링크리어스였어요.

연료 탱크 수업의 그래프 시각화 데모를 살펴보려면 아래 데모를 시청하세요.

NASA의 다음 단계는 무엇일까요?

우리는 사용자가 데이터베이스에 직접 학습을 입력할 수 있는 기능을 제공할 수 있도록 MongoDB에 적용하는 작업을 진행 중이에요. 또한 텍스트 분석을 실행해서 실제로 유사할 수 있지만 너무 멀리 떨어져 있는 문서를 포착할 수 있는 텍스트 재사용 또는 유사성을 찾을 거예요. 해당 수업의 전체 단락이나 문장뿐만 아니라 감정도 살펴볼 수도 있고요.

우리는 지난 15년 동안 국제 우주 정거장 탐사에 대해 우주비행사들이 남긴 모든 의견을 조사하는 또 다른 프로젝트에 집중하고 있어요. 여기에는 무엇이 옳았는지, 무엇이 잘못되었는지, 무엇을 좋아하고 무엇을 좋아하지 않았는지에 대한 의견이 포함되죠. 우리는 약 90,000개의 댓글에 대한 데이터베이스를 가지고 있는데, 이게 많은 것처럼 들리지는 않지만 개인이 이러한 댓글을 조사해서 추세를 찾는 건 정말 어려웠어요.

우리는 감정 분석부터 시작해서 댓글을 '좋음'과 '나쁨'으로 나누기로 결정했어요. 대부분의 댓글이 좋았다는 사실을 알게 되면 기쁘겠지만, 아마도 우주비행사들의 정치적 올바름 때문일 거예요. 그들은 우주로 돌아가고 싶어하기 때문에 너무 나쁜 말을 하고 싶지 않은 거죠.

하지만 우리는 이 텍스트 전체를 보고 말한 모든 것에서 의미를 찾으려고 노력할 수 있어요. Knowledge Graph 관리 부분을 사용하면 할 수 있죠. 수년간 IT 분야에서 일한 후에 저는 올바른 비즈니스 결정을 내리려면 지식 관리, 정보학, 데이터 과학의 조합이 필요하다는 것을 깨달았어요. 잘못된 의사소통이나 의사소통의 부족은 지식 아키텍처를 통해 피할 수 있는 많은 문제를 일으킬 수 있고요.

여러분의 회사는 Knowledge Graph 아키텍처를 통해 어떤 이점을 얻을 수 있을까요?

Knowledge Graph 아키텍처의 모든 이점을 누릴 수 있다면 회사에서 무엇을 할 수 있을까요?

여러분이 가지고 있는 문서 종류와, 이걸 최종 사용자를 위한 실행 가능한 지식으로 바꾸는 방법을 한번 살펴볼까요? 이렇게 하면 의사 결정을 훨씬 개선할 수 있을 거예요. 물론, 우리는 똑같은 실수를 반복하는 경향이 있으니 과거의 교훈을 잘 활용해야겠죠.

가장 중요한 교훈은, 우리가 교훈을 얻었던 데이터베이스를 다시 실행하는 방법을 계속 찾고 있다는 점이에요. 문제 중 하나는, 문제가 생겼을 때 데이터베이스를 잘 안 본다는 거죠. 그래서 이걸 해결할 더 나은 방법을 찾아야 해요. 하지만 지식 관리에서 중요한 부분은, 이런 노하우를 최종 사용자를 위한 정보로 만들고, 다음 세대에 전달하는 능력이랍니다.

이런 기능들을 활용하면 정보를 훨씬 빠르고 쉽게 얻을 수 있고, 기존 콘텐츠 및 문서 관리 시스템의 범위를 훨씬 넓힐 수 있어요. 게다가 더 심층적인 분석을 하려면 정보 시스템 내에서 메타데이터를 늘려야 해요. 메타데이터가 많을수록 더 좋은 결과를 얻을 수 있거든요.

David의 연설에서 영감을 받으셨나요? 아래 링크를 클릭해서 무료로 Neo4j 배우기 전자책을 읽고, 세계 최고의 Graph Database를 따라잡아 보세요!

• Data Science
• GraphConnect
• Knowledge Architecture
• 잠재 Dirichlet 할당
• MongoDB
• NASA

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지