개발과 일상

파인튜닝 글에서 작은 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로 누르는 식이다. 왜 이게 크기에 직접 영향을 주냐면, 모델 용량은 거의 "가중치 개수 × 가중치 하나당 바이트"로 정해지기 때문이다. 정밀도를 낮추면 가중치..

지난 글에서는 질의처리기를 규칙 기반에서 소형 LLM으로 옮겨보기로 한 이유를 적었다. 말은 그렇게 했지만, 막상 모델을 직접 학습시켜 본 적은 없었다. GPU가 달린 장비도 없었고, 비용을 들이기 전에 일단 "이게 되긴 되는가"부터 확인하고 싶었다. 그래서 무료 Colab T4 한 장으로 소형 모델을 파인튜닝해봤고, 이번 글에는 그 과정을 셀 단위로 적어둔다. 한 번에 끝난 게 아니라 데이터를 늘려가며 네 라운드를 돌렸는데, 처음 57%에서 96%까지 올라간 흐름도 같이 담는다. 목표는 단순하다. 사용자의 파일 검색 질의에서 필터 조건과 키워드를 JSON으로 뽑아내는 일이다. 예를 들어 "지난달 마케팅팀 보고서 pptx" 같은 문장을 받으면 아래처럼 정리해주면 된다.{"file_types": ["ppt..

지난 글에서는 질의처리기를 테스트하기 위한 테스트셋을 어떻게 만들었는지 정리했다. 테스트셋을 만들고 나니 다음 질문이 생겼다. 이 테스트셋을 기준으로 작은 모델을 학습시키면, 룰 기반 질의처리기를 대체하거나 보완할 수 있을까? 검색 본경로에 큰 LLM을 그대로 넣기는 어려웠다. 프롬프팅만으로 질의처리를 맡겼을 때 정확도는 50%대에 머물렀고, 온디바이스 환경에서는 속도 부담도 컸다. 하지만 질의처리 작업 자체는 범위가 비교적 명확했다. 사용자의 입력에서 검색 키워드·날짜·파일 타입·작성자·경로 같은 정보를 JSON으로 뽑아내면 된다. 자유로운 답변을 생성하는 것보다 훨씬 좁은 문제였다. 그래서 작은 모델을 이 작업에 맞게 파인튜닝해보면 어떨까 생각했다. 이번 글은 RAG 구축 고려사항 중 모델 양자화에도..

지난 글에서는 검색기 앞단의 질의처리 방향을 어떻게 정리했는지 적었다. 테스트 결과, 사용자의 질의를 그대로 검색하는 방식이 형태소분석 후 키워드만 넘기는 방식보다 조금 더 안정적이었다. 하지만 그렇다고 질의처리가 필요 없는 것은 아니었다. 검색 본문으로 사용할 표현은 최대한 보존하되, 날짜나 지역, 파일 타입, 기관명처럼 조건으로 다룰 수 있는 정보는 별도로 구조화하는 편이 더 적절해 보였다. 결국 핵심은 LLM을 쓰느냐 마느냐가 아니었다. 검색어로 남길 것, 필터 조건으로 분리할 것, 제거할 것을 나누는 기준이 더 중요했다. 그렇다면 다음으로 정해야 할 것은 이 기준을 어떻게 테스트할 것인가였다. 검색기는 정답 문서가 검색 결과 상위에 들어오는지를 보면 된다. 하지만 질의처리기는 정답 문서를 직접 찾..

지난 글에서는 검색을 개선하기 전에 평가셋부터 다시 짜야 했던 이유를 적었다. 이번 글은 RAG 구축 고려사항 중 질의 강화·키워드 추출에 해당한다. 결론부터 말하면, 질의를 키워드로 바꾸는 게 오히려 검색을 깎아먹었다.검색기를 의심했는데, 검색기 문제가 아니었다검색 품질이 아쉬우면 가장 먼저 검색기를 의심하게 된다. 나도 그랬다. 임베딩 모델을 바꿔보고, 인덱싱 방식을 손보고, 청크 크기를 조절하며 며칠을 보냈다. "검색이 약하니 검색기를 강하게 만들면 되겠지"라는 게 당연한 출발점이었다. 그런데 평가셋을 정리하고 나서, 검색기는 그대로 둔 채 질의를 넘기는 방식만 바꿔 같은 조건에서 비교해봤다. 원질의를 그대로 검색할 때, 키워드만 추출해 넘길 때, 추출한 키워드를 확장해 넘길 때. 결과는 예상과 정..

현재 온디바이스(On-Device) 환경에서 쓸 RAG 검색 시스템을 개선하고 있다. 그런데 막상 "검색을 개선하자"고 마음먹고 나니, 제일 먼저 막힌 건 알고리즘이 아니라 "개선됐는지 어떻게 아느냐" 였다. 개선이라는 건 결국 "전보다 나아졌다"를 보여야 하는데, 그 "전보다"를 재는 자가 흔들리면 무슨 짓을 해도 "좋아진 것 같다"는 느낌으로만 남는다. 이 글은 이전 글에서 정리한 'RAG 구축 시 고려할 것들' 중 검색 품질을 측정하는 기준에 해당한다. 결론부터 말하면, 검색을 건드리기 전에 평가셋부터 다시 짜야 했고, 그 과정에서 생각보다 고민할 게 많았다.1. 테스트 목적이 하나가 아니었다처음엔 단순하게 생각했다. "검색 평가셋 하나 잘 만들면 그걸로 다 재면 되지." 그런데 실제로 실험을 돌리..