개발과 일상

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

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

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

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