Retrieval · RAG
질의에 맞는 근거를 찾아 답변 생성에 공급하는 검색 계층
Posts 5
같은 질문에 근거가 매번 달랐던 이유는 정렬 없는 LIMIT이었습니다
같은 50문항을 두 번 검색하면 근거가 43문항에서만 같았습니다. 그래프 조회의 정렬 없는 LIMIT을 고치면서, 순위 알고리즘은 라이브러리가 맡고 저장소 조회는 제품 어댑터가 맡도록 경계를 다시 그은 과정입니다.
98 대 86으로 진 평가는 같은 조건의 비교가 아니었습니다
경쟁 클라우드 에이전트와 캐피탈 사내 규정 165문항으로 다시 비교하기 전에 문서 적재, 청크, 근거 개수, 평가기 시간을 하나씩 맞췄습니다. 같은 답변 모델과 같은 채점 모델로 한 번 실행한 결과는 80.0% 대 66.7%였습니다.
붉게 칠한 노드의 대부분은 근거가 아니었습니다
검색 품질을 높이고 그래프 뷰어에서 답을 검증하니 강조된 노드가 실제 근거보다 훨씬 많았습니다. 강조 범위를 줄이면서, 저희가 만든 것이 근거 추적이 아니라 문자열 대조였다는 것도 함께 확인했습니다.
느리고 부정확하다는 결과가 빈 그래프를 잰 것이었습니다
멀티턴 검색이 더 느리고 정확도도 낮다는 A/B 결과가 나왔습니다. 실행 기록을 보니 평가가 데이터 없는 그래프를 조회하고 벡터 검색만으로 답하고 있었습니다. 다시 측정한 뒤 검색 구조를 바꾼 과정입니다.
컨텍스트를 줄이려고 자른 것이 답의 근거였습니다
관계를 여러 단계 따라가려고 멀티턴 검색을 넣었습니다. 컨텍스트가 커져 도구 결과를 500자로 잘랐더니 표와 긴 원문의 뒷부분이 합성 단계에 도달하지 못했습니다. 탐색을 넓히며 무엇을 잃었는지 정리합니다.
Engineering 21
DB 원본과 지식 그래프를 맞추는 법: 증분 키를 버리고 행 지문으로 추가·변경·삭제를 감지하기
외부 DB 테이블을 LLM 없이 그래프로 만드는 기능에서, 사용자가 고르는 증분 키는 값만 바뀐 행·시각이 되돌아간 행·지워진 행을 놓쳤습니다. PK keyset 전수 읽기와 sha256 행 지문 비교로 원본이 진실인 동기화를 만들고, 실패한 회차의 지문이 그래프보다 앞서지 않도록 지문을 먼저 비우고 가리켜지는 행은 자리 노드로 남겨 실패 경로를 닫았습니다.
10만 노드 지식 그래프 뷰어: 렌더링 최적화에서 '무엇을 그릴 것인가'로 옮겨 간 문제
온톨로지 그래프를 브라우저에서 탐색하려고 Three.js InstancedMesh 렌더러와 Web Worker 물리 연산을 만들었지만, 컬렉션이 커지자 병목은 무엇을 그릴지로 옮겨 갔습니다. CDP 프로파일링으로 리프 노드가 비용의 대부분임을 확인해 구조 우선 샘플링으로 CPU 점유를 25%에서 7%로 낮추고, 렌더 상한 밖의 노드는 서버 검색으로 찾아 불러오게 했습니다.
LLM 없는 개체 추출의 이름 품질: 우연에 걸린 표 판정, 탈락한 어근, 적재 계층 이름 게이트
기본 빌드가 LLM 없이 개체를 뽑게 되자 그래프 품질은 곧 이름 품질이 됐습니다. 산문을 표로 오인하던 판정, 어근과 접미사를 버리던 형태소 결합, 경로마다 흩어진 정제 로직을 원인별로 고치고, 이름 정규화와 모양 검사를 추출기가 아닌 그래프 적재 계층 한 곳으로 내렸습니다.
공정 비교는 평가 파이프라인을 의심하는 데서 시작했습니다: 대조군 오염, 평가기 루프 차단, 회수 지표 결함
사내 규정 165문항으로 경쟁 클라우드 에이전트와 비교하기 전에 평가 파이프라인 자체를 검증했습니다. 적재 결함, 오염된 대조군, 상대 설정 오인, 응답 시간을 부풀리던 평가기, 회수를 과소 집계하던 지표를 차례로 찾아 고친 뒤 같은 조건에서 80.0% 대 66.7%를 측정했습니다.
재색인을 요청-응답에서 백그라운드 작업으로: 30초 타임아웃 뒤에 있던 UI와 백엔드의 계약 불일치
요청 하나 안에서 전 청크 재임베딩까지 끝내던 재색인 API가 클라이언트 30초 타임아웃에 걸려 실패처럼 보이고 중복 실행되던 문제를, 202 응답과 상태 조회, Redis 사본과 SET NX로 다중 파드에서도 컬렉션당 한 작업만 도는 구조로 바꿨습니다. 두 파드 시나리오 테스트가 상태 조회 순서 결함을 잡아냈습니다.
그래프 크기를 따라가던 검색 비용과 흔들리던 근거: PostgreSQL 그래프 조회 계층 정비
PostgreSQL 위 GraphRAG 검색이 한 번에 54~127초 걸리거나 같은 질문에 근거가 달라지는 현상을 pg_stat_activity, 실행 계획, 로그 타임스탬프로 추적했습니다. 플래너 통계, 그래프 전체를 읽던 PPR, 검색마다 반복되던 집계, 정렬 없는 LIMIT을 차례로 고쳐 비용을 후보 크기에 묶고 근거 재현을 50/50으로 맞췄습니다.
오답 60건을 시스템 시점에서 감사하기: 실패를 근거 활용과 후보 회수로 나누고 개선안을 실측으로 거른 기록
평가 런 4개의 오답을 모아 정답 청크 60건을 골든셋 앵커 없이 시스템이 보는 정보만으로 감사했고, 오답의 60%가 검색이 아니라 근거 활용에서 난다는 것을 확인했습니다. 원인 9가지와 개선안 10가지로 기획을 세운 뒤, 검색 회수를 먼저 재는 프로토콜로 개선안 대부분을 실측으로 걸러 냈습니다.
은행 관리 콘솔 에이전트 온톨로지: 운영 테이블에서 LLM 없이 구성하고 분포로 판정하기
관리자가 300여 개 에이전트와 컬렉션·DB·도구의 관계를 탐색하고 질문할 수 있도록, 문서를 다시 추출하지 않고 운영 테이블에서 에이전트 그래프를 결정론적으로 구성했습니다. 상태 서명 기반 증분, 분포 기반 인사이트 규칙, 그래프 근거 질의, 서버 측 그래프 요약까지 설계 판단과 실측을 정리합니다.
출처는 생산 지점에서, 원본도 같은 정책으로: RAG 출처 표시 파이프라인 재정비
답변 출처가 검색 모드에 따라 사라지거나, 검색 노드 없이도 붙거나, 원본 열람이 마스킹 정책을 우회하고, 큰 CSV 출처가 브라우저를 멈추던 문제를 차례로 추적했습니다. 출처는 백엔드 생산 지점에서 결정하고, 원본도 청크와 같은 정책을 거치며, 뷰어는 보이는 만큼만 그린다는 원칙으로 정리했습니다.
FAQ 검색 순위 수리: 전제가 맞지 않던 그래프 융합을 끄고 빠져 있던 BM25F 어휘 점수 되돌리기
고객센터 FAQ 165문항에서 정답 문서가 후보에는 있는데 상위 3개 밖으로 밀리던 원인을 단계별 순위 측정으로 추적했습니다. 노드 단위가 맞지 않던 그래프 융합을 끄고, 어댑터에서 빠져 있던 BM25F 어휘 점수를 라이브러리 설계대로 복원해 정답 문서 1위 비율을 66.1%에서 96.4%로 올렸습니다.
판단 주체가 없는 사전 검색: 규칙 엔진에서 LLM 사전 검색으로, 노드 교체 없이 엔진 전환하기
매 턴 코드가 검색하는 사전 검색 모드가 특정 조항을 못 찾던 원인을 판단 주체의 부재로 정의하고, 규칙 엔진을 거쳐 검색어·폴더 선택만 LLM에 맡기는 구조로 다시 설계했습니다. 엔진은 노드 ID를 바꾸지 않고 관리 설정으로 전환하며, 배포 뒤 드러난 404·스트리밍·마스킹 결함까지 정리했습니다.
시간 상한은 탐색에만, 합성 지연은 스트리밍으로: 근거 누출 사고에서 시작한 검색 지연 재설계
질문당 총시간을 보장하려고 건 25초 하드 상한이 합성 LLM에 4초만 남겨, 내부 근거가 답변으로 새는 사고로 이어졌습니다. 로그와 단계별 계측으로 지연의 대부분이 합성 대기임을 확인하고, 상한은 탐색에만 두고 체감 지연은 합성 입력의 문자 예산과 답변 스트리밍으로 다뤘습니다.
Fuseki 없이 지식 그래프 운영하기: PostgreSQL 테이블 3개로 옮기며 드러난 숨은 결합들
별도 JVM 트리플스토어인 Fuseki는 설정 하나가 어긋나면 그래프 계층 전체가 멈추고 폐쇄망 반입 부담도 컸습니다. 같은 빌드를 두 저장소에 이중 기록해 충실도를 대조한 뒤 Fuseki 쓰기를 기본 비활성화했고, 완료 판정·재시도·카운트·품질 지표에 숨어 있던 Fuseki 전제를 하나씩 걷어내며 검색을 라이브러리로 일원화했습니다.
날짜 경계처럼 보인 도구 멈춤의 실체: HWP 파서가 남긴 UTF-16 서로게이트와 보이지 않던 도구 오류
8월 5일 이후 보도자료만 멈추던 에이전트 도구를 첨부 형식별 전수 대조로 추적해, HWP 파서가 한컴 사설 영역 문자를 UTF-16 서로게이트 쌍으로 남겨 UTF-8 인코딩이 실패한 것과 도구 오류 이벤트가 UI로 전달되지 않던 것을 찾았습니다. 서로게이트를 무손실 복원하는 정규화를 발원지와 공통 길목에 적용했습니다.
XGEN MAKER: 코드 지식그래프 착지 정확도를 사람이 머지한 MR 2,827건으로 잰 개발 자동화 하네스
다중 저장소 플랫폼의 코드를 결정론적 정적 분석으로 지식그래프화하고, 자연어 요청을 파일·라인 단위로 착지시켜 구현·검증·MR 준비까지 수행하는 하네스입니다. 착지 품질은 사람이 실제로 머지한 MR 2,827건으로 측정했고, 표본을 넓히는 과정에서 작은 표본에 과적합된 순위 상수를 찾아 걷어냈습니다.
컬렉션 데이터 소스: 휴면 스케줄러를 살리지 않고 provider 두 메서드로 원천을 늘린 증분 인덱싱
내부 파일 저장소 폴더를 컬렉션에 연결하면 변경분만 자동 인덱싱되는 데이터 소스를 바인딩·durable 작업 큐·해시 diff 골격으로 만들고, 휴면 상태의 저장소 동기화 기능을 되살리는 대신 API 도구를 provider로 흡수했습니다. DB 연결 창이 2분 넘게 멈추던 원인도 접속 시간 제한 누락과 이벤트 루프 차단으로 찾아 고쳤습니다.
외부 채점기로 검증한 검색 라이브러리: BM25F, 그래프 동반 융합, SQLite 영속화
XGEN의 GraphRAG 검색 로직을 저장소 비종속 라이브러리 omnifuse로 추출한 뒤, 다른 오픈소스가 공개한 한국어 금융법령 코퍼스와 채점 스크립트, 공개 IR 데이터셋으로 랭킹과 효율을 측정하며 고쳤습니다. 데이터셋별 튜닝과 결과 자르기를 금지한 측정 계약 아래에서 채택한 변경과 기각한 변경을 정리합니다.
sam2-mcp: 30초 호출 한도에 맞춘 비전 MCP 서버와 이미지형 PDF 실패 추적
GPU 없는 머신에서 SAM 2 세그멘테이션과 비전 OCR을 에이전트 도구로 제공하는 FastMCP 서버입니다. 호출당 30초 한도와 세션당 단일 호출이라는 플랫폼 제약을 실측으로 확인해 병렬 처리를 서버 안으로 옮겼고, 이미지형 PDF에 몰린 심의 실패를 서로 독립된 결함들로 분해해 고쳤습니다.
XGEN CREATOR: 클릭이 실행한 백엔드 코드 라인을 증거로 산출물을 만드는 라이브 트레이서
브라우저 클릭을 프론트엔드 소스에 연결하고, 그 클릭이 실행한 백엔드 Python 라인을 sys.monitoring 기반 트레이서로 캡처해 UI 정의서·테스트결과서·API 명세서를 생성하는 도구입니다. 실제 XGEN 스택에서 관측이 대상을 멈추는 문제, 산출물은 나오는데 트레이스가 0건인 조용한 실패, 콜스택 깊이 오차를 차례로 고쳤습니다.
GraphRAG 검색 재설계: 순차 ReAct를 병렬 인덱스 시드와 단일 합성으로 바꾼 근거
단일 적응형 ReAct 검색이 기존 1턴 검색보다 느리고 부정확하다는 A/B 결과를 다시 읽어, 손실된 근거와 빈 그래프를 잰 하니스라는 두 원인을 찾았습니다. 탐색과 답변 합성을 분리한 병렬 인덱스 시드 구조로 바꿔 고정 100문항 정답성을 0.230에서 0.465로 올렸습니다.
LG CNS Singlex 사내 RAG 챗봇
목차로 매뉴얼을 먼저 고르는 2단계 검색을 제안하고, 프롬프트 버전별 실제 화면 응답 비교를 자동화했습니다.