Knowledge Graph
문서·테이블·DB를 클래스·개체·관계로 구조화해 검색과 에이전트의 근거로 쓰는 지식그래프
Posts 13
업로드마다 LLM을 부르는 빌드는 자동으로 켜 둘 수 없었습니다
온톨로지가 문서를 올릴 때마다 만들어지려면 기본 빌드에는 호출 비용이 없어야 했습니다. 표 구조와 형태소, 한국어 패턴만으로 클래스·개체·상하위를 세우고 관계 추출은 옵션 단계로 분리한 과정과, 그 뒤 드러난 문서 500개 상한 결함을 정리합니다.
같은 질문에 근거가 매번 달랐던 이유는 정렬 없는 LIMIT이었습니다
같은 50문항을 두 번 검색하면 근거가 43문항에서만 같았습니다. 그래프 조회의 정렬 없는 LIMIT을 고치면서, 순위 알고리즘은 라이브러리가 맡고 저장소 조회는 제품 어댑터가 맡도록 경계를 다시 그은 과정입니다.
에이전트마다 빌드하면 같은 문서를 에이전트 수만큼 다시 읽어야 했습니다
은행 관리 설정에서 늘어나는 에이전트를 온톨로지로 보여 주려 했습니다. 문서 지식은 자산마다 한 번만 빌드하고, 에이전트의 소유·자산·배포·실행 관계는 설정 테이블에서 LLM 없이 구성해 규칙 인사이트까지 낸 과정입니다.
그래프 서버가 없는 곳에서 빌드는 트리플 0개로 완료되고 있었습니다
폐쇄망 고객에게 별도 그래프 서버는 반입 심사와 승인, 운영 인력이 따로 드는 구성 요소였습니다. 지식그래프의 정본을 이미 있는 PostgreSQL 테이블 세 개로 옮기고, 같은 빌드 결과를 두 저장소에 이중 기록해 대조한 과정입니다.
이름으로 만든 URI가 동명이인을 한 사람으로 합쳤습니다
조회 결과를 CSV로 내보내 다시 빌드하던 경로를 걷어내고 데이터베이스의 타입과 키를 그대로 썼습니다. 표시 이름을 식별자로 쓰면 동명이인이 합쳐지고 개명하면 다른 행이 됩니다. 정체성과 스냅샷 교체를 다시 설계한 과정입니다.
작업은 성공이라고 나왔는데 그래프가 비어 있었습니다
추출 모델을 로컬 소형 모델로 바꾸자 배치가 끝나지 않거나, 성공으로 기록된 작업이 빈 그래프를 남겼습니다. 잘린 JSON과 시간 초과가 빈 결과처럼 처리되고 있었습니다. 실패를 실패로 만든 과정입니다.
문서용 중복 정리가 정형 테이블을 합치고 있었습니다
CSV 테이블 열 개를 빌드했는데 후처리가 끝난 그래프에는 클래스가 네 개였습니다. 문서 개념을 정리하는 규칙이 스키마 식별자까지 합친 것입니다. 생성 출처를 저장해 보호 범위를 만든 과정입니다.
붉게 칠한 노드의 대부분은 근거가 아니었습니다
검색 품질을 높이고 그래프 뷰어에서 답을 검증하니 강조된 노드가 실제 근거보다 훨씬 많았습니다. 강조 범위를 줄이면서, 저희가 만든 것이 근거 추적이 아니라 문자열 대조였다는 것도 함께 확인했습니다.
느리고 부정확하다는 결과가 빈 그래프를 잰 것이었습니다
멀티턴 검색이 더 느리고 정확도도 낮다는 A/B 결과가 나왔습니다. 실행 기록을 보니 평가가 데이터 없는 그래프를 조회하고 벡터 검색만으로 답하고 있었습니다. 다시 측정한 뒤 검색 구조를 바꾼 과정입니다.
그래프를 정리하다가 정상 클래스 1,500개를 지웠습니다
인스턴스와 관계가 부족한 클래스를 자동 삭제했더니 정상 클래스 약 1,500개가 함께 사라졌습니다. 추출이 아직 만들지 못한 관계를 후처리가 불필요로 판정한 것입니다. 탐지와 삭제를 나눈 과정입니다.
트리플 수로는 지식그래프 품질을 알 수 없었습니다
같은 파이프라인이 한쪽에서는 25만 트리플을, 다른 쪽에서는 1천 트리플을 만들었습니다. 둘 다 문제가 있었고 방향은 정반대였습니다. 적재량·구조·출처·검색·답변을 나눠 재기 시작한 과정입니다.
컨텍스트를 줄이려고 자른 것이 답의 근거였습니다
관계를 여러 단계 따라가려고 멀티턴 검색을 넣었습니다. 컨텍스트가 커져 도구 결과를 500자로 잘랐더니 표와 긴 원문의 뒷부분이 합성 단계에 도달하지 못했습니다. 탐색을 넓히며 무엇을 잃었는지 정리합니다.
질문이 답의 범위까지 정하고 있었습니다
역량 질문을 먼저 정하고 답에 필요한 개념을 찾는 방식이었습니다. 배송과 반품을 묻는 질문만 있으면 원문의 예외 승인 절차는 그래프에 남지 않았습니다. 질문을 빌드에서 빼고 평가에 남긴 과정입니다.
Engineering 20
DB 도구가 느린 이유는 DB가 아니었다: LLM 왕복 99.8%와 이름 충돌, 방언 등록 구조로 통합
에이전트에 DB 도구를 여러 개 연결하면 일부가 조용히 사라지던 문제를 도구 이름 충돌로 진단해 고치고, 느리다는 제보는 실행 기록 27건에서 시간의 99.8%가 LLM 왕복이라는 사실로 좁혔습니다. 결과 행 상한, 테이블·컬럼 사전 적재, DB 방언 등록 구조로 바꿔 질문당 LLM 호출을 4회에서 2회로 줄였습니다.
DB 원본과 지식 그래프를 맞추는 법: 증분 키를 버리고 행 지문으로 추가·변경·삭제를 감지하기
외부 DB 테이블을 LLM 없이 그래프로 만드는 기능에서, 사용자가 고르는 증분 키는 값만 바뀐 행·시각이 되돌아간 행·지워진 행을 놓쳤습니다. PK keyset 전수 읽기와 sha256 행 지문 비교로 원본이 진실인 동기화를 만들고, 실패한 회차의 지문이 그래프보다 앞서지 않도록 지문을 먼저 비우고 가리켜지는 행은 자리 노드로 남겨 실패 경로를 닫았습니다.
10만 노드 지식 그래프 뷰어: 렌더링 최적화에서 '무엇을 그릴 것인가'로 옮겨 간 문제
온톨로지 그래프를 브라우저에서 탐색하려고 Three.js InstancedMesh 렌더러와 Web Worker 물리 연산을 만들었지만, 컬렉션이 커지자 병목은 무엇을 그릴지로 옮겨 갔습니다. CDP 프로파일링으로 리프 노드가 비용의 대부분임을 확인해 구조 우선 샘플링으로 CPU 점유를 25%에서 7%로 낮추고, 렌더 상한 밖의 노드는 서버 검색으로 찾아 불러오게 했습니다.
온톨로지 빌드 2단계 분리: LLM 0회 기본 빌드와, 검색을 해치지 않을 때까지 다시 설계한 관계 형성
업로드마다 LLM 추출을 실행하면 비용을 감당할 수 없어, 개체 추출은 LLM 0회 기본 빌드로, 관계 추출은 사용자가 켤 때만 실행하는 관계 형성으로 나눴습니다. 기본 빌드가 표를 행 단위 사실로 읽게 하고, 관계 형성은 원문 단위 위의 번호 분류와 어휘 우선 구조로 다시 설계한 뒤 같은 검색 코드로 번갈아 측정했습니다.
LLM 없는 개체 추출의 이름 품질: 우연에 걸린 표 판정, 탈락한 어근, 적재 계층 이름 게이트
기본 빌드가 LLM 없이 개체를 뽑게 되자 그래프 품질은 곧 이름 품질이 됐습니다. 산문을 표로 오인하던 판정, 어근과 접미사를 버리던 형태소 결합, 경로마다 흩어진 정제 로직을 원인별로 고치고, 이름 정규화와 모양 검사를 추출기가 아닌 그래프 적재 계층 한 곳으로 내렸습니다.
그래프 크기를 따라가던 검색 비용과 흔들리던 근거: PostgreSQL 그래프 조회 계층 정비
PostgreSQL 위 GraphRAG 검색이 한 번에 54~127초 걸리거나 같은 질문에 근거가 달라지는 현상을 pg_stat_activity, 실행 계획, 로그 타임스탬프로 추적했습니다. 플래너 통계, 그래프 전체를 읽던 PPR, 검색마다 반복되던 집계, 정렬 없는 LIMIT을 차례로 고쳐 비용을 후보 크기에 묶고 근거 재현을 50/50으로 맞췄습니다.
은행 관리 콘솔 에이전트 온톨로지: 운영 테이블에서 LLM 없이 구성하고 분포로 판정하기
관리자가 300여 개 에이전트와 컬렉션·DB·도구의 관계를 탐색하고 질문할 수 있도록, 문서를 다시 추출하지 않고 운영 테이블에서 에이전트 그래프를 결정론적으로 구성했습니다. 상태 서명 기반 증분, 분포 기반 인사이트 규칙, 그래프 근거 질의, 서버 측 그래프 요약까지 설계 판단과 실측을 정리합니다.
출처는 생산 지점에서, 원본도 같은 정책으로: RAG 출처 표시 파이프라인 재정비
답변 출처가 검색 모드에 따라 사라지거나, 검색 노드 없이도 붙거나, 원본 열람이 마스킹 정책을 우회하고, 큰 CSV 출처가 브라우저를 멈추던 문제를 차례로 추적했습니다. 출처는 백엔드 생산 지점에서 결정하고, 원본도 청크와 같은 정책을 거치며, 뷰어는 보이는 만큼만 그린다는 원칙으로 정리했습니다.
값이 아니라 자리로 가린다: DB 결과의 컬럼 단위 PII 마스킹과 감사 로그 실행 신원
전화번호 정규식이 계좌번호를 가리고 이름·주소는 놓치던 문제를 값의 모양 대신 컬럼으로 판단하는 층으로 풀었습니다. 연결·쿼리 템플릿·노드 3층 규칙을 DB 결과가 LLM에 닿기 전에 적용하고, 실측으로 찾은 에이전트 DB 도구 경로의 누락, 비활성 정책의 원문 유출, 비어 있던 감사 로그 실행 신원까지 막았습니다.
증분 빌드라 불렀지만 비용은 전량이었습니다: 청크 기준선, 조회 상한 500, 이름 색인으로 끊은 비례
문서를 추가할 때마다 온톨로지 빌드가 전체를 다시 처리하거나, 새 문서가 없는데도 같은 빌드를 반복하고 있었습니다. 빌드된 청크 집합을 PostgreSQL 기준선으로 두고 SDK 기본 조회 상한 500 때문에 문서 57.8%가 그래프에서 빠지던 결함을 고친 뒤, 대상 조회·후처리·감분 단계마다 비용이 전체가 아니라 변경분에 비례하도록 바꿨습니다.
시간 상한은 탐색에만, 합성 지연은 스트리밍으로: 근거 누출 사고에서 시작한 검색 지연 재설계
질문당 총시간을 보장하려고 건 25초 하드 상한이 합성 LLM에 4초만 남겨, 내부 근거가 답변으로 새는 사고로 이어졌습니다. 로그와 단계별 계측으로 지연의 대부분이 합성 대기임을 확인하고, 상한은 탐색에만 두고 체감 지연은 합성 입력의 문자 예산과 답변 스트리밍으로 다뤘습니다.
Fuseki 없이 지식 그래프 운영하기: PostgreSQL 테이블 3개로 옮기며 드러난 숨은 결합들
별도 JVM 트리플스토어인 Fuseki는 설정 하나가 어긋나면 그래프 계층 전체가 멈추고 폐쇄망 반입 부담도 컸습니다. 같은 빌드를 두 저장소에 이중 기록해 충실도를 대조한 뒤 Fuseki 쓰기를 기본 비활성화했고, 완료 판정·재시도·카운트·품질 지표에 숨어 있던 Fuseki 전제를 하나씩 걷어내며 검색을 라이브러리로 일원화했습니다.
엑셀 요청이 항상 실패하던 문서 생성 도구: 폴백 대신 계산되는 데이터 시트로 변환하기
LLM이 마크다운으로 넘긴 엑셀 요청이 항상 실패하던 렌더러 분기를 단순 폴백이 아닌 데이터 시트 변환으로 고쳐 숫자·표시형식·틀고정을 살렸습니다. 셀 검색 도구 부재와 반복 한도 계산 오류로 편집이 중단되던 문제, 코드 생성 없이 차트를 그리는 경로도 함께 정리했습니다.
xgen-seepage: 인터넷 없이 설치되는 Excel 에이전트 커넥터와 Office.js를 걷어낸 이유
XGEN 에이전트가 사용자가 열어 둔 Excel 통합문서를 직접 읽고 편집하게 하는 독립 커넥터입니다. Office 애드인 대신 COM 직결과 단일 실행 파일 배포를 택해 폐쇄망 설치를 가능하게 했고, 실제 서버와 실제 Excel에서 검증하며 압축 협상 충돌, 실행 파일의 번들 누락, Office.js 대기 멈춤을 차례로 해결했습니다.
XGEN MAKER: 코드 지식그래프 착지 정확도를 사람이 머지한 MR 2,827건으로 잰 개발 자동화 하네스
다중 저장소 플랫폼의 코드를 결정론적 정적 분석으로 지식그래프화하고, 자연어 요청을 파일·라인 단위로 착지시켜 구현·검증·MR 준비까지 수행하는 하네스입니다. 착지 품질은 사람이 실제로 머지한 MR 2,827건으로 측정했고, 표본을 넓히는 과정에서 작은 표본에 과적합된 순위 상수를 찾아 걷어냈습니다.
컬렉션 데이터 소스: 휴면 스케줄러를 살리지 않고 provider 두 메서드로 원천을 늘린 증분 인덱싱
내부 파일 저장소 폴더를 컬렉션에 연결하면 변경분만 자동 인덱싱되는 데이터 소스를 바인딩·durable 작업 큐·해시 diff 골격으로 만들고, 휴면 상태의 저장소 동기화 기능을 되살리는 대신 API 도구를 provider로 흡수했습니다. DB 연결 창이 2분 넘게 멈추던 원인도 접속 시간 제한 누락과 이벤트 루프 차단으로 찾아 고쳤습니다.
XGEN CREATOR: 클릭이 실행한 백엔드 코드 라인을 증거로 산출물을 만드는 라이브 트레이서
브라우저 클릭을 프론트엔드 소스에 연결하고, 그 클릭이 실행한 백엔드 Python 라인을 sys.monitoring 기반 트레이서로 캡처해 UI 정의서·테스트결과서·API 명세서를 생성하는 도구입니다. 실제 XGEN 스택에서 관측이 대상을 멈추는 문제, 산출물은 나오는데 트레이스가 0건인 조용한 실패, 콜스택 깊이 오차를 차례로 고쳤습니다.
완료로 기록된 빈 그래프: 구조 복원, 부분 커밋, 출력 예산 기반 배치 사이징
빌드는 완료로 표시되는데 그래프가 비어 있거나 구조가 무너진 문제를 석 달에 걸쳐 추적했습니다. 리팩토링이 지운 중복 제거·상속 로직을 복원하고, 오진을 세 번 정정하며 예외를 삼키던 배치 처리와 all-or-nothing 저장을 찾아냈고, 배치 크기를 모델 출력 한도에서 산출해 절단 시 반분 재시도하게 바꿨습니다.
GraphRAG 검색 재설계: 순차 ReAct를 병렬 인덱스 시드와 단일 합성으로 바꾼 근거
단일 적응형 ReAct 검색이 기존 1턴 검색보다 느리고 부정확하다는 A/B 결과를 다시 읽어, 손실된 근거와 빈 그래프를 잰 하니스라는 두 원인을 찾았습니다. 탐색과 답변 합성을 분리한 병렬 인덱스 시드 구조로 바꿔 고정 100문항 정답성을 0.230에서 0.465로 올렸습니다.
빌드 진행률은 어디서 읽어야 하는가: 그래프 역산을 걷어내고 PostgreSQL 카운터를 정본으로
진행률을 RDF 그래프 역질의로 복원하던 구조 때문에 74초 걸리는 진행률 API, 좀비 잡, 빌드 중 전체 API 무응답이 겹쳤습니다. 정본을 PostgreSQL로 옮겼다가 되돌리고 다시 옮긴 경위와, 진행 상태와 빌드 결과를 분리한 네 가지 원칙, 이벤트 루프 오프로드의 실측을 정리합니다.