개발과 일상

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

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

RAG라고 하면 보통 임베딩과 벡터 검색을 먼저 떠올린다. 의미가 비슷한 문서를 찾아주는 그 능력이 RAG의 핵심처럼 보이니까. 그런데 막상 실제 문서 검색에 붙여보면, 벡터만으로는 자꾸 새는 구멍이 있다. 예를 들어 "IITP"나 "국가연구개발혁신법" 같은 정확한 고유명사·법령명을 검색할 때다. 이런 건 의미가 비슷한 걸 찾으면 곤란하다. 글자 그대로 들어맞는 문서를 찾아야 한다. 벡터 검색은 "비슷함"에 강하지만 "정확히 같음"에는 의외로 약하다. 철자 하나 다른 약어, 학습 때 못 본 신조어, 숫자가 섞인 코드 같은 건 임베딩이 뭉뚱그려버린다. 그래서 키워드(lexical) 검색이 한 축으로 필요했고, 그 표준이 BM25였다. 직접 구현해서 붙여보며 정리해둔다. 솔직히 처음엔 나도 "그냥 질의 단어..