Graph Note

편집자 주: 이 프레젠테이션은 다음에서 제공되었습니다.실파 카케라 at 연결: 그래프를 통한 혁신 가속화.

Usha Renal Care Foundation에서는 의료 데이터에 대한 풍부한 지식 저장소를 갖기 위해 자체 구성 맵에 넣을 정보를 수집하고 있다고 해요. 이 계획은 단계적으로 진행될 예정이고, 현재는 초기 단계에 있죠.

LangChain 및 Neo4j를 사용하는 고급 그래프 기반 메타데이터 기술로 Vector Search를 최적화합니다.

In Retrieval-Augmented Generation(RAG) 애플리케이션, 텍스트 임베딩 및 Vector Search는 문서의 의미와 서로 얼마나 유사한지를 이해하여 문서를 찾는 데 도움이 돼요. 하지만 날짜나 카테고리와 같은 특정 기준에 따라 정보를 정렬할 때는 텍스트 임베딩이 효과적이지 않죠. 예를 들어, 특정 연도에 생성된 모든 문서를 찾거나 "공상 과학"과 같은 특정 카테고리에 태그가 지정된 문서를 찾아야 하는 경우에요.

메타데이터 필터링, 즉 필터링된 Vector Search가 중요한 역할을 하는 곳이죠! 구조화된 필터를 효과적으로 처리해서 사용자가 특정 속성에 따라 검색 결과를 좁힐 수 있거든요.

제공된 이미지에서 프로세스는 사용자가 2021년에 새로운 정책이 구현되었는지 묻는 것으로 시작돼요. 그런 다음 메타데이터 필터를 사용하여 지정된 연도(이 경우 2021년)를 기준으로 더 큰 인덱스 문서 풀을 정렬하죠. 결과적으로 해당 연도의 문서 하위 집합만 필터링되는 거예요.

가장 관련성이 높은 문서를 더욱 정밀하게 조사하기 위해 이 하위 집합 내에서 Vector Search가 수행됩니다. 이 방법을 사용하면 시스템은 2021년의 문맥상 관련된 문서 풀 내에서 관심 주제와 밀접하게 관련된 문서를 찾을 수 있어요. 이 2단계 프로세스인 메타데이터 필터링과 Vector Search는 검색 결과의 정확성과 관련성을 높여준답니다.

최근에 소개한 메타데이터 필터링을 위한 LangChain 지원은 Neo4j에서 Node 속성을 기반으로 해요. 하지만 같은 Graph Database는 구조화되지 않은 데이터와 함께 매우 복잡하고 연결된 구조화된 데이터를 저장할 수 있다는 점! 다음 예를 한번 살펴볼까요?

데이터 세트에서 구조화되지 않은 부분은 시각화의 오른쪽 상단에 있는 기사와 텍스트 덩어리를 나타내요. 텍스트 청크 `Node`에는 텍스트와 해당 텍스트 `Embedding` 값이 들어있고, 날짜, 감정, 작성자 같은 기사에 대한 추가 정보가 있는 기사 `Node`에 연결되죠.

그런데 기사는 기사에서 언급한 조직과 추가로 연결돼요. 이 예시에서는 기사에 Neo4j가 언급되어 있네요. 게다가 우리 데이터 세트에는 투자자, 이사회 구성원, 공급업체 등 Neo4j에 대한 구조화된 정보가 풍부하게 들어있답니다.

그래서 이 광범위한 구조화된 정보를 활용해서 정교한 메타데이터 필터링을 실행할 수 있고, 다음과 같은 구조화된 기준을 사용해서 문서 선택을 정확하게 세분화할 수 있어요.

• Rod Johnson이 이사회 구성원으로 있는 회사 중에 새로운 재택근무 정책을 시행한 회사가 있나요?
• Neo4j가 투자한 회사에 대한 부정적인 소식이 있나요?
• 현대자동차에 납품하는 기업의 공급망 문제와 관련해서 주목할 만한 소식이 있었나요?

이런 예시 질문들을 보면 구조화된 그래프 기반 메타데이터 필터를 사용해서 관련 문서 하위 집합의 범위를 얼마나 좁힐 수 있는지 알 수 있죠.

이번 블로그 포스팅에서는 OpenAI 함수 호출 에이전트와 함께 LangChain을 사용해서 그래프 기반 메타데이터 필터링을 구현하는 방법을 보여드릴게요. 코드는 에서 확인할 수 있어요.

의제

소위 `Graph Database`를 사용할 건데요, Neo4j가 호스팅하는 공개 데모 서버에서 사용할 수 있어요. 다음 자격 증명을 사용해서 액세스할 수 있습니다.

Neo4j Browser URI: https://demo.neo4jlabs.com:7473/browser/
username: companies
password: companies
database: companies

데이터 세트의 전체 `Schema`는 다음과 같아요.

그래프 스키마는 Organization 노드를 중심으로 구성돼요. 여기에는 공급업체, 경쟁업체, 위치, 이사회 구성원 등에 대한 방대한 정보가 담겨 있죠. 앞서 말씀드렸듯이, 특정 조직을 텍스트 덩어리와 함께 언급하는 기사도 있고요.

사용자 입력을 기반으로 Cypher 쿼리를 동적으로 생성하고 Graph Database에서 관련 텍스트 chunk를 검색할 수 있는 도구를 사용해서 OpenAI 에이전트를 구현할 수 있어요. 이 예제에서 도구는 4개의 선택적 입력 매개변수를 가지고 있죠.

• 주제: 조직, 국가, 감정 외에 사용자가 관심을 갖는 특정 정보나 주제를 말해요.
• 조직: 사용자가 정보를 찾고자 하는 조직이에요.
• 국가: 사용자가 관심을 갖는 조직의 국가고요. 미국, 프랑스처럼 전체 이름을 사용해야 해요.
• 감정: 기사의 감정을 나타내요.

4개의 입력 매개변수를 기반으로 동적으로, 그렇지만 확실하게 해당 Cypher 쿼리를 구성해서 그래프에서 관련 정보를 검색하고, 이걸 컨텍스트로 사용해서 LLM을 통해 최종 답변을 생성하는 거죠.

코드를 따라 하려면 OpenAI API key가 필요해요.

기능 구현

Neo4j에 대한 사용자 인증 정보와 관련 연결을 정의하는 것부터 시작해 볼게요.

import os

os.environ["OPENAI_API_KEY"] = "sk-"
os.environ["NEO4J_URI"] = "neo4j+s://demo.neo4jlabs.com"
os.environ["NEO4J_USERNAME"] = "companies"
os.environ["NEO4J_PASSWORD"] = "companies"
os.environ["NEO4J_DATABASE"] = "companies"

embeddings = OpenAIEmbeddings()
graph = Neo4jGraph()
vector_index = Neo4jVector.from_existing_index(
    embeddings, 
    index_name="news"
)

이 글을 쓰는 시점에는 Vector Index를 사전 필터링 접근 방식과 함께 사용할 수 없어요. Vector Index와 함께 사후 필터링만 적용할 수 있죠. 하지만 사후 필터링에 대한 논의는 이 글의 범위를 벗어나요. 철저한 벡터 유사성 검색과 결합된 사전 필터링 접근 방식에 집중할 거니까요.

전체 블로그 게시물은 Cypher 쿼리를 동적으로 생성하고 관련 정보를 검색하는 다음 `get_organization_news` 함수로 요약돼요. 명확하게 보여드리기 위해 코드를 여러 부분으로 나눠서 설명할게요.

def get_organization_news(
    topic: Optional[str] = None,
    organization: Optional[str] = None,
    country: Optional[str] = None,
    sentiment: Optional[str] = None,
) -> str:
    # If there is no prefiltering, we can use vector index
    if topic and not organization and not country and not sentiment:
        return vector_index.similarity_search(topic)
    # Uses parallel runtime where available
    base_query = (
        "CYPHER runtime = parallel parallelRuntimeSupport=all "
        "MATCH (c:Chunk)<-[:HAS_CHUNK]-(a:Article) WHERE "
    )
    where_queries = []
    params = {"k": 5} # Define the number of text chunks to retrieve

입력 매개변수를 정의하는 것부터 시작해 볼게요. 보시다시피 모두 선택적 문자열이에요. `topic` 매개변수는 문서 내에서 특정 정보를 찾는 데 사용되죠. 실제로는 `topic` 매개변수의 값을 임베딩해서 벡터 유사성 검색을 위한 입력으로 사용하는 거예요. 다른 세 가지 매개변수는 사전 필터링 접근 방식을 보여주는 데 사용되고요.

사전 필터링 매개변수가 모두 비어 있으면 기존 Vector Index를 사용해서 해당 문서를 찾을 수 있어요. 그렇지 않다면 사전 필터링된 메타데이터 접근 방식에 사용될 기본 Cypher 쿼리 준비를 시작하는 거죠. `CYPHER Runtime = Parallel ParallelRuntimeSupport=all` 절은 Neo4j Database에 병렬 런타임을 사용하도록 지시하는 부분이에요. 다음으로 `Chunk` node와 해당 `Article` node를 선택하는 `match` 구문을 준비하고요.

이제 Cypher 쿼리에 메타데이터 필터를 동적으로 추가할 준비가 됐어요. 먼저 `Organization` 필터부터 시작해 볼게요.

if organization:
    # Map to database
    candidates = get_candidates(organization)
    if len(candidates) > 1:  # Ask for follow up if too many options
        return (
         "Ask a follow up question which of the available organizations "
         f"did the user mean. Available options: {candidates}"
        )
    where_queries.append(
        "EXISTS {(a)-[:MENTIONS]->(:Organization {name: $organization})}"
    )
    params["organization"] = candidates[0]

LLM이 사용자가 관심을 갖는 특정 조직을 식별하는 경우, 먼저 `get_candidates` 함수를 사용하여 값을 데이터베이스에 매핑해야 해요. 내부적으로 `get_candidates` 함수는 전체 텍스트 인덱스를 활용한 키워드 검색으로 후보 `Node`를 찾죠. 여러 후보자가 발견되면 LLM에게 사용자에게 후속 질문을 해서 정확히 어떤 조직을 의미하는지 명확히 하도록 지시합니다.

그렇지 않으면 우리는 실존 하위 쿼리를 사용해서 특정 조직을 언급하는 기사를 필터 목록으로 필터링해요. Cypher 삽입을 방지하기 위해 쿼리를 연결하는 대신 쿼리 매개변수를 사용하고요.

다음으로, 사용자가 언급된 조직의 국가를 기반으로 텍스트 청크를 사전 필터링하려는 상황을 처리해볼게요.

if country:
    # No need to disambiguate
    where_queries.append(
        "EXISTS {(a)-[:MENTIONS]->(:Organization)-[:IN_CITY]->()-[:IN_COUNTRY]->(:Country {name: $country})}"
    )
    params["country"] = country

국가는 표준 명명 표준을 따르므로 LLM은 대부분의 국가 명명 표준에 익숙해서 값을 데이터베이스에 매핑할 필요가 없어요.

마찬가지로 감정 메타데이터 필터링도 처리해볼까요?

if sentiment:
    if sentiment == "positive":
        where_queries.append("a.sentiment > $sentiment")
        params["sentiment"] = 0.5
    else:
        where_queries.append("a.sentiment < $sentiment")
        params["sentiment"] = -0.5

감정 입력 값으로 긍정적이거나 부정적인 두 가지 값만 사용하도록 LLM에 지시합니다. 그런 다음 이 두 값을 적절한 필터 값에 매핑하는 거죠.

`topic` 매개변수는 사전 필터링에 사용되지 않고 벡터 유사성 검색에 사용되므로 약간 다르게 처리해요.

if topic:  # Do vector comparison
    vector_snippet = (
        " WITH c, a, vector.similarity.cosine(c.embedding,$embedding) AS score "
        "ORDER BY score DESC LIMIT toInteger($k) "
    )
    params["embedding"] = embeddings.embed_query(topic)
else:  # Just return the latest data
    vector_snippet = " WITH c, a ORDER BY a.date DESC LIMIT toInteger($k) "

LLM이 사용자가 뉴스의 특정 주제에 관심이 있음을 식별하면, `topic` 입력의 텍스트 임베딩을 사용하여 가장 관련성이 높은 문서를 찾아요. 반면에 특정 주제가 식별되지 않으면 최신 기사 몇 개만 반환하고 벡터 유사성 검색을 완전히 피합니다.

이제 Cypher 문을 함께 배치하고 이를 사용하여 데이터베이스에서 정보를 검색해야 해요.

return_snippet = "RETURN '#title ' + a.title + 'n#date ' + toString(a.date) + 'n#text ' + c.text AS output"

complete_query = (
    base_query + " AND ".join(where_queries) + vector_snippet + return_snippet
)

# Retrieve information from the database
data = graph.query(complete_query, params)
print(f"Cypher: {complete_query}n")
# Safely remove embedding before printing
params.pop('embedding', None)
print(f"Parameters: {params}")
return "###Article: ".join([el["output"] for el in data])

모든 쿼리 조각을 결합하여 최종 `complete_query`를 구성합니다. 그런 다음 동적으로 생성된 Cypher 문을 사용하여 데이터베이스에서 정보를 검색하고 이를 LLM에 반환해요. 입력 예를 위해 생성된 Cypher 문을 한번 살펴볼까요?

get_organization_news(
  organization='neo4j',
  sentiment='positive',
  topic='remote work'
)

# Cypher: CYPHER runtime = parallel parallelRuntimeSupport=all
# MATCH (c:Chunk)<-[:HAS_CHUNK]-(a:Article) WHERE 
# EXISTS {(a)-[:MENTIONS]->(:Organization {name: $organization})} AND 
# a.sentiment > $sentiment 
# WITH c, a, vector.similarity.cosine(c.embedding,$embedding) AS score 
# ORDER BY score DESC LIMIT toInteger($k) 
# RETURN '#title ' + a.title + 'ndate ' + toString(a.date) + 'ntext ' + c.text AS output

# Parameters: {'k': 5, 'organization': 'Neo4j', 'sentiment': 0.5}

동적 쿼리 생성은 예상대로 작동하며 데이터베이스에서 관련 정보를 검색할 수 있다는 것을 알 수 있어요.

OpenAI 에이전트 정의

다음으로 함수를 에이전트 도구로 래핑해야 해요. 먼저 입력 매개변수 설명을 추가해볼게요.

사전 필터링 매개변수는 설명하기 꽤 간단했지만, `topic` 매개변수가 예상대로 작동하게 만드는 데 약간의 어려움이 있었어요. 결국, LLM이 더 잘 이해할 수 있도록 몇 가지 예시를 추가하기로 결정했죠. 또한 국가 명명 형식에 대한 LLM 정보를 제공하고, 감정에 대한 열거형도 제공하는 것을 볼 수 있어요.

이제 LLM 사용 시기에 대한 지침이 포함된 설명과 이름을 지정해서 커스텀 툴을 정의할 수 있어요.

class NewsTool(BaseTool):
    name = "NewsInformation"
    description = (
        "useful for when you need to find relevant information in the news"
    )
    args_schema: Type[BaseModel] = NewsInput

    def _run(
        self,
        topic: Optional[str] = None,
        organization: Optional[str] = None,
        country: Optional[str] = None,
        sentiment: Optional[str] = None,
        run_manager: Optional[CallbackManagerForToolRun] = None,
    ) -> str:
        """Use the tool."""
        return get_organization_news(topic, organization, country, sentiment)

마지막으로 `agent_executor`를 정의하는 거예요. 얼마 전에 구현했던 OpenAI 에이전트의 LCEL 구현을 그대로 재사용했어요.

llm = ChatOpenAI(temperature=0, model="gpt-4-turbo", streaming=True)
tools = [NewsTool()]

llm_with_tools = llm.bind(functions=[format_tool_to_openai_function(t) for t in tools])

prompt = ChatPromptTemplate.from_messages(
    [
        (
            "system",
            "You are a helpful assistant that finds information about movies "
            " and recommends them. If tools require follow up questions, "
            "make sure to ask the user for clarification. Make sure to include any "
            "available options that need to be clarified in the follow up questions "
            "Do only the things the user specifically requested. ",
        ),
        MessagesPlaceholder(variable_name="chat_history"),
        ("user", "{input}"),
        MessagesPlaceholder(variable_name="agent_scratchpad"),
    ]
)

agent = (
    {
        "input": lambda x: x["input"],
        "chat_history": lambda x: _format_chat_history(x["chat_history"])
        if x.get("chat_history")
        else [],
        "agent_scratchpad": lambda x: format_to_openai_function_messages(
            x["intermediate_steps"]
        ),
    }
    | prompt
    | llm_with_tools
    | OpenAIFunctionsAgentOutputParser()
)

agent_executor = AgentExecutor(agent=agent, tools=tools)

이 에이전트는 뉴스 정보를 검색하는 데 사용할 수 있는 툴을 하나 가지고 있어요. 또한 `chat_history` 메시지 플레이스홀더를 추가해서 에이전트가 대화할 수 있도록 하고, 후속 질문과 답변이 가능하도록 만들었답니다.

구현 테스트

몇 가지 입력을 실행하고 생성된 Cypher 문과 파라미터를 살펴볼게요.

agent_executor.invoke(
  {"input": "What are some positive news regarding neo4j?"}
)

# Cypher: CYPHER runtime = parallel parallelRuntimeSupport=all 
# MATCH (c:Chunk)<-[:HAS_CHUNK]-(a:Article) WHERE 
# EXISTS {(a)-[:MENTIONS]->(:Organization {name: $organization})} AND 
# a.sentiment > $sentiment WITH c, a 
# ORDER BY a.date DESC LIMIT toInteger($k) 
# RETURN '#title ' + a.title + 'date ' + toString(a.date) + 'text ' + c.text AS output
# Parameters: {'k': 5, 'organization': 'Neo4j', 'sentiment': 0.5}

생성된 Cypher 문이 유효하네요. 특정 주제를 지정하지 않았으니 Neo4j를 언급하는 긍정적인 기사의 마지막 5개 텍스트 청크를 반환하는군요. 좀 더 복잡한 작업을 해볼까요?

agent_executor.invoke(
   {"input": "What are some of the latest negative news about employee happiness for companies from France?"}
)

# Cypher: CYPHER runtime = parallel parallelRuntimeSupport=all 
# MATCH (c:Chunk)<-[:HAS_CHUNK]-(a:Article) WHERE 
# EXISTS {(a)-[:MENTIONS]->(:Organization)-[:IN_CITY]->()-[:IN_COUNTRY]->(:Country {name: $country})} AND 
# a.sentiment < $sentiment 
# WITH c, a, vector.similarity.cosine(c.embedding,$embedding) AS score 
# ORDER BY score DESC LIMIT toInteger($k) 
# RETURN '#title ' + a.title + 'date ' + toString(a.date) + 'text ' + c.text AS output
# Parameters: {'k': 5, 'country': 'France', 'sentiment': -0.5, 'topic': 'employee happiness'}

LLM 에이전트는 사전 필터링 파라미터를 올바르게 생성했지만 특정 항목도 식별했어요. 주제 말이죠. 이 주제는 Vector Embedding 유사성 검색에 대한 입력으로 사용되므로 검색 프로세스를 더욱 세분화할 수 있어요.

요약

이번 블로그 포스팅에서는 예제 그래프 기반 메타데이터 필터를 구현해서 Vector Embedding 검색 정확도를 향상시켰어요. 하지만 데이터 세트에는 훨씬 더 정교한 사전 필터링 쿼리를 허용하는 광범위하고 상호 연결된 옵션이 있답니다. Graph Database 표현을 통해 구조화된 필터의 가능성은 LLM 함수 호출 기능과 결합되어 Cypher 문을 동적으로 생성할 때 정말 무궁무진하죠.

또한 에이전트에는 이 블로그 포스팅에 표시된 것처럼 구조화되지 않은 텍스트를 검색하는 도구와 다음을 수행할 수 있는 기타 도구가 있을 수 있어요. 구조화된 정보 검색, Knowledge Graph를 많은 RAG 애플리케이션에 대한 탁월한 솔루션으로 만들어주죠.

코드는 다음에서 사용할 수 있습니다. .

유행어를 좋아하든 싫어하든 '빅데이터'는 피할 수 없는 현실이에요. 비즈니스 인텔리전스든 생물정보학이든, 추천 엔진이든 위험 분석이든 상관없이, data는 계속 증가할 뿐이죠.

그래프는 빅데이터 작업을 위한 강력한 도구라는 건 의심할 여지가 없어요. 안타깝게도 그래프의 가장 큰 장점 중 하나인 직관적인 시각화는 기본적으로 고정된 리소스인 화면 크기로 인해 제한되죠. 아무리 큰 모니터라도 수백 개의 Node만 수용하면 그래프 구조를 분석하기 어려워져요.

너무 빽빽해요

2012년에 제가 처음 시작한 스타트업은 공유 경제를 위한 신뢰 기반으로 소셜 네트워크를 활용했어요. (이건 전문 용어 빙고 at 그래프커넥트 2018에서 훌륭한 연습이 되기도 했죠). 우리는 많은 실제 및 가짜 소셜 네트워크 계정의 그래프 서명을 살펴봤어요. 이러한 계정 간의 차이를 정량화하기는 어렵지만, 시각화하면 패턴의 차이가 명확하게 나타나요.

하지만 우리는 인기 있는 사람들 덕을 보지는 못했어요. 예를 들어 아래 그래프는 최대 2,000명의 친구를 보유한 사용자를 보여줘요. 별도의 커뮤니티를 나타내는 다양한 색상의 그래프 레이아웃은 Gephi를 사용하여 2D로 만들었어요.

이건 꽤 멋지고 몇 가지 뚜렷한 클러스터를 보여주지만, 이 접근 방식의 단점도 드러내죠. 가장 눈에 띄는 건 모든 것이 겹쳐 보이는 왼쪽의 거대한 Node 덩어리예요. 2D 레이아웃은 개별 클러스터를 효과적으로 분리하지만, 해당 클러스터가 서로 연결되어 있으면 답이 없어요.

이제 남은 건 그래프만 보여주는 그래프 시각화뿐이에요. 연결 수, 활동 수준, 위치 등과 같은 매개변수별로 클러스터링하려는 경우 색상이나 크기를 다시 할당하는 것 외에는 할 수 있는 일이 많지 않아요. Node를 시각적으로 정렬하고 분류하는 건 쉽지 않죠.

물론 데이터를 별도의 애플리케이션으로 가져와 해당 속성의 2D 산점도를 생성하거나 지도에 Node를 펼칠 수도 있어요. 하지만 우리는 그래프에 의해 직관적으로 포착된 차트와 관계 사이의 연결을 잃게 될 거예요.

게다가, 저는 그 사이를 쉽게 전환할 수 없어요.(u0:User)-[:friend_of]-(u1:User)위의 관점을 다음과 같이 표현합니다.

1. (u:User)-[:mentioned_in]->(p:Post)
2. (p0:Post)-[:mentioned_same_user_with]-(p1:Post)
3. (u0:User)-[:mentioned_in_same_post_with]-(u1:User)

3차원으로!

2년 후 저는 현재의 스타트업인 키네비즈를 설립했어요. 첫 번째 클라이언트인 Box는 파일 공유 플랫폼에서 협업을 시각화하기 위해 우리를 초대했죠. 이 "콜라보 그래프"는 BoxWorks 고객 컨퍼런스를 위해 만들어졌고, 참석자들은 제스처 컨트롤을 사용하여 대형 화면에서 그래프와 상호 작용했어요.

제스처 인터페이스를 최대한 활용하기 위해 우리는 레이아웃을 3D로 하기로 결정했어요. 우리를 놀라게 한 첫 번째 점은 3,000개 이상의 Node가 있는 이 3D 그래프가 300개 이상의 Node로 구성된 2D 그래프만큼 빽빽해 보이지 않는다는 것이었어요!

클러스터는 상호 연결을 잃지 않고 시각적으로 분리돼요. 직관적으로 고차원 정보는 고차원 시각화에서 이점을 얻는다는 것을 알 수 있었죠 (그래프의 각 연결이 차원으로 간주된다는 점을 고려하면). 2D에서 3D로의 선형적 증가는 편안하게 배치할 수 있는 데이터 양의 기하급수적인 증가를 의미해요.

VR을 이용한 소수자 신고

3D 데이터 시각화는 완전히 새로운 건 아니고 단점이 없는 것도 아니에요. 2D 화면에서는 깊이 정보가 손실되죠. 그리고 모든 화면 기반 시각화는 글로벌 컨텍스트를 유지하면서 로컬 구조를 조사하는 것 사이의 단절로 인해 어려움을 겪어요 (일명 Google 지도 문제: 거리를 확대하면 도시의 컨텍스트를 잃게 되잖아요).

GenAI-Stack 및 OpenAI를 사용한 단계별 연습

Abstract

이번 글에서는 이전 블로그 게시물의 아이디어와 실험을 바탕으로 PDF 문서에서 RAG 애플리케이션을 구축하는 데 필요한 모든 단계를 안내해 드릴 거예요.

프로젝트 저장소: 깃허브.

GitHub – Joshua-Yu/graph-rag: 그래프 기반 검색 + GenAI = 프로덕션에서 더 나은 RAG

개요

더 나은 Retrieval-Augmented Generation(RAG) 솔루션을 구축하는 방법에 대한 글과 제품이 정말 많죠. 과거에는 Property Graph Database를 사용한 지식 저장, 인덱싱 및 검색을 중심으로 RAG의 주요 측면을 설명했어요. 비정형 데이터와 정형 데이터 모두.

• 벡터를 Knowledge Graph와 함께 저장해야 하는 이유는 무엇일까요?

여기에서는 를 보여드리면서 모든 부분을 하나로 모아보려고 해요. PDF 문서 파싱 및 수집부터 Knowledge Graph 생성, 주어진 자연어 질문에 대한 그래프 검색에 이르기까지 엔드투엔드 파이프라인을 다루고 있답니다.

주요 솔루션 구성 요소

1. PDF 문서 파싱 및 콘텐츠 추출

LLM Sherpa(깃허브)는 계층적 레이아웃 정보(예: 문서, 섹션, 문장, 표 등)로 PDF 문서를 파싱하기 위한 Python 라이브러리이자 API에요.

일반적인 청킹 전략과 비교하면 (고정 길이 + 텍스트 겹침) 문서 구조를 보존할 수 있다면 보다 유연한 청킹이 가능해지기 때문에 생성을 위한 더 완전하고 관련성 높은 컨텍스트를 제공할 수 있어요.

2. 지식 저장소용 Neo4j AuraDB

AuraDB에는 기능을 실험하고 시험해 볼 수 있는 free 티어가 있어요. 자신만의 인스턴스를 생성하는 자세한 단계를 보려면 다음 온라인 문서 또는 이 기사를 참고하세요:

간단한 3단계로 Knowledge Graph에 Q&A 기능 추가하기

3. 데이터 수집을 위한 Python + Neo4j 드라이버

PDF 문서의 내용은 Cypher 쿼리 언어를 사용하는 Python 드라이버를 통해 Neo4j에 로드돼요.

4. Semantic Search를 위한 Neo4j Vector Index

Neo4j가 제공하는 표준 데이터 유형, 자유 형식 텍스트 및 텍스트 임베딩 절차에 의해 생성된 벡터에 대한 Index에요.

텍스트 임베딩과 벡터가 처음이라면 개념과 사용 샘플을 설명하는 게시물을 참조해 보세요.

텍스트 임베딩 — 무엇을, 왜, 어떻게?

5. 빠른 프로토타이핑을 위한 GenAI-Stack

The GenAI 스택은 Neo4j가 협력하여 만든 사전 구축된 개발 환경이에요. , 랭체인, 그리고 를 사용하죠. 이 스택은 특히 RAG를 통해 LLM(Large Language Models)에서 생성된 응답의 정확성, 관련성, 출처를 개선하는 데 중점을 두고 GenAI 애플리케이션을 생성하도록 설계되었답니다.

숙달을 위한 빠른 길: 효율적인 LLM 애플리케이션을 위한 Neo4j GenAI 스택

우리 프로젝트에서는 채팅 애플리케이션의 빠른 개발을 위해 LangChain 부분이 필요해요.

6. 임베딩 및 텍스트 생성을 위한 OpenAI 모델

OpenAI의 임베딩 모델인 *text-embedding-ada-002* 와 LLM *GPT-4* 가 사용되니까, OpenAI API 키가 필요해요.

프로젝트 연습

1. 준비

1.1 를 저장소에서 복제하세요: .

1.2 Neo4j AuraDB 무료 인스턴스를 생성하세요.

1.3 필요한 종속성을 설치해야 해요.

• llmsherpa ()
• Neo4j GenAI-stack (). 여기에는 LangChain과 Streamlit(프론트엔드)이 이미 포함되어 있어요.
• Python용 Neo4j 드라이버

1.4 OpenAI API 키도 필요하겠죠?

2. PDF 문서 파싱 및 Neo4j로 로드

샘플 프로젝트 폴더 아래의 custom 폴더에서 LayoutPDFReader_KGLoader 노트북을 실행해 보세요. 다음 단계를 따르면 돼요:

• 파일 시스템 또는 URL에서 PDF 문서의 위치를 ​​제공하세요.
• Neo4j AuraDB 연결 세부 정보를 업데이트하세요.
• initNeo4j()를 실행해서 constraint와 index를 생성하세요 (한 번만).
• ingestDocumentNeo4j()를 실행해서 문서의 모든 내용을 Graph Database에 로드하세요. 현재는 텍스트 chunk와 table이 지원된답니다.

3. 텍스트 및 테이블 이름에 대한 임베딩 생성 및 저장

KGEmbedding_Populate 노트북을 열고 실행해서 임베딩을 생성하고 저장하세요. OpenAI API 키와 Neo4j AuraDB 연결 정보를 입력한 후에 embedding node를 만들면 돼요.

# First parameter is the node label, 
# second is the node property name which contains text to be embedded

LoadEmbedding("Chunk", "sentences")

LoadEmbedding("Table", "name")

이제 다음과 같은 스키마를 가진 가 만들어졌어요.

4. 채팅 애플리케이션 준비

복제된 프로젝트 위치로 이동해서GenAI Stack을 클릭하고 아래 파일과 하위 폴더를 복사하세요. GenAI Stack 폴더의를요. 간단하게 설명해 드릴게요.

• chains.py: 구조 인식 검색기의 새로운 프로시저가 포함된 업데이트된 Python 파일이에요.

# from line 154
def configure_qa_structure_rag_chain(llm, embeddings, embeddings_store_url, username, password):
    # RAG response based on vector search and retrieval of structured chunks 

  ...
  ...

• cs_bot_papers.py: Streamlit 및 새로운 검색기를 기반으로 한 채팅 프런트 엔드입니다.

이 구조 인식 검색기에 대한 자세한 설명은 제 다른 블로그 게시물을 확인해 보세요.

GenAI 스택에 구조 인식 검색 추가

5. 채팅 애플리케이션 실행

이제 실행할 준비가 되었어요! 다음을 입력해서 Streamlit 애플리케이션을 실행해 보세요 (Python 환경에 따라 약간 다른 명령줄을 사용할 수 있어요).

python -m streamlit run cs_bot_papers.py

기능을 보여드리기 위해 비교적 최신 논문을 넣어서 테스트해봤는데요,Natural Language Is All You Need for Graph(arXiv) 그리고 "instructGLM" 접근 방식에 대해 질문했어요.

만약 Retrieval-Augmented Generation (RAG)이 disabled 상태라면, GPT-4는 지식 마감일이 2023년 4월이기 때문에 정답을 제공할 수 없어요.

Retrieval-Augmented Generation (RAG)이 되면, 애플리케이션은

• 먼저 질문의 텍스트 Vector Embedding을 생성해요.
• 그런 다음 Neo4j AuraDB에서 벡터 검색에 사용되죠.
• 가장 많이 일치하는 chunk에 대해 관련 내용같은 section이 검색됩니다 (구조 인식 검색 부분).
• 답변을 생성하기 위해 사용자 질문과 함께 GPT-4로 전달돼요.

이것은 소위구조 인식 검색을 사용하는데요. 아래 스크린샷을 보면, 검색된 정보에서 답변뿐만 아니라 메타데이터로 전달된 참조 위치도 제공되는 것을 확인할 수 있어요.

추가 토론

위 단계를 따라 Graph Database로 구동되는 RAG 채팅 애플리케이션을 성공적으로 실행할 수 있기를 바라요.

Neo4j를 사용해서 지식을 저장하면 유연한 모델, 다양한 indexing 기능, 빠른 query 성능뿐만 아니라 Cypher query language로 복잡한 검색과 같은 더 많은 잠재력을 얻을 수 있어요.

GenAI

앞으로 이 샘플 프로젝트에 더 중요한 기능을 추가하는 여정을 계속할 거예요.

"Allianz Benelux에서는 연결된 데이터 관점에서 데이터를 볼 수 있게 해주는 그래프를 정말 중요하게 생각해요. 데이터를 개별 정보 조각으로 보는 대신, 모든 조각이 어떻게 연결되어 있는지 이해하고 싶거든요." 라고 Allianz Benelux의 비즈니스 인텔리전스 책임자 Jan Doumen이 말했어요.

이번 주 5분 인터뷰에서는 비즈니스 인텔리전스 책임자인 Jan Doumen과 Aarthi Kumar (수석 데이터 과학자), Niels Holtrop (데이터 과학자) 님과 이야기를 나눠볼 거예요. 이 분들은 모두 Graphie Award 수상자이기도 한데요, Allianz Benelux에서 Neo4j를 사용해서 고객 프로필을 만들고 보험 업계의 사기를 어떻게 탐지하는지 한번 알아볼까요?

자기소개를 부탁드려요.

Jan: 안녕하세요! 이 글을 읽고 계신 시간이 언제든 좋은 아침, 좋은 오후, 좋은 저녁, 혹은 좋은 밤이에요.

저희는 Allianz Benelux, 그 중에서도 데이터 오피스라는 조직 내 사업 부서에 속해 있어요. Allianz는 세계에서 가장 큰 보험 회사 중 하나이고, Benelux는 벨기에, 네덜란드, 룩셈부르크 이렇게 세 나라를 아우르는 국경을 넘나드는 운영 기관이죠.

저희 사업은 소매, 중소기업(SMB), 중견 기업, 그리고 손해보험(재산 및 손해) 사업과 생명 보험 사업 모두에 집중하고 있어요. 주로 브로커가 중개하는 시장에서 보험을 판매하고 있답니다. 그래프로 어떤 일을 하는지 좀 더 자세히 알려드릴게요.
저는 고객 인사이트 및 인텔리전스, 관리 정보 및 인사이트 분야의 전문 분야 책임자이자 팀장인 Jan Doumen입니다.

Aarthi: 안녕하세요, 여러분! 저는 Aarthi Kumar이고요, 수석 데이터 과학자이자 고객 및 브로커 인사이트 및 인텔리전스 부문의 수석 리더입니다.

Niels: 만나서 반가워요. 제 이름은 Neils Holtrop이고, 사기 정보 팀의 데이터 과학자이자 주요 리더입니다. 저희는 사기 사업부와 함께 사기 퇴치에 고급 분석 및 Machine Learning 알고리즘을 통합하는 것을 목표로 하고 있어요.

Neo4j를 어떻게 사용하고 있나요?

Jan: Allianz Benelux에서는 연결된 데이터 관점에서 데이터를 볼 수 있게 해주는 그래프의 중요성을 굳게 믿고 있어요. 데이터를 개별 정보 조각으로 보는 대신, 이 모든 조각들이 어떻게 서로 연결되어 있는지 이해하고 싶거든요. 이런 관점을 통해 이미 큰 이익을 얻고 있는 두 가지 영역이 있어요.

하나는 고객 인텔리전스인데, 고객에 대한 진정한 360도 뷰를 만들 수 있었어요. 고객이 실제로 필요로 하는 것이 무엇인지 이해하기 시작했죠. 다른 하나는 사기 정보예요. 아시다시피 사기는 저희 비용의 상당 부분을 차지하고, 이는 정직하게 보험금을 청구하는 대다수 고객에게 부정적인 영향을 미치거든요.

Neo4j를 사용하기 전에는 이 문제를 어떻게 해결했나요?

Niels: 보험에서 사기 문제는 정말 큰 문제예요. 추정치에 따르면 지급된 청구 비용의 약 5~10%가 사기 때문에 발생한다고 해요. 여기에는 전문적인 사기꾼뿐만 아니라 자신의 주장을 과장하는 일반 소비자도 포함되죠. 보험 업계에서 그래프 기술을 사용하는 건 주로 단계적이거나 과장된 청구와 관련된 전문적인 사기에 초점을 맞추고 있어요. 이런 종류의 주장은 어떤 식으로든 서로를 아는 사람들 사이에서 발생하는 사회적 연결을 통해 주로 발견되거든요.

과거에는 이런 관계를 파악하는 과정이 수많은 수작업으로 이루어져서 시간이 엄청 오래 걸렸어요. 어떤 사건을 입증하려면 네트워크 전체를 그려서 누가 누구와 어떤 방식으로 관련되어 있는지 확인해야 했죠. 하지만 그래프를 사용하면 버튼 클릭 한 번으로 네트워크를 생성할 수 있어요. 그래서 당사자들의 초기 개요를 만드는 데 시간을 엄청나게 절약할 수 있게 되었죠.

Aarthi: 고객 데이터는 모든 조직의 금맥과 같아요. 그래프가 없었다면 고객 Golden Profile(중앙 고객 마스터 프로필) 대신 고객 Golden Record(고객에 대한 일치하는 단일 뷰)를 사용했을 거예요.

전통적인 관계형 데이터베이스는 사람이 이해하기 어려운 고객에 대한 사실 기록을 제공했죠. 데이터에 더 많은 차원을 추가할수록 영업 및 마케팅 팀이 데이터를 사용하는 게 점점 더 어려워졌어요. 주요 사용 사례 중 하나는 교차 판매 및 상향 판매 기회인데요, McKinsey 연구에 따르면 보험 회사의 교차 판매 및 상향 판매 기회는 매출을 최소 10~20% 증가시킬 수 있다고 해요. 이런 기회를 놓치고 싶지 않겠죠?

Neo4j를 선택하게 된 계기가 무엇인가요?

Jan: 저희는 여러 그래프 데이터베이스 제공업체를 살펴보고 있었어요. 결국 대부분은 기존 데이터베이스 위에 그래프를 제공하더라고요. 네이티브 그래프를 만드는 곳은 소수에 불과했고, Neo4j도 그 중 하나였죠. 그래서 다른 제품들과 비교하면서 Neo4j를 선택하게 되었어요. 저는 광범위한 구현에서 우리를 얼마나 지원할 의향이 있는지 회사 뒤에 있는 사람들과 이야기를 나눴어요.

오늘날의 경제 환경에서는 깊고 신뢰할 수 있는 통찰력과 강력한 예측이 꼭 필요해요. 데이터는 정말 소중한 자산이지만, 데이터 내부와 데이터 간의 관계는 아직 제대로 활용되지 못하고 있는 경우가 많죠.

Graph Embedding은 연결된 데이터의 구조를 학습해서 가장 시급한 문제들을 해결하는 새로운 방법을 제시하고, 미처 보지 못했던 부분에 대한 가시성을 더해주는 새로운 기술이에요.

점점 더 많은 조직들이 데이터 내 연결의 가치를 알아보고 있고, 그만큼 그래프 분석이 현대적인 데이터 및 분석 전략의 기초로 널리 인정받고 있어요. 예를 들어 Gartner는 그래프가 2021년 10%에서 2025년까지 데이터 및 분석 혁신의 80%에 사용될 거라고 예측하고 있대요.

Knowledge Graph에 대한 강력한 심층 `Query`는 과거에는 조사하는 데 몇 주씩 걸렸을 비즈니스 질문에 빠르게 답변을 제공해줘요. 그래프 시각화 도구는 자유로운 탐색을 촉진하고 "아하!" 하는 순간을 만들어내죠.

그런데 전체 그래프를 분석하거나 예측하는 경우는 어떨까요? 아니면 이미 질문하는 방법을 알고 있는 질문을 뛰어넘어보는 건 어때요?

일반적인 첫 번째 단계는 비지도 Machine Learning 기술을 사용하는 거예요. 그래프 알고리즘을 사용해서 패턴, 이상 현상 등을 식별하는 거죠. 예를 들어, 데이터 과학자는 PageRank와 같은 중심성 알고리즘을 사용해서 회사에서 가장 중요한 사람을 식별하거나, Louvain과 같은 커뮤니티 탐지 알고리즘을 사용해서 자금 세탁을 찾아낼 수 있어요.

그래프 분석의 다음 개척지는 지도 Machine Learning을 적용하는 건데요. 즉, 다음에 일어날 일을 예측하고, 누락된 데이터를 채우고, 그래프 구조가 미래를 예측할 수 있는 방법을 이해하는 거예요. 바로 이럴 때 Graph Embedding이 필요한 거고, 연결된 데이터 내에서 통찰력을 얻기 위한 기본 기술이 되는 거죠.

이번 블로그 포스팅에서는 다음 내용을 살펴볼 거예요.

• 지금 Graph Embedding이 필요한 이유
• Graph Embedding이란 무엇이고 어떻게 작동하나요?
• Graph Embedding의 실제 사용 예시

지금 Graph Embedding이 필요한 이유

Graph Embedding은 연결된 데이터(Knowledge Graph, 고객 여정, 거래 네트워크)를 예측 신호로 변환하는 데 사용되는 기술이에요.

데이터 과학자는 보통 과거 데이터를 사용해서 예측 모델을 강화하죠. 하지만 최근 전 세계적으로 유행하는 전염병이나 자연 재해와 같은 '블랙 스완' 사건을 생각해보면, 이런 데이터는 예측 가능성이 훨씬 낮아져요. 과거 데이터 표의 행과 열을 살펴보는 대신, Graph Embedding을 사용하면 연결된 데이터에서 통찰력을 얻을 수 있어요.

그래프는 복잡한 공급망, 의료 연구, 고객 360, 사기 탐지 등 거의 모든 종류의 데이터를 나타낼 수 있다는 사실! 정말 흥미롭죠?

Wikimedia Commons에 따라 라이센스가 부여된 칠레 ESO Paranal Observatory의 레이저가 인공 참조 별을 생성하는 방법에 대한 표지 이미지.

Knowledge Graph로 구동되는 RAG 애플리케이션에서 부모-자식 관계, 질문 기반, 주제 요약과 같은 그래프 데이터 모델을 사용하는 경우를 알아볼까요?

Retrieval-Augmented Generation(RAG) 애플리케이션을 구축할 때 문서를 벡터 또는 Graph Database에 넣고, 임베딩을 생성하고, 코사인 유사성을 실행하고 싶은 유혹이 들 수 있어요.

이 글에서는 이러한 애플리케이션을 향상시키는 데 사용할 수 있는 몇 가지 대체 그래프 데이터 모델과 각 모델이 제공하는 고유한 이점에 대해 설명할게요. 이 글을 읽기 전에 여러분이 Graph Database와 RAG에 어느 정도 익숙하다고 가정할게요.

여기에는 GitHub 저장소가 포함되어 있고, 다음을 통해 이러한 데이터 모델을 생성하고 탐색하는 코드가 들어있어요. arrows.app 또는 Neo4j 브라우저를 사용하면 자신의 애플리케이션에 대한 데이터 모델을 수정할 수 있어요.

Neo4j

Neo4j는 벡터 검색을 수행할 수 있는 벡터 인덱싱 기능이 있는 Graph Database를 제공해요. 다음을 사용해서 로컬에서 Neo4j를 사용해 볼 수 있어요: 데스크톱 버전 또는 클라우드 호스팅 환경에서 Neo4j AuraDB를 무료로 사용할 수 있어요. 데이터베이스를 초기화할 때 Neo4j 버전 ≥ 5.13을 실행해서 벡터 인덱싱 기능이 있는지 확인하세요.

Vector Embedding

Vector Embedding은 미디어를 수학적으로 나타내는 일련의 숫자예요. 이는 전통적으로 단어와 문장으로 수행되었지만 이제는 오디오, 이미지 및 비디오를 Vector Embedding으로 인코딩하는 것도 가능해요. 벡터의 길이를 차원이라고 해요.

Neo4j는 최대 4096차원의 벡터를 지원하며 일반적인 값은 768 및 1536이에요.

[0.123, -0.423, 0.519, ..., -0.942]

컨텍스트 검색

반환된 컨텍스트는 사용자 질문 임베딩과 그래프에 있는 텍스트 임베딩 간의 계산된 유사성 점수에 따라 결정돼요.

일치하는 임베딩에서 검색된 텍스트를 분리하는 것이 좋아요. 이는 원시 청크에 삽입 시 인코딩된 정보를 희석시킬 수 있는 필러 단어와 추가/충돌 정보가 포함될 가능성이 높기 때문이에요.

더 작은 및/또는 처리된 텍스트 청크를 포함함으로써 유사성 일치를 더 정확하게 만들 수 있으며, 그래프 관계를 탐색하여 응답 생성을 위해 LLM에 반환되는 텍스트를 제어할 수 있어요.

기본 그래프 데이터 모델

이 그래프 데이터 모델은 문서 `Node`에 텍스트 청크를 저장하고 반환된 텍스트에서 일치하는 임베딩을 분리하지 않아요. 문서 `Node`의 임베딩 속성에 대해 벡터 검색을 실행하여 LLM에 컨텍스트로 반환할 가장 관련성이 높은 텍스트를 찾을 수 있어요. 원한다면 `Relationship`을 탐색하여 각 텍스트 덩어리의 출처를 찾아 인용을 제공할 수도 있어요.

이 모델은 개념 증명에 적합하지만 크게 개선될 수 있으며 생산 애플리케이션에 더 나은 옵션이 있어요.

부모-자식

부모-자식 모델은 기본 모델과 유사하지만 텍스트 덩어리를 더 세분화하여 예상 질문에 더 가까운 길이를 만들어요. 이렇게 하면 질문과 일치하는 텍스트 간의 정보 세분성이 유지되므로 한 단락에 대해 몇 단어를 일치시키지 않아요.

하위 `Node` 포함 일치 항목이 있으면 `Relationship`을 탐색하여 하위 텍스트와 주변 텍스트가 포함된 상위 `Node` 텍스트를 검색할 수 있어요. 이 방법은 보다 정확한 벡터 검색 일치를 제공하는 동시에 컨텍스트가 풍부한 결과를 반환해요.

애플리케이션에서 일반적인 질문의 길이를 찾으려면 실험이 필요하지만 문서 채팅 애플리케이션에서는 140자가 표준 길이인 것으로 나타났어요.

질문

오늘날 대부분의 대규모 조직에서는 데이터가 사일로에 갇혀 있다는 점을 인지하고 있을 거예요.

데이터 연결이 끊어지면, 보고서가 불완전해지고 제대로 활용하기 어려워지죠. 그래서 데이터 사일로를 통합해서 보여주는 보고서가 필요한 거예요. 그래야 조직 내에서 중요한 정보를 찾고, 비즈니스 성공에 도움이 되는 정확한 정보를 실행하고 제공하는 부서의 능력을 확신할 수 있거든요.

NoSQL: 데이터 사일로에 대한 해답

대부분의 조직은 데이터 사일로 문제를 야기했던 도구와 기술로는 그 문제를 해결할 수 없다는 걸 이미 알고 있어요. 그래서 지난 몇 년 동안 NoSQL 데이터베이스와 기술이 개발되고 배포되는 걸 볼 수 있었죠. NoSQL은 데이터를 더 빠르고, 더 큰 규모로, 더 민첩하게 통합하는 데 도움을 주거든요.

이 강력한 새 데이터베이스와 플랫폼은 기존 방식보다 데이터 통합 시간을 단축시켜 주지만, 개발자 중심이라는 또 다른 과제를 안겨주죠. 특히, 이러한 최신 기술을 개발하고 사용하는 데 필요한 새로운 기술을 습득해야 해요.

우리는 데이터베이스 르네상스라는 멋진 시대에 살고 있고, 멋진 새로운 기술들을 모두 가지고 있지만, NoSQL 전문 지식은 아직 상대적으로 새롭고 발전하고 있어요. 40년 넘게 사람들은 SQL 기반 기술을 사용해서 데이터 관리 및 통합 솔루션을 개발해 왔거든요. 마치 40년 동안 사람들이 오른손으로 데이터 관리를 연습해 온 것과 같은 거죠.

NoSQL의 최첨단에 있는 사람들은 와서 데이터로 무엇을 할 수 있는지 보여주면서 이렇게 말해요. "보세요, 우리는 귀하의 데이터를 사용해서 유연하고 안전하게 대규모로 결과를 제공하고, 현재 수행하는 시간의 1/4 만에 통찰력을 제공할 수 있도록 도와드릴 수 있습니다!" 개발자와 기업은 우리의 말을 듣고 기뻐하며 "좋아요, 한번 해봐요! 어떻게 하면 되죠?"라고 외치죠. 그러면 우리는 "쉬워요! 이 새로운 기술로 성공하기 위해 우리가 할 일은... 왼손을 사용하도록 요청하는 것뿐입니다."라고 대답하는 거예요.

기존 분석 방식으로는 대규모 데이터 세트 내의 복잡한 관계를 처리하기 어려워서, 많은 조직들이 연결된 데이터로부터 강력한 통찰력을 얻는 데 어려움을 겪고 있어요. 진정으로 정보에 기반한 의사 결정을 내리려면 사기 탐지, 추천 시스템 개선, 민감한 데이터 보호, 공급망 최적화 등 데이터 속 숨겨진 연결 고리를 이해하는 게 중요하죠.

그래프 분석은 데이터 엔터티 간의 관계를 분석해서 숨겨진 패턴, 추세, 이상 징후를 찾아내는 데 도움을 줘요. 기존 분석 방법으로는 놓칠 수 있는 예측을 가능하게 하고, 새로운 통찰력을 얻을 수 있게 해주죠.

이번 가이드에서는 그래프 분석이 어떻게 데이터 문제를 기회로 바꿔주는지 알아볼 거예요. 그래프 분석의 실제 적용 사례들을 살펴보고, 가 어떻게 복잡한 데이터 분석을 간소화하고 즉시 활용 가능한 통찰력을 제공하는지 배워볼게요.

사기 탐지 및 위험 분석: 복잡한 사기 계획 탐색

은행, 소매업체, 통신 회사, 전자 상거래 기업들은 모두 보안 위험에 노출되어 있죠. 예를 들어 합성 신원 사기, 계정 탈취, 정교한 교차 채널 공격 등이 있을 수 있어요. 조직은 공유 IP 주소, 장치 지문 일치, 조정된 거래 패턴 등 악의적인 행위자들과 그들의 활동 간의 연결 고리를 식별해서 사기 조직과 사이버 범죄 네트워크의 정체를 밝혀내고 피해를 예방하거나 최소화할 수 있어요. 하지만 안타깝게도, 이런 연결 고리들은 엄격한 테이블 구조를 강요하고 복잡한 관계를 표현하는 데 많은 비용이 드는 기존 관계형 데이터베이스 아키텍처에서는 잘 보이지 않는 경우가 많아요. 특히 JOIN 연산은 더욱 그렇죠. 악의적인 행위자들은 의심스러운 활동을 여러 계정과 채널에 분산시켜서 이러한 구조적 제약, 특히나 `Schema`의 경직성이나 JOIN 관련 성능 제약을 악용하곤 해요.

이러한 아키텍처 제약으로 인해 다음과 같은 시스템이 만들어지게 돼요.

• 사전 정의된 규칙에 의존하며, 진화하는 사기 전술에 제대로 적응하지 못해요.
• 충분한 맥락 정보 없이 연결 고리만 분석하기 때문에 잘못된 경고를 많이 발생시켜요.
• 다양한 플랫폼이나 서비스 전반에서 조직적으로 이루어지는 사기 활동을 제대로 탐지하지 못해요.

관계형 데이터베이스를 사용하는 기존 사기 탐지 시스템이 가진 핵심적인 기술적 문제들을 해결하는 데 도움을 줄 수 있는 Neo4j Aura Graph Analytics를 소개합니다! 아래 표에서 Neo4j Aura Graph Analytics가 사기 탐지에 어떤 영향을 미칠 수 있는지 한번 살펴볼까요?

사용 사례: 자금세탁 집단 식별

그래프 알고리즘은 계정 간의 거래 흐름을 추적해서 잠재적인 자금 세탁 활동을 찾아내요. 예를 들어, 여러 지역에 걸쳐 관련 없는 계정 간에 이체가 빠르게 연속적으로 발생하면 의심스러운 행동을 나타낼 수 있죠. Neo4j AuraDB 같은 Graph Database는 계정을 Node로, 트랜잭션을 Relationship으로 모델링해서 주기, 클러스터 및 "허브" 계정을 감지한답니다.

이 시각화는 전형적인 자금세탁 계획을 보여주네요.

• 여러 관할권에 걸친 국제 거래(미국, 중국, 러시아, 브라질, 인도, 케이맨 제도)
• 조세 피난처의 중앙 허브 계정(케이맨 제도)
• 결국 근원으로 돌아가는 순환적인 돈의 흐름
• 각 전송 시 약간의 양 감소(스트리핑)
• 신속한 연속 전송(모두 몇 시간 내에 발생)

Neo4j Aura 그래프 분석은 중복 제거 및 엔터티 해결을 합리화해서 유사한 엔터티와 그 Relationship을 식별해요. 데이터 엔터티(고객, 계정, 장치 등)를 속성(이름, 주소, 이메일 등)을 소유한 Node로 모델링한 다음 이러한 엔터티 간의 Relationship을 생성해서 상호 작용이나 연결을 나타낼 수 있죠. 이 접근 방식을 사용하면 데이터 생태계 전반에서 엔터티가 어떻게 연결되어 있는지 확인하고 기존 데이터베이스에서 종종 놓치는 패턴을 찾아낼 수 있어요. 예를 들어, 이름은 약간 다르지만 동일한 판매자 계정과 동일한 거래 패턴을 가진 두 개의 고객 레코드가 있는 경우 이를 잠재적인 중복으로 표시할 수 있답니다.

대규모 데이터 세트에서 JOIN 집약적인 작업으로 어려움을 겪는 기존 관계형 데이터베이스와 달리 Neo4j의 솔루션은 대규모 데이터 세트 내의 Relationship을 효율적으로 분석해서 성능 문제 없이 수백만 개의 엔터티로 확장돼요.

Neo4j Aura Graph Analytics는 확률적 커뮤니티 감지와 유사성 알고리즘을 결합해서 정교한 사기 감지도 가능하게 해요. 플랫폼의 약하게 연결된 구성요소 알고리즘은 의심스러운 속성을 공유하는 그룹 계정은 관련 없어 보이는 개체 간의 숨겨진 연결을 드러내죠.

다음과 같은 유사성 알고리즘 Jaccard, 코사인 및 오버랩은 여러 차원에서 서로 다른 엔터티가 얼마나 밀접하게 일치하는지 측정해서 합성 ID를 감지하는 데 도움이 돼요. 예를 들어 Jaccard 유사성은 합법적인 신원 구성 요소의 비정상적인 조합을 식별해서 도난당한 데이터 조각으로 구성된 잠재적인 합성 신원을 표시할 수 있죠. 이 접근 방식은 복잡한 JOIN 작업의 성능 저하 없이 실시간 사기 위험 점수를 생성하므로 금융 기관이 즉시 조치를 취할 수 있답니다.

Neo4j 그래프 기술을 사용해서 자금 세탁을 방지하는 방법에 대해 자세히 알아보려면 다음을 읽어보세요. 이 심층 가이드. Neo4j를 사용한 사기 탐지에 대해 더 자세히 살펴보고 싶다면 다음을 확인하세요. 이 블로그 시리즈.

추천 엔진: 관계를 통해 고객 참여 강화

전자상거래 및 스트리밍 서비스는 기존 추천 시스템으로 인해 어려움을 겪고 있어요. 대부분은 협업 필터링을 사용해서 사용자 유사성이나 과거 상호 작용을 기반으로 항목을 추천하죠. 이 접근 방식은 빈도나 기록 기반 패턴을 넘어 다양한 제품이나 사용자 행동이 어떻게 연결되어 있는지와 같은 복잡한 Relationship을 식별하지 못하는 경우가 많아요.

기존 시스템은 또한 "콜드 스타트" 문제로 어려움을 겪고, 정적인 과거 데이터에 의존해서 진정으로 개인화된 경험을 제한한답니다.

사용 사례: 개인화된 콘텐츠 추천

Netflix나 Spotify 같은 스트리밍 서비스들은 그래프 기반 추천 엔진이 얼마나 뛰어난 개인화 경험을 제공할 수 있는지 보여주는 좋은 예시죠. Netflix는 시청 기록뿐만 아니라 시청 시간, 시간대, 사용 기기 등 시청 방식까지 분석해서 서로 연결된 데이터 포인트를 활용해 복잡한 네트워크를 만들어요.

Spotify도 마찬가지로 음악 객체(노래, 아티스트, 앨범)와 이들의 관계(장르, 분위기, 아티스트)를 나타내는 Knowledge Graph를 사용해서 Discover Weekly 플레이리스트를 제공하고 있어요. 그래프 구조 안에서 콘텐츠 속성과 사용자 행동을 모두 분석함으로써, 기존의 테이블 형태 데이터베이스에서는 놓칠 수 있는 미묘한 음악적 선호도까지 연결할 수 있는 거죠.

스트리밍 플랫폼이 그래프 기반 방식으로 추천 시스템을 설계하는 방법을 한번 살펴볼까요?

이 다이어그램은 서로 연결된 사용자, 프로그램, 완료율, 그리고 기기를 보여주는 스트리밍 플랫폼 네트워크를 나타내요. 그래프 기반 접근 방식은 이러한 엔터티 간의 깊은 관계를 밝혀내서 플랫폼이 상황을 잘 파악한 추천 시스템을 구축할 수 있도록 도와주죠.

Neo4j Aura Graph Analytics는 65개 이상의 내장 그래프 알고리즘, 예를 들어 개인화된 PageRank나 K-최근접 이웃 같은 알고리즘을 통해 다양한 차원에서 관계를 분석해서 추천 정확도를 높여요. 이러한 알고리즘은 그래프 구조를 사용해서 근접성, 영향력, 유사성을 기준으로 항목 점수를 매기고, 1초 안에 개인화된 제안을 제공해서 참여 지표를 개선하는 데 도움을 줘요. Neo4j는 유연한 스키마와 확장 가능한 아키텍처를 통해 개발 주기를 단축시켜 주기도 하고요.

Neo4j는 사용자, 항목, 상호 작용을 Nodes와 Relationships로 모델링해서 복잡한 Queries를 단순화하고 실시간으로 적응하는 추천을 제공해요. 최신 추천 엔진을 위한 이상적인 솔루션이라고 할 수 있죠.

공급망 최적화: 복잡한 네트워크 관계 마스터하기

제조, 소매, 물류, 제약, 식품 회사들은 공급망 문제 때문에 어려움을 겪고 있어요. 공급망 단계 사이의 격차 때문에 가시성이 계속 문제가 되고, 기존 데이터베이스 시스템은 속도가 느리죠. 문제가 발생하면 기업들은 영향을 받는 제품을 빨리 찾아내거나 백업 공급 업체를 찾기가 어려울 때가 많아요. 기존 시스템은 현대 공급망의 고도로 연결된 특성을 처리하도록 만들어지지 않았거든요. 공급업체와 물류 데이터를 저장하기 위해 엄격한 스키마를 사용하기 때문에 상호 의존성을 분석하기가 어렵기 때문이에요.

그래프 분석 모델은 공급망을 서로 연결된 엔터티의 실제 네트워크로 표현해요. Neo4j Aura 데이터베이스를 사용하면 공급망 관리자는 네트워크 깊이에 상관없이 일관된 성능으로 여러 단계의 공급업체, 유통 센터, 운송 경로를 탐색할 수 있어요. 이를 통해 문제가 발생했을 때 실시간으로 영향 분석을 할 수 있을 뿐만 아니라, 기존 관계형 데이터베이스 시스템이 따라올 수 없는 사전 예방적 위험 관리도 가능해져요.

사용 사례: 위험 완화 및 경로 최적화

공장, 유통 센터, 항구, 운송 경로를 서로 연결된 그래프로 모델링함으로써 제조업체는 최적의 배송 경로를 식별하는 동시에 잠재적인 병목 현상을 빠르게 감지하고 예방할 수 있어요.

글로벌 제조업체가 Neo4j를 사용해서 어떻게 공급망을 최적화하는지 한번 살펴볼까요? 아래 시나리오는 다단계 공급망 전체에서 가시성 문제에 직면한 회사가 그래프 분석을 사용해서 전체 공급 네트워크를 그래프로 모델링하고 다음과 같은 통찰력을 얻는 방법을 보여줘요.

• 2차 및 3차 공급업체에 대한 의존도
• 구성 요소 전달을 위한 중요 경로
• 특정 지역의 위험 집중
• 문제 발생 시 대체 소싱 기회

Neo4j의 그래프 모델을 사용하면 신속하게 영향 평가를 하고 대체 공급업체를 활성화할 수 있어요. 최단 경로 알고리즘으로 밀리초 단위로 라우팅을 최적화하는 거죠. 그동안 매개 중심성은 단일 포트가 배송의 80%를 처리하는 것처럼 중요한 오류 지점을 정확히 찾아낸답니다.

Neo4j Aura는 재고 및 운송 시간부터 외부 위험까지 공급망 데이터를 효율적으로 분석해줘요.

사이버 보안 및 위협 탐지: 디지털 위협 환경 매핑

금융 서비스, 정부 기관 및 중요 인프라 부문이 직면한 문제는 정교한 위협인데요, 이들은 네트워크를 통해 측면으로 이동하면서 의도적으로 합법적인 동작을 모방해요. 이러한 위협은 알려진 공격 패턴에 의존하는 기존 탐지 임계값을 회피하죠.

그래프 분석은 보안 데이터를 격리된 경고나 로그가 아닌 상호 연결된 엔터티 및 이벤트로 모델링해요. 사용자, 장치, IP 주소 및 네트워크 활동을 Node와 Relationship으로 표시함으로써 Neo4j는 네트워크 전반에 걸쳐 시간이 지남에 따라 전개되는 공격 패턴을 추적할 수 있어요. 이러한 관계 중심 접근 방식을 통해 보안 팀은 기존 방식에서 볼 수 없었던 측면 이동, 권한 상승, 데이터 유출 시도를 탐지할 수 있는데, 이는 보안정보 및 이벤트 관리(SIEM) 시스템이 놓치는 부분이죠.

Neo4j Aura Graph Analytics 알고리즘은 겉으로는 관련이 없어 보이는 이벤트 사이의 미묘한 연결을 식별하여 매일 발생하는 수십억 건의 보안 이벤트 속에 숨겨져 있을 공동 공격을 밝혀낼 수 있답니다.

사용 사례: 피싱 캠페인에 대응

금융 기관은 공격자가 합법적인 기관을 사칭하여 중요한 시스템에 무단으로 액세스하는 정교한 피싱 캠페인에 직면해 있어요. 이러한 공격에는 일반적으로 스푸핑된 이메일, 가짜 웹사이트, 사회 공학적 전술 등 여러 접점이 포함되어 있어서 기존 보안 도구로는 탐지하기 어렵죠. 이러한 캠페인이 성공하면 자격 증명 도용, 계정 탈취, 그리고 궁극적으로 수천 명의 고객에게 영향을 미치는 데이터 침해로 이어질 수 있어요.

보안 팀의 과제는 여러 시스템과 기간에 걸쳐 서로 다른 지표를 연결하여 조정된 캠페인이 성공하기 전에 식별하는 거예요. 기존 SIEM 시스템은 새로운 공격 기술에 적응할 수 없는 사전 정의된 상관 관계 규칙에 의존하기 때문에 이러한 복잡한 공격 패턴을 식별하는 데 어려움을 겪죠.

보안 팀은 서로 다른 보안 데이터를 포괄적인 그래프 모델로 통합하여 이러한 문제를 극복할 수 있어요. 물리적 개체에 초점을 맞춘 공급망 모델링과 달리 사이버 보안 그래프는 계정, 장치, 애플리케이션 및 네트워크 리소스를 액세스 관계 및 상호 작용 이벤트와 통합합니다. 더욱이, Neo4j LLM 지식 그래프 빌더는 구조화되지 않은 보안 로그 및 위협 인텔리전스 보고서에서 엔터티와 관계를 추출할 수 있답니다.

보안 데이터에 대한 전체적인 뷰를 통해 금융 회사는 IP 주소, 장치 지문, 로그인 시도를 매핑해서 숨겨진 연결을 찾을 수 있어요.

예를 들어 공격자가 탐지를 피하려고 IP 주소를 바꿔도, 그래프 분석을 통해 단일 장치에서 접근하는 의심스러운 계정 클러스터가 드러날 수 있죠. 보안 팀은 그래프를 탐색하면서 네트워크를 통해 공격자의 측면 이동을 추적하고, 캠페인에서 잠재적으로 손상될 수 있는 모든 계정, 시스템, 데이터 세트를 식별할 수 있어요.

Neo4j의 중심성 알고리즘은 공격자가 표적으로 삼을 만한 중요한 리소스를 찾아낼 수 있어요. 예를 들어 PageRank는 과도한 권한을 가진 고도로 연결된 서버를 식별할 수 있고, Label Propagation은 유사한 행동 패턴을 보이는 손상된 사용자 계정 그룹을 탐지하는 데 도움이 되죠. 이런 알고리즘은 데이터베이스 크기에 상관없이 효율적으로 작동하기 때문에, 관계형 데이터베이스 쿼리를 손상시킬 수 있는 성능 저하 없이 페타바이트 규모의 보안 데이터에서 실시간 위협 검색이 가능해요.

콘텐츠 네트워크 및 미디어 인텔리전스: 정보 생태계 탐색

미디어 조직, 뉴스 매체, 콘텐츠 게시자는 콘텐츠, 주제, 객체, 청중 상호 작용 간의 복잡한 관계를 관리하는 데 어려움을 겪고 있어요. 기존 시스템은 키워드 매칭에 의존하기 때문에 콘텐츠 검색 및 인사이트 생성에 한계가 있죠.

그래프 분석은 정보 생태계의 자연스럽게 연결된 구조를 모델링해서 콘텐츠 관리를 혁신해요. Neo4j를 사용하면 조직이 Knowledge Graph를 만들 수 있어요. 기사, 주제, 사람, 장소, 이벤트는 복잡한 JOIN이 필요한 조각난 테이블이 아니라, 서로 연결된 네트워크로 존재하는 거죠. 이 접근 방식은 수백만 개의 문서에서도 일관된 쿼리 성능을 유지하면서, 기존 시스템이 감지할 수 없는 상황별 관계와 패턴을 드러내요.

사용 사례: 잘못된 정보 네트워크 식별

잘못된 정보 캠페인에는 생성된 콘텐츠를 개별적으로 분석할 때 합법적인 것처럼 보이는 조정된 계정 네트워크가 포함돼요. 격리된 콘텐츠에 초점을 맞추는 기존 조정 시스템은 이런 조직적인 노력을 제대로 감지하지 못하죠.

Neo4j는 구조화되지 않은 콘텐츠를 풍부한 Knowledge Graph로 변환해서 이런 문제를 해결해요. 여기서 엔티티와 그 관계가 눈에 보이게 되죠. 예를 들어 미디어 인텔리전스 회사는 사용자 계정, 콘텐츠, 해시태그, 참여 패턴을 상호 연결된 그래프로 모델링해서 정치적 행사 중에 수백만 개의 소셜 미디어 게시물을 분석할 수 있어요. 이렇게 표현하면 기존 분석에서는 보이지 않던 네트워크 구조가 바로 드러나죠.

사용자, 게시물, 관련 해시태그, 다양한 주제를 매핑해서 의심스러운 패턴을 찾아내는 샘플 그래프를 한번 살펴볼까요?

각 게시물은 개별적으로 보면 괜찮아 보일 수 있지만, 그래프에서는 조정된 콘텐츠 증폭, 공유 장치, 유사한 해시태그의 반복 사용을 나타내는 멀티홉 관계를 식별할 수 있어요.

Neo4j의 그래프 알고리즘은 사용자 참여를 분석하는 데 도움을 주는데요. 예를 들어, 학위 중심성 알고리즘(Degree Centrality Algorithm)을 통해 참여를 유도하는 영향력 있는 계정을 식별하고, 루뱅 알고리즘(Louvain Algorithm)으로 상호 작용 패턴을 기반으로 사용자를 의미 있는 커뮤니티로 분류할 수 있죠. 가장 중요한 점은 연결되지 않은 이데올로기 그룹을 연결하는 연결 중심성이 높은 계정이 잠재적인 잘못된 정보 슈퍼전파자로 식별될 수 있다는 거예요. 이러한 전략적 Node에 조정 노력을 집중함으로써 플랫폼은 광범위한 콘텐츠 검열 없이 허위 정보의 확산을 줄일 수 있답니다.

이러한 타겟 접근 방식은 잘못된 정보를 억제할 뿐만 아니라 사용자가 커뮤니티 내에서 그리고 네트워크 전반에서 상호 작용하는 방식을 밝혀 더 깊은 참여 통찰력을 제공해요.

의료 및 생의학 연구: 생명을 구하는 연관성 찾기

의료 서비스 제공자, 제약 회사, 연구 기관은 전자 건강 기록, 게놈 서열, 단백질 상호 작용, 임상 시험을 포괄하는 방대한 생물 의학 데이터 세트를 관리하고 있어요. 기존의 관계형 데이터베이스는 질병, 약물, 환자 간의 관계를 추적하기 어렵게 만드는 방식으로 데이터를 조각화하죠.

관계형 데이터베이스에서 생물학적 관계를 Query하는 작업은 경로 길이에 따라 기하급수적으로 느려지고, 다단계 분석에 많은 비용이 들어요. 다양한 생물 의학 데이터 형식과 온톨로지의 통합을 복잡하게 만드는 엄격한 Schema 요구 사항과 결합된 이러한 단편화는 약물 발견 노력과 포괄적인 환자 치료를 심각하게 방해한답니다.

그래프 분석은 생물학적 시스템을 단절된 데이터 사일로가 아닌 상호 연결된 네트워크로 표현함으로써 생의학 연구를 변화시키는데요. Neo4j의 Schema에 구애받지 않는 구조는 게놈 데이터, 단백질체학, 임상 기록, 연구 문헌을 통일된 Knowledge Graph로 원활하게 통합하여 의료 혁신을 주도하는 상황별 관계를 보존해요. 사전 정의된 JOIN 테이블이 필요한 관계형 데이터베이스와 달리 Neo4j는 관계 깊이에 대한 성능 저하 없이 3단계 약물-단백질-질병 상호 작용을 분석하든 10단계 대사 단계를 분석하든 상관없이 복잡한 경로를 지속적으로 탐색할 수 있어요. 이 기능은 전자 건강 기록(Electronic Health Record)과 CRISPR처럼 서로 다른 데이터 소스를 연결할 때 정말 중요하죠. 기존 시스템이 호환되지 않는 Schema와 지연된 Query 응답으로 어려움을 겪고 있는 심사 결과에요.

사용 사례: 약물 용도 변경

약물 용도 변경, 즉 기존 승인 약물에 대한 새로운 치료 응용 분야를 찾는 것은 일반적으로 10~15년과 수십억 달러가 소요되는 기존 약물 개발보다 더 빠르고 비용 효율적인 치료 경로를 제공해요. 하지만 유망한 용도 변경 후보를 식별하는 것은 쉽지 않아요. 단백질-단백질 상호 작용, 유전자 발현 패턴, 경로 분석, 임상 결과를 포함하여 서로 다른 데이터 세트에 걸쳐 복잡한 생물학적 상호 작용을 분석해야 하거든요. 기존의 데이터베이스 접근 방식은 이러한 다차원 관계 Query로 인해 어려움을 겪기 때문에 잠재적인 연결을 체계적으로 발견하는 것이 거의 불가능하답니다.

잠재적인 약물 용도 변경 기회를 식별하기 위해 약물, 질병, 유전자, 단백질 간의 관계를 명시적으로 모델링하는 샘플 그래프를 한번 살펴볼까요?

Neo4j는 질병, 약물, 유전자, 단백질, 경로 등 수많은 생물 의학 개체를 포괄적인 Knowledge Graph로 연결해줘요. 공개 데이터와 독점 데이터를 통합해서 기업은 생물학적 메커니즘, 약물 표적, 질병 경로에 대한 통합된 뷰를 만들 수 있죠.

게다가 Neo4j의 Text2Cypher 기능 덕분에, 해당 분야 전문가가 Natural Language Processing 쿼리를 사용해서 정교한 네트워크 분석을 수행할 수 있어요. 전문적인 프로그래밍 기술이 없어도 괜찮아요! 예를 들어 임상의가 "질병 Y에서 상향 조절되는 유전자 X와 동일한 경로를 표적으로 하는 승인된 약물은 무엇입니까?"라고 간단하게 질문할 수 있고, 잠재적인 용도 변경 기회를 시각적으로 매핑된 결과로 얻을 수 있는 거죠.

TensorFlow 같은 Machine Learning 프레임워크와 통합되면, Neo4j는 Graph Neural Network 기술을 통해 새로운 약물 상호작용과 부작용을 예측해서 약물 재활용을 향상시킬 수 있어요. 이런 모델은 Graph 표현 고유의 풍부한 관계 컨텍스트를 사용해서 기존 표 형식 데이터로는 불가능했던 예측 정확도를 달성하는 거죠.

IT 인프라 및 네트워크 관리: 디지털 생태계 매핑

복잡한 IT 인프라를 가진 대기업은 물리적 환경과 가상 환경 전체에서 컴포넌트 간의 관계를 모델링하고 분석하는 데 어려움을 겪고 있어요. 기존 도구는 현대 기술 생태계의 역동적이고 상호 연결된 특성을 제대로 포착하지 못하는 정적인 표현을 사용하기 때문에, 종속성을 이해하고 영향을 추적하며 중요한 경로를 식별하는 게 거의 불가능하죠.

Neo4j Aura Graph Analytics는 기술 환경을 자연스럽게 상호 연결된 시스템으로 모델링해서 IT 인프라 관리를 위한 이상적인 기반을 제공해요. Neo4j는 서버, 애플리케이션, 네트워크 장치, 서비스를 Nodes로 표현하고, 해당 종속성과 통신 경로를 Relationships로 표현해서 전체 생태계의 살아있는 지도를 만드는 거예요.

Neo4j는 다른 방법으로는 즉시 종속성을 매핑해요. 예를 들어 Configuration Management Database는 "이 서버에 장애가 발생하면 어떤 애플리케이션이 영향을 받나요?"와 같은 간단한 Query에 복잡한 JOIN이 필요한 관계형 데이터베이스를 기반으로 구축되었죠. 이는 컨테이너 오케스트레이션이 기존 인벤토리 시스템이 효과적으로 추적할 수 없는 지속적으로 변화하는 인프라를 생성하는 클라우드 네이티브 환경에서 특히 중요해요.

With Neo4j의 실시간 관계 모델링, IT 팀은 폭발 반경 계산을 즉시 시각화하고, 근본 원인 분석을 수행하고, 기존 모니터링 도구에 숨겨져 있던 단일 장애 지점을 식별할 수 있어요.

사용 사례: 클라우드 비용 최적화

환경이 점점 더 복잡해짐에 따라 클라우드 인프라를 최적화하는 건 점점 더 어려워지고 있어요. 일반적으로 조직은 사용되지 않는 Resources를 식별하고, 서비스 간의 종속성을 이해하고, 중요한 비즈니스 운영을 방해하지 않고 컴포넌트를 안전하게 폐기하는 데 어려움을 겪죠. 기존의 클라우드 관리 도구는 기본적인 사용량 지표를 제공하지만, Resources 간의 복잡한 관계 웹을 드러내는 데는 실패했어요. 이로 인해 고아 인스턴스, 과잉 프로비저닝된 서비스, 중복 컴포넌트에 대한 불필요한 지출이 발생해요. 이러한 종속성을 완전히 파악하지 못한 채 비용 절감 계획을 시도하면 기업은 예상치 못한 서비스 중단을 초래할 위험이 있어요.

예를 들어 아래 그래프는 데이터베이스 및 컴퓨팅 인스턴스와 같은 배포된 클라우드 애플리케이션에 대한 종속성을 보여줍니다.

클라우드 인프라에는 사용량 지표를 자세히 보지 않으면 찾기 힘든 고아 인스턴스가 있을 수 있어요.

SaaS 제공업체는 Neo4j를 사용해서 전체 클라우드 인프라를 연결된 그래프로 모델링해서 이런 문제를 해결할 수 있죠. 애플리케이션, 서비스, 데이터베이스, 컴퓨팅 리소스 간의 종속성을 매핑해서 직/간접적인 관계를 모두 보여주는 환경의 포괄적인 디지털 트윈을 만드는 거예요. Neo4j의 중심성 알고리즘을 사용하면 중요한 경로와 병목 현상을 식별하는 동시에, 여전히 비용이 발생하는 고아 리소스와 축소할 수 있는 활용도가 낮은 EC2 인스턴스를 찾을 수 있어요. 가장 중요한 점은, 그래프 시각화가 독립적으로 보이는 서비스 간의 숨겨진 종속성을 보여줘서 팀이 연속적인 오류 없이 중복 구성 요소를 안전하게 해제할 수 있다는 거죠.

Neo4j AuraDB의 실시간 `Query` 기능은 IT 팀이 인프라를 모니터링하고 문제를 해결하는 방식을 바꿔줘요. 제한된 컨텍스트로 미리 정의된 대시보드만 제공하는 기존 모니터링 도구와는 달리, Neo4j는 모든 시작점에서 전체 종속성 체인을 동적으로 탐색할 수 있어요. 사고가 발생하면 팀은 영향을 받는 모든 서비스, 데이터베이스, 애플리케이션 전반에 걸쳐 영향 경로를 즉시 추적할 수 있죠. 예를 들어, 깊이 우선 검색 경로 찾기 알고리즘을 사용하면 여러 서비스 계층에서 API 오류의 근본 원인을 빠르게 추적해서 평균 해결 시간을 크게 줄일 수 있어요. 이러한 실시간 관계 인식은 사전 비용 최적화와 사후 사고 관리 모두에 필요한 상황별 이해를 제공해요. 이건 플랫 파일 CMDB와 기존 모니터링 도구가 제공할 수 없는 기능이죠.

결론

그래프 분석은 기존 시스템이 효과적으로 해결할 수 없는 문제를 해결함으로써 연결된 데이터를 이해하는 새로운 방법을 조직에 제공해요. 그래프 기술은 데이터 포인트 간의 관계를 자연스럽게 모델링함으로써 사기 탐지에서 숨겨진 패턴과 관계를 찾아내고, 미묘한 추천을 제공하고, 복잡한 공급망을 최적화하고, 사이버 보안 방어를 강화하고, 콘텐츠 검색을 개선하고, 생물 의학 연구를 가속화하고, IT 인프라 관리를 단순화하죠.

Neo4j Aura 그래프 분석은 조직이 전문적인 인프라 전문 지식 없이도 그래프 솔루션을 빠르게 구축하고 확장할 수 있는 확장 가능하고 직관적인 플랫폼을 제공해요. 내장된 알고리즘, 직관적인 시각화 기능, 구조화된 데이터와 구조화되지 않은 데이터를 원활하게 결합하는 기능을 통해 팀은 데이터에서 실행 가능한 통찰력을 빠르게 얻을 수 있죠.

궁극적으로 Neo4j Aura Graph Analytics는 조직이 격리된 데이터 포인트를 넘어 비즈니스를 추진하는 관계에 대한 더 깊은 이해를 향해 나아가고 복잡한 과제를 성장과 혁신을 위한 명확한 기회로 전환하도록 도와요.