개발과 일상

문서 검색 도구를 만드는 중에 메모리 이슈가 올라왔다. 인덱스가 크지 않은 검색 서버의 프로세스가 메모리를 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를 매일 쓰고 있어서, 아쉬운 게 있어 갈..

한동안 검색을 들여다보다 구멍을 하나 발견했다. 한국어 검색인데, 외래어가 섞인 질의가 자꾸 헛돌았다. 예를 들어 "스마트 팩토리"로 찾으면, 정작 스마트 팩토리를 다루는 문서가 위로 안 올라오고 엉뚱한 게 섞였다. "작년 회의 자료" 같은 평범한 한국어 질의는 멀쩡한데, 이렇게 영어에서 온 말이 한글로 적힌 구간에서만 새는 현상이 있었다. 문제의 원인을 찾는건 그렇게 어렵지 않았는데, 검색의 초기 버전이 임베딩 모델에 전적으로 의존하고 있었기 때문이다.그때 쓰던 건 범용 다국어 임베딩이었다. 여러 언어를 두루 하는 모델. 검색 성능을 조금 더 올리고 싶던 참이라, 이번엔 임베딩 모델 자체를 손대보기로 했다. 한국어에 특화된 임베딩으로. 이 글은 RAG 구축 고려사항의 임베딩 모델 항목에 해당하는, 성능..

"내 PC에서 LLM을 직접 굴려보고 싶다." 여기까지는 쉬운데, 막상 찾아보면 도구가 셋이나 나온다. LM Studio, Ollama, llama.cpp. 뭘 골라야 하나 싶어 한참 헤맸는데, 알고 보니 셋은 경쟁하는 대체재가 아니라 층이 다른 것이었다. 맨 밑에 엔진(llama.cpp)이 있고, 그 위에 편의 도구(Ollama·LM Studio)가 얹힌 구조다. 이 글은 그 셋을 쉬운 순서로 하나씩 띄워보고, 언제 뭘 쓰면 좋은지까지 정리한다. (양자화 글에서 모델을 GGUF로 만드는 얘기를 했는데, 이 글은 그 GGUF를 실제로 굴리는 법이다. RAG 구축 고려사항의 서빙 곁가지쯤.)1. 제일 쉬운 길 : LM Studio (터미널 없이 클릭 몇 번)터미널이 부담스러우면 여기서 시작하는 게 제일 편..

BM25 글에서 키워드 검색을 다뤘다. 정확히 같은 단어로 물어보면 강하다. 그런데 "회의 자료"로 색인된 문서를 누가 "미팅 정리본"이라고 검색하면? 단어가 안 겹쳐서 못 찾는다. 키워드 검색의 천장이 여기다. 이걸 벡터(임베딩) 검색이 메워준다 — 단어가 달라도 의미가 가까우면 잡는다. 그럼 둘을 합치면 되지 않나? 그게 이번 글, 하이브리드 검색이다. 이 글은 RAG 구축 고려사항에서 1차 검색을 완성하는 자리다. 다음 글에선 이 1차 위에 리랭커(2차)를 얹는다.1. 두 검색은 강점이 다르다 — 키워드 vs 벡터키워드 검색(BM25)은 어휘 일치다. 질의의 단어가 문서에 그대로 있으면 점수가 붙는다. 그래서 파일명이나 고유한 용어처럼 "딱 그 단어"를 찾을 땐 거의 안 틀린다. 대신 같은 뜻 다른..