LoanGuard AI: 규정 준수 및 조사를 위한 그래프 기반 에이전트 AI - 2부 중 1부
금융 서비스에서 자주 묻지 않는 질문이 있습니다.
그러나 그렇게 되면 모든 것이 멈춥니다.
이 대출이 승인된 이유는 무엇입니까?
체크리스트를 충족하지 못했습니다.
그러나 추론을 통해 저를 안내해주십시오.
이 차용인이 어떻게 되는지 보여주세요.대출 가치 비율(LVR), 그들에게 적용된 표준에 따라 평가되었습니다. 체인을 보여주세요.
이런 질문을 받는 팀은 준비가 되어 있지 않은 경우가 거의 없습니다. 그들은 규칙을 알고 있습니다. 과정이 이어졌습니다.
문제는 그것을 하나로 묶어줄 아무것도 만들어지지 않았다는 것이다.
- 그 이유는 분석가 노트에 나와 있습니다.
- 정책은 PDF에 포함되어 있습니다.
- 승인은 이유가 아닌 무슨 일이 일어났는지 기록하는 워크플로 도구에 있었습니다.
모든 올바른 조각이 존재했습니다.그들은 단지 연결되지 않았을 뿐입니다.
그 격차는 규정 준수 실패가 아닙니다. 구조적인 것입니다. 그리고 AI가 모든 규제 산업 전반에 걸쳐 그림의 일부가 되면서 그 격차는 더욱 커질 것입니다.
이것이 바로 LoanGuard AI가 구축된 이유입니다. 대출 준수 모니터링 및 금융 범죄 수사를 위한 지식 그래프 기반 에이전트 AI 시스템오스트레일리아 사람금융 서비스. 대출신청 확인호주건전성감독청(APRA)건전성 기준(OCC 또는 EBA와 유사한 호주의 은행 규제 기관), 차용자 네트워크 전반에 걸쳐 위험 신호를 표면화하고 모든 결정을 전체 추론 체인 및 인용 증거가 포함된 지식 그래프에 다시 작성합니다.
목표는 결코 득점이 아니었습니다. 답변이었습니다.
이것은 해당 아키텍처의 1부입니다.
설명 가능성은 아키텍처 결정입니다.
AI 개발에는 설명 가능성이 그 위에 얹어지는 것이라는 일반적인 가정이 있습니다.
모델을 구축합니다. 출력을 조정합니다. 그런 다음 사실 뒤에 설명 가능성을 추가하세요.
그 가정은 도전이다.
설명 가능성은 기능이 아닙니다. 이는 시스템이 설계된 방식의 결과입니다. 결정과 이를 지배하는 규칙 사이의 연결이 시스템에 존재하지 않으면 쿼리 시 이를 검색할 수 없습니다. 대략적으로 알 수 있습니다. 추론할 수 있습니다. 하지만 추적할 수는 없습니다.
추적성은 구조적이어야 합니다. 설계되어야 합니다.
LoanGuard AI를 형성한 질문은"어떻게 하면 출력을 더 설명하기 쉽게 만들 수 있나요?"
그것은:"설명이 이미 존재하고 검색되기를 기다리는 시스템을 어떻게 구축합니까?"
답은 그래프입니다.
규정 준수 및 조사를 위해 지식 그래프를 사용해야 하는 이유는 무엇입니까?
대부분의 데이터 시스템은 저장 및 검색을 위해 구축되었습니다. 그래프는 다음을 위해 만들어졌습니다..
일반적인 대출 환경에서 차용인은 CRM에 거주합니다. 정책은 문서 저장소에 있습니다. 승인은 워크플로 도구에 있습니다. 서로 참조하지만 연결되지는 않습니다. 이러한 경계를 넘는 질문에 답하려면 누군가 수동으로 조인을 수행해야 합니다.
지식 그래프가 이를 변화시킵니다. 모든 항목, 모든 관계, 모든 규칙은 단일 단계로 연결되고, 통과되고, 쿼리 가능한 노드로 존재합니다.
LoanGuard AI에서 그래프는 세 개의 레이어에 걸쳐 있습니다.
- 레이어 1에는 금융 기관이 포함됩니다.차용인, 대출 신청, 관할권.
- 레이어 2는 규제 지식을 보유합니다.APRA 표준은 규정, 섹션 및 삽입 가능한 덩어리로 분석됩니다.
- 레이어 3은 런타임 결과를 보유합니다.규정 준수 평가 및 이를 생성한 추론 단계(각각은 도출된 정확한 섹션 참조)
준법 감시인이 “이 대출이 규정을 준수합니까?”, 시스템은 대출 신청부터 규제, 규정 준수 평가 및 그 사이의 모든 추론 단계까지 순회합니다.
이러한 순회가 비즈니스 가치입니다. 더 빠른 조사. 모든 검토 주기 전에 조립되지 않고 시스템에 감사 준비가 내장되어 있습니다.
벡터 데이터베이스는 관련 텍스트를 찾을 수 있습니다. 그래프만이 알 수 있다why특정 규정에 따라 특정 차용인이 특정 판결을 받았습니다.
이러한 구별은 규제 대상 산업에서 매우 중요합니다.
LoanGuard AI를 디자인한 방법
시스템에는 오케스트레이터 뒤에 두 명의 에이전트가 있습니다. 쿼리가 들어오면 조정자는 인텐트를 읽고(claude-haiku-4–5 사용) 이를 라우팅합니다(규정 준수 확인, 금융 범죄 조사 또는 둘 다).
규정 준수 담당자
규정 준수 에이전트는 대출 신청을 받고, 그래프를 탐색하여 해당 APRA 표준을 찾고, 관련 규제 부분을 검색하고, 각 요구 사항에 대해 구조화된 평가를 실행합니다.
APS-112에 따른 자본 적정성 기준, APG-223에 따른 모기지 대출 통제, APS-220에 따른 신용 위험 관리 의무를 확인합니다.
모든 결과는 인용된 소스, 규정 준수 상태, 평가된 특정 기준을 포함하는 추론 단계로 레이어 3에 다시 기록됩니다.
조사 대리인
뭔가 다른 일을 합니다. 공유 계정, 연결된 엔터티, 거래 시기, 관할권 불일치 등 차용자 네트워크 전반에서 패턴을 찾습니다. 데이터가 연결될 때만 표시되는 신호의 종류입니다. 단일 대출 신청서는 별개로 보면 깨끗해 보일 수 있습니다. 관련 엔터티 네트워크 전체에서 그림이 변경됩니다.
3개 레이어 그래프
3계층 그래프 데이터 모델이 이를 가능하게 합니다.
- 레이어 1은 구조화된 금융 대출 데이터를 저장합니다.차용인, 대출, 계좌, 관할권.
- 레이어 2는 규제 지식을 저장합니다.APRA 표준은 섹션, 임계값, 요구사항이 묻힌 텍스트가 아닌 탐색 가능한 엔터티로 존재하는 구조화된 노드로 파싱됩니다.
- 레이어 3은 런타임 정보를 저장합니다.모든 평가, 모든 결과, 모든 추론 단계는 인용된 소스 및 규정 준수 결과와 함께 쿼리 시 그래프에 다시 기록됩니다.
그래프는 단지 답을 담고 있는 것이 아닙니다. 그것은 그것을 만들어낸 추론의 사슬을 담고 있습니다.
두 에이전트 모두 온도가 0으로 설정된 Claude-sonnet-4-6 모델을 추론 엔진으로 사용합니다. 규정 준수 평결을 작성할 때는 창의성보다 일관성이 더 중요합니다.
규제 컨텍스트가 크고 요청 전반에 걸쳐 대부분 정적인 규정 준수 에이전트에 프롬프트 캐싱이 적용됩니다.
그래프는 기억이다. 에이전트는 추론입니다. 오케스트레이터는 인텐트 라우터입니다. 각 레이어는 한 가지 일을 잘 수행합니다.
전체 소스코드는 다음에서 확인하실 수 있습니다..
GitHub – emillaurence/loanguard-ai: 호주 금융 서비스의 대출 준수 모니터링 및 금융 범죄 조사를 위한 Agentic GraphRAG 시스템입니다. Neo4j, Claude 및 APRA 건전성 표준을 기반으로 구축되었습니다. 다중 에이전트 파이프라인, 3계층 지식 그래프 아키텍처, 인용된 규제 증거가 포함된 전체 추론 체인이 특징입니다.
다시 내리고 싶은 세 가지 디자인 결정
1. 모든 추론 단계를 그래프에 다시 작성합니다.
판결뿐만이 아니다.. 인용된 섹션, 확인된 임계값, 관찰된 값, 도달한 결론.
이것이 시스템을 만드는 것입니다..
규정 준수 담당자는 모든 평가를 열고 체인을 따라갈 수 있습니다. 적용된 규정은 다음과 같습니다. 임계값은 다음과 같습니다. 이 차용인의 LVR이 이에 대해 측정된 방법은 다음과 같습니다. 통과 또는 실패 이유는 다음과 같습니다.
분석가의 메모에 의존하지 않고, 파일을 가져오지 않고, 원본 수표를 실행한 사람을 찾지 않고도 첫 번째 원칙에 따라 모든 결정을 재구성할 수 있습니다.
2. 추론과 검색을 분리합니다.
그래프는 관련 규정을 검색합니다. LLM은 그 이유를 설명합니다. 이는 서로 다른 두 가지 작업이며 이를 혼합하면 디버그하기 어렵고 신뢰하기 어려운 시스템이 만들어집니다.
검색과 추론이 구별되면 실패를 추적할 수 있습니다.
판결이 틀리면먼저 검색을 확인하세요.: 그래프가 올바른 규제 상황을 반환했습니까?
그렇다면 당신은: LLM이 올바르게 해석했나요? 이별은 당신에게깨끗한 결함 경계. 이는 거의 모든 곳에서 중요한 것보다 프로덕션 규정 준수 시스템에서 더 중요합니다.
3. APRA 표준을 원시 문서가 아닌 구조화된 노드로 구문 분석합니다.
규제 PDF를 포함 가능한 텍스트로 분류하면 의미 체계 검색이 가능해집니다. 이를 그래프로 분석하면 어떤 섹션이 어떤 규정에 있는지, 어떤 임계값이 어떤 조건에 적용되는지, 어떤 요구 사항이 시행 가능한지, 권고 사항인지 등의 구조를 얻을 수 있습니다.
이러한 구조를 통해 대략적인 일치가 아닌 인용 수준의 정확한 준수 여부 판단이 가능해집니다. 시스템에서 대출이 APS-112 섹션 4.2에 실패했다고 말하면 이는 이를 의미합니다. 섹션은 노드입니다. 임계값은 노드입니다. 그들 사이의 관계는 순회 가능합니다. 무엇을 평가했는지, 왜 평가했는지에 대한 모호성은 없습니다.
아키텍처에서 비즈니스 가치까지
비즈니스 가치는 요청하는 사람에 따라 다르게 나타납니다.
공통 스레드는쿼리 시 설명 가능성. 사실 이후에 재구성되지 않았습니다. 로그에서 근사치로 계산되지 않았습니다. 이미 그곳에서 회수를 기다리고 있습니다.
규정 준수 팀의 경우 조사에 며칠이 아닌 몇 분이 소요됩니다. 감사자에게 이는 누군가가 추론을 처음부터 재조립하지 않고도 질문에 답할 수 있는 시스템을 의미합니다. 경영진과 위험 위원회에게 이는 규제 기관이 이유를 물을 때 제도적 기억에 의존하지 않고 구조적으로 답변이 가능하다는 확신을 의미합니다.
일어난 일을 기록하는 시스템에서 이유를 보존하는 시스템으로의 변화가 중요합니다.
내가 배운 것
데이터 모델은 시스템입니다.
가장 어려운 부분은 AI가 아니었습니다. 데이터 모델링이었습니다.
3계층 그래프 아키텍처를 올바르게 설정하고, 무엇이 노드인지 속성인지 결정하고, 추론 단계가 규제 덩어리에 다시 연결되어야 하는 방법을 파악하고, APRA 섹션에 대한 올바른 세분성을 결정합니다.
해당 작업은 에이전트 코드 한 줄을 작성하기 전에 발생합니다., 이는 다운스트림의 모든 것을 결정합니다. 잘못 모델링된 그래프는 잘 구조화된 구성을 생성합니다. 잘 모델링된 그래프는 감사 가능한 진실을 생성하고 잘 설계된 애플리케이션에 적합합니다.
설명 가능성은 품질을 강제하는 기능입니다.
모든 판결이 이루어져야 할 때, 모호하거나 환각적인 추론이 즉시 눈에 띄게 됩니다. 신뢰도 점수 뒤에는 부정확성을 숨길 수 없습니다. 설명에 대한 요구 사항은 시스템을 정밀하게 만들고, 정밀도는 데이터 모델을 체계적으로 만듭니다.
검색과 추론을 별도로 유지하면 디버그 시 이점을 얻을 수 있습니다.
특히 초기 결과가 유망해 보일 때 LLM이 단일 통화로 모든 것을 처리하도록 하고 싶은 유혹이 있습니다. 하지만 규정 준수 시스템에 문제가 발생하면 정확히 어디에서 문제가 발생하는지 알아야 합니다.
LoanGuard AI에서 그래프는 검색을 처리합니다. 즉, 대출 신청에서 관할권까지 이동하고 해당 APRA 규정을 가져오고 관련 섹션과 임계값을 반환합니다.
LLM은 추론을 처리합니다. 즉, 해당 맥락을 해석하고, 이를 차용자에게 적용하고, 인용된 출처를 통해 평결을 내립니다.
판결이 잘못된 경우,결함 경계가 명확합니다.그래프가 잘못된 규정을 반환했거나 LLM이 올바른 규정을 잘못 읽었습니다. 시스템이 무엇을 결정했는지뿐만 아니라 어떻게 결정했는지 설명해야 하는 규제된 환경에서는 이러한 명확성이 중요합니다.
LoanGuard AI는 문서 위의 챗봇이 아닙니다. 이는 재무 데이터, 규제 지식 및 규정 준수 추론이 구조적으로 연결되어 있고 모든 답변에 추적 가능한 증거 체인이 제공되는 시스템입니다.
설명 가능성은 모델이 이미 실행된 후에 추가되는 것이 아니라 처음부터 설계되었을 때의 모습입니다.
제가 계속해서 떠올리는 질문은 오늘날 귀하의 조직이 구축하고 있는 시스템에서 추론이 실제로 어디에 존재하는가 하는 것입니다. 검색 가능한가, 아니면 누군가가 재구성해야 합니까?
2부에서는 에이전트 파이프라인, Cypher 검색기, 프롬프트 아키텍처, 실행 세부 정보 및 마지막 반복의 개선 사항 등 시스템 내부로 들어갑니다. 다음에는
2부 이전에 아키텍처를 살펴보고 싶다면 다음 저장소를 참조하세요..
- AI 에이전트
- 지식 그래프
에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.
'Agent AI' 카테고리의 다른 글
| 슐라이히, 그래프 데이터 모델로 시맨틱 PDM을 구현하다 (2) | 2026.04.15 |
|---|---|
| RAG 챗봇 대신 에이전트를 선택한 이유 (1) | 2026.04.15 |
| 리테일 혁신: Neo4j, Oneture, 그리고 AWS로 구현하는 멀티 에이전트 스토어 어드바이저 (2) | 2026.04.14 |
| LangGraph와 MCP로 ReAct Agent, 초고속 구축하기 (1) | 2026.04.14 |
| LangChain Agents로 Neo4j Cypher와 Vector Templates를 활용하여 RAG 성능 끌어올리기 (1) | 2026.04.14 |