개발과 일상

RAG 검색 성능을 올리기 위한 작업으로 보통은 임베딩 모델이나 리랭커부터 본다. 대부분 LLM에 의존한 작업이기 때문에 바꿔가면서 비교해보는데, 이런 저런 테스트를 해보면 생각보다 큰 차이는 없다. 언어 특화 임베딩 모델을 쓰면 좋아질 수 있지만, 모든 언어에 대응하는 임베딩 모델을 사용할 수는 없다. 그래서 이번에는 그보다 앞단인 청킹 전략을 바꿔보기로 했다. 검색이 잘 안 되는 문서가 있어서 조각을 하나씩 열어봤더니 표가 반토막 나 있고, 헤더를 제대로 읽지 못하는 현상이 있어서 그걸 계기로 시작해봤다. 위쪽 조각엔 표의 머리행만 남아 있고, 아래쪽 조각엔 숫자만 줄줄이 있었다. 남겨진 청크만 봐서는 무슨 표에 담겨진 데이터인지 알 수 없다. 당연히 검색도 잘 안 된다. 청크를 일정 크기로 자르는 ..

지난 글에서 Jev를 가입하고 이것저것 눌러봤다. 싸고 빠르고 한글도 읽는다는 건 확인했는데, 정확도는 안 재봤다.이번엔 실제 일을 하나 시켜봤다. 문서를 보고 어떤 카테고리인지 맞히는 일이다. 요즘 문서를 카테고리로 나눠서 다르게 자르는 청킹 실험을 하고 있는데, 거기서 제일 오래 붙들린 게 "이 문서가 어느 카테고리인가"를 판별하는 단계였다. 여럿 중 하나를 고르는 일이라 Jev의 choice 질문에 딱 맞는다. 문서 하나에 한 번만 부르면 되니 호출 수도 적다. 지난 글 끝에 규칙, 작은 언어모델, Jev를 같은 판에 올려보겠다고 적었는데 그건 못 했다. 재다 보니 서로 입력 조건이 달라서 같은 표에 올릴 수가 없었다. 그래서 이번 글은 Jev만 놓고 본다. 얼마나 맞히는지, 같이 나오는 확률은 믿..

주말 사이 개발자 커뮤니티를 뜨겁게 달군 모델이 하나 있다. TypeSafe AI라는 곳에서 낸 Jev 인데 System One 모델이라는 새 이름까지 붙여서 내놨다.https://docs.typesafe.ai/introduction (얘네 홈페이지를 너무 러프하게 만들어서 docs에서 보는게 편함) 다른 LLM과의 가장 큰 차이는 문장을 안 만든다는 것이다. 가입하면 크레딧을 5달러 주길래 이것 저것 테스트 해봤다. 한글이 되는지, 얼마나 쓸 수 있는지, 뭘 시킬 만한지 순서로 적어둔다. 가입부터 첫 호출까지 10분이면 되니 관심 있으면 직접 해보는 게 빠르다.System One Model : Jev보통 모델한테 "이 문의 어느 팀으로 보낼까"라고 물으면 이렇게 답한다. "결제 관련 문의로 보이므로 ..

문서 검색 도구를 만드는 중에 메모리 이슈가 올라왔다. 인덱스가 크지 않은 검색 서버의 프로세스가 메모리를 3GB나 쓰고 있었다. 디스크에 있는 인덱스 파일과 맞먹는 크기니, 거의 통째로 메모리에 올라온 것이다. 개발환경은 비교적 작은 크기지만, 실제 환경은 문서가 지금보다 열 배쯤 많다. 그렇다면 메모리에 올라가는 인덱스는 단순 비례로 잡으면 수십 GB가 넘게 된다. 이 포스팅은 검색 정확도는 그대로 두고 전체 메모리를 40% 넘게 줄인 트러블 슈팅에 대한 글이다.트러블 슈팅 내내 생각한 문제가 아닌 것이 반복됐다. 반복되는 검증 과정에서 문제를 정의해가는 과정을 정리했다.3GB는 어디에 있었나일단 프로세스가 시작하면서 단계별로 얼마나 늘어나는지부터 쟀다.파이썬만 ..

BM25로 키워드 검색을 뜯어본 것부터 시작해서, 평가셋, 질의처리기, 하이브리드 검색, 한국어 임베딩, 리랭커까지 왔다. 검색 하나를 붙들고 꽤 오래 적은 셈이다. 검색 개선기를 완결 짓기 전에 한 번 정리해두려고 한다. 뭘 만들었고, 뭐가 아쉬웠고, 다음은 어디로 갈 것 같은지도 생각해봤다.결과물최종 결과물은 온디바이스에서 도는 RAG 기반 검색기를 만들었다. 별도의 온프렘/클라우드 서버는 없고 사용자 기기 안에서 돌아가는 구조라, 2B급 소형 모델을 중심으로 붙였다. 개선기에 적어둔 것들이 그 안에 하나씩 들어가 있다. 전체를 늘어놓으면 이런 구조다.질의 "지난달 회의 자료" │ ├ 질의처리 슬롯(기간·종류)과 키워드로 쪼갠다 │ ├ 1차 검색 키워드(BM25) ─┐ ..

질의처리기에서 질의를 다듬고, 하이브리드 검색으로 키워드와 벡터를 합치고, 리랭커로 1등을 끌어올렸다. 이 개선기 내내 검색을 한 겹씩 쌓아 올린 셈이다. 그런데 그 모든 단계에서 "이게 정말 나아졌나"를 판정해준 건, 매번 뒤에서 조용히 돌던 '재는 일'이었다. 개선기를 닫는 이번 글은 그 잣대 자체, 평가지표 이야기다. 처음 개괄했던 글에서 지표를 한 번 훑었는데, 여기선 한 발 더 들어간다. nDCG까지 넣어 '계산'과 '진단'을 제대로 정리한다. Precision, Recall, Hit Rate, MRR, nDCG. 이름은 딱딱한데, 계산은 사실 더하기랑 나누기가 전부다. 계산보다 중요한 건 각 지표가 "무슨 문제를 알려주는지"다.1. 하나의 예시로 다 계산해보기상황 하나를 끝까지 붙들고 간다. ..

질의처리기 글에서 질의를 슬롯과 키워드로 나눴고, 하이브리드 검색 글에서 키워드(BM25)와 벡터를 합쳐 1차 검색을 완성하는 데까지 왔다. 그런데 그 1차 결과를 들여다보다 자꾸 같은 장면에 걸렸다. 정답 문서가 분명히 후보 안에는 있는데, 1등이 아니다. 넓게 건지는 건 잘 되는데 맨 위에 정답을 올려놓는 건 약했다. 그 마지막 한 끗을 손보는 게 이번 글의 주제, 리랭커(re-ranker)다. 이 글은 RAG 구축 고려사항 중 여섯 번째, 리랭커 매듭이다.1. 왜 리랭커인가 — 넓게 건지기와 1등 맞히기는 다른 일1차 검색의 일은 "넓게, 빠르게 건지기"다. 후보 안에 정답이 들어 있게만 하면 절반은 성공이다(이걸 recall이라 부른다). 그런데 그 후보들 중 무엇이 진짜 1등인지 가리는 정밀함은..

헤르메스(Hermes) 에이전트를 요즘 하도 좋다좋다 하길래 설치해봤다. 평소 Claude Code를 잘 쓰고 있으면서도, "무료 모델로 도는 자율 에이전트"라는 말에 궁금해서 손이 갔다. . 결론부터 적어두면, 뭔가 미묘하게 나쁜 도구는 아닌 것 같은데 나한테는 안 맞았다.(무료 오픈라우터 에이전트를 쓴 이유도 있을 것 같다) 정확히는 "안 좋다"가 아니라, 헤르메스의 동작 방식이 현재 작업 중인 환경에서는 큰 장점이 아니었다. 왜 그렇게 느꼈는지 설치부터 순서대로 적어둔다.1. 왜 깔았나이유랄 게 딱히 거창하진 않다. 여기저기서 좋다는 얘기가 자꾸 들렸다. 자율 에이전트인데 무료 모델로도 돌릴 수 있다길래, 가벼운 마음으로 설치했다. 이미 Claude Code를 매일 쓰고 있어서, 아쉬운 게 있어 갈..