ENGINEERING NOTES
김진수의 엔지니어링 노트
문서와 표를 지식그래프로 만들고, 에이전트가 근거를 들고 답하게 하는 일을 기록합니다. 하네스와 온톨로지를 만들며 내린 결정, 잘못 잰 실험, 고객 환경에서 다시 확인한 숫자를 남깁니다.
연재
전체 보기지식그래프 설계
- 01질문이 답의 범위까지 정하고 있었습니다
- 02컨텍스트를 줄이려고 자른 것이 답의 근거였습니다
- 03몇 시간짜리 빌드를 캐시에 올려두고 있었습니다
에이전트 하네스 설계
- 01재시도 횟수로는 실행을 설명할 수 없었습니다
- 02저장소를 나눴는데 의존성은 그대로였습니다
- 03설치는 됐는데 같은 실행이라고 부를 수 없었습니다
현장에서 다시 잰 것들
- 01규칙을 고친 뒤에도 남은 판정 흔들림은 공유 추론 서버에서 왔습니다
- 02그래프 서버가 없는 곳에서 빌드는 트리플 0개로 완료되고 있었습니다
- 0398 대 86으로 진 평가는 같은 조건의 비교가 아니었습니다
모든 글
개념 지도로 보기업로드마다 LLM을 부르는 빌드는 자동으로 켜 둘 수 없었습니다
온톨로지가 문서를 올릴 때마다 만들어지려면 기본 빌드에는 호출 비용이 없어야 했습니다. 표 구조와 형태소, 한국어 패턴만으로 클래스·개체·상하위를 세우고 관계 추출은 선택으로 돌린 과정과, 그 뒤 드러난 문서 500개 상한 결함을 정리합니다.
같은 질문에 근거가 매번 달랐던 이유는 정렬 없는 LIMIT이었습니다
같은 50문항을 두 번 검색하면 근거가 43문항에서만 같았습니다. 그래프 조회의 정렬 없는 LIMIT을 고치면서, 순위 알고리즘은 라이브러리가 맡고 저장소 조회는 제품 어댑터가 맡도록 경계를 다시 그은 과정입니다.
에이전트마다 빌드하면 같은 문서를 에이전트 수만큼 다시 읽어야 했습니다
은행 관리 설정에서 늘어나는 에이전트를 온톨로지로 보여 주려 했습니다. 문서 지식은 자산마다 한 번만 빌드하고, 에이전트의 소유·자산·배포·실행 관계는 설정 표에서 LLM 없이 조립해 규칙 인사이트까지 낸 과정입니다.
98 대 86으로 진 평가는 같은 조건의 비교가 아니었습니다
경쟁 클라우드 에이전트와 캐피탈 사내 규정 165문항으로 다시 비교하기 전에 문서 적재, 청크, 근거 개수, 평가기 시간을 하나씩 맞췄습니다. 같은 답변 모델과 같은 채점 모델로 한 번 돌린 결과는 80.0% 대 66.7%였습니다.
그래프 서버가 없는 곳에서 빌드는 트리플 0개로 완료되고 있었습니다
폐쇄망 고객에게 별도 그래프 서버는 반입 심사와 승인, 운영 인력이 따로 드는 구성 요소였습니다. 지식그래프의 정본을 이미 있는 PostgreSQL 표 세 개로 옮기고, 같은 빌드를 두 저장소에 동시에 써서 결과를 대조한 과정입니다.
재시도를 다 썼는데 같은 답을 계속 채점하고 있었습니다
품질 재시도가 상한을 전부 쓰고 끝났습니다. 기록을 따라가니 모델은 도구를 부르며 진행 중이었고 판정기는 직전 실패 답을 다시 채점하고 있었습니다. 점수와 후보의 수명을 한 회차로 묶은 과정입니다.
이름으로 만든 URI가 동명이인을 한 사람으로 합쳤습니다
조회 결과를 CSV로 내보내 다시 빌드하던 경로를 걷어내고 데이터베이스의 타입과 키를 그대로 썼습니다. 표시 이름을 식별자로 쓰면 동명이인이 합쳐지고 개명하면 다른 행이 됩니다. 정체성과 스냅샷 교체를 다시 설계한 과정입니다.
도구가 목록에는 보이는데 부를 수는 없었습니다
검색 범위를 좁히려고 허용 목록을 걸었더니 사용자가 직접 연결한 도구까지 함께 빠졌습니다. 이름 공개와 스키마 공개와 실행 권한을 각각 다른 시점에 두게 된 과정입니다.
작업은 성공이라고 나왔는데 그래프가 비어 있었습니다
추출 모델을 로컬 소형 모델로 바꾸자 배치가 끝나지 않거나, 성공으로 기록된 작업이 빈 그래프를 남겼습니다. 잘린 JSON과 시간 초과가 빈 결과처럼 처리되고 있었습니다. 실패를 실패로 만든 과정입니다.
문서용 중복 정리가 정형 테이블을 합치고 있었습니다
CSV 테이블 열 개를 빌드했는데 후처리가 끝난 그래프에는 클래스가 네 개였습니다. 문서 개념을 정리하는 규칙이 스키마 식별자까지 합친 것입니다. 생성 출처를 저장해 보호 범위를 만든 과정입니다.
규칙을 고친 뒤에도 남은 판정 흔들림은 공유 추론 서버에서 왔습니다
대형 유통 품질검사 에이전트가 같은 서류에 합격과 불합격을 번갈아 냈습니다. 판정 규칙, 이미지 판독, 프롬프트, 부하를 하나씩 제외하고 같은 텍스트를 10번 넣는 실험으로 공유 서버의 배치 처리까지 좁힌 과정입니다.
가까운 기억이 항상 이기게 두면 안 됐습니다
세션 요청이 플랫폼 정책보다 구체적이니 우선해야 할 것 같았습니다. 그렇게 두면 사용자가 정책을 덮어쓸 수 있었습니다. 실행 간 기억의 범위와 종류를 나누고 충돌을 푼 과정입니다.
붉게 칠한 노드의 대부분은 근거가 아니었습니다
검색 품질을 높이고 화면에서 답을 검증하니 강조된 노드가 실제 근거보다 훨씬 많았습니다. 강조 범위를 줄이면서, 저희가 만든 것이 근거 추적이 아니라 문자열 대조였다는 것도 함께 확인했습니다.
30배 차이가 모델의 차이가 아니었습니다
같은 워크플로우에 두 모델을 연결하니 2,488초와 84초가 나왔습니다. 반복 횟수와 출력 상한을 맞추자 2,488초가 100초가 됐습니다. 모델을 비교하기 전에 무엇을 고정해야 하는지 정리합니다.
느리고 부정확하다는 결과가 빈 그래프를 잰 것이었습니다
멀티턴 검색이 더 느리고 정확도도 낮다는 A/B 결과가 나왔습니다. 실행 기록을 보니 평가가 데이터 없는 그래프를 조회하고 벡터 검색만으로 답하고 있었습니다. 다시 잰 뒤 검색 구조를 바꾼 과정입니다.
검증셋을 떼어뒀다고 믿었는데 아니었습니다
설정을 자동으로 탐색하게 만들면서 승격 문턱과 검증셋을 뒀습니다. 구현을 다시 읽어보니 후보를 제안하는 쪽이 그 검증 기록을 보고 있었습니다. 자동 탐색기에 무엇을 맡길 수 있고 무엇을 맡길 수 없는지 정리합니다.
그래프를 정리하다가 정상 클래스 1,500개를 지웠습니다
인스턴스와 관계가 부족한 클래스를 자동 삭제했더니 정상 클래스 약 1,500개가 함께 사라졌습니다. 추출이 아직 만들지 못한 관계를 후처리가 불필요로 판정한 것입니다. 탐지와 삭제를 나눈 과정입니다.
제출 도구를 부르고도 실행이 멈추지 않았습니다
종착 도구가 성공했는데 실행이 계속됐고, 반대로 이전 회차의 기록만 보고 현재 회차를 일찍 끝내기도 했습니다. 다시 호출하는 이유와 종료를 소유하는 위치를 나눈 과정입니다.
트리플 수로는 지식그래프 품질을 알 수 없었습니다
같은 파이프라인이 한쪽에서는 25만 트리플을, 다른 쪽에서는 1천 트리플을 만들었습니다. 둘 다 문제가 있었고 방향은 정반대였습니다. 적재량·구조·출처·검색·답변을 나눠 재기 시작한 과정입니다.
답을 만든 모델에게 채점까지 맡기고 있었습니다
같은 모델이 답을 만들고 이어서 자기 답이 규칙을 지켰는지 판단하면 생성 방법과 합격 기준이 한 컨텍스트에 섞입니다. 업무를 수행하는 책임과 결과를 채택하는 책임을 나누고, 나눈 뒤에도 남은 한계를 정리합니다.
몇 시간짜리 빌드를 캐시에 올려두고 있었습니다
빌드가 몇 시간으로 늘자 작업 상태를 공유 캐시에 복제했습니다. 캐시가 만료되면 취소와 재개 정보를 복원할 수 없었습니다. 실행 상태와 지식 결과를 서로 다른 저장소로 나눈 과정입니다.
설치는 됐는데 같은 실행이라고 부를 수 없었습니다
워크플로우를 wheel로 묶어 다른 환경에 설치했습니다. 도구를 호출하자 제품 안에서만 성립하던 전제가 드러났습니다. 포장 형식을 두 번 갈아엎으며 무엇을 고정해야 실행이 옮겨가는지 확인한 과정입니다.
컨텍스트를 줄이려고 자른 것이 답의 근거였습니다
관계를 여러 단계 따라가려고 멀티턴 검색을 넣었습니다. 컨텍스트가 커져 도구 결과를 500자로 잘랐더니 표와 긴 원문의 뒷부분이 합성 단계에 도달하지 못했습니다. 탐색을 넓히며 무엇을 잃었는지 정리합니다.
저장소를 나눴는데 의존성은 그대로였습니다
엔진을 별도 모듈로 옮겼지만 실행하려면 제품의 설정 객체와 데이터베이스 세션, 캔버스 노드를 먼저 불러와야 했습니다. 독립을 선언한 사흘 뒤부터 누수를 잡으며 배운, 경계가 닫혔는지 확인하는 방법입니다.
질문이 답의 범위까지 정하고 있었습니다
역량 질문을 먼저 정하고 답에 필요한 개념을 찾는 방식이었습니다. 배송과 반품을 묻는 질문만 있으면 원문의 예외 승인 절차는 그래프에 남지 않았습니다. 질문을 빌드에서 빼고 평가에 남긴 과정입니다.
재시도 횟수로는 실행을 설명할 수 없었습니다
도구를 세 번 쓴 실행과 품질 검증에 세 번 실패한 실행이 같은 '재시도 3회'로 남았습니다. 생성·검증·도구 실행·재시도를 하나의 반복문에서 꺼내 명시적인 상태와 전이로 나눈 과정입니다.