개발과 일상

질의처리기 글에서 질의를 슬롯과 키워드로 나눴고, 하이브리드 검색 글에서 키워드(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)은 어휘 일치다. 질의의 단어가 문서에 그대로 있으면 점수가 붙는다. 그래서 파일명이나 고유한 용어처럼 "딱 그 단어"를 찾을 땐 거의 안 틀린다. 대신 같은 뜻 다른..

파인튜닝 글에서 작은 LLM으로 질의처리기를 만들어봤지만, 표준 어순에선 잘 되다가 변형에서 무너졌고 결국 곁가지로 남았다고 적었다. 그러면 본선 질의처리기는 어떻게 됐을까. 결국 LLM을 걷어내고 규칙 기반으로 다시 만들었다. 사실 질의처리 글에서 이미 답이 나와 있었다 — 질의처리의 핵심은 LLM을 쓰느냐가 아니라, 검색어·필터·제거를 나누는 기준이라는 것. 이 글은 RAG 구축 고려사항 중 질의 강화·키워드 추출의 마지막 매듭이다.1. 왜 다시 규칙이었나LLM으로 질의를 처리하면 깔끔해 보인다. 그런데 검색 본경로에 두기엔 세 가지가 걸렸다. 1. 호출이 느렸고,2. 같은 질의에 매번 결과가 조금씩 달라졌으며(비결정성)3. 파인튜닝으로 정확도를 올려도 학습에 없던 표현에서 흔들렸다(오버피팅). 돌아..

검색이든 질의처리든, 한국어를 다루는 일은 결국 "문장을 어떻게 쪼개느냐"에서 시작한다. 질의처리 글에서 검색어·필터·제거를 나눈다고 했고, BM25 글에서는 질의와 문서를 같은 단어로 맞춰야 점수가 붙는다고 했다. 두 글 모두 바닥에 같은 도구를 깔고 있었다. 형태소 분석기 Kiwi(github.com/bab2min/Kiwi, 파이썬 래퍼는 kiwipiepy)다. 이번 글은 그 바탕을 따로 짚는다.1. 한국어는 띄어쓰기로 안 갈린다영어는 띄어쓰기가 곧 단어 경계다. "marketing report"는 공백으로 자르면 끝이다. 그런데 한국어는 단어에 조사·어미가 찰싹 붙어 한 덩어리로 다닌다. "마케팅 보고서를 찾아줘"를 그냥 공백으로 자르면 이렇게 된다."마케팅 보고서를 찾아줘" 띄어쓰기로만 자르면..

지난 글에서는 학습한 모델을 GGUF로 바꿔 Ollama에 올렸다. 그때 "GGUF Q8_0으로 변환했다"고 한 줄 적고 넘어갔는데, 사실 그 한 줄에는 숨은 결정이 하나 있었다. 어느 정밀도로 양자화할 것인가. 이번 글은 RAG 구축 고려사항 중 ⑦모델 양자화에 해당하는, 그 결정에 대한 이야기다.1. 양자화는 결국 "비트를 줄이는 일"이다모델은 수십억 개의 가중치, 그러니까 숫자 덩어리다. 이 숫자를 원본은 보통 16-bit 부동소수점(fp16)으로 저장한다. 양자화는 이 숫자를 더 적은 비트로 근사해서 저장하는 일이다. 8-bit, 4-bit로 누르는 식이다. 왜 이게 크기에 직접 영향을 주냐면, 모델 용량은 거의 "가중치 개수 × 가중치 하나당 바이트"로 정해지기 때문이다. 정밀도를 낮추면 가중치..