LLM과 그래프 기술로 연간 보고서 파헤치기: Neo4j와 GraphRAG 활용

이제 Natural Language Processing이 더 쉬워졌어요!

TL;DR — 접근 방식이 이전과는 다르고, 훨씬 쉽고 더 좋아졌다는 사실! 결과는 쉽게 확장될 수 있다는 점도 매력적이죠.

2019년에 저는 체험형 그래프 플랫폼 개발을 주도했는데요. 솔루션 구성, 아이디어/POC 유사성, 그리고 연례 보고서처럼 텍스트가 많은 문서에 대한 분석 등 그래프 모델링이 잠재력을 보여줄 수 있는 다양한 영역을 탐색했었어요. 당시 NLP 분석은 Azure Cognitive Services API를 활용했고, 저희 팀은 논문에서 주요 주제와 트렌드를 파악하는 분석 기능을 구현했죠. 또한 플랫폼 내 다른 모듈의 잠재적 솔루션과 결과를 매칭하는 기능까지 갖춘 멋진 솔루션을 개발했답니다. 당시 주요 접근 방식은 에 자세히 문서화되어 있어요.

그때는 그랬죠. 하지만 지금은 달라요!

Large Language Model(LLM)을 사용할 수 있게 되면서, 구조화되지 않은 텍스트를 분석하는 것은 물론이고, 결과를 Graph Database에 넣기 위한 코드까지 생성할 수 있게 되었잖아요. 이제 코딩을 거의 하지 않는 사람도 화이트보드에 스케치만 하면, 2019년에 저희 팀이 구현했던 NLP 솔루션을 다시 만들 수 있을까요?

우선, Kristof Neys에게 감사를 표하고 싶어요. 이 모든 것의 토대가 된 훌륭한 Colab 노트북을 공유해줬거든요. Kristof의 노트북은 환자 의료 기록에서 Graph Database를 읽고 생성하는 과정을 담고 있어요. 검토에 필요한 모든 백엔드 단계를 처리해줘서, 제가 원래 생각했던 비즈니스 과제에 집중할 수 있었죠. Kristof의 도움이 없었다면 시작조차 못했을 거예요.

바로 그거에요! 우리는 수년 동안 '데이터의 민주화'에 대해 이야기해 왔지만, 지금처럼 피부로 와닿았던 적은 없었던 것 같아요. 구현 기술의 복잡성에 시간을 쏟지 않고, 문제 자체에 집중해서 제 역량을 발휘할 수 있었으니까요.

제 좋은 친구이자 코치인 Peter Beijer 박사는 제가 소프트웨어 엔지니어에서 솔루션 아키텍트로 커리어를 전환하던 2000년대 초반에 솔루션 아키텍처의 원칙을 가르쳐줬어요. 그때 그가 해준 조언은 제 커리어를 완전히 바꿔놓았죠. 특히 솔루션을 비즈니스, 기능, 기술, 구현이라는 4개의 계층으로 나눌 수 있다는 원칙은 제가 거의 매일 적용하는 핵심적인 부분이에요. 솔루션 설계자로서의 경험과 현재 고객 성공 부서에서 일하면서 얻은 강점은, 기술 계층을 이해하고 다룰 수 있다는 점이죠. 물론, 확장성 좋고 성능 뛰어난 클라우드 아키텍처를 구현해달라고 하시면 곤란해요!

본격적으로 시작하기

기술적인 준비가 약간 필요했지만, 설정하는 과정이 고통스럽거나 하진 않았어요. OpenAI API 키를 설정하고, Neo4j AuraDB 인스턴스를 프로비저닝하는 정도였으니까요. 이걸 마치고 나니, Kristof의 노트북을 따라 하면서 샘플 Database를 만들 수 있는지 확인해볼 수 있었어요.

제 관심사는요.

저는 제 도전의 기반을 가치 있는 것에 두고 싶었어요. 판매와 성공의 핵심은 솔루션이 고객의 요구와 목표를 어떻게 충족하는지 이해하는 것이죠. 그러면 이걸 어디서 배울 수 있을까요? 이러한 정보에 대한 가장 신뢰할 수 있는 출처는 조직에서 발행하는 연례 보고서와 전략 문서인 경우가 많아요.

하지만 중요한 건, LLM(Large Language Model)은 허공에서 의미 있는 통찰력을 생성하지 않는다는 점이에요. 문제를 해결하려면 논리적인 접근 방식이 있어야 해요. 먼저, 해당 문서의 내용을 이해하고 목표를 정의해야 하죠. 연간 보고서에는 풍부한 데이터가 포함되어 있는데, 추출하려는 구체적인 정보는 무엇인가요? 재무제표, 인수 합병 세부 정보, 시장 동향, 산업 방향, 법적 측면, 위험 또는 외부 요인인가요? 이 단일 자산에서 얻을 수 있는 통찰력의 잠재력은 엄청나기 때문에 LLM이 검색해야 하는 것이 무엇인지 명확하게 정의하는 것이 중요해요.

둘째, 다음 단계는 그래프 모델을 설계하는 거예요. 문서에서 추출하려는 내용을 이해한 후에는 초기 그래프 모델 제작을 시작할 수 있죠. 제 초기 모델은 상당히 단순했어요…

arrows.app을 사용하여 생성된 연례 보고서의 잠재적인 Graph Data Model 개요

프롬프트

이게 2019년 접근 방식과 흥미롭고 다른 점이에요. 2019년에는 Natural Language Processing API가 모든 작업을 수행하도록 했어요. 우리는 여기에 텍스트 블록을 전달하고 결과로 entity와 category를 가져왔죠. LLM 접근 방식을 사용하면 제가 관심 있는 내용을 더 자세히 분석할 수 있었어요. Prompt를 사용하여 문제의 틀을 잡기 시작했죠. 이러한 Prompt는 비즈니스 상황에 맞게 조정되었으며 문서의 세부 구조를 설명할 필요가 없었어요. 대신 비즈니스 동향, 기술 동향, 주요 개인 등 모델이 중점을 두어야 할 사항을 설명했죠. 이러한 변화는 문서의 복잡성을 자세히 조사하지 않고도 귀중한 통찰력을 효율적으로 추출할 수 있음을 의미하며 프로세스를 더욱 민첩하게 만들고 특정 비즈니스 목표에 부합하게 만들었어요.

다음은 label 정의의 일부 예시예요.

label:'TechnologyTrend' name:string,name:string //any known technology term within the text,summary:string //Summary of the trend as defined by openAI;'name' property is the name of the technology trend, in lowercase & camel-case & should always start with an alphabet; summary is a description as defined within openai
label:'Risk' name:string,summary:string //any known factor which might present a risk to the organisation, summary:string //Summary of the trend as defined by openAI;'name' property is the name of the risk, in lowercase & camel-case & should always start with an alphabet; summary is a description as defined within openai

그래프 내에 생성될 각 label 또는 Node는 해당 name, 필수 property 값, 그리고 이러한 값을 식별하기 위해 LLM이 고려해야 할 사항에 대한 세부 정보로 설명돼요. 또한 OpenAI LLM 내에 정의된 일반 설명을 저장하기 위해 요약 property를 추가했어요.

Relationship도 비슷한 방식으로 설명돼요. 여기에는 텍스트 내에서 특정 항목이 언급된 횟수를 기록하는 counter 값도 포함했죠.

paper|MENTIONS_BUSINESSTREND{countof:sting}|businesstrend //the properties inside MENTIONS_BUSINESSTREND gets populated from the text and is a count of the number of times the trend is mentioned

결과

초기 결과에는 2019년 프로젝트 범위, 알려진 비즈니스 및 기술 동향에 해당하는 entity만 포함하기로 결정했어요. 생성된 데이터 측면에서는 2019년에 달성한 결과와 매우 유사했죠. 하지만 한 가지 주목할 만한 이점이 있었어요. Prompt를 간단히 수정하여 데이터 모델을 빠르게 반복할 수 있다는 것이죠.

신속한 수정을 통해 빠르게 모델을 개선하는 능력은 정말 획기적이에요. 이를 통해 출력을 Fine-tuning하는 데 더욱 동적이고 반응성이 뛰어난 접근 방식이 가능하므로 놀라운 속도로 결과를 조정하고 개선할 수 있죠. 이 반복적인 프로세스는 2019년 프로젝트의 범위를 유지했을 뿐만 아니라 데이터 추출에 새로운 유연성과 효율성을 도입했어요.

물론 제가 사전에 알고 있는 항목이나 category에만 결과를 제한하는 위험이 있어요. 이 문제는 Prompt 정의에 "catch all" label을 추가하여 해결되었죠.

 label:'EoI' id:string,name:string, summary:string //any other entity within the text which is of potential interest //Summary is the general description of the entity as defined within OpenAI

샘플 결과 세트

분류되지 않은 관심 항목만 보여주는 샘플 데이터 세트 — Neo4j Bloom의 시각화

제가 개발한 최종 데이터 모델은 초기 스케치를 훨씬 뛰어넘었어요. 그 결과 일련의 연례 보고서를 통해 철저하게 분석할 수 있는 보다 포괄적인 entity 집합이 탄생했죠. 데이터 모델의 발전으로 이러한 보고서에 포함된 정보를 더욱 깊고 세밀하게 이해할 수 있게 되었고, 이를 통해 데이터에서 도출할 수 있는 통찰력의 품질과 깊이가 향상되었어요.

"EntityOfInterest"라는 포괄적인 label을 포함한 최종 데이터 모델

제가 개발한 모델과 프롬프트를 기반으로 한 샘플 데이터 세트

이것을 프로덕션에 적용

위의 노트북과 프로토타입은 LLM을 사용하여 주요 엔터티를 추출하고 Knowledge Graph를 생성하는 것의 높은 가치를 보여주죠. 이러한 접근 방식을 프로덕션에 적용하려면 2019년에 채택한 것과 동일한 방법을 적용해야 해요.

청킹(Chunking):

Azure NLP API에는 단일 호출 내에서 처리할 텍스트 길이에 대한 제한이 있고, LLM API에도 마찬가지로 적용돼요. API에는 7,500자 제한이 있으므로 문장 중간에 텍스트가 분할되어 컨텍스트가 손실되지 않도록 텍스트가 분할되는 위치를 고려해야 하죠.

API 비용:
API를 호출할 때마다 비용이 발생해요. 2019년에는 이 문제를 해결하기 위해 각 텍스트 청크에 대한 MD5 값을 수집 및 저장하고 새 청크만 API로 보냈어요. 일치하는 텍스트 청크를 위해 기존 그래프를 검색했죠. API 호출을 강제하는 옵션을 사용하여 이 접근 방식을 여기에 적용해서 Prompt Engineering 정의에 대한 업데이트를 적용하고 LLM 자체 내 업데이트를 활용할 수도 있어요.

 

사용자가 문서를 설명하고 PDF 문서 세트를 끌어서 놓을 수 있는 잠재적인 경량 범용 애플리케이션을 구상할 수 있어요. 이러한 문서는 LLM에 의해 분류 및 분석되며 결과는 그래프 시각화로 표시되죠.하지만 이는 실제로 코딩할 수 있는 사람을 위한 거예요.

노트북 사본을 에서 사용할 수 있어요

참고 자료

Knowledge Graph 및 LLM: Neo4j로 Large Language Model 활용(오스카 헤인)

---

• nlp

---

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

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