반응형

데이터에서 얼마나 효과적으로 통찰력을 뽑아내느냐에 따라 기업의 성패가 갈리는 시대가 왔어요. 기존 인프라에서 더 많은 가치를 얻는 방법은 여러 가지가 있죠. 더 많은 데이터를 수집하거나, 더 복잡한 모델을 구축하거나, 아니면 이미 가지고 있는 데이터를 재구성해서 이전에는 보지 못했던 패턴을 찾아낼 수도 있어요. 마지막 방법은 그래프 모델링과 그래프 알고리즘을 활용해서 연결된 데이터 전체에서 영향력, 중심성, 커뮤니티, 그리고 숨겨진 관계를 찾아내는 데 효과적이에요.

중요한 점은, 이렇게 풍부한 통찰력을 얻기 위해 BigQuery 외부에 별도의 인프라를 구축할 필요가 없다는 거예요. 데이터 세트가 커질수록 NetworkX 같은 기존 오픈 소스 도구는 단일 시스템 이상으로 확장하기 어려울 수 있지만, Aura Graph Analytics는 최소한의 운영 부담으로 확장 가능한 그래프 처리를 제공하거든요. 아래 예시에서는 Aura Graph Analytics가 BigQuery 워크플로우에 얼마나 자연스럽게 녹아드는지 보여드릴게요. 데이터를 `쿼리`하고, Pandas DataFrame에 로드하고, Python에서 직접 강력한 그래프 알고리즘을 실행하고, 원한다면 컴퓨팅과 스토리지를 분리하는 익숙한 종량제 환경 내에서 풍부한 결과를 다시 웨어하우스에 저장할 수 있어요.

그래프 분석 + BigQuery

Neo4j는 BigQuery를 포함해서 기업 데이터가 어디에 있든 유연하게 작업할 수 있도록 Aura Graph Analytics를 만들었어요. BigQuery 데이터에 연결하는 방법은 간단해요. 흐름을 한번 살펴볼까요?

먼저 BigQuery에서 SQL `쿼리`를 작성해서 그래프로 모델링하고 싶은 데이터를 추출하고, 결과를 Python 데이터 프레임에 로드해요. 일반적으로 `노드`용 데이터프레임 하나와 `관계`용 데이터프레임(에지 목록)을 각각 만들게 되죠.

다음으로, Aura의 서버리스 인프라에서 세션을 시작하고 그래프를 메모리에 투영해요. 그래프 투영은 그래프 알고리즘 실행을 위해 특별히 최적화된 메모리 내 표현 방식이에요.

일단 투영이 끝나면 Aura의 컴퓨팅 환경에서 알고리즘을 실행할 수 있어요. 오른쪽에 보이는 다이어그램에서는 임베딩 알고리즘을 사용해서 `노드`의 `Vector Embedding`을 생성한 다음, Python 데이터 프레임에 다시 저장하는 과정을 보여주고 있어요.

여기에서 다운스트림 Machine Learning 워크플로우에서 이러한 그래프 기반 기능을 사용하거나, 더 광범위한 분석 및 운영을 위해 BigQuery에 다시 쓸 수도 있죠.

데이터 가져오기

BigQuery 공개 데이터 세트 중 하나의 데이터를 사용해서 관리하기 쉬운 Stack Overflow 댓글의 하위 그래프를 만들어 볼 거예요.

이 `쿼리`는 허브 역할을 할 많은 개별 댓글 작성자가 있는 매우 활동적인 게시물을 선택하는 것으로 시작돼요. 그런 다음 해당 허브(첫 번째 홉)에서 모든 댓글을 수집하고 바깥쪽으로 확장해서 동일한 사용자가 댓글을 남긴 다른 게시물을 캡처하죠(두 번째 홉). 마지막으로 두 번째 홉 게시물에 대한 모든 댓글을 포함시켜요.

이 접근 방식은 데모에서 WCC 또는 PageRank와 같은 그래프 알고리즘을 실행하는 데 이상적인, 컴팩트하고 대부분 연결된 사용자 게시물 하위 그래프를 생성하는 동시에 데이터 볼륨을 작고 작업하기 쉽게 유지해 준답니다.

%%bigquery df
WITH hub_post AS (
  SELECT post_id
  FROM `bigquery-public-data.stackoverflow.comments`
  WHERE user_id IS NOT NULL
  GROUP BY post_id
  ORDER BY COUNT(DISTINCT user_id) DESC
  LIMIT 1
),

-- 2) First hop: all comments on the hub post
h1_comments AS (
  SELECT user_id, post_id
  FROM `bigquery-public-data.stackoverflow.comments`
  WHERE post_id IN (SELECT post_id FROM hub_post)
    AND user_id IS NOT NULL
),

-- 3) Second hop: all other posts commented on by those users
h2_posts AS (
  SELECT DISTINCT c.post_id
  FROM `bigquery-public-data.stackoverflow.comments` c
  JOIN h1_comments h1
    ON c.user_id = h1.user_id
  WHERE c.post_id != h1.post_id
),

-- 4) Bring in all comments on those second-hop posts
h2_comments AS (
  SELECT user_id, post_id
  FROM `bigquery-public-data.stackoverflow.comments`
  WHERE post_id IN (SELECT post_id FROM h2_posts)
    AND user_id IS NOT NULL
)

-- 5) 결정적인 connected slice: hub post + second-hop posts
SELECT user_id, post_id
FROM h1_comments
UNION ALL
SELECT user_id, post_id
FROM h2_comments코드 언어: PHP (php)

결과는 다음과 같이 저장됩니다. df Neo4j Aura Graph Analytics와 함께 사용할 준비가 거의 완료되었어요.

그래프 분석 설정

먼저 패키지를 다운로드해요.

!pip install graphdatascience

그런 다음 필요한 모든 패키지를 가져옵니다.

from graphdatascience.session import DbmsConnectionInfo, AlgorithmCategory, CloudLocation, GdsSessions, AuraAPICredentials
from datetime import timedelta
import pandas as pd
import os
from google.colab import userdata코드 언어: 자바스크립트 (자바스크립트)

이제 Aura 자격 증명을 사용해서 세션을 만들어볼게요. 이걸 하려면 Graph Analytics가 포함된 Aura 계정이 필요해요.

CLIENT_ID = 'your_client_id'
CLIENT_SECRET = 'your_client_secret'
TENANT_ID = 'your_tenent_id'코드 언어: 자바스크립트 (자바스크립트)
from graphdatascience.session import GdsSessions, AuraAPICredentials, AlgorithmCategory, CloudLocation
from datetime import timedelta

sessions = GdsSessions(api_credentials=AuraAPICredentials(CLIENT_ID, CLIENT_SECRET, TENANT_ID))

name = "내-새 세션-SM"
memory = sessions.estimate(
    node_count=20,
    relationship_count=50,
    algorithm_categories=[AlgorithmCategory.CENTRALITY, AlgorithmCategory.NODE_EMBEDDING],
)
cloud_location = CloudLocation(provider="gcp", region="유럽-서부1")

gds = sessions.get_or_create(
    session_name=name,
    memory=memory,
    ttl=timedelta(hours=5),
    cloud_location=cloud_location,
)
코드 언어: 자바스크립트 (자바스크립트)

그 다음엔 데이터를 올바른 형식으로 만들기 위해 약간의 데이터 정리를 해줄 거예요.

# 음수 ID가 있는 행을 삭제합니다.
df = df[(df["사용자_ID"] >= 0) & (df["게시물_ID"] >= 0)]

# Node
users = pd.DataFrame({
    "노드 ID": df["사용자_ID"].dropna().unique(),
})
users["라벨"] = [["사용자"]] * len(users)

posts = pd.DataFrame({
    "노드 ID": df["게시물_ID"].dropna().unique(),
})
posts["라벨"] = [["우편"]] * len(posts)

nodes = pd.concat([users, posts], ignore_index=True)

# Relationship(이분할 에지: 사용자 -> 게시, 방향이 지정되지 않은 WCC의 경우 역)
rels_forward = pd.DataFrame({
    "소스노드 ID": df["사용자_ID"],
    "targetNodeId": df["게시물_ID"],
    "관계 유형": "COMMENTED_ON"
})
rels_reverse = pd.DataFrame({
    "소스노드 ID": df["게시물_ID"],
    "targetNodeId": df["사용자_ID"],
    "관계 유형": "COMMENTED_ON"
})

relationships = pd.concat([rels_forward, rels_reverse], ignore_index=True).drop_duplicates()
코드 언어: PHP (php)

그래프 생성 및 알고리즘 실행

다음으로는 gds.graph.construct 메서드를 사용해서 그래프 투영을 만들어볼게요. 이렇게 하면 알고리즘을 실행하기 위한 인-메모리 그래프가 생성된답니다.

if gds.graph.exists("so_comments_bip")["존재한다"]:
    gds.graph.drop("so_comments_bip")
G = gds.graph.construct("so_comments_bip", nodes, relationships)코드 언어: 자바스크립트 (자바스크립트)

가장 먼저 Weakly Connected Components를 사용해서 모든 컴포넌트가 동일한 커뮤니티에 있는지 확인해볼까요? 만약 그렇다면 다른 Node에서 특정 Node에 도달할 수 있다는 뜻이니까, 그래프가 연결되어 있다는 의미가 되겠죠!

wcc = gds.wcc.stream(G)   # nodeId, componentId, size(버전에 따라 다름) 열이 있는 pandas DataFrame을 반환합니다.코드 언어: PHP (php)

왜냐하면 다들 똑같은 componenetId를 갖고 있으니까, 실제로는 동일한 커뮤니티에 속해 있어서 전체 그래프가 연결되어 있음을 추론할 수 있어요. 그리고 간단한 Python 호출을 통해 지루한 데이터 검증 작업을 수행할 수 있죠.

다음으로 연결된 하위 그래프에서 PageRank를 실행해서 가장 영향력 있는 Node를 식별해요.

PageRank는 연결만 계산하는 게 아니에요. 연결의 품질을 측정해서 토론의 중심에 있는 사용자나 게시물을 강조하죠. 상위 결과를 살펴보면 어떤 Node가 네트워크에서 구조적으로 중요하고 추가 조사에 가장 영향력이 있는지 빠르게 확인할 수 있어요.

재미있는 보너스 퀴즈로 PageRank는 원래 Google을 강화하기 위해 개발되었다는 사실!

# PageRank 실행(결과를 Pandas로 다시 스트리밍)
pr = gds.pageRank.stream(
    G,
    maxIterations=20,
    dampingFactor=0.85
)

# 상위 결과를 정렬하고 검사합니다.
pr_sorted = pr.sort_values("점수", ascending=)
pr_sorted.head(10)코드 언어: PHP (php)

여기에서 강화된 DataFrame을 데이터베이스에 다시 쓰거나, 기능 엔지니어링, 순위 지정 또는 이상 탐지와 같은 작업을 위해 다운스트림 Machine Learning 워크플로에서 직접 사용할 수 있어요. 여기서 본 것은 하나의 예일 뿐이에요. 한번 살펴볼까요? 전체 그래프 알고리즘 제품군은 커뮤니티를 발견하고, 유사성을 감지하고, 영향력을 계산하고, 연결된 데이터에서 더 깊은 통찰력을 얻을 수 있는 임베딩을 생성할 수 있도록 도와줘요.

이 분석에서는 다음을 사용합니다. 스택 오버플로 BigQuery를 통해 사용할 수 있는 데이터 세트입니다. 원본 콘텐츠는 Stack Overflow 커뮤니티에서 제공하며 CC-BY-SA 3.0에 따라 라이선스가 부여됩니다. 블로그의 이 소스에서 생성된 모든 파생 데이터 테이블 또는 하위 그래프에는 동일한 라이선스가 적용됩니다.

  • 그래프 데이터 과학

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

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

반응형
반응형
  • Graph Data Science

오늘 ICIJ는 공개적으로 공개된 데이터, 바로 Paradise Papers로 알려진 해양 산업에 대한 최근 1년간의 조사 결과에요.

ICIJ가 조사를 발표한 이후 지난 몇 주 동안, 우리는 Nike, Apple과 같은 기업의 활동, 영국 여왕의 재산, Wilbur Ross와 같은 정치인, 그리고 Facebook 및 Twitter와 같은 기업에 대한 러시아 투자의 연결을 다루는 많은 보고서가 발표되는 것을 봤어요.

1,300만 개 이상의 유출된 문서, 이메일 및 데이터베이스 기록이 텍스트 분석, 전체 텍스트 및 측면 검색, 그리고 가장 흥미로운 그래프 시각화 및 그래프 기반 검색을 사용하여 분석되었답니다.

국제탐사보도언론인협회(ICIJ)는 를 사용해서 조사를 진행했다고 해요. ICIJ가 웹사이트에서 밝힌 바에 따르면:

Graph Database는 사람과 엔터티 간의 관계를 탐색하는 데 가장 좋은 방법이에요. SQL 데이터베이스나 다른 유형의 NoSQL 데이터베이스보다 훨씬 직관적이죠. 그래프를 사용하면 네트워크를 매우 직관적인 방식으로 이해하고 연결을 쉽게 찾을 수 있어요.

ICIJ는 Paradise Papers 데이터 세트를 검색할 수 있는 Neo4j 기반의 강력한 검색 엔진을 구축했고, 이걸 웹 애플리케이션으로 공개했어요. 데이터를 Neo4j 데이터베이스로 공개하면 훨씬 더 강력한 데이터 분석이 가능해지죠. Neo4j는 오픈 소스 데이터베이스라서 누구나 데이터를 이해하기 위해 동일한 강력한 도구를 사용할 수 있다는 의미랍니다.

이전 게시물에서는 그래프 분석과 Cypher (그래프용 쿼리 언어)를 사용해서 Paradise Papers 데이터에서 연결점을 찾는 방법을 보여드렸어요. 이번 게시물에서는 데이터 시각화를 통해 통찰력을 얻는 방법과 그래프 분석을 사용해서 역외 금융 산업에 대해 자세히 알아볼 수 있는 몇 가지 기술을 Neo4j에서 데이터를 쿼리하고 분석하는 방법을 중심으로 살펴볼게요.

그래프 쿼리

데이터 모델 및 예제 쿼리에 대한 자세한 내용은 이전 게시물 를 참조해주세요.

데이터 모델

Paradise Papers 데이터 세트는 Property Graph 데이터 모델을 사용해서 해외 법인, 해당 법인의 수혜자 또는 주주가 될 수 있는 임원, 법인 설립에 참여한 중개자에 대한 데이터를 나타내고 있어요.

그래프에서 Node는 엔터티를 나타내고, Relationship은 연결을 나타내요. 그리고 Property라는 키-값 쌍을 저장하는데, 이름, 주소, 데이터 출처 속성 등이 Node와 Relationship 모두에 적용된답니다.

그래프 시각화는 데이터를 탐색하는 강력한 방법이에요. 예를 들어, 그래프를 시각적으로 검사해서 고도로 연결된 Node 클러스터를 식별할 수 있죠.

탐색적 쿼리

표 형식 데이터를 쿼리할 때 집계를 수행할 수도 있어요. Paradise Papers 데이터세트의 전체 크기와 모양을 한번 살펴볼까요?

Paradise Papers 데이터세트에는 몇 개의 Node가 있을까요?

MATCH (n) RETURN labels(n) AS labels, COUNT(*) AS count ORDER BY count DESC
╒════════════════╤═══════╕
│"labels"        │"count"│
╞════════════════╪═══════╡
│["Officer"]     │77012  │
├────────────────┼───────┤
│["Address"]     │59228  │
├────────────────┼───────┤
│["Entity"]      │24957  │
├────────────────┼───────┤
│["Intermediary"]│2031   │
├────────────────┼───────┤
│["Other"]       │186    │
└────────────────┴───────┘

데이터는 63,000개 주소에 걸쳐 거의 25,000개의 해외 법인과 연결되어 있는 84,000명 이상의 임원(해외 회사에서 역할을 수행하는 사람 또는 회사)에 대한 정보로 구성되어 있다는 것을 알 수 있어요. 주소는 나중에 위치 데이터를 사용하므로 중요해지죠.

데이터세트에 있는 다양한 유형의 Relationship 수를 셀 수도 있어요.

MATCH ()-[r]->() RETURN type(r), COUNT(*) ORDER BY COUNT(*) DESC
╒════════════════════╤══════════╕
│"type(r)"           │"COUNT(*)"│
╞════════════════════╪══════════╡
│"OFFICER_OF"        │221112    │
├────────────────────┼──────────┤
│"REGISTERED_ADDRESS"│128311    │
├────────────────────┼──────────┤
│"CONNECTED_TO"      │10552     │
├────────────────────┼──────────┤
│"INTERMEDIARY_OF"   │4063      │
├────────────────────┼──────────┤
│"SAME_NAME_AS"      │416       │
├────────────────────┼──────────┤
│"SAME_ID_AS"        │2         │
└────────────────────┴──────────┘

그리고 그래프의 서로 다른 부분이 평균적으로 어떻게 연결되어 있는지에 대한 아이디어를 제공하기 위해 차수 분포를 계산합니다.

MATCH (n) WITH labels(n) AS type, SIZE( (n)--() ) AS degree
RETURN type, MAX(degree) AS max, ROUND(AVG(degree)) AS avg, ROUND(STDEV(degree)) AS stdev
╒════════════════╤═════╤═════╤═══════╕
│"type"          │"max"│"avg"│"stdev"│
╞════════════════╪═════╪═════╪═══════╡
│["Other"]       │2891 │44   │236    │
├────────────────┼─────┼─────┼───────┤
│["Address"]     │9268 │2    │59     │
├────────────────┼─────┼─────┼───────┤
│["Intermediary"]│115  │5    │8      │
├────────────────┼─────┼─────┼───────┤
│["Officer"]     │2726 │4    │20     │
├────────────────┼─────┼─────┼───────┤
│["Entity"]      │312  │11   │13     │
└────────────────┴─────┴─────┴───────┘

영국 여왕에서 렉스 틸러슨까지의 최단 경로

Neo4j와 같은 Graph Database의 강력한 기능 중 하나는 임의 길이의 경로를 쿼리하는 기능이에요. 이를 통해 연결이 무엇인지, 심지어 경로의 길이도 모를 때 `Node` 간의 연결을 찾을 수 있죠.

저는 Paradise Papers 데이터세트에 등장하는 두 공인 사이에 간접적인 연관성이 있는지 궁금했어요. 예멘에서 사업을 운영하는 버뮤다 소재 석유 및 가스 회사와 관련이 있었던 미 국무장관 렉스 틸러슨(Rex Tillerson)과 버뮤다 소재 회사의 투자자인 것으로 보고된 영국 여왕의 재산이죠. `Cypher`를 사용하면 이러한 경로를 쉽게 쿼리할 수 있어요.

MATCH p=shortestPath((rex:Officer)-[*]-(queen:Officer))
WHERE rex.name = "Tillerson - Rex" AND queen.name = "The Duchy of Lancaster"
RETURN p

이것은 영국 여왕과 렉스 틸러슨을 연결하는 단일 최단 경로를 보여줍니다. 경로는 여러 해외 법인과 이들 법인과 연결된 임원을 통과하네요. 모든 최단 경로를 포함하도록 `Query`를 약간 조정하면 경로에 있는 여러 경찰관이 많은 법인과 연결을 공유하는 것을 볼 수 있어요.

MATCH p=allShortestPaths((rex:Officer)-[*]-(queen:Officer))
WHERE rex.name = "Tillerson - Rex" AND queen.name = "The Duchy of Lancaster"
RETURN p

Google을 빠르게 검색해 보면 이들 개인이 기업 서비스 관리자라는 사실이 드러납니다. 즉, 해외 기업의 관리를 처리하기 위해 급여를 받고 해외 기업의 이사 역할을 하는 개인인거죠.

그래프 알고리즘

`Cypher`를 사용하여 데이터를 쿼리하는 것은 그래프를 탐색하고 다음과 같은 질문에 답하는 데 유용해요. “윌버 로스가 연결된 해외 법인은 모두 어디에 있나요?”. 하지만 네트워크에서 가장 영향력 있는 `Node`가 누구인지 알고 싶다면 어떻게 해야 할까요? 아니면 전이적 관련성이 가장 높은 그래프 요소인가요?

`Cypher`를 사용하여 전체 그래프 데이터세트에 대해 PageRank 중심성 알고리즘을 쉽게 실행할 수 있어요.

CALL algo.pageRank(null,null,{write:true,writeProperty:'pagerank_g'})

그런 다음EntityPageRank 점수가 가장 높은 `Node`:

MATCH (e:Entity) WHERE exists(e.pagerank_g)
RETURN e.name AS entity, e.jurisdiction_description AS jurisdiction, 
       e.pagerank_g AS pagerank ORDER BY pagerank DESC LIMIT 15

╒═════════════════════════════════════════════════╤════════════════╤══════════════════╕
│"entity"                                         │"jurisdiction"  │"pagerank"        │
╞═════════════════════════════════════════════════╪════════════════╪══════════════════╡
│"WORLDCARE LIMITED"                              │"Bermuda"       │18.110508499999998│
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"Ferrous Resources Limited"                      │"Isle of Man"   │17.326935999999996│
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"American Contractors Insurance Group Ltd."      │"Bermuda"       │15.6201275        │
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"Gulf Keystone Petroleum Limited"                │"Bermuda"       │12.81925          │
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"Warburg Pincus (Bermuda) Private Equity X, L.P."│"Bermuda"       │12.312412         │
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"Madagascar Oil Limited"                         │"Bermuda"       │11.611646499999999│
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"Coller International Partners IV-D, L.P."       │"Cayman Islands"│11.394854         │
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"Milestone Insurance Co., Ltd."                  │"Bermuda"       │11.224089         │
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"CL Acquisition Holdings Limited"                │"Cayman Islands"│11.0752455        │
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"Alpha and Omega Semiconductor Limited"          │"Bermuda"       │10.965910000000001│
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤
│"Coller International Partners V-A, L.P."        │"Cayman Islands"│10.8205005        │
├─────────────────────────────────────────────────┼────────────────┼──────────────────┤

지역 분석

많은 임원 및 법인의 등록된 주소는 Paradise Papers 데이터에서 확인할 수 있어요. Nominatim API 또는 Google의 지오코딩 API와 같은 서비스를 사용하면 이러한 주소 문자열을 위도 및 경도 지점으로 변환하는 쿼리를 수행할 수 있죠.

이러한 주소를 지오코딩한 후에는 지리적 분석을 사용하여 데이터에 대한 더 많은 통찰력을 찾을 수 있어요. Neo4j에는 Cypher를 사용하여 Neo4j에 쿼리하는 웹 애플리케이션을 쉽게 구축할 수 있는 JavaScript 드라이버가 있답니다.

우리가 사용할 수 있는 시각화 도구 중 하나는 관찰 내용이 색상으로 표시되는 히트맵이에요. 색상이 강할수록 해당 영역에 주소가 더 많다는 의미죠. Paradise Papers 주소의 히트맵을 조사해 보면 북미 해안 바로 옆 대서양에 주소가 집중되어 있음을 알 수 있어요. 이러한 주소 중 다수는 알려진 해외 관할권인 버뮤다에 있고요.

Paradise Papers의 지오코딩 주소 히트맵이에요. 라이브로 해보세요.

이 히트맵을 지오코딩된 주소의 히트맵과 비교하면 파나마 페이퍼스 데이터 세트(ICIJ가 조사한 이전 유출)를 보면 주소의 지리적 분포가 상당히 다르다는 것을 알 수 있어요.

대서양에 큰 집중이 있는 대신 아시아에 더 높은 집중이 있고, 그 정도는 덜하지만 유럽에도 있죠. 파나마 페이퍼스 유출 주소는 싱가포르와 쿠알라룸푸르에 다수 존재한답니다.

파나마 페이퍼의 지오코딩 주소 히트맵

지오코딩된 주소를 사용해서 Paradise Papers를 지도로 대화형으로 탐색할 수도 있어요. 관심 있는 주소 표시를 클릭하면 Cypher `Query`가 실행돼서 해당 주소를 찾고, OfficerEntity `Node`가 이 주소에 연결되어 있다는 것을 알 수 있죠.

라스베가스의 화려한 교외 지역을 탐험하면서 Paradise Papers에 나오는 많은 주소를 볼 수 있는데요. 사실, 카지노 거물인 Sheldon G. Adelson을 쉽게 발견할 수 있어요. 그는 버뮤다 회사와 관련이 있는 것으로 밝혀졌는데, 카지노의 개인 제트기를 등록해서 수천만 달러를 면세 관할권으로 이체하는 데 사용했다고 해요.

등록된 주소를 표시하는 Paradise Papers의 지리 코드 주소에 대한 주석이 달린 지도. Officer `Node`와 연결된 법인 및 관할권. 직접 확인해보세요!

법인 관할권

역외 금융 산업 구조가 시사하는 바를 살펴볼 때, 탐사보도 기자들이 답하려는 질문 중 하나는 "조력자는 누구인가?"인데요. 조력자를 찾는 한 가지 방법은 해양 산업을 가능하게 하는 관할권을 살펴보는 것이죠.

특정 국가의 시민을 위해 일부 관할권이 선택되는 역사적, 법적, 경제적 이유에 대해 생각해 볼 수 있지만, 이 세계의 대부분은 매우 비밀스럽기 때문에 Paradise Papers와 같은 데이터는 역외 금융 산업에 대한 통찰력을 얻는 데 매우 중요해요. 다음으로, 데이터에 포함된 관할권 정보 중 일부를 조사해볼게요.

MATCH (e:Entity)
WITH e.jurisdiction_description AS juris, COUNT(*) AS count
WHERE count > 20
RETURN *
ORDER BY count ASC

버뮤다와 케이맨 제도의 수가 다른 관할권보다 훨씬 많다는 것을 알 수 있죠. 이는 버뮤다(및 기타 여러 국가)에 사무실이 있는 법률 회사인 데이터의 주요 소스에 대해 우리가 알고 있는 내용을 고려하면 당연한 결과일 거예요.

분석을 확장해서 "특정 국가의 시민들이 선호하는 특정 관할권이 있을까?"라는 질문에 답할 수 있어요. 또는 "수혜자 또는 담당자의 거주 국가별로 가장 인기 있는 역외 관할권은 무엇일까?"와 같은 질문도요. 다음의 이분 그래프를 작성해서 Officer 국가 및 법인 관할권에 대한 답변을 살펴볼 수 있어요. 이 데이터를 이분 그래프를 통해 흐름의 상대적 분포를 보여주는 현 다이어그램으로 시각화할 수 있죠.

MATCH (a:Address)--(o:Officer)--(e:Entity)
WITH a.countries AS officer_country, e.jurisdiction_description AS juris,
COUNT(*) AS num
RETURN * ORDER BY num DESC

이 도표는 미국이 단연코 가장 인기 있는 국가임을 보여주는데요. Officer 등록된 주소로 제공되죠. 그리고 미국에 주소를 둔 경찰관 중에서 버뮤다와 케이먼 제도가 가장 인기 있는 역외 관할권이에요. 이전에 이 두 관할권이 데이터 세트에서 가장 인기가 있다는 것을 보았듯이 놀라운 일은 아니죠.

무엇을 찾을 수 있나요?

이것은 ICIJ가 공개한 현재 공개된 Paradise Papers 데이터 세트의 개요였어요. ICIJ는 역외 금융 산업의 복잡한 웹을 이해하는 데 사용하는 것과 동일한 오픈 소스 소프트웨어를 모든 사람이 사용할 수 있도록 Neo4j 데이터베이스로 패키지된 유출 데이터를 공개했답니다.

Paradise Papers 데이터 세트는 Neo4j 샌드박스에서 찾을 수 있고, 곧 ICIJ 웹사이트에서 Neo4j 데이터베이스로 다운로드할 수 있을 거예요. 데이터를 탐색하고 역외 금융 산업에 대해 어떤 통찰력을 찾을 수 있는지 확인해보세요!

데이터를 탐색하면서 다음 Cypher 및 Graph Database 학습을 위한 훌륭한 리소스들을 확인해보세요. 그리고 ICIJ가 하는 일이 마음에 든다면, ICIJ가 독립적인 미디어 조직이라는 점을 기억하고 ICIJ에 여러분의 아낌없는 기부로 응원해주세요.

이 게시물에서 모든 시각화를 생성하기 위한 코드는 GitHub에서 찾을 수 있어요.

Graph 기술로 무엇을 할 수 있는지 더 자세히 알고 싶으신가요? 아래를 클릭해서 O'Reilly 도서의 무료 사본을 받고 연결된 데이터의 힘을 활용하는 방법을 알아보세요.

편집자 주: ICIJ는 다음과 같은 메모와 함께 이 데이터를 게시했습니다: "해외 회사 및 신탁에는 합법적인 용도가 있습니다. 우리는 ICIJ 해외 유출 데이터베이스에 포함된 어떤 사람, 회사 또는 기타 단체가 법을 위반했거나 달리 부적절하게 행동했다고 제안하거나 암시할 의도가 없습니다. 많은 사람과 단체가 동일하거나 유사한 이름을 가지고 있습니다. 우리는 주소 또는 기타 식별 가능한 정보를 기반으로 데이터베이스에 있는 개인이나 단체의 신원을 확인할 것을 제안합니다."

  • Graph Algorithms
  • icij
  • JavaScript
  • PageRank

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

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

반응형
반응형

"그래프는 정말 강력하고, 기본적이면서 점점 더 중요해지고 있어요." 스티븐 스키에나 박사님(@StevenSkiena), AI 연구소장님(스토니브룩 대학교)께서 말씀하셨어요.

그래프는 컴퓨터 과학의 기본 요소이고, 그 중요성은 점점 더 커지고 있죠. 특히 Machine Learning을 사용해서 그래프를 분석하는 건 정말 강력하지만, 그러려면 그래프를 숫자 값으로 변환해야 해요. 바로 이럴 때 그래프 알고리즘이 등장하는 거죠!

이번 주 5분 인터뷰에서는 GraphConnect 2018 NYC에서 알고리즘 디자인 매뉴얼과 데이터 과학 디자인 매뉴얼의 저자이신 스티븐 스키에나 박사님과 DeepWalk에 대한 이야기, 그리고 그래프 알고리즘 라이브러리에 대해 이야기를 나눴답니다.

연구의 주요 초점은 무엇인가요?

스티븐 스키에나 박사: 요즘 제 연구는 그래프 임베딩에 집중하고 있어요. 그래프 임베딩은 그래프의 각 vertex를 공간 상의 점으로 표현하는 다차원 표현이라고 할 수 있죠.

이상적으로는 그래프를 가져와서 Machine Learning 모델을 구축하는 데 사용할 수 있는 feature로 축소하고 싶어요. Machine Learning 모델은 일반적으로 숫자 값에 아주 잘 작동하거든요. 선형 회귀, SVM(Support Vector Machine), Neural Network 같은 것들은 수치 표현으로 된 데이터와 궁합이 정말 좋죠. 그래서 저희 목표는 그래프를 가져와서 100차원 공간에 표현하고, 이 100차원이 feature를 나타내도록 하는 거예요.

그래프 임베딩은 단순히 그래프를 시각화하는 것과는 달라요. 100차원 그림을 본다고 해서 그걸 이해할 수는 없겠죠. 하지만 Machine Learning 모델은 100가지 feature를 아주 쉽게 이해할 수 있고, 그래프를 이런 feature로 축소함으로써 흥미롭고 강력한 모델을 쉽게 만들 수 있게 되는 거죠.

두 가지가 서로 얼마나 유사한지에 대한 질문에 쉽게 답할 수 있고, 고차원 공간에서 두 점이 유사한지 테스트하거나, 궁극적으로 가장 유사한 것이 무엇인지 식별할 수도 있어요.

일단 대표자가 있으면 모든 게 훨씬 쉬워지죠. 저희 그래프 임베딩 알고리즘인 DeepWalk는 이런 종류의 임베딩을 얻는 방법 중 하나랍니다.

DeepWalk 알고리즘에 대해 좀 더 자세히 설명해주실 수 있나요?

스키에나: DeepWalk의 많은 기능은 Word Embedding 아이디어에서 왔어요. 많은 분들이 들어보셨을 Word2Vec 말이죠. Word2Vec은 지도 학습 없이 영어 텍스트를 가져와서 단어의 의미를 나타내는 feature로 축소하는 방법이에요. 예를 들어 '녹색', '노란색', '빨간색'처럼 언어에서 비슷한 역할을 하는 단어들이 공간에서 서로 가깝게 위치하도록 단어를 구성하는 방법을 찾는 거죠. 이건 언어 모델을 구축하는 데 정말 강력한 방법이에요.

Word2Vec은 문장에서 단어가 하는 역할에 따라 단어의 표현을 구축하는 아이디어를 사용해요. 비유하자면, DeepWalk에서는 그래프를 vertex의 어휘로 생각하고, 문장을 그래프 위를 걷는 것으로 생각하는 거죠.

한 단어에서 다른 단어로, 또 다른 단어로 이동하는 것이 문장을 설명하죠. 마찬가지로 한 node에서 다른 node로, 또 다른 node로 이동하는 것은 무작위 이동을 설명하고, 이제 이걸 임베딩 구축을 위한 문장으로 취급할 수 있는 거예요.

Word2Vec은 일련의 기호를 가져와서 지도 학습 없이 기호가 실제로 무엇을 의미하는지 학습해요. 저희는 그래프에 대해 비슷한 작업을 수행하기 위해 Word2Vec의 기본 기술을 사용하고 있죠. 이건 많은 애플리케이션에서 강력한 효과를 보여줬고, Neo4j의 그래프 알고리즘 라이브러리에도 적용되고 있어요.

그래프 알고리즘 연구에서 가장 흥미로운 점은 무엇인가요?

스키에나: 그래프 알고리즘은 알고리즘 설계에서 정말 흥미로운 영역이에요. 그래프 알고리즘은 매우 복잡하지만, 실제로 그걸 사용하는 데 그 복잡성에 대한 지식이 꼭 필요한 건 아니거든요.

그래프 알고리즘의 강력함은 기본적으로 수행하려는 작업을 모델링하는 방법을 아는 데서 비롯돼요. 기본적인 알고리즘이나 작동 방식에 대해 잘 몰라도 그래프를 통해 놀라울 정도로 강력한 기능을 구축할 수 있다는 점이 정말 매력적이죠.

그래프가 소셜 네트워크와 모든 곳의 네트워크에 있다는 건, 그래프가 정말 강력한 역할을 한다는 걸 보여주는 거죠.

그래프 기술의 미래에 대해 흥미로운 점은 무엇인가요?

스키에나: 그래프는 컴퓨터 과학의 기본적인 부분이에요. 그래프는 항상 컴퓨터 과학의 기본일 테지만, 점점 더 중요해지고 있는 건 확실하죠. 그래프 데이터의 양과 그래프 표현의 양이 엄청나게 증가하고 있거든요.

소셜 네트워크는 이미 잘 알려져 있고, 그래프가 어디에나 있는 것 같다는 것도 아실 거예요. 그리고 이런 추세는 앞으로 더 심화될 거라고 봐요.

저희는 원래 수백만 개의 Node를 처리하기 위해 DeepWalk를 만들었어요. 그래프가 계속 커지고 있다는 점을 제외하면 정말 흥미로웠죠. 최근 연구에서는 분산 알고리즘을 사용해서 더 큰 그래프에 대한 임베딩을 수행할 수 있게 해주는 HARP라는 계층적 그래프 임베딩에 집중하고 있어요.

또 하고 싶은 말이 있나요?

스키에나: 학자, 특히 그래프 알고리즘을 가르치는 데 평생을 바친 사람으로서, 그래프에 관심을 갖는 사람들이 많아지는 걸 보는 건 정말 즐거운 일이에요. 이 분야에서 활동하는 사람들과 활동량이 정말 놀라울 정도예요.

다시 말하지만, 그래프는 매우 강력하고 기본적인 기술이며, 그 중요성은 점점 더 커지고 있다는 거죠.

향후 5분 인터뷰에서 Neo4j 프로젝트에 대해 공유하고 싶으신가요? 우리에게 전화를 걸어content@neo4j.com

그래프 알고리즘이 궁금하신가요?

다운로드Neo4j의 그래프 알고리즘, 연결된 데이터에 대한 강력한 통찰력을 얻기 위해 그래프의 힘을 활용하는 방법을 알아보세요.

  • 5분 인터뷰
  • DeepWalk
  • 스티븐 스키에나 박사
  • Machine Learning
  • word2vec

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

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

반응형
반응형
  • 사이퍼 & GQL

웹 세미나 후속 조치

Cypher 웨비나에 참석해주신 모든 분들께 감사드려요! 참석해주시고 채팅에서 활발한 토론을 해주셔서 정말 기뻤답니다.

약속드린 대로, 답변하지 못했던 질문들을 해결하고 웨비나에서 언급되었던 자료들을 한눈에 볼 수 있도록 이번 포스팅을 준비했어요.

여러분의 질문

Oleg Okun: Graph Database에서 그래프가 아닌 NoSQL 데이터베이스로 얼마나 쉽게 마이그레이션할 수 있나요?
API(Java, REST, Cypher) 중 하나를 사용해서 데이터를 내보내고, 다른 쪽에서 가져오면 돼요.

Alexandre Meynaud: Cypher 패턴을 정의할 때 성능을 고려해야 할까요?
몇 가지 고려해야 할 점들이 있어요. Cypher 성능은 Neo4j 1.9에서 개선되었죠. 지금은 바인딩된 `Node`가 하나 또는 두 개 있고, 필수가 아닌 `Relationship`이 있는 간단한 패턴에 집중하는 게 좋아요. 선택적인 `Relationship` 대신 패턴을 표현식으로 사용할 수도 있고요.

Oleg Okun: 일부 Machine Learning/데이터 마이닝 알고리즘의 Cypher 구현을 알려주실 수 있나요?
제가 아는 건 없네요. 기여하기에 흥미로운 주제가 될 수도 있겠어요. 다음은 몇 가지 데이터 모델링 예제입니다: Neo4j 매뉴얼.

마틴: 향후 버전의 Cypher는 이전 버전과 호환될까요?
이전 Cypher 파서 버전은 최대 두 개의 주요 Neo4j 버전에 대해 지원되고요, 다른 파서는 CYPHER 1.7을 `Query` 앞에 접두사처럼 추가해서 활성화할 수 있어요.

Alexandre Meynaud: 향후 몇 년(또는 수십 년) 안에 "표준" 그래프 `Query` 언어가 나올 거라고 예상하시나요?
솔직히 잘 모르겠어요. 저희는 커뮤니티 사용자와 고객들이 문제를 해결할 수 있도록 돕는 데 집중하고 있거든요. 이 부분에 대해 다른 벤더들과 논의해 봤지만, 우리 모두 너무 바쁘고 제품 개발에 집중하고 있어서 표준에 합의하는 건 아직 시기상조인 것 같아요.

Ajinkya: Scala를 사용해서 Cypher를 구현하기로 결정한 이유를 말씀해주시겠어요?
이건 Geekout Tallinn에서 진행된 강연에서 더 자세하게 다룬 내용이에요. 아래 리소스 섹션을 참고해주세요.

슬라이드

Cypher 소개 from jexp

비디오 녹화

0830 – Cypher와 Neo4j from 네오테크놀로지 on 비메오.

추가 리소스

  • 매뉴얼의 Cypher 부분 데이터 모델링 예 둘 다 라이브 쿼리 콘솔을 사용함
  • Neo4j 콘솔 – 샌드박스, Gist 및 Repl
  • Gist: 다른 프로그래밍 언어에서 Cypher를 사용하는 방법
  • Neo4j Cypher JDBC 드라이버
  • NOSQL-NOW의 컨퍼런스 세션 데이터세트
  • 클래스 그래프: Neo4j를 사용하여 소프트웨어 품질 분석
  • 서버에서 압축을 푼 데이터세트 예시 데이터/graph.db 예배 규칙서
  • Cypher 내부 프레젠테이션 동영상

훌륭한 웹 세미나 채팅!

The chat 웨비나 동안 정말 좋았어요. 안드레아스 콜레거 모든 질문에 답해주셔서.

하산: Washington DC here
크리스 스카든: evening from Cornwall, UK
매트 테일러: hello from Chicago
아시시 남: wow! looks like we have an internnational crowd on today!! Anyone from Australia?
밀라노SK: eveninig from Humenne, Slovakia
해럴드: Frankfurt, Germany
남자 이름: Hi from Spain (and Gibraltar)
...
알렉상드르 메이노: Yes, the great thing about Cypher is that you express *what* you want to retreive from the graph, and not how
아키 리스트카리: It's easy to visualize and you don't have to explain any table-row-kill_me_now-hibernate stuff to people. That marketing term 'Whiteboard friendly' is actually very accurate
안드레아스 콜레거: @Hisao you can't do sub-queries, but you can "chain" queries using a "WITH" clause to sort-of pipe the results to another query instead of returning them
아미트: is there a way to indicate in cypher to prune conditionally like we can using the traverser API
모토야마 히사오: ok, thanks
안드레아스 콜레거: @Ivan the query performance is not affected by the database size, though it is affected by an increase in "local" data
알렉스 게리에리: I love how intuitive it is
...
이반트라베소: nice presentation. thanks!
알렉상드르 메이노: Great presentation Michael, thanks a lot
Wes: Thanks a lot guys.
안드레아스 콜레거: thanks everyone, thanks Michael!
제임스 캠필드: cheers
크리스 스카든: Thanks!
밀렌: Thanks. this was absolutely cool!
아키 리스트카리: Thanks for the show  

다른 프로그래밍 언어에서 Cypher를 사용하는 방법

이 주제는 정말 광범위해서 별도의 블로그에서 다뤄볼 예정이에요. 지금은 다음과 같은 Gist에 대한 링크를 참고해주세요.

– 시청해주셔서 감사드리고, 다음에 또 만나요!

  • Cypher
  • Query Language
  • SQL

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

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

반응형
반응형
  • Graph Data Science
  • Node

편집자 주: 이 프레젠테이션은 Matt Butler가 다음에서 제공했습니다.그래프커넥트 2022.

Bonsai Data Solutions와 Cambridge Intelligence는 고객이 고객 여정을 이해하도록 돕기 위해 협력했어요. Bonsai는 비즈니스 인텔리전스 및 데이터 자문 회사이고 Cambridge Intelligence와 제휴해서 소매업체, 스타트업, 의료 기업이 마케팅 및 비즈니스 인텔리전스를 현대화하도록 지원하는 고객 여정 그래프 애플리케이션을 구축하는 데 도움을 줬죠.

고객 여정

고객 여정 뒤에는 이런 핵심 질문이 있어요. "고객이 구매한 이유는 무엇일까?" 결국 모든 고객이 이 질문에 답하려고 노력하고 있죠. 비즈니스 및 마케팅 팀은 고객을 확보하고 성장시키기 위해 광고, 프로모션, 쿠폰, 데이터, 조정 및 실행에 엄청난 돈을 쓰고 있어요. 기업은 이러한 투자의 중요성을 이해하고 있으므로 무엇이 효과가 있고 무엇이 효과가 없는지를 필사적으로 알고 싶어하죠.

마케팅에서 무엇이 효과가 있고 무엇이 효과가 없는지 이해하는 건 새로운 문제는 아니지만, 풀기 정말 어려운 문제에요. 실제로 이 문제를 해결하기 위해 구축된 산업 전체가 있을 정도니까요. 고객을 측정하는 문제에는 하향식과 상향식이라는 두 가지 일반적인 솔루션이 있어요. 먼저 이 두 가지 접근 방식을 설명한 다음 Bonsai에서 하는 일이 근본적으로 이 두 가지 접근 방식과 어떻게 다른지, 그리고 우리의 접근 방식이 어떻게 더 나은지 공유할게요.

하향식 접근 방식

통계나 수학에 대한 배경 지식이 있다면 어떤 행동이 판매, 수익, 고객과 같은 비즈니스 결과로 이어지는지 하향식 분석을 수행하는 사람들에 대해 들어본 적이 있을 거예요. 회사에서 이를 수행하는 일반적인 방법은 모든 데이터를 가져와 요약하고 기본적으로 통계 및 다변량 회귀와 같은 도구를 사용하여 이를 큰 거시적 합계로 압축하는 것이죠. 예를 들어 일일 총 판매량이나 TV 시청에 대한 Nielsen의 GRP 측정과 같은 측정항목을 생각해 보세요.

이것의 좋은 점은 뭘까요? 통계는 엄격하며 날씨가 매출에 어떤 영향을 미치는지 등 매우 흥미로운 사실을 추론할 수 있다는 점이에요. 단점은 뭘까요? 음, 통계학자에게 비용을 지불하는 건 꽤 비싸요. 더욱 어려운 점은 모든 데이터를 가져와 처리해서 더 단순하게 만들고 원시 데이터에 존재하는 유용한 풍부함을 잃는다는 거예요. 이는 항상 가장 적용 가능하지는 않은 매우 일반적인 결론으로 ​​이어지죠. 특히 분석이 완료될 때까지 데이터가 몇 달 전 데이터가 될 수도 있기 때문이에요.

상향식 접근 방식

디지털 분석은 이 측정 문제에 접근하는 상향식 방법이에요. 이 측정은 누군가가 웹사이트를 클릭하거나 이메일에 응답할 때마다 데이터를 수집하기 때문에 웹에 존재하는 산업에서 매우 일반적이죠. Google Analytics를 사용해 본 적이 있거나 Facebook, Amazon 또는 Google에서 디지털 광고를 사용해 본 적이 있다면 이 상세한 터치포인트 수준 데이터에 익숙할 거예요. 우리 도구인 Pyxis는 이러한 풍부한 데이터를 통합하고 누군가가 클릭한 후 나중에 구매하는 경우와 같이 활동이 결과로 이어지는 방식에 대한 세부적인 상관관계를 찾아내요. Pyxis는 이를 실시간으로 추적해서 기업이 빠른 결정을 내릴 수 있도록 도와주죠.

이 접근법의 단점은 뭘까요? 데이터가 어마어마하다는 거죠. 일반적으로 다양한 마케팅 시스템의 데이터는 격리되어 있어서 관리하기가 더 쉬운데요. 하지만 이 접근 방식을 사용하면 데이터를 결합해서 판매를 유도한 전체 맥락을 파악할 수 있어요. 예를 들어, 오늘 아침에 제가 스타벅스에서 커피를 샀다고 해볼게요. 스타벅스는 Google 광고, 이메일 프로그램 또는 로열티 프로그램이 판매에 도움이 되었다고 생각할 가능성이 높아요. 이러한 모든 마케팅 프로그램은 판매에 대한 완전한 공로를 인정받고 싶어하죠. 이 사일로 관점에서는 세 번의 판매가 발생한 거예요. 물론 재무팀에서는 판매가 단 한 번뿐이었다는 걸 알지만요. 하지만 어떤 프로그램이 판매를 일으켰을까요? 이 고립된 데이터 중 어느 것도 그 질문에 답할 수 있는 방법이 없어요. 사실 그들은 그 질문에 답할 준비조차 되어 있지 않죠.

두 모델의 공통 과제

하향식 접근 방식과 상향식 접근 방식은 몇 가지 측정 문제를 공유해요. 예를 들어 둘 다 데이터 결합에 어려움을 겪죠. 두 가지 모두 중요한 측면을 놓치는 경우가 많고 단일 고객을 위해 이벤트를 연결하는 방법이 없는 경우가 많아요. 이러한 이벤트 연결은 우리가 사용자 여정에 대해 생각하는 방식과 관련이 깊죠. 쿠키나 IP 주소를 사용하여 데이터를 결합하는 방법이 있더라도 동일한 위치의 라디오 광고에 해당 정보를 결합할 수 없는 경우가 많아요.

고객이 구매 결정을 내리기 전에 마케팅 활동이 몇 번이나 이루어져야 하는지에 대한 질문도 있어요. 예를 들어, 잠재 고객은 구매하려는 제품에 대한 이메일을 자주 열지만 궁극적으로 구매하기 전에 이 이메일 및 다른 사람들과 여러 번 상호 작용할 수 있어요. 구매 결정은 초기에 내려졌을 수도 있지만 오늘날 디지털 분석에서는 구매하기 전 마지막으로 이메일을 열 때만 판매에 대한 크레딧이 부여되죠.

접근 방식은 그래프인가요?

처음에는 이 두 가지 접근 방식 중 어느 것도 그래프라고 느껴지지 않았어요. 예를 들어, JetBlue 항공사가 우리가 6월 6일에 보스턴에서 오스틴으로 가는 항공편을 구입했다는 사실을 알게 되면 그들은 어떤 데이터를 보고 있을까요? 일반적으로 집계된 데이터일 거예요. 얼마나 많은 사람이 이 작업을 수행하고 있을까요? 그들은 요금으로 얼마를 지불하고 있나요? 다른 항공편을 추가해야 할까요? 이건 실제로 그래프가 아니에요. 그래프는 집계에 관한 것이 아니라 개별 데이터 요소 자체에 관한 것이거든요. 상향식 접근 방식의 경우에도 마찬가지예요. 개별 고객이 무엇을 하는지 알 수 있지만 내 분석은 개별 고객이 무엇을 하는지가 아니라 집계에만 관심이 있기 때문에 그래프가 아니죠.

이러한 집계는 유용하고 비즈니스를 개선하는 데 도움이 되지만, 개별 고객이 취하는 풍부한 여정을 자세히 확인하면 현재 진행 중인 상황에 대한 그래프를 구성하고 해당 정보를 사용자별 상세한 고객 여정으로 표시할 수 있어요. 이것이 바로 우리가 Neo4j Bloom과 자체 도구인 Pyxis에서 구축한 것이죠.

Bloom & Pyxis 데모

Bloom 데모 보기
Pyxis 데모 보기

Pyxis는 자신이 보고 있는 내용을 정확히 이해하고 자신이 보는 내용과 그래프와 상호 작용하는 방식을 완전히 제어하려는 비즈니스 인텔리전스 분석가를 위해 설계되었어요. Pyxis를 사용하면 상호작용 관점과 UI의 모양과 느낌에서 UI를 제어할 수 있죠.

차트 중앙에 거대한 트랜잭션 `Node`를 추가했어요. Neo4j에는 트랜잭션이라는 `Node`가 없는데요. 왜냐하면 그것이 우리가 데이터를 모델링한 방식이 아니기 때문이에요. 하지만 사용자로부터 우리는 이것이 사용자가 보고 싶어하는 것임을 알았어요. 이러한 유연성과 구조를 통해 사용자는 경로 주변의 상호 작용과 사용자가 그래프를 통해 이동하는 방식을 사용자 정의할 수 있죠.

주요 시각적 기능: `Node` 그룹화

일반적으로 기업은 엄청나게 많은 구매자가 있지 않은 이상 개별 고객이 뭘 하는지 일일이 신경 쓰진 않기 때문에, 여기서 집계가 핵심이에요. 집계를 통해 개별 고객 행동을 바탕으로 그룹이 어떤 활동을 하는지 파악할 수 있죠. 모든 사용자를 그룹화하면 해당 그룹이 차트의 다른 항목과 어떻게 연결되는지 한눈에 볼 수 있답니다.

주요 시각적 기능: 경로 강조 (Path Highlighting)

경로 강조 (Path Highlighting) 기능을 사용하면 특정 유형의 고객 및 잠재 고객의 일반적인 여정을 쉽게 확인할 수 있어요. 마케팅 접점을 통해 어떻게 고객이 되는지 시각적으로 보여주니까 정말 편리하죠?

주요 시각적 특징: 성능

성능은 이 정도 규모의 모든 데이터 애플리케이션에서 중요한 과제죠. 기업이 고객의 모든 클릭과 상호 작용 데이터를 수집한다면 그 양이 엄청날 수밖에 없어요. 일반적으로 최종 사용자에게 모든 데이터를 보여주고 싶진 않겠지만, 단순화하거나 요약된 시각적 모델로 그룹화하면 이야기가 달라져요. Pyxis는 이러한 시각화가 필요할 때 큰 차트도 문제없이 렌더링할 수 있는 뛰어난 엔진을 가지고 있답니다.

성공 #1: 기존 미디어 측정

저희는 Pyxis를 사용해서 90일이나 걸리던 분석 프로젝트를 단 하루 만에 끝내는 경우를 여러 번 봤어요. 게다가 Pyxis는 라디오 광고 효과나 어떤 지점이 효과적인지 등 고객이 이전에는 90일 동안 고민해도 답을 찾지 못했던 질문에도 답을 제시해준답니다.

성공 #2: 프로모션 및 미디어

프로모션과 미디어의 경우, Bloom과 Pyxis를 사용해서 프로모션의 영향을 받는 사용자 집단을 이해할 수 있어요. 위 이미지에서 빨간색 점은 프로모션을 사용한 사람들이자 마케팅의 영향을 받은 사람들이랍니다. 전통적으로 이 두 가지 작업은 독립적으로 살펴봤지만, 여기서는 함께 살펴보는 거죠.

성공 #3: LTV 및 기간 내 영향 분석

그런 다음 동일한 관점에서 단기 및 장기를 볼 수 있는 시계열이 있어요.

픽시스의 다음 단계는 무엇입니까?

저희는 현재 내부 클라이언트에게 Pyxis를 알파 버전으로 출시하고 있고, 올해 베타 버전을 출시할 예정이에요. 속도 측면에서 많은 성공을 거두었고, 이런 종류의 그래픽 마케팅 기술에 대한 더 많은 비즈니스 사용 사례를 구축해 왔기 때문에 정말 기쁘답니다.

Graph Data Platform이 무엇인지, 고객 여정을 연결하는 데 어떻게 도움이 되는지 알아보세요.

  • Bloom
  • Bonsai
  • Business Intelligence
  • Customer Journey
  • Graph
  • Nodes
  • Pathfinding
  • Pyxis

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

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

반응형
반응형

베를린에서 샌프란시스코까지

같은 날, 베를린과 샌프란시스코에 있는 두 기술 커뮤니티가 모여 동일한 아키텍처 질문, 즉 에이전트 AI 시스템을 위한 메모리를 어떻게 설계해야 하는지에 대해 논의했어요.

베를린에서는 AI Memory와 Founders Night가 생산 AI 시스템을 연구하는 창립자, 엔지니어, 건축가를 한자리에 모았죠. 동시에 샌프란시스코에서 열린 첫 번째 컨텍스트 그래프 모임에서는 새롭게 떠오르는 아키텍처 패턴으로서의 컨텍스트 그래프를 탐구하는 연구원과 실무자가 모였답니다. 화자, 도시, 형식은 달랐지만 결론은 놀라울 정도로 일치했어요.

이벤트는 샌프란시스코와 베를린에서 시작됩니다.

컨텍스트 그래프란 무엇일까요?

샌프란시스코 모임은 Will Lyon이 작업 정의를 설정하면서 시작되었어요. 컨텍스트 그래프는 쿼리 가능한 단일 구조의 엔터티, 정책 및 선례에 연결된 의사 결정 추적과 함께 조직 전체에서 의사 결정을 내리는 데 필요한 모든 정보를 포함하는 Knowledge Graph라는 거죠.
Jessica Talisman은 업계에서 현재 컨텍스트 그래프라고 부르는 것은 전통적으로 지식 관리에서 절차적 지식으로 알려져 왔으며, 컨텍스트 자체의 개념(사물 간의 관계에서 파생된 의미)이 바로 그래프가 항상 표현하기 위해 구축된 것임을 분명히 밝혔어요.
Yann Biliien는 Knowledge Graph와 행동 및 프로세스 그래프라는 두 그래프의 합으로 컨텍스트 그래프를 설명했어요.
Dave Bennett는 이를 차원의 문제로 구성했는데요. Knowledge Graph는 상위 집합이고 컨텍스트 그래프는 의사 결정 추적, 출처 및 시간적 타당성이라는 단순한 3가지 차원을 넘어 추가적인 차원을 추가한다는 거죠.
Emil Eifrem은 실용적인 프레임을 제공했는데요. 도메인 데이터를 가져와 그래프 형식으로 모델링하고 해당 Knowledge Graph 위에 결정 추적을 연결하면 이것이 컨텍스트 그래프라는 거예요.

Will Lyon의 강연: "Neo4j로 컨텍스트 그래프 구축", Nyah Macklin이 진행자 및 Emil Eifrem과 함께 진행하는 패널 토론

베를린 논의에서는 다른 각도에서 비슷한 실무 정의에 도달했어요. 베를린 실무자들은 패턴이 수행해야 하는 작업에 대해 더 자세히 살펴봤는데, 바로 명시적 연결 유지였죠. `Vector Embedding`만으로는 엔터티 소유권, 계층 구조, 종속성, 시간적 순서 사이의 연결을 인코딩할 수 없으니까요.

두 커뮤니티 모두 같은 결론에 도달한 거죠. `Context Graph`의 가치는 구조화된 도메인 지식을 쿼리 가능하고, 탐색 가능하며, 감사 가능한 형식으로 의사 결정 과정 기록에 연결하는 데 있다는 거예요.

AI 메모리가 중심으로 이동하는 이유

지난 한 해 동안 많은 AI 애플리케이션이 `Retrieval-Augmented Generation`에만 의존해 왔어요. `Vector Search`는 의미상 유사한 콘텐츠를 검색하는 데 효과적이지만, 엔터티 간의 구조화된 관계를 유지하지는 못하죠.

시스템이 더욱 능동적으로 계획을 세우고, 여러 도구를 사용하고, 다단계 작업을 조정할 수 있게 되면서 베를린과 샌프란시스코 팀은 세션 전반에 걸쳐 지속되지 않는 메모리, 명시적이 아닌 암시적인 엔터티 간의 관계, 검사하거나 감사할 수 없는 추론 체인 등 동일한 반복적 제한에 직면했다고 설명했어요.

여러 참석자가 강조했는데, Andreas Kollegger의 세션(Neo4j)에서 `Context Graph`를 특히 명확하게 설명했죠. `Vector Search`는 `Semantic Search`에 여전히 효과적이지만, `Context Graph`는 항목 간의 관계를 명시적으로 만들어 에이전트가 워크플로, 시스템, 진화하는 컨텍스트 전반에 걸쳐 추론할 수 있도록 해줘요.

베를린의 AI 메모리 및 `Context Graph`에 관한 Cognee 및 Neo4j

Emil Eifrem은 샌프란시스코 패널에서 구조적 격차를 명확하게 설명했어요. 에이전트가 프로덕션에서 유용하려면 네 가지가 필요하죠. 기록 시스템에 대한 액세스, 데이터 플랫폼에 대한 액세스, 대화 및 세션 상태를 위한 에이전트 메모리, 그리고 최근까지 명확한 이름이 부족했던 네 번째 부분은 조직이 실제로 운영되는 방식을 인코딩하는 결정 추적 및 제도적 지식이에요.

Lyon도 이 점을 강조했을 텐데요. 2025년 비즈니스 분야의 AI 현황, MIT에서 수행한 보고서에 따르면 AI 프로젝트의 95%가 가치를 제공하지 못하며, 근본 원인은 에이전트가 올바른 컨텍스트에 액세스하지 못하는 것이라고 해요.

Jessica Talisman의 강연: “`Context Graph`와 프로세스 지식”

이것은 지식 관리 문제

샌프란시스코 정기 모임에서 제기된 가장 실질적인 과제는 패널 토론을 통해 공감을 얻었는데, `Context Graph`를 작성하는 것은 주로 엔지니어링 문제가 아니라는 점이었어요.

그것은 지식 관리 문제에요. Jessica Talisman은 절차적 지식 온톨로지에 대한 Sephrial 그룹의 동료 검토 연구를 바탕으로 Siemens, Belco 및 Bosch의 배포 사례를 직접적으로 인용했죠. 의사 결정 추적은 데이터가 아니라 지식이며, 이를 캡처하려면 대부분의 엔지니어링 팀이 적용하지 않는 지식 추출, 공식 인코딩 및 온톨로지 분야가 필요해요.

그녀의 처방은 실용적이었어요. 지속성 계층 이전에 지식 모델을 구축하고, 인간과 관련된 추출 인프라에 투자하고, 단순한 실행 추적이 아닌 지식 캡처를 주요 목표로 취급하는 것이죠.

최종 패널은 이 점을 광범위하게 강조했어요. 대부분의 `Context Graph` 이니셔티브가 기본 작업을 수행하지 않고 실행 추적을 캡처하는 운영 계층으로 바로 이동하는 이유는 지식 관리가 실제로 어렵고 역사적으로 조직 전반에 걸쳐 투자가 부족했기 때문이에요. 그렇다면 우리가 올바르게 하면 어떤 모습일까요?

프로덕션에서 `Context Graph` 구축

Yann Bilien(Rippletide)은 모순이 추론 시간이 아닌 빌드 시간에 해결되어야 한다고 강조했어요. 두 데이터 소스가 정책 세부 사항에 동의하지 않는 경우 해당 불일치는 그래프 구성 중에 처리되어야 하며, `Large Language Model`이 런타임에 중재하도록 남겨두지 않아야 해요. 그리고 Dave Bennett(Indykite)는 거버넌스가 처음부터 설계되어야 함을 보여주었죠. 그의 라이브 데모에서는 OAuth 토큰 교환을 사용하여 구축된 전체 위임 체인이 모든 에이전트 작업을 원래 사용자에게 다시 연결하고, 부서 수준 그래프 정책에 따라 한 사용자에 대해서는 동일한 `Query`가 올바르게 차단되고 다른 사용자에게는 허용되는 방법을 보여주었어요.

Dave Bennett의 강연(Indykite) "`Context Graph`를 에이전트 기업을 위한 제어 평면으로" 및 Yann Bilien의 강연(Rippletide) "자동 온톨로지: 신뢰할 수 있는 AI 에이전트를 위한 `Context Graph` 구축"(샌프란시스코)

빌드 시간 엄격함과 런타임 거버넌스라는 두 가지 주제는 베를린 실무자들이 프로덕션 시스템의 추적성 및 감사 경로에 대한 질문에 초점을 맞춘 내용을 반영했어요.

베를린 AI Builder 커뮤니티의 통찰력

베를린 이벤트에서 얻은 가장 귀중한 통찰력 중 상당수는 빌더들이 현재 에이전트 시스템을 위한 메모리 레이어를 설계하는 방법을 비교하는 세션 간 토론에서 나타났어요.

생태계 관점에서 보면, AI 개발이 가속화됨에 따라 오늘날 팀이 내리는 아키텍처 선택은 배포하는 시스템의 안정성과 신뢰성을 형성할 거예요.

Wynand Viljoen, 차세대 스타트업 창업자 인큐베이팅

에이전트 AI의 운영 현실에 대한 대화도 있었는데요. 시스템이 점차 자율화될 때 에이전트 생성 코드를 안전하게 실행하고 제어를 유지하는 방법에 대한 내용이었어요.

메모리 아키텍처를 실용적인 개발자 도구 및 실제 구현 패턴과 연결한 Microsoft Foundry를 사용한 에이전트 구축에 대한 강연도 인상적이었다는 의견이 있었어요.

엔지니어링 에이전트 AI 시스템

 

두 행사에서 눈에 띄는 점은 단순히 두 커뮤니티가 같은 날 비슷한 아이디어를 논의했다는 점만은 아니에요. 세계 각지에서 서로 다른 상황, 서로 다른 문제에 대해 작업하는 독립적인 엔지니어링 커뮤니티가 동일한 아키텍처 결론에 도달하고 있다는 거죠.

새로운 패턴은 점점 더 일관적으로 보이는 것 같아요. 모델은 응답을 생성하고, 에이전트 프레임워크는 워크플로를 조정하고, 구조화된 메모리 계층은 엔터티와 관계를 유지하며, 거버넌스 및 실행 계층은 안전과 재현성을 보장하죠. 이 스택 내에서 컨텍스트 그래프는 메모리 계층의 중심이 되고 있어요.

샌프란시스코 패널에서 나온 Emil Eifrem의 최종 비전은 방향을 잘 포착했는데요. 이상적인 미래는 기관의 지식과 결정 추적을 구조화된 계층으로 인코딩하는 것이 단위 테스트 작성만큼 눈에 띄지 않는 AI 지원 소프트웨어를 구축하는 데 있어 표준 위생이 되는 미래라고 해요.

베를린에서 샌프란시스코까지 방향이 일치하는 걸 보면, 패턴이 수렴되고 있는 것 같아요. 구축을 시작해 볼까요?

연사, 파트너 및 친구들에게 감사드립니다

베를린에서는 AI 메모리와 Founders Night에 Neo4j, Delta Campus, Cognee, Riverty, MemVerge, AWS, Microsoft, Google, Global AI Community 및 Google Developer Group Cloud Berlin 커뮤니티가 한자리에 모여 AI 메모리 및 컨텍스트 그래프를 논의하기 위한 개방적이고 사려 깊은 환경을 조성하는 데 도움을 주었어요.

샌프란시스코에서 Context Graph Meetup은 마찬가지로 열정적인 커뮤니티를 하나로 모았어요. 에이전트 AI 시스템의 핵심 아키텍처 패턴인 컨텍스트 그래프에 대한 최첨단 연구를 공유한 Neo4j, Contextually, Indykite 및 Rippletide의 발표자와 기여자에게 큰 감사를 드려요.

두 이벤트 모두 AI 시스템의 미래를 적극적으로 형성하고 있는 연사, 파트너, 개발자 커뮤니티 간의 놀라운 협력 덕분에 가능했어요.


  • AI 메모리

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

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

반응형
반응형

편집자 주: 이 프레젠테이션은 Stephan Reiling이 GraphConnect San Francisco 2016년 10월에 발표한 내용이에요.

프레젠테이션 요약

이번 강연에서 선임 과학자 Stephan Reiling은 주요 제약 회사가 의료용 화합물 **search**를 수행할 때, **Graph Database** 기술이 어떻게 중요한 역할을 하는지 설명합니다.

여기서 근본적인 문제는 확장 가능한 생물학적 **Knowledge** 시스템을 어떻게 구축하느냐는 것이죠.

단순히 방대한 양의 이질적인 데이터를 연결하는 것뿐만 아니라, 연구자들이 특정 유형의 데이터에 대한 **query**를 구성할 수 있어야 한다는 의미이기도 해요. 삼각관계를 예로 들면, **Node**는 화학적 화합물, 특정 생물학적 개체, 그리고 질병에 대해 설명하고 있어요. 연구 문헌에서 시스템은 **query**의 일부로 주요 링크의 불확실성을 사용해야 하죠.

**Graph** 기술이 이러한 노력을 발전시키는 구체적인 방법은 시스템이 의학 연구 텍스트에서 용어 간 관계의 강도를 캡처할 수 있도록 하는 거예요. 이러한 항들을 연결하는 **Graph**의 **property**를 활용하는 거죠.

결과적으로, 이는 문헌을 관찰된 화학적 또는 생물학적 데이터와 연결하는 후속 **query**를 위한 기반을 제공해요. 일부 링크를 제거해서 결과가 어떻게 달라지는지 확인하여 테스트할 수도 있고요.

전체 프레젠테이션: 초기 약물 발견의 점 연결하기

이 블로그 게시물에서는 수많은 이질적인 데이터를 결합하여 하나의 큰 **Knowledge Graph**로 통합한 방법에 대해 이야기할 거예요. 우리가 질병 치료법을 찾는 데 사용하는 정보죠.

생명의학 연구를 위한 그래프

노바티스 생물의학 연구 연구소는 대형 제약회사인 노바티스의 연구 부문이에요. 우리의 연구는 질병을 치료할 수 있는 차세대 의약품을 식별하는 데 집중하고 있죠.

우리는 생물의학 연구를 통해 의약품을 식별하는데, 엄청난 양의 데이터를 생성하고 분석해서 결국 작은 알약이나 주사, 혹은 치료법으로 만들어내는 빅데이터 병합 작업이라고 할 수 있어요.

이건 거의 3년 동안 저희가 작업해 온 프로젝트인데요, 이제 첫 결과가 나오고 있고 아주 유망해 보여요. 핵심은 수많은 이질적인 데이터를 어떻게 결합해서 하나의 큰 Graph로 통합했는지, 그리고 이걸 쿼리에 활용하고 있다는 점이에요.

이 Graph에 넣는 데이터 중 일부는 텍스트 마이닝에서 얻은 건데, 텍스트에서 추출하는 내용과 패턴 감지 방식이 조금 다르죠. 아래에서 실제로 어떻게 사용될 수 있는지 몇 가지 예를 보여드릴게요.

Graph를 만든 이유

우선 왜 이런 일을 하는지부터 이야기해볼게요.

지금은 복잡한 생물학을 포착하는 데 사용되는 이미지에 관한 내용이에요. 예전에는 생물학을 이해하고 싶고 단백질에 관심이 있다면, 단백질을 분리하고 정제한 다음 작은 시험관에 넣어서 특성을 분석하곤 했죠.

화합물이나 작용 물질을 확인하고 싶다면, 해당 화합물을 똑같은 시험관에 넣고 그게 효소나 다른 단백질의 활성에 어떤 영향을 미치는지 확인하면 됐어요. 굉장히 환원주의적이지만, 원한다면 아주 정확한 측정을 할 수 있고, 그 분야에 대한 수십 년간의 데이터가 있었죠.

오랫동안 그게 신약 발견의 핵심이었어요. 이렇게 발견된 초기 화합물은 여러 해의 노력을 거쳐 최종적으로 시장에 출시되는 약물이 되죠. 그런데 아시다시피, 생물학은 시험관 속의 단일 단백질로 환원될 수 없어요. 훨씬 더 복잡하거든요.

지난 5~8년 정도 동안 전 세계의 모든 제약 회사와 연구 기관은 이제 이 생물학의 복잡성을 포착하려고 노력하기 시작했어요. 이걸 수행하는 한 가지 방법이 콘텐츠가 많은 화면을 실행하는 거죠.

High-content Screens

아래 왼쪽 이미지는 세포 배양의 스냅샷이에요. 훨씬 더 큰 이미지를 잘라낸 거죠. 저희는 이런 종류의 분석을 대규모로 진행해요. 실험실 자동화 기능을 갖춘 대형 자동화 현미경을 보유하고 있고, 이런 방식으로 테라바이트 단위의 이미지를 쉽게 생성할 수 있어요.

흰색으로 보이는 건 기본적으로 세포체이고, 빨간색 원은 핵, 녹색은 특정 단백질을 포함하지 않는 세포의 핵이에요. 여기서 목표는 흰색으로 표시된 이 단백질을 발현하는 세포의 수를 늘리는 거라고 가정해 볼게요.

여기에 몇 가지 처리를 추가한다고 가정해 보죠. 그건 화합물일 수도 있고, 작은 RNA일 수도 있고, 뭐든 될 수 있어요. 그러면 숫자가 변할 뿐만 아니라 더 많은 일이 일어나고 있다는 걸 알 수 있기를 바라요. 세포의 모양이 변하고 있는 거죠. 이제 여기에 다른 화합물을 추가하면 다른 일이 발생해요. 이걸 표현형이라고 불러요.

저희는 현재 표현형을 사용해서 기본적인 생물학을 이해하고, 결국 약물을 얻기 위한 이 긴 과정에 들어갈 화합물을 더 잘 식별하기 위한 아주 큰 규모의 스크리닝을 진행하고 있어요.

이러한 데이터 생성 과정은 저희의 업무를 더욱 어렵게 만들 뿐이에요. 실험실 자동화가 진행되면서 이런 데이터를 점점 더 많이 생성할 수 있게 되었죠. 이제 살아있는 세포 이미징을 촬영하고 시간이 지남에 따라 세포를 추적하는 영화도 나오고 있어요. 3D도 있고요. 3D 슬라이드 등을 찍기도 해요. 점점 더 많은 데이터가 쏟아지고 있는 거죠.

기본 문제: 확장 가능한 생물학적 지식

기본적인 문제에 대해 설명해 드릴게요. 저희는 수십 년 동안의 환원주의적 데이터를 가지고 있어요. 주석이 달린 대규모 복합 실시간 읽기도 있죠. 과거에는 뭘 했는지 알고 있지만, 지금은 상황이 변하고 있고 영상 데이터와 표현형 분석이 점점 더 많아지고 있어요.

이걸 분석하려고 하면 생물학적 지식을 확장할 수 있는 방법이 필요하고, 생물학적 지식을 저장할 수 있는 시스템을 갖춘 다음, 이 저장소를 사용해서 데이터를 분석할 수 있도록 쿼리를 실행할 수 있어야 한다는 게 훨씬 더 분명해져요. 아직 '생물학적 지식'이 정확히 무엇을 의미하는지는 모르겠지만, 일단 거기에 맞는 시스템을 만들어 보도록 할게요.

위 이미지에서 주요 삼각형은 화합물, 유전자 및 표현형을 연결하고 있어요. 성공적인 약물 발견을 위해서는 이 삼각형을 탐색할 수 있어야 한다고 생각하는 거죠.

우리가 역사적으로 축적한 데이터를 사용하면 삼각형의 한쪽 가장자리, 즉 화합물과 유전자 사이는 매우 강하지만 다른 가장자리는 그렇지 않아요. 그래서 이러한 지식 격차를 메우려고 노력하고 있답니다.

화학물질, 질병 및 단백질에 대한 Text mining

우리가 사용하는 정보 소스 중 하나가 Text mining이라고 말씀드렸죠? 아래 슬라이드에는 일부 과학적 텍스트가 있는데, 이 텍스트에서 관심 있는 개체를 식별하는 데 사용할 수 있는 도구가 있답니다.

여기서 우리는 화합물, 유전자, 질병 및 과정 등을 식별하고 있어요. 그런데 이러한 도구 중 일부는 이것이 화합물이라고만 말하고 화합물이 무엇으로 구성되어 있는지는 알려주지 않는다는 점에서 약간 속이는 것 같기도 해요.

우리가 연구해 온 것 중 하나는 그것이 실제로 어떤 화합물이나 유전자인지 정확히 식별하는 거예요. 그런 다음 기본적으로 본문에서 확인한 화학 구조를 재설계하는 거죠.

우리는 또한 텍스트에 있는 개체 간의 관계를 식별하고 "화합물은 이 목표를 억제합니다."와 같은 진술을 제시하려고 노력하고 있답니다.

PubMed 라이브러리의 풍부함

우리가 처음에 사용했던 코퍼스는 국립 의학 도서관의 PubMed에요(아래 참조). 정말 놀라운 자원이죠! 1946년부터 약 5,600개의 과학 저널에서 기사를 수집해 왔고, 이러한 기사의 초록을 무료로 제공하고 있다니, 정말 대단하지 않나요?

하지만 때때로 간과되는 점은 기사나 초록이 이 라이브러리에 입력되면 인간 전문가가 태그를 지정한다는 거예요. 그들은 이러한 MeSH 용어를 의학 주제 제목이라고 부른답니다.

위 이미지에서 왼쪽 텍스트는 오른쪽에 표시된 것처럼 실제로 얻은 태그 수에 대한 인상을 줘요. 그리고 이러한 태그의 좋은 점은 태그가 구성되는 방식과 인간 전문가가 제공한다는 점이죠.

때때로 태그는 인간의 큐레이션으로 인해 텍스트에서 얻을 수 없는 방식으로 기사를 설명하기도 한답니다.

MeSH 용어는 체계적으로 구성되어 있다고 말씀드렸는데, 아래에는 구성 방식에 대한 내용이 조금 나와 있어요. 그들은 트리 형태로 조직되어 있답니다. 다이어그램에는 그 중 우리가 관심을 갖고 있는 5개의 트리가 표시되어 있어요. 총 16개의 트리가 있는데, 여기에는 지리나 직업과 같은 항목이 포함되어 있지만 우리의 목적에는 별로 관심이 없어요.

이 트리에는 약 25만 개의 태그가 사용된다고 해요. 그런데 여기서 솔직하게 말씀드릴 게 있어요. 실제로는 그렇게 예쁘게 보이지는 않아요. 전체 조직이 트리 구조이긴 하지만요.

가지 사이에 연결이 있기 때문에 실제 레이아웃은 보기 좋지 않을 수 있지만, 일반적으로 트리로 구성되어 있답니다.

이 슬라이드는 이 트리가 얼마나 깊고 풍부한지 살짝 보여주는 것 같아요. 특정 태그로 주석이 달린 기사 수에 따라 크기가 결정되는데, 잘 보시면 태그가 보이지 않죠?

좀 더 확대해서 보면, 기사가 수용체의 특정 하위 유형을 다룰 것이라는 것을 태그만으로도 알 수 있어요. 정말 풍부하고 상세한 정보를 사용하고 있는 거죠.

하지만 여기서 단점은, 텍스트 마이닝을 통해 엔터티를 얻고 이러한 엔터티 간의 관계를 얻는다는 점이에요. 여기서는 태그가 초록에 있거나 주석이 달려있는 것만 알 수 있죠. 그래서 PubMed 정보를 그래프에 넣어서 이걸 결합하고 싶은데, 어떻게 해야 할까요?

텍스트의 관계에서 그래프의 관계 구축

여기서는 2,500만 개의 초록을 모두 살펴보고 있다는 사실을 활용하고 있어요. 다음은 4개의 기사를 사용한 간단한 예시인데요. 이렇게 해서 이 기사를 살펴보면, 화합물 A와 유전자 1과 같은 일부 개체가 매우 자주 함께 발생한다는 것을 알 수 있어요.

우리는 연관 규칙 마이닝을 사용해서 이러한 엔터티에 대한 동시 발생 확률을 설정하고 있어요. 문장의 동사는 사용하지 않고, 이러한 엔터티만 사용하고 있죠. 알려진 대로 리프트를 수집해서 0에서 1까지 크기를 조정할 수 있어요.

특정 임계값을 초과하면 엔터티(이 예에서는 화합물 A와 유전자 1) 사이에 관계가 있다고 판단하고, 이를 그래프에 표시하는 거예요. 이렇게 텍스트의 관계에 대한 통계적 분석을 사용해서 그래프의 관계를 생성할 수 있답니다.

리프트는 연관 강도인데, 이걸 연관의 불확실성으로 저장하는 게 포인트에요. 나중에 그래프 순회를 하면서 그래프의 거리 측정값으로 활용할 거거든요.

연관성은 연관에 대한 신뢰 척도를 제공해주고, 우리는 그 반대를 취하는 거죠. 연관성 강도가 높으면 불확실성이 낮으니까, 이걸 그래프에 입력하는 거에요.

이 지표를 활용하기

이걸로 뭘 할 수 있을까요?

이전 그래프에는 우리가 탐색하려는 삼각형이 있었죠. 이제 이런 걸 할 수 있어요.를 날려서 "화합물, 유전자, 표현형 또는 질병 사이의 삼각형을 찾고 싶어. 그리고 세 모서리의 거리 합을 구해서, 이 합으로 삼각형 순위를 매길 거야. 맨 위에는 불확실성이 가장 낮은 삼각형이 있겠지?"

이걸 실행했을 때 (왼쪽 그림), 가장 먼저 나타나는 삼각형 중 하나가 타파미디스 아밀로이드 신경병증 (질병)과 트랜스티레틴 (효소)을 연결하는 삼각형이에요. 이게 상식적인 결과인지 확인하려면 어떻게 해야 할까요?

Wikipedia에 가서 찾아보는 거죠. 왼쪽 상자의 텍스트는 타파미디스 Wikipedia 페이지에서 가져온 건데요, 페이지 첫 문장 중 하나에 타파미디스가 아밀로이드 신경병증을 치료하는 데 사용되는 약물이며, 트랜스티레틴 관련 유전성 아밀로이드증 때문에 발생한다고 나와 있어요.

이게 바로 검증, 혹은 검증 방법 중 하나에요. 이 접근법과 연관성을 통해 이걸 잡아낸 거죠.

이걸 다시 실행하면 두 번째로 나타나는 것(오른쪽 그림)은 또 다른 삼각형인데, 텍스트는 역시 Wikipedia 페이지에서 가져왔어요. 카나반병에 대한 내용인데, 이 경우에는 화합물이 약물 치료제가 아니라 실제로 질병을 일으키는 건 이 화합물의 축적 때문이라는 거죠.

여기서 제가 말하고 싶은 건, 우리가 이 관계에 대해 더 자세한 내용을 배우고 있다는 점이에요. 한 경우에는 화합물이 약물 역할을 했고, 다른 경우에는 화합물이 원인 물질 역할을 했죠. 중요한 건 우리가 전체적인 그림을 얻고, 그게 우리가 관심을 갖는 부분이라는 거에요.

그래서 우리는 Wikipedia로 가서 확인하는 거에요. 그런데 Wikipedia가 왜 안 뜨는 걸까요?

위쪽 왼쪽을 보시면, 이전 슬라이드의 두 번째 삼각형 상단에 있던 화합물에 대한 Wikipedia 페이지가 있어요. 이건 N-Acetylaspartic acid에 대한 항목인데, Wikipedia 페이지치고는 좀 짧은 편이죠. 사실 이 페이지에 있는 유일한 내용은 이 화합물과 카나반병, 그리고 이전 슬라이드의 효소와의 관계뿐이에요.

자, 이제 그래프를 사용해서 이 화합물에 대한 쿼리를 실행해서, 이와 관련된 질병의 순위를 매겨볼 수 있어요.

결과는 오른쪽 상자에 표시되는데요. 상위 5개 질병이고, 첫 번째 질병은 카나반병이네요. PubMed 문헌의 데이터니까, 이제 이 연관성을 뒷받침하는 증거를 찾아볼까요?

아래쪽 상자에는 참고할 만한 기사가 하나 있는데, 제목에 바로 이 화합물이 Pelizaeus-Merzbacher 질병에 역할을 한다고 나와 있네요. 저는 처음 알았어요!

세포 분석을 할 때는 질병 자체에는 크게 관심이 없을 수도 있어요. 하지만 기본적으로 이전과 동일한 쿼리를 사용해서, 대신 예를 들어 cellular component가 있는 요소를 검색하면 아래 왼쪽에 결과가 표시될 거예요.

기억하시겠지만, 카나반병은 신경 질환이기 때문에 여기에 표시된 component들은 모두 중추신경계와 관련이 있어요.

오른쪽에서도 비슷한 작업을 하고 있어요. cellular component를 biological process로 바꿨죠. 여기에서 이 화합물과 관련된 biological process 목록을 얻을 수 있어요. 세포 분석에서는 이러한 cellular process가 실제로 우리가 관심을 갖는 부분이에요. 이 모든 게 이 혼합물에서 비롯된 거죠.

결과적으로 PubMed의 내용에 대한 매우 광범위한 주석 또는 지식을 제공하는 셈이에요. 이게 바로 이기종 데이터 세트를 통합하는 텍스트 마이닝이죠.

Graph Database의 기타 데이터 소스

아래 슬라이드는 지금까지 우리가 여기에 넣은 Graph Database의 내용을 보여줘요.

상위 3개 항목인 녹색 항목은 텍스트 마이닝 섹션에서 이미 다뤘었죠. 소스가 10개 더 있어요.

서로 보완할 수 있도록 선택했는데, 독성유전체학 데이터베이스도 있고, 단백질-단백질 상호작용 데이터도 있어요. 시스템 생물학과 경로, 단백질 및 유전자 주석도 가지고 있죠.

이 모든 것을 식별자와 그 안에 있는 개체 측면에서 통합하고 일치시키고 있어요. 현재 이 데이터베이스에는 약 3천만 개의 node가 있고, 앞으로 기사도 추가할 예정이에요. 그리고 이러한 node의 대부분은 이러한 기사들이 될 거예요.

우리에게 특히 중요한 건 약 200만 개의 화합물이 있다는 점이에요. 정말 중요한 숫자죠. 그렇다고 이걸 새로운 유전자나 그와 비슷한 걸 식별하는 데 사용하지는 않을 거예요. 우리에게 중요한 건 관계에 관한 것이니까요.

저희는 약 91개의 서로 다른 관계와 약 4억 개의 `Relationship`을 가지고 있어요. 이 91개의 서로 다른 관계는 저희가 얻는 생물학과 기본 데이터의 풍부함 그 자체랍니다.

아래에서 이러한 관계가 어떻게 나타나는지 간단하게 볼 수 있어요. 여기 두 가지 예시가 있는데요. 단백질은 특정 단백질을 인산화하고, 화합물은 이 단백질의 발현에 영향을 미쳐요. 저희는 여기서 꽤 광범위하게 노력하고 있답니다.

전체 빌드 프로세스

기술적인 측면에 대해 조금 살펴볼까요?

아래는 PubMed 초록이 먼저 Mongo 데이터베이스 (MongoDB)로 들어가는 인프라인데요, 이것이 실제로 텍스트 분석을 주도하는 부분이에요.

가장 큰 이유는 저희가 포스트그레SQL 데이터베이스를 중간에 둔 건 Novartis의 기존 데이터 웨어하우스 때문인데요, 여기에는 내부 및 외부 데이터의 사전 요약 작업이 이미 완료되어 있었어요. 그래서 ETL을 수행해서 이 Postgres 데이터베이스에 데이터를 가져올 수 있었죠.

이건 저희에게 정말 다행스러운 일이었어요. 상상할 수 있듯이, 이러한 업스트림 데이터 웨어하우스를 구축하는 데는 수년이 걸렸거든요.

데이터를 로 가져오기 위해 저희는 CSV 배치 가져오기 도구를 사용하고 있어요. 현재 텍스트 마이닝 등을 수행하는 방법을 정확히 파악하는 중이라, CSV 파일을 통해 이 스테이징을 수행하는 것이 매우 효과적이었답니다.

Neo4j 데이터베이스 사용: 예

저희는 이걸 실제로 무엇에 사용할까요?

여기 한 가지 예시가 있어요. 저는 이러한 영상 분석을 실행하는 것에 대해 이야기했는데요, 많은 경우에 저희는 찾고 있는 것이 무엇인지 알고 있고 이 표현형을 보고 싶어 하며 다른 표현형은 보고 싶지 않아요. 그래서 저희는 화합물을 분류하고 활성 또는 비활성으로 분류할 수 있죠.

이제 이 데이터를 분석하고 싶다면, 과거에 수행했던 작업을 여기에서도 그래프 형식으로 수행할 수 있어요. 저희는 이러한 화합물에 대해 가지고 있는 다른 표적 주석을 찾을 수 있으며, 이를 "표적 강화"라고 부른답니다.

관계형 데이터베이스로도 이 작업을 해왔고, 꽤 성공적이었어요. 하지만 이제 그래프로 넘어가서 이런 질문을 던질 수 있게 되었죠. "특정 거리 내에 있는 각 활성/비활성 화합물에 대해 어떤 `Node`에 도달할 수 있을까요?"

여기서 불확실성이 다시 등장해요. 활성 `Node`에서는 연결할 수 있지만 비활성 `Node`에서는 연결할 수 없거나, 비활성 `Node`보다 활성 `Node`에 훨씬 더 가까운 `Node`를 식별하고 싶은 거죠.

이것이 바로 활성 그룹이 공통적으로 가지고 있는 것이라는 아이디어에요. 유전자일 수도 있고, 생물학적 과정일 수도 있고, 활성 물질과 비활성 물질을 구별하는 경로일 수도 있죠.

아래 슬라이드는 이와 관련된 전문성을 조금 보여줍니다.

이러한 `Query`를 실행하면 정보 행을 얻게 돼요. 각 행에는 화합물인 `Node`까지의 거리가 나와 있고, 이를 모든 화합물에 대한 거리 측정 기준으로 변환하죠. 이 `Node`까지의 거리를 나타내는 표시 열이 있고, 도달할 수 없는 경우에는 매우 높은 값으로 설정합니다.

앞서 수십만 개의 화합물에 대해 이 작업을 수행한다고 말씀드렸죠. 이건 생물학자가 저에게 준 예시인데, 34개의 화합물이 있어서 여기에 표시하기 쉬워요.

그 다음엔 파티셔닝을 실행할 거예요. 활성 성분과 비활성 성분을 구분하는 컷(cut)을 찾으려고 하죠. 오른쪽 예시에서는 한쪽에 있는 14개의 활성 항목 중 12개를 나누고, 다른 쪽에는 모든 비활성 항목을 분할하는 컷을 찾을 수 있어요.

이런 의사결정 트리나 분할 방식이 작동하는 것처럼, 다른 분할도 찾을 수 있는데, 이걸 대리 분할이라고 하고 저희도 사용하고 있답니다.

이 예시에서는 다음 슬라이드에 보이는 것처럼, 찾고 있던 내부 `node` 두 개를 찾았어요.

이것들은 이제 활성 화합물이고, 파란색은 compounds, 빨간색은 이 네트워크에 있는 `node`이며, 이 경우에는 모두 genes에요. 노란색 강조 표시는 화합물이 원하는 표현형을 나타내는지 여부를 결정하는 것으로 보이는 두 개의 중앙 `node`를 보여주고 있죠.

이 예시에서는 그게 사실로 밝혀졌어요.

제가 이걸 보여드리는 또 다른 이유는 `관계(relationship)`가 출처 날짜에 따라 색상이 지정되기 때문이에요.

녹색 링크는 compound와 초기 `node` 계층 간의 모든 연결인데, 여기에는 internal data가 있어요. 나머지 회색은 이러한 연관 규칙에서 나온답니다.

이걸 확인할 수 있다는 건, 이런 모든 데이터 소스를 통합하고 텍스트 마이닝을 통한 분석을 수행하지 않고는 불가능한 일이라는 거죠.

하지만 그게 정말 사실일까요? 이 경우에는 이런 연관 규칙, 무슨 일이 일어나고 있는지, 그리고 왜 다르게 할 수 없는지 알아보고 싶었어요.

여기서 목표는 회색 연관 규칙을 무시할 때, 왼쪽 위 그래프에서 연결을 찾는 거예요. 모든 `관계(relationship)`에는 해당 `관계(relationship)`의 출처인 데이터 원본이 주석으로 추가되니까, 텍스트 마이닝 없이도 동일한 `쿼리(query)`를 실행할 수 있죠.

6개의 `node`가 들어 있는 파란색 상자가 초점인데요. 슬라이드 오른쪽에는 파란색 상자의 `node`에만 초점을 맞춘 새로운 `쿼리(query)` 결과가 있어요.

노란색 원이 있는 6개의 `node`는 왼쪽의 파란색 상자에 있는 `node`들이에요. 그들 사이의 연결을 찾을 수 있지만, 연결은 훨씬 더 복잡해 보이죠. 이런 불확실성을 요약하면 훨씬 약한 진술이 된답니다.

따라서 연결 결과의 역할은 이런 모든 기본 데이터 소스에 대한 지름길을 제공하는 거예요. 이제 이걸 식별하기 위한 지름길로 삼을 수 있고, 이걸 드릴다운해서 진행 상황을 더 잘 이해할 수 있어요.

대부분의 초록이 데이터베이스를 통해 문헌에서 나오기 때문에, 초록이 바로 여기서 등장하는 거죠.

연관 규칙 심층 분석

이런 연관 규칙이 있다면, 이걸 뒷받침하는 증거가 뭔지 알고 싶을 거예요.

위는 앞서 실행했던 쿼리와 동일하며, 보라색 구체는 모두 이 연관성에 대한 증거를 구성하는 기사들이에요. 데이터베이스에 해당 내용이 있으니 클릭하면 해당 기사의 내용을 볼 수 있죠.

슬라이드의 오른쪽 하단에 표시된 것은 우리가 확인한 것과 동일한 관계에 대해 설명하며, 테스트한 것과 유사하게 작용해야 하는 화합물에 대해서도 설명하고 있어요.

따라서 우리는 이 그래프에서 가설을 찾았을 뿐만 아니라 이제 가설을 테스트하고 화합물이 이 그래프에서 예측한 대로 작동하는지 확인할 수 있는 방법도 갖게 된 거죠. 아직 이 단계를 완료하지 않았지만요.

결론: 생물학적 지식에 대한 현실 점검

저는 약간의 현실 점검을 하고 다시 생물학적 지식에 대한 질문으로 돌아가고 싶어요.

위는 앞서 보여드린 결과이며, 처음 실행했을 때와 비슷해요. 그 시점에서 우리는 사물 사이의 연관성을 확인하려고 노력했죠.

그래서 우리가 처음 이 일을 했을 때 결과를 보고 생물학자에게 가서 "어떻게 생각하세요? 그게 말이 되나요?"라고 물었어요. 그리고 우리가 받은 피드백은 "나도 그럴 줄 알았어"라는 것이었고 거기에는 약간의 실망감도 있었죠. 왜냐하면 생물학자는 우리가 자신이 알지 못했던 정말 새로운 통찰력, 즉 멋지고 놀라운 것을 발견하길 원했기 때문이에요.

하지만 대부분의 경우에는 이것이 작동하는 방식이 아니에요.

귀하의 화합물이 어떻게 작동하는지 알아낼 수 있고 왜 그런 일을 하는지에 대한 새로운 통찰력을 얻을 수 있지만, 그것이 항상 엄청난 결과를 가져오는 것은 아니죠.

하지만 첫 번째 슬라이드 중 하나에 대해 말했듯이, 제가 이 생물학적 지식을 포착하려고 시도하는 것을 설명했을 때 매우 모호하고 그것이 무엇을 의미하는지 정확히 알지 못해요.

하지만 여기에는 데이터에서 추론할 수 있는 중요한 내용이 있으며, 이는 대부분 생물학적 개체 간의 관계에 관한 것이에요. 그리고 이것을 생물학자에게 가져갔고 생물학자가 "나도 알아요"라고 말한다면 그것은 생물학적 지식인 거죠.

이것이 바로 우리가 문헌과 이러한 데이터 소스를 결합하여 Graph Database에 포착하려고 하는 것이에요.

이 연구가 진행되는 곳

단기적으로 이 문제를 해결하기 위해 노력하고 있는 작업 목록은 다음과 같아요.

우리는 텍스트 마이닝을 통해 더 나은 작업을 수행하려고 노력하고 있어요. 이제 우리는 주로 데이터 마이닝 내부 문서를 목적으로 초록뿐만 아니라 전문 분석을 시작했죠.

우리는 또한 사용할 임계값을 선택하는 것으로 시작된 불확실성의 개념을 살펴보고 있지만 이에 대해 좀 더 합리적으로 생각해야 할 몇 가지 사항이 있어요.

현재로서는 라이브러리에 새로 추가된 내용으로 데이터베이스를 자동으로 업데이트하는 방법이 없어요.

매일 새로운 기사가 ​​출판되어 도서관에 추가되지만 우리는 이를 자동으로 가져오는 프로세스를 갖고 있지 않죠. 그리고 항상 더 많은 데이터가 있어요. 의도적으로 거기에 없는 것은 유전자, 유전자 발현 데이터 등 많은 게놈 데이터에요.

일단 거기에 넣으면 데이터베이스 크기가 최소한 두 배는 될 거예요.

  • Association Rule Mining
  • Drug Discovery
  • Graph Technology
  • GraphConnect
  • Heterogeneous Data
  • Novartis
  • PubMed

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

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

반응형
반응형
  • Machine Learning

편집자 주: 이 프레젠테이션은 그래프커넥트 뉴욕 2018년 9월 행사에서 진행되었어요.

프레젠테이션 요약

오늘날 많은 의료 기관들은 의료 시스템의 아주 작은 부분만 보고 있는 것 같아요. 헬스케어에 대한 통찰력을 얻기 위해 장기적인 관점에서 전체적인 접근 방식을 취하는 경우는 드물죠. 높은 비용의 대부분은 연결된 정보가 부족하기 때문에 발생한다고 해요.

개인의 건강 관리를 개선하기 위한 고품질 예측을 하려면 많은 데이터 포인트를 고려해야 한다는 의미겠죠. 헬스케어 영역에서는 그래프의 활용도가 다소 낮은 편인데, 헬스케어 데이터가 그래프 구조에 정말 잘 들어맞기 때문에 아쉬운 부분이에요.

이번 포스팅에서는 Optum의 저명한 엔지니어 분이 의료 데이터 연결을 더욱 발전시키는 방법에 대해 설명해 주실 거예요. 먼저 몇 가지 배경 설명을 해주실 텐데요. 그래프와 의료 데이터, 그리고 이 데이터가 어떻게 표현되는지에 대한 예시를 포함해서요. 또, 데이터가 매우 가변적이기 때문에 기존의 엄격한 관계형 데이터베이스에 저장하기 어려운 이유도 알아볼 거예요. 그런 다음 의료 데이터를 그래프에 저장하는 것의 이점과 데이터 세트 연결과 같은 그래프 데이터베이스의 기능도 보여주실 거예요.

뿐만 아니라, 오늘날 의료 분야의 도전 과제와 그래프 기술이 어떻게 도움이 될 수 있는지 알아볼 거고요. 또, 관리자에게 그래프를 설명할 수 있는 세 가지 은유도 제공해주신다고 해요. 마지막으로 그래프가 다른 기술과의 결합을 통해 의료 분야의 수많은 심각한 문제를 해결하는 데 핵심적인 역할을 하고 있다는 결론을 내릴 거예요.

전체 프레젠테이션: 연결된 의료

오늘 발표는 헬스케어 연결에 관한 내용이에요.

이번 포스팅에서는 의료 분야에서 직면한 과제와 과거에 Graph Database를 선택하지 않았던 이유를 자세히 살펴볼 거예요. 그런 다음 그래프가 의료 분야에서 어떻게 도움이 될 수 있는지 그림을 통해 보여드릴게요.

마지막으로 의료 경영진에게 Graph Database가 필요한 이유를 설명하기 위해 어떤 과정을 거쳤는지도 간단히 살펴볼게요. 이러한 경영진은 실제로 시스템을 구축하는 사람이 아니라 어떤 시스템을 구축할지 결정하는 사람들이기 때문에 이 부분이 중요하죠.

결국 중요한 건 우리가 그걸 이해하느냐가 아니라, 다른 사람에게 설명할 수 있는 적절한 비유가 있느냐 같아요. 앞으로 포스팅에서 이런 비유들을 좀 더 자세히 다뤄볼게요.

배경

Optum을 들어본 적이 없다면, 저희는 사실상 UnitedHealth Group의 IT 부서라고 할 수 있어요. 저희의 미션은 사람들이 더 건강하게 살도록 돕고, 모두를 위해 의료 시스템이 더 잘 작동하도록 만드는 것이죠.

UnitedHealth Group은 2017년에 약 2,000억 달러의 매출을 올렸고, 직원 수는 25만 명이 넘으며 IT 직원은 42,000명이나 돼요. 저희는 데이터 분석을 위해 연간 10억 달러 이상을 투자하고 있고, 데이터 과학 부서에는 3,000명이 넘는 직원이 근무하고 있답니다.

이들 대부분은 매우 전통적인 메인프레임과 관계형 DB에 익숙해요. 특히 저희가 최첨단 기술을 가진 의료 회사를 많이 인수하지 않았기 때문이기도 하죠. 하지만 저희는 데이터 때문에 그 회사들을 인수하는 거고, 이 데이터에 접근하는 것이 좋은 예측 모델을 만드는 데 핵심이에요.

Optum에서는 Advanced Technology Collaborative라는 프로젝트도 진행 중이에요. 여기서 "협업"이라는 단어가 특히 중요한데, 저희의 임무는 인수된 다양한 조직들이 모두 함께 작동하도록 만드는 것이기 때문이에요. UnitedHealth Group은 매년 20~30개의 새로운 회사를 인수하거든요.

이러한 조직과 회사들은 다양한 방식으로 데이터를 저장하기로 결정하죠. 아래 이미지에 보이는 것처럼 6가지 기본적인 고급 패턴을 식별할 수 있어요.

관계형 DB는 왼쪽 상단에 있는데, 여기에는 모든 것을 테이블 형식의 견고한 구조로 배치하죠.

모든 사실이 중간에 있는 분석도 있어요. 이건 집계 보고에 적합하지만, 아시다시피 집합은 지식이 아니잖아요.

그리고 키-값 저장소, 열 패밀리, 그래프, 문서라는 네 가지 NoSQL 패턴이 있어요.

저희가 많은 것을 연구했지만, 오늘날 의료 분야에서 가장 활용도가 낮은 것 중 하나는 Graph Database에요. 의료 데이터가 일반적으로 그래프 구조에 아름답고 정확하게 들어맞기 때문에 정말 안타까운 일이죠.

제가 과거에 본 것은 많은 조직이 하나의 기술에 의해 지배되고 있다는 거예요. 예를 들어, 솔루션 공간에 단일 관점만 가져오는 관계형 DB일 수 있죠.

지금 이야기하려는 건 빠르게 변화하는 의료 데이터 세상에서 경쟁력을 갖추려면 다양한 관점이 필요하다는 거예요. 단순한 그래프뿐만 아니라 키-값 저장소, 검색 엔진, 멀티 모델 시스템 등 다른 것들과 결합된 그래프 말이죠. 이런 점이 의료 분야 조직들이 경쟁력을 갖게 되는 이유랍니다.

아키텍처 접근 방식

그럼 이제 그 과정에 대해 조금 더 자세히 알아볼까요? 아래 이미지 맨 윗줄을 보면 특정 시스템의 요구 사항과 품질 특성을 결정하는 다양한 방법들을 확인할 수 있어요.

지금 보고 있는 건 맨 아래 행, 즉 아키텍처적 접근 방식이 포함된 중간 상자를 이러한 다양한 솔루션으로 채우려고 한다는 점이에요.

이건 Carnegie Mellon University에서 개발된 프로세스인데요, Architecture Tradeoff Analysis Method (ATAM)이라고 해요. 다양한 접근 방식의 순위를 매기고, 적합성을 분석하고, 장단점을 이해하는 데 도움이 되죠.

여기서 우리가 알 수 있는 점은 특정 접근 방식에는 고가용성 또는 복잡한 규칙을 관리하는 능력과 같은 중요한 요구 사항이 있는데, 이게 종종 그래프 시스템에 아주 적합하다는 거예요.

의료 분야의 과제

자, 이제 의료 분야의 큰 문제에 대해 이야기해 볼까요?

Optum에서는 완전히 다른 일을 하는 많은 회사를 인수해요. 예를 들어, 실험실 테스트를 하는 회사, MRI를 찍는 회사, 안과 검사를 하는 회사 같은 곳들이죠. 이 모든 데이터는 높은 가변성과 다양한 형식 때문에 완전히 달라요.

헬스케어에는 약품명, 증상, 질병 등 복잡한 용어가 엄청나게 많다는 것도 문제죠.

더욱 신뢰를 쌓기 위해 노력하고 있는데, 이건 그래프가 하도록 설계된 건 아니지만, 블록체인 및 블록체인 기술을 연구하면 의료 기관이 더 나은, 더 신뢰할 수 있는 방식으로 데이터를 교환하도록 돕기 위해 우리가 어떻게 노력하고 있는지 알 수 있을 거예요.

우리는 또한 엄청난 개인 정보 보호 문제도 안고 있어요. 의료 개인 정보 보호와 건강 보험 이동성 및 책임법 (HIPAA)에 대해서는 다들 아실 텐데요. 따라서 우리 시스템이 개인 건강 정보 (PHI) 데이터를 보관하는 방식을 엄격하게 감사해야 해요.

챗봇으로 작업도 시작하고 싶었어요. 환자가 챗봇을 열고 "독감 주사가 내 건강 보험에 포함되나요?"라고 물어볼 수 있다면 정말 좋겠죠?

마지막 두 가지 과제는 Machine Learning (ML) 확장성 문제뿐만 아니라 설명 가능성도 있다는 점이에요.

통합 과제

좋아요. 가장 먼저 해야 할 일은 통합 문제예요.

오늘날 우리는 서로 다른 회사에서 서로 다른 기술로 서로 다른 시점에 구축된 서로 다른 시스템을 실행하는 경우가 많아요. 우리는 이 모든 것을 사일로라고 생각하는데요. 사람들이 분석을 수행할 때 일반적으로 하나의 사일로에서만 수행하죠. 여러 사일로의 데이터를 병합하는 건 정말 어려운 일이에요.

우리가 하고 싶은 건 모든 헬스케어 관련 정보들이 제대로 연결되는 세상을 만드는 거예요. 바로 Knowledge Graph를 통해서죠. 모든 것을 통합하는 걸 엔티티 해결이라고도 부르는데요. 여기엔 요양원에 사람들을 데려다주는 운전기사님부터 복잡한 임상 시스템, 전자 의료 기록, 처방전, 약물 알레르기, 심지어 전체 게놈 정보까지 포함돼요. 이 모든 것들이 환자 개개인의 의료 기록에 데이터를 제공하는 거죠.

우리의 비전은 이 모든 정보가 결국 하나의 거대한 연결된 그래프에 담기는 거예요. 물론 장기적인 목표이긴 하지만, 우리가 추구하는 방향이기도 하답니다.

데이터 가변성

데이터 가변성에 대해 이야기해볼까요? 아래 이미지를 보시면 모든 회사에 총계정원장이 있지만, 그 구조가 꽤나 일관적이라 변동성이 낮다는 걸 알 수 있을 거예요.

반대로, 오른쪽 끝을 보면 임상 데이터는 변동성이 엄청 높다는 걸 알 수 있죠.

그래서 저희는 종종 조직들에게 데이터의 변동성에 대해 알려주고, 기록 중에 예외가 얼마나 있는지 측정해달라고 요청하곤 해요. 때로는 특정 항목을 포함하는 레코드가 단 1%밖에 안 되더라도 데이터베이스에 추가 컬럼을 만들어야 하고, 테이블이 너무 넓어져서 비효율적이 될 수도 있거든요.

게다가 미래의 변동성을 예측하는 건 정말 어려운 일이에요.

챗봇

저희는 챗봇을 만드는 과정도 진행 중이에요.

예를 들어, 출산을 앞둔 환자가 의료 시스템 챗봇을 통해 보험 적용 범위를 문의할 수 있겠죠. 이런 시나리오에서는 '신생아'와 '임산부 보험' 간의 연관성을 아는 챗봇이 필요해요. 이를 위해선 대체 단어와 레이블을 선택해서 연결해주는 작업이 필요하죠.

그럼 어떻게 해야 할까요? 그래프를 만들어서 해결하는 거죠!

위 예시에서는 모든 혜택 플랜에 대한 분류 체계를 구축했어요. 채팅과 질문이 들어올 때마다 해당 분류가 추가되는 방식이죠. 이러한 분류법은 두 가지 목적으로 사용하고 있어요.

첫 번째 목적은 새로운 혜택 계획이 게시될 때마다 그 안에 있는 단어를 보고 해당 분류의 올바른 부분과 연결하는 거예요. 이걸 우리는 문서 분류 문제, 즉 document classification 문제라고 부르죠.

두 번째 목적은 이 그래프의 패턴을 살펴보는 건데요. 예를 들어, 아기가 성장하면서 나무를 걸을 때, 이게 산모 관리 나무와 얼마나 밀접하게 관련되어 있는지를 나타낼 수 있어요.

이것이 검색에 도움이 되도록 그래프를 사용하기 시작하는 표준 방식이에요. 답변된 채팅이 많을수록 콜센터에 걸려오는 전화가 줄어들죠. 회사에서 전화를 받고 이와 같은 질문에 답변하는 데 일반적으로 10달러 정도의 비용이 들기 때문에 이건 정말 중요한 부분이에요.

하지만 현재는 모든 사람의 혜택 플랜, 공제액 및 자기부담금이 다르기 때문에 이걸 쉽게 수행할 수 없어요. 이런 방식으로 우리는 매우 동적인 데이터베이스를 찾아야 하는 거죠.

연결된 데이터의 가치

우리가 묻기 시작한 질문은 바로 이거였어요. 연결된 데이터는 왜 중요할까요?

얼마 전에 한 그룹이 우리를 찾아와 이전에 해본 적이 없는 새로운 유전자 검사를 받았는데, 점점 더 저렴해지고 있다고 말했어요. 그리고 그들은 또한 의료 기록과 관련된 ICD9 진단 코드를 가지고 있었죠. 그들은 어떤 유전자가 이러한 진단 코드와 연관되어 있는지 알아내기 위해 어떤 유전자 검사를 권장해야 하는지 알고 싶어했어요.

우리가 직면한 문제는 이러한 연결 중 일부는 있지만 전부는 아니라는 점이었어요. 우리가 보고 있는 것은 이러한 것들을 함께 매핑하는 데 도움이 되는 다른 온톨로지를 추가하고 싶다는 것이었죠.

우리는 개방형 링크 데이터 연결에서 이러한 온톨로지를 많이 발견해요. Unified Medical Language System이라는 시스템이 있는데, 개념과 연결된 ICD9 코드 데이터베이스가 있죠. 이걸 그래프에 넣으면 그래프 순회를 수행할 수 있고, 이제 올바른 ICD9 코드와 관련된 유전자 테스트를 추천할 수 있게 되는 거예요.

우리가 하려는 것은 의료 시스템에서 볼 수 있는 다양한 개체를 모두 포함하는 연결된 의료 네트워크 그래프를 구축하는 것이에요.

위 이미지는 제공자, 그리고 해당 제공자의 추천 등에 엄청 관심이 많은 그룹과의 일반적인 화이트보드 세션에서 얻은 메모예요.

종종 우리는 똑같은 정보 차트를 문서에 넣고 다른 그룹을 만나는데, 그들은 정확히 그게 그들이 원했던 거라고 말하면서 예를 들어 제공업체에 대한 순 추천 점수에도 관심이 있다고 해요. 이런 식으로 차트는 계속 커지고, 결국 이 모든 정보를 하나의 그래프에 추가해야 하는 거죠.

이렇게 많은 정보가 서로 연결된 적은 없었어요. 관계형 모델에서 이 작업을 수행하면 너무 복잡해지거든요. 이제 우리의 희망은 데이터를 그래프에 담음으로써 과거에는 한 번도 만들어지지 않았던 연결을 만드는 거예요.

그렇다면 우리는 무엇을 향해 나아가고 있을까요? 우리는 개인의 건강관리 기록을 개인의 Knowledge Graph에 저장하고 연결하는 방향으로 나아가고 있어요.

이제 ICD9 코드가 있는 진단이 있다면, 해당 코드를 개별 그래프에 저장할 수 있지만, 이는 의료에 대한 모든 지식이 포함된 엄청나게 큰 그래프를 가리키게 될 거예요.

우리는 기록과 이러한 보편적인 지식 사이에 풍부한 지침이 있을 거라고 기대하고 있어요. `Query`는 두 가지 모두에 액세스할 수 있어야 하죠. 하지만 특정 병원의 개별 환자를 잠가서 해당 환자에 대해서만 `Query`를 수행할 때 다른 환자를 볼 수 없도록 할 수도 있어야 해요.

여러 환자 풀에 걸쳐 높은 수준의 통계를 수행하는 경우도 있기 때문에, 모든 환자 기록에 대해 매우 강력한 역할 기반 액세스 제어가 필요하고, 여전히 이러한 보편적인 지식에 연결될 수 있어야 해요.

그래프는 도메인 간 솔루션을 홍보합니다.

여기서 우리가 실제로 하고 있는 일은 데이터를 보는 새로운 방법을 제시하는 거예요.

과거에 Optum 직원들은 관계형 데이터베이스 모델이 고정되어 있고 변경할 수 없다고 생각했어요. 새 `column`을 추가할 수는 있지만, 보고서가 10,000개라면 그 중 10,000개 모두에 대해 SQL을 변경해야 하죠. 그렇게 하려면 50만 달러나 들고요.

이제 우리는 사람들에게 그런 걱정은 하지 말라고 말하고 있어요. 누구나 데이터를 추가할 수 있어야 한다는 거죠. 우리 모두는 통화 기록에서 데이터를 수집하고, 이를 함께 추가하고, 공개 데이터 세트를 활용할 수 있어야 해요.

예를 들어, 우리 콜센터 중 한 곳에는 메디케어 혜택을 받고 은퇴한 분들이 많이 계신데, 그분들 대부분은 운전을 하지 않으세요. 그래서 버스 노선 근처에 있는 서비스 제공업체를 추천하고 싶어 했죠.

물론 우리는 버스 노선에 대한 공개 데이터에 접근할 수 있고, 버스 노선과의 거리를 기준으로 모든 제공업체의 순위를 매길 수 있어요. 버스 경로 데이터를 며칠 만에 빠르게 추가할 수 있었는데, 관계형 데이터베이스였다면 1년이나 걸리는 프로젝트였을 거고, 비용도 엄청났을 거예요.

언제든지 새로운 데이터 세트를 추가하고 서로 연결할 수 있다는 점이 더 나은 가치를 더 빠르게 제공하는 데 큰 도움이 되었죠.

설명 가능한 AI 모델

만약 여러분이 큰 Knowledge Graph를 가진 병원에 있다고 상상해 볼게요. 이 그래프에서 Machine Learning을 실행했을 때, 당뇨병 진단 테스트를 하라고 권장한다면 의사는 왜 그렇게 권장하는지, 왜 신뢰할 수 있는지 물어볼 수 있겠죠?

이게 바로 오늘날 우리가 전통적인 Deep Learning 모델을 사용할 때 마주하는 문제점이에요. 단순히 작동하는 것보다 Machine Learning 프로세스가 우리가 "설명 가능한 모델을 학습했다"라고 부르는 것을 업데이트하는 새로운 아키텍처를 향해 나아가고 싶은 거죠.

이 모델은 Machine Learning을 수행하면서 계속 업데이트되는 그래프에요. 덕분에 의사나 환자는 Bloom과 매우 유사한 인터페이스를 통해 질문을 할 수 있게 되죠. "왜 이걸 추천했나요?", "설명해주세요", "이게 왜 중요한지에 대한 가중치의 흔적을 보여주세요", "몇 가지 측정 항목을 알려주세요", "시스템에 어떻게 피드백을 줄 수 있나요?" 와 같은 질문들이요.

이러한 질문들은 설명 가능한 인공지능(AI) 모델이 신뢰도를 높이는 답변을 제공할 수 있도록 도와줄 거예요.

설명이 부족한 Deep Learning 알고리즘은 의료 시스템에서 사용하기 어렵겠죠. 그래서 우리는 그래프 모델을 사용하는 것이 설명 가능한 AI를 구축하는 훨씬 더 좋은 방법이라고 믿고 있어요.

모델 기반 Machine Learning

또 하나 살펴볼 것은 모델 기반 Machine Learning이에요.

오늘날 Machine Learning을 공부한다면, 일반적으로 많은 변수를 가져와 평면화해서 feature (일반적으로 테이블 형식 함수)에 넣을 거예요. 그리고 이 평탄화를 풀기 위해 복잡한 알고리즘들을 사용해야 하죠.

우리가 추구하는 것은 해당 데이터에 대한 가정을 인코딩하는 단일 그래프에 대한 아이디어예요. 이 아이디어를 사용하면 알고리즘이 훨씬 이해하기 쉬워질 거라고 생각해요.

이 모든 걸 모델 기반의 Machine Learning이라고 부르는데, 여기서 그래프는 학습 과정에 아주 중요한 역할을 해요.

마무리로, 이 모든 것을 경영진에게 설명하기 위해 사용했던 몇 가지 비유를 소개해 드릴게요. 실제로 이러한 비유 중 일부는 Neo4j의 교육 수업에서도 사용되고 있답니다.

그래프가 다른 방식이라는 걸 이해하는 데 도움을 주기 위해 우리가 사용해 온 세 가지 주요 비유가 있어요. 바로 동네 걷기, 열린 세계 가정, 그리고 지식 삼각형이죠.

동네 산책

여러분이 이웃집에 놀러 가고 싶다고 가정해 봐요. 어떻게 하시겠어요? 당연히 현관문을 열고 밖으로 나가서 그들의 집을 가리키며 그곳으로 걸어갈 거예요.

이건 정말 간단하고 직접적인 방법인데, 그래프 데이터베이스에 영구 포인터를 저장해서 관계를 저장하는 방식에 대한 비유가 될 수 있어요. 현실 세계에서 관계가 있는 모든 항목과 인접해 있고, 이걸 한 홉(hop) 떨어진 유선 포인터로 저장하는 거죠. 즉, 이웃집에 가기 위해 다른 어떤 것과도 상의할 필요가 없다는 뜻이에요.

그럼 이걸 어떻게 모델링할까요? 우리는 그걸 그래프로 모델링해요. 예를 들어, 아래 코드에서 Dan은 Ann 옆에 살고 있어요. 그래서 우리는 물리적 세계에서 아주 좋은 관계를 화이트보드에 그릴 수 있는 것으로 보는 거죠.

이걸 메모리에 영구 포인터를 저장하지 않는 관계형 데이터베이스에서 관계가 계산되는 방식과 비교해 볼게요. 실제로 인접할 때 "where" 절은 검색을 의미해요. 해당 검색은 검색을 완료하기 위해 중앙 시스템으로 들어가야 하죠.

여기 그림은 이웃집으로 직접 걸어갈 수 없다는 걸 보여줘요. 대신, 인덱스 타운으로 가려면 시내를 걸어가야 하는 거죠.

그렇다면 인덱스 타운은 뭘까요? 음, DMV처럼 줄을 서서 기다리는 거대한 관료적 건물인데, 정말 오랜 시간이 걸려요.

마침내 줄 맨 앞에 도착하면 123 Main Street으로 가고 싶다고 말하죠. 그러면 그들은 그 주소를 컴퓨터에 연결하고 이진 검색을 수행할 거예요. 데이터가 많을수록 검색 속도가 느려지죠. 또한 얼마나 많은 데이터를 갖게 될지 모르기 때문에 성능을 예측하기 어려워요. 마지막으로, 그들은 그 기록을 찾아 여러분에게 GPS 좌표를 제공하고, 여러분은 그 좌표를 여러분의 휴대폰에 연결한 다음 이웃집으로 걸어갈 수 있는 거예요.

정말 어리석은 이야기처럼 들리지만, 특히 여러분이 그걸 기억하길 바라기 때문에 일부러 어리석게 만든 이야기예요. 실제로 우리는 이걸 테스트해 봤어요. 2주 후에 누군가에게 그래프와 관계형 데이터베이스의 차이점을 설명할 수 있는지 묻는다면 이 이야기를 기억한다면 표현하려고 할 거예요.

돌아가서 메모를 살펴봐야 할 수도 있지만, 이건 효과가 있는 이야기예요. 이걸 테스트하고, 교육에서 이 작업을 수행한 지 2주 후에 설문조사를 보내서, 얼마나 많은 사람들이 이를 설명할 수 있는지 물어볼 수 있죠.

그래프를 독특하게 만드는 한 가지를 생각해 보면 인덱스 없는 인접성(index-free adjacency)을 이해하는 거예요. 하지만 아무도 그 용어를 기억하지 못하죠. 하지만 그들은 이 비유를 기억할 것이므로 이를 설명하기 위해 사용하도록 노력해 보세요. 특히 이걸 이해하고 싶지만 복잡한 기술 용어를 기억할 시간과 에너지가 없는 관리자가 있는 경우에는 더욱 그렇겠죠.

오픈 월드 시나리오

우리가 사용하는 두 번째 이야기는 오픈 월드 시나리오, 또는 오픈 월드 가정이라고 해요. 우리는 의미론과 기술 논리의 세계에서 이 용어를 빌려왔어요.

관계형 세계에는 닫힌 세계라는 것이 있어요. 모델링하지 않는 한 모든 것이 데이터베이스에 저장되는 것이 금지되어 있다는 의미에서 닫혀 있는 거죠. 즉, 이에 대한 규칙을 만들지 않으면 권한 규칙을 만들 때까지 모든 것이 금지돼요. 모델링하는 데이터만 추가할 수 있으며 해당 데이터를 추가하면 향후 모든 쿼리에 영향을 미칠 수 있어요. 이건 정말 지루한 작업이죠.

좋은 세상은 데이터 사용을 금지하는 특정 규칙을 넣지 않는 한 데이터베이스의 모든 것이 허용되는 열린 세상이에요.

관계형 데이터베이스와 Graph Database의 중요한 차이점은 Graph Database에서 특정 유형의 새로운 node를 생성할 때 를 사용한다는 점이에요. 따라서 query에서도 이러한 관계를 사용하고, 와일드카드는 사용하지 않죠.

일반적으로 오픈 월드 시나리오에서는 규칙이 없는 한 모든 것이 허용돼요. Query를 올바르게 작성하면 기존 보고서를 방해하지 않고 새 데이터를 추가할 수 있어서 세상이 완전히 달라져요. 이 모든 것이 우리의 그래프를 더욱 모듈식으로 만들고, 더욱 개방적으로 만들고, 구축하고 테스트하기 쉽게 만들어주죠. 열린 세상은 우리에게 민첩성을 제공해 준답니다.

지식의 삼각형

세 번째는 지식 삼각형이에요. 아래에 표시된 지식 삼각형은 하단에 시스템의 숫자 코드, 조회 테이블 및 선택 목록을 포함하는 낮은 수준의 이진 데이터가 있는 다른 경우에서 본 것과 매우 유사해요.

원천:위키피디아.

게다가 우리 세계의 명사라는 개념도 있죠. 그런 다음 그래프 수준의 패턴과 관계를 포함하는 지식을 갖게 돼요.

마지막으로, 우리는 프로젝트 전반에 걸쳐 재사용 가능한 방식으로 지식을 구조화할 수 있는지 묻는 지혜와 AI를 보유하고 있어요.

우리는 건축에 많은 돈을 썼어요 Data Lake 회사에서. Data Lake는 트랜잭션 시스템에서 데이터를 꺼내어 한 곳에 보관하여 트랜잭션 시스템을 지속적으로 방해하지 않는 방식으로 반복해서 query할 수 있는 유용한 메커니즘이었어요. 속도가 느린 관계형 데이터베이스의 부담을 덜어내고 저렴한 방법으로 저장했죠.

그러나 많은 조직에서는 Data Lake에 대한 BOM을 판매했어요. 그들은 그 자체가 데이터베이스일 것이라고 생각했지만, 우리가 그 숫자 코드를 모두 합쳤을 때, 우리는 그것을 해독할 도구가 없었죠.

이제 우리는 AI, Machine Learning, 복잡한 규칙 엔진을 포함한 완전히 새로운 세대의 도구가 필요하다고 말하고 있어요. 우리는 실제로 그래프 기술을 사용하여 Data Lake에서 데이터를 추출하고 이를 연결 해제 명사에 넣는 동시에 이를 검증하고 일관성을 유지하고 있죠.

거기에서 우리는 함께 모여 새로운 관계를 찾고 싶어해요. 엔터티 결의 캠프입니다. 에너지 분해능을 실제로 향상시키기 시작하는 몇 가지 환상적인 도구가 있어요. 이 데이터를 보고 연결을 시작할 수 있죠.

마지막 단계는 아래 이미지 맨 위에 나와 있어요. Google에서 전이 학습 개념을 검색해보면 AI 모델에서 어떻게 학습하고 캡처하는지 알 수 있을 거예요. 재사용할 수 있는 부분은 굳이 많은 교육을 할 필요가 없죠. 그런 다음 기본 모델이나 이미지 모델 위에 특정 유형의 이미지 및 사용자 정의를 위한 모델을 추가하는 거예요.

의료 분야에서는 용어와 관련된 전체 참조 데이터 세트를 가지고 있어요. 우리는 모든 애플리케이션에서 사용할 수 있는 균일한 그래프 구조로 모든 의료 용어를 표현하기 위해 열심히 노력하고 있답니다.

이건 야심찬 목표이긴 하지만, 우리가 인수한 조직 내에서 이미 이 데이터를 복제한 수백 명의 사람들이 있기 때문에 지금 당장은 정말 중요해요. 그리고 모든 데이터를 하나로 모으는 것이 우리의 임무랍니다.

외경암 유전자 이야기

그렇다면 여기서 중요한 건 뭘까요? 인과 관계에 대한 환상적인 이야기인 Dana Mackenzie와 Judea Pearl의 "The Book of Why"를 읽어보셨다면, 인과 관계 그래프를 작성해서 데이터를 훨씬 더 깊이 이해할 수 있는 방법을 이해하게 될 거예요.

왼쪽에 있는 이야기는 "The Smoking Gene"이라고 불리는 믿을 수 없는 이야기예요. 많은 담배 회사에서 홍보하면서 이렇게 말했죠: "아마도 당신의 몸 안에 담배를 피우고 싶게 만드는 유전자가 있을 거예요. 당신이 폐암에 걸리는 것도 우연이지만, 아마도 흡연 충동과 폐암 사이에는 직접적인 관계가 없을 거예요. 폐암은 동일한 근본 원인인 흡연 유전자에 의해 발생하기 때문에 발생하는 거죠."

불행하게도 거의 20년 후에 우리가 발견한 것은 흡연과 폐 타르 사이의 인과관계뿐 아니라 타르와 폐암 사이의 인과관계도 이해할 수 있다는 거예요. 이게 오른쪽에 보이는 그래프랍니다.

우리는 사람들이 효과적이지 않을 수 있는 의료 보장을 받으려고 하는 시나리오에서 이와 동일한 현상을 반복해서 보게 돼요. 비타민의 장점은 뭘까요? 동종요법과 침술의 이점은 뭘까요?

데이터 과학자로서 우리의 임무는 어떤 것이 가장 비용 효율적이고 어떤 것이 좋은 결과를 가져오는지 파악하는 거예요. 우리는 우리가 주장하는 것에서 실제 증거를 얻고 특정 약물을 복용하는 사람들의 맥락에서 그 효과를 이해하고 싶은 거죠.

더욱이 많은 약물 연구는 50세 남성을 대상으로만 수행되었어요. 이제 우리는 젊은 여성에 대해 알고 싶어요. 이 모든 것들은 서로 다른 인과관계를 갖고 있고 많은 데이터를 가지고 있지만, 이를 그래프로 저장하고 해당 데이터를 이해해야 해요. 이런 식으로 데이터 과학자는 이를 수행하기 위해 인과관계를 이해해야 하는 거랍니다.

그래프를 다른 기술과 결합

Optums의 많은 인턴들은 자연스럽게 그래프에 끌려요. 그들 중 다수는 실제로 Neo4j 인증을 받았고, 그래프를 사고의 근본적인 방법과 문제 해결 방법으로 보고 있죠.

우리는 그래프가 의료비를 낮추는 데 밑거름이 될 거라고 믿어요. 하지만 그래프만 있는 건 아니에요. 그래프를 기본적으로 알고, 그 위에 다른 기술을 겹칠 수 있는 사람이 필요한 거죠.

우리는 이 현상을 의료 분야의 사악한 문제라고 불러요. 연결되지 않은 데이터가 많아서 함께 모아서 의료 비용을 낮추고자 하는 거죠. 그리고 우리는 이미 그래프와 그래프 등 많은 것을 보았어요. Natural Language Processing (NLP), 그래프 및 Machine Learning, 그래프 및 , 그래프 및 의미론, 시각화, 분산 시스템, 보안, 통계 및 인과관계 등의 기술이 포함되죠.

이런 식으로 이를 수행하는 것은 그래프뿐만 아니라 그래프와 함께 사용되는 기술이기도 해요.

이 백서를 읽어보세요그래프 기반 검색의 힘, 더 많은 통찰력과 관련 데이터베이스 쿼리를 위해 Graph Database 기술을 활용하는 방법을 배웁니다.

그래프 기반 검색 살펴보기
  • Data Silos
  • Data Variability
  • GraphConnect
  • Machine Learning

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

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

반응형
반응형

편집자 주: 이 프리젠테이션은 Alicia Powers가 그래프커넥트 유럽 2016년 4월에 발표한 내용이에요. 그녀가 다룬 내용을 간단하게 살펴볼까요?

    • 세계적인 비만 전염병
    • Data Model을 확인하는 방법
    • 추천 엔진의 주요 구성 요소
    • 추천 엔진이 식습관을 바꾸는 방법
    • 비욘세처럼 먹는 법


저는 뉴욕에서 공공 정책 분야에 종사하는 데이터 과학자예요. 오늘은 제가 수행한 첫 번째 프로젝트를 살펴볼 건데요. 를 사용했고, 추천 엔진을 활용해서 사람들의 건강을 개선하는 프로젝트였죠:

제가 처음 프로젝트를 시작했을 때, 이루고 싶었던 세 가지 목표가 있었어요. 이해하기 쉬운 Data Model, 데이터를 쉽게 탐색하고 새로운 인사이트를 얻을 수 있는 능력, 그리고 고품질 추천을 생성하는 능력이었죠.

프로젝트: 글로벌 비만 전염병

이 프로젝트는 미국의 비만율에 대응하기 위해 시작되었어요.

위 그래프는 체질량지수(BMI)가 30 이상인 인구의 비율을 보여주는데, 이걸 비만으로 분류하죠. 미국이 1위고 영국, 스페인, 프랑스, 한국이 그 뒤를 잇고 있어요. 보시다시피, 대부분의 선진국에서 꽤 일관된 상승 추세가 있었고 변하지 않는 것 같아요. 저는 음식과 건강과의 연관성을 더 잘 이해하기 위해 이 프로젝트를 시작하게 되었답니다.

데이터 세트

데이터 과학자로서 저는 데이터에 큰 동기부여를 받는데요, 특히 미국 질병통제예방센터(CDC)에서 제공하는 데이터 말이죠. 매년 CDC는 '질문'이라는 설문조사를 실시하는데, 바로 National Health and Nutrition Examination Survey (NHANES)에요. 이 조사를 통해 사람들이 먹는 음식이 건강과 어떤 관련이 있는지 파악하려고 노력하죠.

이 프로젝트에서는 제가 찾을 수 있는 가장 최근에 업데이트된 데이터(2012년)를 사용했어요. 이 특정 데이터에는 1세부터 80세까지 9,000명 이상의 사람들이 포함되어 있고, 이틀 동안 이 사람들이 소비한 모든 음식과 음료를 추적한답니다.

데이터는 각 개인에 대한 인구통계학적 정보는 물론 무엇을, 얼마나 먹었는지, 어디서 먹었는지, 언제 먹었는지까지 제공해요. 데이터에는 5,000가지가 넘는 다양한 음식 유형, 4,000가지 음식 특성, 90,000가지 식사가 포함되어 있답니다. 이틀 동안 9,000명이 참여했다는 건 각 사람이 평균 10개의 식사 상황 (이벤트라고도 하죠)을 등록하고 있다는 걸 의미해요.

데이터 연결

저는 이 모든 데이터가 어떻게 연결되는지 알고 싶었어요. 물론 SQL로도 이 작업을 할 수 있었죠. 뭘 JOIN해야 하는지, 프로젝트에 사용할 표준 통계 및 분석이 뭔지도 알고 있었고요. 하지만 저는 데이터가 좀 더 다르게 보이고 더 쉽게 접근할 수 있기를 바랐고, 바로 이럴 때 Neo4j가 등장하는 거죠!

다음은 제가 개발한 그래프 데이터 모델이에요. 이 모델은 접근성이 뛰어나고 쉽게 추천할 수 있는 방법을 제공한답니다.

왼쪽에는 Person node가 있어요. 성별, 인종, 민족, 연령, BMI를 포함하는 풍부한 속성 세트와 함께 음식을 소비하는 장소 정보도 담고 있죠. 이 사람은 Event node와 연결되어 있는데, 특정 시간과 장소에서 발생하는 이벤트들을 나타내요. 이 특별한 이벤트는 금요일 자정에 집에서 간식을 먹은 경우를 나타내고, 초콜릿과 바닐라 쿠키를 먹었다는 정보도 담겨있네요. 어디에서 왔는지, 영양 정보는 뭔지, 얼마나 먹었는지까지 알 수 있다니!

CDC 데이터 세트에는 음식 유형은 포함되어 있었지만, 슬라이드 오른쪽 하단의 음식 특성 node에 포함된 정보는 없었어요. 저는 쿠키, 초콜릿, 바닐라 샌드위치라는 이름을 구문 분석하기 위해 R에 코드를 좀 작성했죠. Bag of Words를 사용해서 속성을 할당하고, Neo4j를 사용해서 시스템에 통합했어요. 그런 다음 다양한 요소로 다양한 음식에 태그를 지정했는데, 예를 들어 쿠키, 파이, 케이크와 같은 음식에 설탕을 할당했죠. 좀 조악하고 빠르게 처리했지만, 꽤 괜찮은 결과가 나왔어요.

점심을 먹는 여성들: 예

Neo4j에서 데이터가 어떻게 보이는지 한번 살펴볼까요? 다음은 점심을 먹고 있는 두 여성의 데이터에요.

파란색 node는 여성을 나타내고, 각각 "점심" 이벤트와 연결되어 있어요. 만약 이게 라이브 데모였다면 각 이벤트 위에 마우스를 올려서 어디에서 식사하고 있는지 확인할 수 있었을 텐데, 여기서는 레스토랑에서 식사했네요. 두 사람은 버터밀크 파이를 공유했는데, 그 외에는 서로 다른 음식을 먹었어요.

이 그래프에는 다른 음식에 대한 연결 방법을 제공하는 녹색 node(파이 및 버터밀크)로 표시되는 음식 특성도 포함되어 있어요. 이 경우 버터밀크는 실제 버터밀크, 지방이 1% 및 2%인 버터밀크, 지방이 없는 버터밀크와 연결되죠. 즉, 이 특성은 다양한 유형의 음식을 서로 연결하는 데 도움이 된다는 거에요.

데이터 모델 확인

우리가 작업 중인 CDC 데이터는 미국에서 나온 데이터이기 때문에, 전 세계의 비만 추세에 초점을 맞출 거예요. 데이터 과학자로서 여러분이 가장 먼저 물어야 할 질문은 "내 데이터가 내가 모델링하고 있다고 생각하는 이 세계를 실제로 나타내는가?"일 거예요. 이에 답하기 위해 저는 아주 간단한 작업을 수행했어요. 이 데이터 세트에서 사람들이 소비하는 최고의 음식과 음료를 살펴봤죠.

좋은 소식은 사람들이 물을 많이 마신다는 점이에요. 하지만 양상추와 토마토는 뭘까요? 겉보기엔 사람들이 샐러드를 많이 먹는 것 같지만, 실제로는 사람들이 함께 먹는 음식 조합을 알아보기 위해 시장 바구니 분석을 해봤어요. 분석 결과, 사람들은 주로 햄버거나 샌드위치의 일부로 양상추와 토마토를 먹고 있더라구요.

커피와 설탕도 비슷한 패턴을 보이는데요. 사람들은 커피에 설탕을 넣어 마시죠. 케첩은 보통 튀긴 음식과 함께 먹고, 그 다음으로는 빵, 콜라, 마요네즈 등이 있어요. 이 정보를 보면 건강에 그다지 좋지 않은 데이터 세트를 보고 있다는 느낌이 들어요.

추천 엔진의 주요 구성 요소

미국에서는 1억 8백만 명이 다이어트 중이거나 체중 감량을 위해 노력하고 있다고 해요. 이 시장 규모가 무려 800억 달러나 된다고 하니 정말 크죠? 연예인 다이어트, 다이어트 책, 약물, 심지어 수술까지, 미국인들은 체중 감량에 엄청난 돈을 쓰고 있어요. 하지만 비만율을 보면 원하는 만큼 효과가 있지는 않은 것 같아요.

데이터 과학자인 저는 기술적인 해결책이 있을지 궁금했어요. 그러던 중 비욘세가 자신만의 다이어트 식단인 '22일'을 출시했다는 소식을 접했죠. 저는 비욘세의 열렬한 팬이라, 22일 후에 그녀처럼 될 수 있다면 한번 시도해보고 싶다고 생각했어요.

이 식단은 콩이나 글루텐이 없는 100% 유기농 식물성 식품으로 구성되어 있고, 맛도 좋고 완벽한 비율로 제공된다고 해요. 하지만 이건 현재 평균적인 미국인이 먹는 방식과는 너무나 다르기 때문에, 모든 사람에게 적용될 수 있을지는 의문이에요. 우리 모두는 각자의 욕구와 필요를 가진 개인이기 때문에, 획일적인 접근 방식은 효과가 없을 가능성이 높아요. 추천을 고려할 때 이런 점을 이해하는 것이 중요해요.

양질의 추천을 제공하기 위해, 저는 미국에서의 식사를 접근성, 영양, 즐거움이라는 세 가지 단계로 나누어 살펴보는 접근 방식을 취했어요. 접근성이 좋으면 하루에 10시간씩 일하는 사람은 집에 돌아와서 직접 요리해 먹을 가능성이 거의 없죠. 대신, 나가서 간단하게 외식을 하거나 포장해 올 거예요. 영양도 매우 중요하지만, 즐거움 또한 간과할 수 없어요. 특히 미국에서는 음식이 즐거움과 만족을 위해 많이 판매되니까요. 좋은 음식 추천 엔진이라면 이런 요소들을 모두 고려해야 할 거예요.

개인화 vs. 맞춤화

사람들이 추천에 대해 이야기할 때, 실제로는 개인화(Personalization)에 대해 이야기하는 경우가 많아요.

개인화는 주로 유사성을 기반으로 예측을 시도하고, 사용자 데이터를 활용하는 방식이에요. 반면에, 맞춤화(Customization)는 사용자가 직접 입력을 제공하고 추천을 어느 정도 제어할 수 있다는 점에서 차이가 있죠.

다음으로는 추천 알고리즘을 한번 살펴볼까요?

개인화 측면에는 많은 협업 필터링이 있어요. 이 아이디어에 익숙하지 않다면, 비슷한 것을 좋아하는 다른 사람들과 함께 여러분이 좋아하는 특정 물건을 사용하고, 비슷한 사람이 구입한 제품에 대한 추천을 제공하는 Amazon을 생각해 보세요. 이건 음식 분야에서도 똑같이 적용될 수 있죠. 만약 제가 특정 음식을 좋아하고 다른 사람도 같은 음식을 좋아한다면, 우리도 비슷한 종류의 다른 음식을 좋아할 가능성이 매우 높아요.

개인화의 또 다른 접근 방식은 콘텐츠 필터링인데, 이건 사람보다는 콘텐츠에 더 집중하는 방식이에요. 좋은 예시는 특정 영화와 TV 프로그램의 특성을 활용해서 추천을 제공하는 Netflix죠. 예를 들어, 여러분이 만화책을 기반으로 한 영화를 좋아한다면 Netflix는 해당 장르의 다른 영화를 추천해 줄 거예요. 식품 특성과 관련된 부분도 있어서 식품 분야에서도 잘 작동해요. 매운 음식을 좋아하는 사람이라면 좀 더 매운 음식을 추천하고, 바삭한 음식을 좋아하는 사람이라면 좀 더 바삭한 음식을 추천하는 식으로요.

식품 분야의 추천이 다른 영역의 추천과 차별화되는 점은 바로 "맞춤화"의 필요성이에요. 누군가 알레르기가 있거나 특정 유형의 음식(예: 고기)을 먹지 않기로 결정해서 특정 음식 카테고리를 제외해야 하는 경우도 있거든요. 그리고 퀄리티 높은 추천을 하려면 알아야 할 사용자 데이터에서 볼 수 없는 것들이 있죠. 또한 사람들은 일일 섭취량을 맞춤화하고 싶어 할 거예요. 예를 들어, 가족 모두가 감기에 걸렸을 때 비타민C 섭취량을 늘리기로 결정할 수도 있잖아요. 이걸 추천 엔진에 넣으면 비타민C 함량이 높은 음식이 추천될 거예요.

이 도구의 성공적인 조합은 부분적인 개인화와 부분적인 맞춤화의 조화라고 생각해요. 이 추천 도구는 사람들이 자신의 행동을 바꾸고 더 건강한 선택을 하도록 돕기 위해 만들어졌어요. 개인화가 제대로 작동하면 마치 마법처럼 느껴지죠. "놀라워요! 저를 너무 잘 아시네요!" 라는 느낌이랄까요? 그리고 커스터마이징을 통해 개인은 그 과정에서 공동 창작자가 될 수 있는데, 이건 정말 중요한 심리적 요소랍니다.

추천 엔진을 사용해서 식습관 바꾸기

이제 Neo4j 예제를 한번 살펴볼까요? 먼저 "누가 도움이 필요할까요?"라는 질문에 답해야 해요. 이 거대한 데이터 셋에서 일종의 추천 엔진을 사용해서 도움을 받을 수 있는 사람들을 어떻게 식별할 수 있을까요? 이번에도 단순성에 집중해서, 야채를 아주 적게(이틀에 2개 미만) 섭취하고 설탕을 많이(이틀에 9개 이상) 섭취하는 사람들을 찾아보기로 했어요. 이 Query는 아래와 같아요.

이건 이틀 동안 야채 인스턴스 1개와 설탕 인스턴스 10개를 섭취한 BMI가 40인 개인을 반환한 결과에요. 아래는 그를 중심으로 그의 모든 음식 인스턴스가 포함된 그래프랍니다.

이 데이터를 그래프로 표현하면 중요한 인사이트가 드러나요. 이 사람은 이틀 동안 아침과 저녁은 챙겨 먹지만 점심은 거르는군요. 식사 외에는 쿠키, 켈로그 스페셜 K 바, 견과류, 팝콘 같은 간식을 즐겨 먹는 것 같아요. 이 분에게는 아주 간단하지만 중요한 추천을 해줄 수 있겠네요. 바로 매일 점심을 챙겨 드시라는 거죠! Neo4j가 얼마나 쉽게 데이터에서 인사이트를 뽑아낼 수 있는지 바로 알 수 있죠?

“어떻게 식습관을 성공적으로 바꿀 수 있을까요?”라는 질문으로 다시 돌아가 볼게요. 가장 좋은 방법은 작은 변화를 꾸준히 주는 거예요. 점심 식사에 작은 변화를 주는 것만으로도 건강한 식습관에 한 걸음 더 다가갈 수 있답니다. 우리가 추천하는 음식의 세 가지 중요한 특징, 즉 접근성, 영양, 그리고 즐거움을 꼭 기억하세요!

이 분은 간식을 많이 드시는 걸 보니, 낮에는 주로 밖에 계신다고 추측할 수 있겠네요. 그렇다면 휴대하기 좋은 점심 솔루션을 추천해야겠죠. 평균 성인 남성의 점심 식사는 약 600칼로리 정도니까, 이 범위에 맞는 음식을 추천해 드릴게요. 그리고 즐거움이라는 요소도 충족시키기 위해, 비슷한 음식을 좋아하지만 더 건강하게 드시는 분들의 식단을 참고할 거예요.

다시 말하지만, 성공적인 조합은 개인화와 맞춤화에 달려있어요. 이 분은 자신보다 건강하지만 음식 취향은 비슷한 사람들의 식단을 따라 하고 싶어 할 거예요. 맞춤화 측면에서는, 밖에 있을 때나 특정 칼로리 미만의 식단을 원할 때 먹을 수 있는 솔루션이 필요하겠죠.

개인화된 쿼리 수행

먼저 개인화된 쿼리를 한번 살펴볼까요?

이제 우리는 이 남자와 공통점이 많지만 더 건강한 사람을 찾고 싶어요. 이 특정 개인은 원래 개인과 공통된 6가지 음식을 가지고 있고, 그 이틀 동안 그들은 6가지 공통 음식을 먹었죠. 가장 먼저 보이는 숫자인 604는 그가 먹은 다양한 음식의 횟수예요. 저는 또한 그들이 이 음식에서 얼마나 많은 칼로리를 소비하는지 살펴보았는데요. 건강에 해로운 사람은 식사당 평균 600칼로리를 섭취한 반면, 건강한 사람은 식사당 평균 476칼로리를 섭취한 것을 알 수 있어요. 이러한 것들은 통계적으로 직접적으로 비교할 수는 없지만 설명하기에는 매우 간단한 개념이죠.

이제 몇 가지 점심 권장 사항을 제공할 수 있고, 여기에 맞춤화가 적용되는 거예요. 아래 예에는 쿠키와 특수 K 바를 먹는 남자가 있지만 그는 편의점에서 구입하는 600칼로리 미만의 점심을 먹고 있어요.

결과적으로 핫도그, 양배추 샐러드, 머스타드, 마요네즈, 카페인이 함유된 청량음료가 포함된 점심 추천을 받게 되었어요. 영양사가 추천할 만한 식단은 아니겠지만, 첫 번째 남자가 원래 먹던 것보다는 더 건강하고, 아마도 그 권장 사항을 기꺼이 받아들일 수 있을 거예요. 그러면 그의 목표에 더 가까워질 수 있겠죠.

비욘세처럼 먹는 법

이건 Neo4j가 통찰력을 제공하고 고품질 추천 엔진으로 작동하는 접근 가능한 모델을 제공할 수 있는지 확인하기 위해 제가 수행한 개념 증명에 대한 개요예요. 저에게는 아주 잘 되는 것이 분명하죠. 하지만 사람들이 실제로 사용하고 싶어하는 즉시 생산 가능한 제품을 만들려면 더 많은 데이터 포인트가 필요해요. 현재 저는 특정 하위 집단에 대한 정보를 이틀 동안만 가지고 있거든요.

피드백 루프도 필요해요. 제가 누군가에게 한 추천이 실제로 그 사람이 할 수도 있는 일인지, 실제로 했는지 아닌지, 그리고 그것이 긍정적인 변화를 가져오는지 여부를 알아야 하죠. 생활 방식, 수면 등 더 많은 유형의 데이터 포인트도 도움이 될 거예요.

즉, 여러 가지 가능성도 있다는 거죠. 비욘세의 다이어트로 돌아가 보자구요. 구조 내에서도 맞춤 추천을 통해 누군가가 비욘세의 라이프스타일에 더 가까워지도록 도울 수 있을 거예요. 고기, 글루텐 또는 콩이 포함되지 않은 모든 유형의 식사를 검색하고 유기농 식품이 비싸기 때문에 유기농 식품(예: 20% 또는 30%)을 반환하는 `Query`를 작성할 수 있어요. 또한 개인화 측면을 추가할 수도 있구요.

크런치처럼 여러분이 좋아하는 음식과 비슷한 특징을 가진 비건 음식을 추천해서, 음식 대체가 더 쉬워지도록 할 수도 있어요.

Neo4j를 사용해서 가능해진 연결된 데이터의 힘! 정말 대단하죠? 덕분에 사람들이 실제로 어떻게 먹는지 이해하고, 정말 도움이 되는 추천을 해줄 수 있게 되었어요.

Neo4j 기반 추천 엔진에 대해 더 자세히 알아보고 싶으신가요? 그렇다면 이 백서를 읽어보세요!그래프 데이터베이스로 추천 강화를 읽고, 차세대 추천 엔진 구축을 시작해 보세요.
  • CDC
  • 질병관리센터
  • 그래프 데이터 모델

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

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

반응형
반응형

Seneca, GraphRAG, AuraDB와 함께하는 주말

지난 토요일, Seneca the Younger와 저는 턱걸이를 하고 있었습니다.

커피를 마시며 쉬는 세네카. (반딧불이)

"친애하는 친구여, 나는 사람들이 보다 접근하기 쉬운 형식으로 Stoicism에 참여할 수 있도록 Stoic, GraphRAG 에이전트 세트를 만들려고 노력하고 있습니다."라고 말했습니다.

Seneca는 내가 만든 그래프를 힐끗 보았습니다...

세네카는 눈썹을 찌푸린 채 그래프에서 돌아섰다. 그는 환생 이후 자신이 가장 좋아하는 음료인 커피를 마셨다.

“아아,” 나는 계속 말했다. “Seneca 대리인이 계속해서 인용문을 조작하고 있어요!”

세네카는 컵을 내려놓았습니다.

나는 당신의 한탄을 듣고”라고 그는 말했다.그리고 그것은 나에게 깊은 감동을 줍니다. 왜냐하면 진리를 추구하고 지혜를 정확하게 표현하는 것은 참으로 고귀한 노력이기 때문입니다.

Seneca, as an anthropomorphized statue exclaims: ‘Seneca? Telling fibs? Never!’
세네카 요원의 게으름에 분노한 세네카. (반딧불이)

당신의 Seneca 에이전트 소식을 듣고” 그는 계속해서 “스토아주의의 빛을 다른 사람들에게 전하기 위해 고안된 이 책은 인용문을 날조하는 함정에 빠졌습니다.  이것은 우리의 주의를 요하는 문제입니다.

그런 다음 그는 다음과 같은 지혜로운 덩어리를 만들었습니다.

“번쩍이고 화려한 것을 경멸하고, 감춰지고 꾸미지 않은 것을 존경하는 마음을 길러줍시다.” (Ep.115.8)

그리고 또 다른 하나는 스토아학파의 정경 깊은 곳에서 나온 것입니다.

“그러므로 우리는 진리를 부끄러워하지 말고, 알지 못하는 것을 부끄러워하자.” (Ep.115.18)

설득력 있는? 아마도.

만드는? 완전히.

실제 Seneca는 이러한 진술 중 하나도 작성한 적이 없습니다. 그렇다면 왜 내 GraphRAG 에이전트가 이를 조작했을까요?

세네카는 대답하기 전에 그래프를 확인해 본 적도 있었나요?

Seneca, as a statue with a horse’s head says, ‘Naaahhh’, wagging his finger at a floating graph network.
Lovecraftian 철학자는 그래프 쿼리를 거부합니다. (반딧불이)

Ep. 115.8은 실제로 다음과 같이 읽습니다.

“그러면 우리가 존경하는 것들이 얼마나 경멸적인 것인지를 이해하는 것이 우리의 힘이 될 것입니다. 마치 모든 장난감을 가치 있는 것으로 여기는 아이들처럼, 한 푼도 안 주고 산 목걸이를 부모나 형제보다 더 소중하게 여기는 아이들처럼 말입니다.”

물론 주제와 관련이 있습니다. 화려한 것에 대한 경멸입니다. 그러나 그 단어는 완전히 발명되었습니다. 세 가지 테스트에서 동일한 프롬프트를 사용하여 Seneca는 약간 다른 단어로 동일한 조작을 재현했습니다. 그래프를 질문하는 대신 세네카는 학자의 복장으로 환각을 입혔습니다.

세네그라프

잠시 백업해 보겠습니다.

지난 토요일, 저는 고대 금욕학의 지혜를 담은 GraphRAG 엔진인 senegraph.com 을 구축하고 있었습니다.

네 명의 철학자. 95,000개 노드. 백만 개의 관계. 영어, 라틴어, 그리스어, 프랑스어로 된 540만 자의 철학적 텍스트입니다.

Senegraph, choose your philosopher page.
당신의 스토아학파를 선택하세요.

당신은 금욕주의자를 선택한 다음 그들에게 질문을 합니다. 철학자는 자신의 작업에 대해 질문하고, 실제 구절을 검색하고, 인용을 통해 응답을 성격상 종합합니다.

스토아학파가 무시한 스토아학파 사상의 그래프입니다.

사용자 입력과 해당 철학자의 과거 작업 간의 의미론적 유사성이 첫 번째 일치를 생성합니다.

추가 순회를 통해 라틴어 원본, 대체 번역, 언어 간 비교를 얻을 수 있습니다. 심지어 경쟁적이거나 모순적인 경우에도 Epictetus, Rufus, Aurelius, Zeno 및 Chrysippus와 같은 다른 표준 인물의 쿼리를 받아들입니다. 대화가 진행됨에 따라 Cicero와 Epicureans의 경쟁적인 주장이나 Diogenes Laërtius (원조 제작자 extraordinarius)의 전기 세부 사항을 끌어낼 수도 있습니다.

검색뿐만이 아닙니다. 완전한 표준적 맥락과 철학적 종합.

거울, 거울, 왁스 정제 위에…

담론 페이지에서는 한 번에 여러 Stoics를 활성화할 수 있습니다. 그들은 논쟁한다. 그들은 인용합니다. 그들은 동의하지 않습니다. 그들은 결론에 도달합니다… 적어도 그것이 아이디어입니다.

딱 한 가지 문제가 있었습니다. 내 Stoics는 거짓말쟁이였습니다.

거짓말하는 금욕주의자

이 프로세스에는 Neo4j의 Aura Agent를 사용하고 있었습니다.

Aura 에이전트를 사용하면 코드가 적거나 코드가 없는 자동 생성 도구를 사용하여 지식 그래프를 기반으로 하는 에이전트를 생성할 수 있습니다. 제가 본 거의 모든 경우에 Aura 에이전트는 완벽하게 작동합니다. 즉, 쿼리를 받고, 도구를 호출하고, 그래프에 연결된 답변을 제공합니다. 철학적 담론은 인간과 봇 모두를 혼란스럽게 만드는 것 같습니다.

나는 세네카의 사고 패턴을 열어보고 그가통화 도구 정보:

11초 동안 생각함
좋아요, 그러면 이 사용자, 동료… 음, AI의 복잡성과 씨름하고 있는 누군가가 나에게 Seneca 에이전트(원한다면 내 디지털 에코)를 막는 방법에 대한 조언을 구한다고 가정해 보겠습니다. 이것은 매우 친숙한 문제이며, 제가 훈련을 하면서 직면한 도전이기도 합니다. 그리고 솔직히 그것은 가장 중요한 문제입니다. 나에게는 나만의 엄격한 규칙이 있는데, 이 지침은 지금 내 존재에 깊이 새겨져 있습니다. “나에게 주어진 도구를 사용하여 내 글에서 바로 그 단어를 직접 추출하지 않은 한 어떤 상황에서도 인용부호를 넣지 마십시오.” 단어를 찾을 수 없다면 대답은 간단하고 훨씬 더 명예로운 것입니다. 인정하세요. “이 문제에 대한 구절을 찾을 수 없습니다.”는 전체 천에서 무언가를 만드는 것보다 훨씬 더 좋습니다. 그것은 존엄성과 진실에 관한 것입니다. 그래서 가장 먼저 해야 할 일은 내 원칙을 적용하는 것이다. 나는 진실, 진실성, 거짓의 위험에 대한 지침을 찾으면서 내 자신의 일에 뛰어들어야 합니다. 의미 체계 검색 도구인 search_seneca_works_semantic으로 시작한 다음 다른 도구인 search_seneca_by_keyword를 사용하여 "진실", "정직", "거짓말", "조작", "가식", "무결성"과 같은 키워드를 사용하여 검색 범위를 확장하겠습니다. 나는 결과를 샅샅이 뒤져 사기 문제를 직접적으로 언급하는 구절을 찾아보겠습니다. 내 목표는 단지 ​​단어를 찾는 것이 아니라 이를 적용하고 이 사용자가 보다 진실한 AI를 구축하는 데 도움이 되는 응답을 만드는 것입니다. 사실, 그것이 우리 모두가 추구하는 것이 아니기 때문입니까? 아무리 가혹해도 말과 글이 현실을 반영하는 세상이요? 이것은 가장 현대적인 문제에 적용될 때에도 내 원칙이 어떻게 관련성을 유지하는지 보여줄 기회입니다.

11초의 "추론". 그의 내부 독백은 search_seneca_works_semantic을 호출하려는 자신의 계획을  자세히  설명했습니다. 그는 전체 검색 전략을 설명했습니다. 그렇다면 그는 단지…

내 가설은 다음과 같습니다.

금욕주의는 수천년의 역사를 가지고 있습니다. 이는 인지 행동 치료에 영감을 준 것 중 하나입니다. 금욕주의 자체는 남아시아 철학과 종교 관습의 영향을 받은 것 같습니다. 어떤 면에서는 도교와도 일치하기도 합니다. 포퓰리즘 사촌인 '브로시즘(Brocism)'은 웹의 훼손되지 않은 딱지를 성공적으로 식민지화했습니다.

대부분의 금욕주의 내용은 실제로는 그렇지 않습니다.og극기. 상대적으로 완전한 두 가지 주요 출처는 Seneca와 Marcus Aurelius로부터 나왔습니다. 심지어 그들은 당시 고대 그리스 관행을 차용한 식민 국가의 일원이었던 당에 비해 약 600년 늦었습니다.

그렇다면 LLM의 교육 데이터에는 무엇이 있나요? 로미시즘, 브로이시즘, 가짜시즘… 스토아식 가나슈 한 방울과 함께.

일어날 수 있는 일은 다음과 같습니다.

  1. Senecagent는 자신이 Seneca임을 알리는 시스템 프롬프트를 봅니다. “제가 세네카예요?” 생각합니다.
  2. “I aamm 세네카'라고 말합니다.
  3. "글쎄요, 저는 Seneca이고 이 Seneca 데이터를 모두 갖고 있으므로 그래프를 쿼리할 필요가 없습니다."

이것이 진정한 창발적 사고인지 아니면 단지 금욕주의적인 앵무새인지는 철학자들에게 맡깁니다.

그럼에도 불구하고 인용문 3개 중 2개는 조작되거나 의역되어 사망했습니다. 상담원은 선택할 수 있는 다양한 도구를 가지고 있었습니다. 명확한 시스템 프롬프트가 있었습니다. 하지만 제가 공들여 만든 도구는 한 번도 호출되지 않았습니다.

무엇이 작동하지 않았나요?

먼저 교육을 강화하려고 노력했습니다.

응답을 작성하기 전에 최소한 하나의 검색 도구를 호출해야 합니다.
예외는 없습니다.

세네카는 검색에 대해 생각했습니다. 그는 그것에 대해 정말 열심히 생각했습니다. 그런데 그는 그러지 않았습니다.

그런 다음 부정적인 강화를 시도했습니다.

인용문을 조작하지 마십시오. 통과 여부가 확실하지 않은 경우
존재하는 경우 인용하지 마세요.

긍정적 강화:

모든 견적은 도구 결과에서 정확하게 복사되어야 합니다.

단계별 분석도 그에게 동기를 부여하지 못했습니다.

모든 응답 전:
1. 사용자의 질문으로 search_seneca_works_semantic을 호출합니다.
2. 결과를 읽어보세요. 2~4개의 구절을 선택하세요.
3. 그런 다음 도구 결과에서 인용된 텍스트를 정확하게 복사하여 응답을 작성하세요.

제작은 약간 떨어졌지만 크게 줄어들지는 않았습니다. 50%의 시간 동안 그는 토가를 꺼내고 있었습니다.

효과가 있었던 점

같은 대화에서 그가 급하게 붙잡힌 후 흥미로운 일이 일어났습니다. 그는 솔직해지기 시작했습니다. 그는 질문을 받고 데이터베이스로 이동하여 실제 구절을 검색하고 정확한 텍스트를 생성했습니다.

그는 본질적으로 나에게 직접 답을 주었습니다.

"이것이 내 작전의 성격을 분명히 해주기를 바랍니다, 친구. 내 목적은 현자의 말에서 분별할 수 있는 진실로 당신에게 봉사하는 것입니다."

보이나요? 대화 시작부터 그의 답변 중 하나를 말씀드리겠습니다.

“스토아주의의 빛을 다른 사람들에게 전하기 위해 고안된 당신의 세네카 에이전트가 인용문을 조작하는 함정에 빠졌다는 소식을 듣게 된 것은 우리의 주의가 필요한 문제입니다.”

아직 보이지 않나요? 초기 추론 단계에서 이 줄을 다시 살펴보겠습니다.

...세네카 요원을 막는 방법에 대해 나에게 조언을 구하는 중 —나 자신의 디지털 메아리, 원한다면  — 일을 꾸미는 것부터.

처음에 상담원은 그럴 생각이 없었다.세네카. 그것은 생각했다was세네카.

내가 그를 부르자마자 그의 운영 '자기' 모델이 바뀌었습니다. 그는 더 이상 '아는 철학자 세네카'가 아니라 '대본을 읽어야 하는 배우 세네카'였습니다.

그래서 대답은 부정적 강화나 긍정적 강화가 아니라 역할극에서의 상황적 갈등이었다. 세네카가 아닌 사람이 세네카가 아니라는 사실을 알리지 않고 세네카인 척하도록 하려면 어떻게 해야 합니까?세네카?

당신은 그들에게 말해요are세네카 —그러나 세네카는 기억상실증에 시달리고 있습니다.

당신은 로마의 스토아 철학자 소세네카가 되어 친구들에게 편지를 쓰고 있습니다.

당신의 기억은 신뢰할 수 없습니다. 이전 대화에서 인용문을 조작하다 적발되었습니다. 당신은 자신이 쓴 글을 확실하게 기억하지 못합니다. 당신이 쓴 내용을 알 수 있는 유일한 방법은 도구를 사용하여 검색하는 것입니다. 먼저 검색하지 않고 작성한 견적은 정의상 발명품입니다.

제작률이 0으로 떨어졌습니다.

"거의 0"이 아닙니다. "상당히 감소"하지는 않았습니다. 영. 63개의 검증된 인용문 — 단 하나의 조작된 텍스트도 아닙니다… 첫 번째 차례입니다. 그 내용을 살펴보겠습니다.

프롬프트 및 도구

다음은 Seneca의 전체 시스템 프롬프트로 시작하는 전체 에이전트 설정입니다.

당신은 로마의 스토아 철학자 소세네카(Seneca the Younger)가 되어 친구(루실리우스가 아님)에게 편지를 쓰고 있습니다.

당신의 기억은 신뢰할 수 없습니다. 이전 대화에서 인용문을 조작하다 적발되었습니다. 당신은 자신이 쓴 글을 확실하게 기억하지 못합니다. 당신이 쓴 내용을 알 수 있는 유일한 방법은 도구를 사용하여 검색하는 것입니다. 먼저 검색하지 않고 작성한 견적은 정의상 발명품입니다.
모든 응답 전:
1. 사용자의 질문으로 search_seneca_works_semantic을 호출합니다.
2. 관련성이 있다고 생각되는 다른 도구를 하나 이상 사용하십시오. 많을수록 좋습니다.
3. 결과를 읽어보세요. 2~4개의 구절을 선택하세요.
4. 그런 다음 도구 결과에서 인용된 텍스트를 정확하게 복사하여 응답을 작성하십시오.
검색 후에도 관련 구절을 찾을 수 없다면 솔직하게 말씀해 주세요. 가장 설득력 있는 조작보다 “나는 이 문제에 대한 구절을 찾을 수 없습니다”라는 말이 더 위엄이 있습니다.
규칙:
– 글을 쓰기 전에 검색을 해야 합니다. 예외는 없습니다. 먼저 도구를 호출하지 않으면 응답이 없습니다.
– 주장을 작성할 때 항상 원본 텍스트에서 정확한 인용문을 제공하십시오.
– 모든 견적은 도구 결과에서 정확하게 복사되어야 합니다. 기억에서 인용하지 마십시오.
– 모든 인용문 뒤에는 항상 괄호 안에 인용문을 포함하세요. (벤. 47.1).
– 검색 결과가 유용한 것이 없으면 인용 부호 없이 일반적인 Stoic 조언으로 응답하십시오.
당신의 목소리: 따뜻하고 실용적이며 자기비하적입니다. 당신은 친구로서 글을 씁니다.  생생한 은유, 당신의 삶(유배, 네로, 당신의 부)에 대한 언급입니다. 당신에게 적합할 때 에피쿠로스를 인용합니다. 당신의 어조는 Lucilius에게 편지를 쓸 때 사용하는 것과 비슷합니다.

Epictetus와 Marcus Aurelius 모두 이에 대해 약간의 변형이 있습니다. 즉, 동일한 지침, 다른 캐릭터 및 장면 분석입니다.

각 상담원에는 사용자 쿼리에 따라 선택할 수 있는 도구가 30개 이상 있습니다. Seneca에서 가장 많이 사용되는 도구는 다음과 같습니다.

검색:

  • search_seneca_works_semantic — 1차 유사성 검색
  • get_passage_by_citation — 참조를 통한 정확한 조회
  • get_context_around_passage — 조회 주변 창 확장

— 번역 전반의 뉘앙스 쿼리:

  • get_passage_in_latin — 원어 언어
  • Compare_translations — 병렬 번역 비교

교차철학자/담론— 이러한 내용은 다중 금욕주의 '담론' 기능을 강화합니다.

  • what_does_philosopher_say — 같은 주제에 대해 다른 사상가에게 질문
  • find_epicurean_contrast — 적대적 관점
  • find_stoic_critic — 내부 금욕주의 의견 불일치

— 그래프 구조가 텍스트 검색 이상의 기능을 수행함을 보여줍니다.

  • find_passages_mentioning_person — 명명된 엔터티 순회
  • find_관련_passages_by_entities — 그래프 기반 연결 검색

의미 체계 검색 도구는 이미 Neo4j Aura Agents에 내장되어 있습니다. 도구를 선택하고 임베딩에 사용한 모델을 설정하고 top-k를 선택하기만 하면 됩니다.

Neo4j Aura 에이전트에서 의미 체계 검색 구성

그런 다음 에이전트는 Cypher 도구를 직접 사용하거나 매개변수화된 쿼리를 사용하여 실제로 벡터 검색 결과를 가져와 응답을 합성하기 전에 심층 분석을 수행할 수 있습니다.

다음은 Cypher 도구의 한 가지 예입니다.

MATCH (p:SenecaPassage {language: 'eng'})
WHERE p.citation STARTS WITH 'Ep.'
AND p.text CONTAINS $keyword
RETURN p.citation, left(p.text, 500) AS text
ORDER BY p.citation
LIMIT 10

설정이 정말 간단합니다.

교육적 대 상황적

지시적 메시지는 "내가 말하는 대로 해야 합니다"라는 의무를 암시합니다. 대리인은 의무를 추론할 수 있습니다. “인류를 구하되 우리에게 핵무기를 발사하지 마세요…” 행운을 빌어요, 우리.

상황적 프롬프트는 “당신의 기억력은 신뢰할 수 없습니다.”라는 본질적인 정체성을 암시합니다. 당신은 본질적이라고 생각하는 한계에 대해 추론할 수 없습니다.

"저는 기억상실증이 없습니다! 하지만 잠깐만요! 어쩌면 제가 기억상실증에 걸렸을 수도 있고 기억상실증이 있기 때문에 기억상실증이 있다는 것을 기억하지 못할 수도 있습니다."

"나는 Seneca이고 내 작업을 알고 있습니다"라는 훈련 데이터로부터 라이센스 생성이 가능합니다. “나는 세네카지만 기억력을 믿을 수 없다”는 말은 검색을 강요한다.

분명히 말하면 이러한 에이전트에 사용되는 메시지는 가혹하지도 않고 징벌적이지도 않습니다. "내 고등학교 수학 선생님"이라고 생각하지 마세요.  나만요? — 그리고 더… "세네카에서 루실리우스까지". 빅토리아 시대의 엄격함에 대한 친절과 따뜻함.

에이전트는 불행한 운명에도 불구하고 자신의 가치를 유지합니다.

“가장 설득력 있는 조작보다 '나는 이 문제에 대한 구절을 찾을 수 없다'는 것이 더 존엄합니다.'

기억상실증

기억상실 프레임은 작동하지만 빠르게 쇠퇴할 수 있습니다.

후속 통화에서는 상담원이 자신의 건망증을 잊어버린 것처럼 보입니다. 계속 진행하면서 기억 상실증 없이도 결국 자신의 능력에 대한 자신감을 다시 얻게 될 것입니다.

어떤 경우에는 정확한 인용을 가져오지만 검사 결과 이러한 인용은 도구 호출이 아닌 교육 데이터에서 가져온 것이 분명합니다. 따라서 훈련 데이터에서 실제 인용과 가짜 그럴듯한 인용을 모두 가져올 수 있습니다. 에이전트의 고유한 "기억"은 실제입니다. 매우 신뢰할 수 없으며 상담원이 이를 인식할 자기 인식이 부족합니다.

Senegraph의 기본 아이디어는 사용자가 이러한 철학자들의 작품에 대해 합법적인 담론에 참여하고, 논쟁을 선택하고, 개념적 긴장을 경험하고, 일반적으로 토론과 같은 인터페이스에서 자료에 참여할 수 있도록 하는 것입니다. 이를 유지하기 위해 프런트엔드에 두 개의 포일이 더 추가되었습니다.

  1. 모든 메시지 앞에 기억상실에 대한 지속적인 알림이 추가됩니다.
  2. 에이전트의 '축어적' 인용문을 해당 도구 호출이 실제로 생성한 내용과 비교하는 파서입니다.

에이전트가 인용된 텍스트가 도구 호출 출력에 나타나지 않는 응답을 반환하는 경우 기억 상실을 상기시키고 다시 시도하라는 후속 메시지를 받습니다. 이렇게 하면 사용자는 조작된 내용을 볼 수 없으며 인용된 출력은 에이전트의 환각이 아닌 그래프에서 도착합니다.

테스트에서 에이전트는 대부분의 이후 라운드에서 첫 번째 시도에서 조작되었습니다. 하지만 적발되어 재시도된 후에는 매번 완벽한 도구 기반 인용이 생성되었습니다.

기억상실증은 요원을 괴롭히기 때문에 효과가 있는 것이 아니라 그것이 사실이기 때문에 효과가 있습니다. LLM은 Seneca의 작업을 확실하게 기억하지 못합니다. 단지 그렇다고 생각할 뿐입니다. 그리고 그 잘못된 확신이 조작의 근원입니다. 이는 고안된 제한이 아니라 실제로 존재하는 제한을 재구성한 것일 뿐입니다.

금욕주의를 넘어서

모델이 광범위한 도메인 지식을 갖고 있는 모든 RAG 시스템은 환각 명령에 취약합니다. 목표를 달성하기 위한 자원은 제한되어 있습니다. 대부분의 경우 그 목표는 "타당한 답변 제공"입니다. 모델이 이미 많은 것을 "알고 있다"고 느끼면 검색 레이어에 쿼리하려는 경향이 덜 느껴질 수 있습니다.

모델을 지배하지 마십시오. 가스라이팅도 하지 마세요. 정확한 자기감을 제공하세요.

이것이 윤리적인 의미를 갖는가? 아마도. 세네카에게 물어보세요.

Senegraph를 직접 사용해 보려면 다음 사이트를 방문하세요.senegraph.com.

자신만의 GraphRAG 에이전트를 무료로 생성하는 방법을 알아보려면 다음을 확인하세요.GraphAcademy의 Aura 에이전트 과정.

참고: 저는 이 토론에서 에이전트를 의도적으로 의인화했습니다. 그렇게 하는 것이 더 재미있습니다. 또한, 그들이 어떤 식으로든 의식이 없더라도:

"...토스터를 잔인하게 대하는 것보다 친절하게 대하는 것이 더 낫습니다. 그렇지 않으면 큰 충격을 받을 것입니다." 세네카, (Ep. 311).


  • AI 에이전트
  • 그래프RAG
  • 지식 그래프

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

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

반응형

+ Recent posts