브라우저에서 소형 언어 모델을 이용한 RAG 실행하기

그래서 제가 이것을 만들었습니다. '내 블로그에 물어보기'입니다. 검색 기능이 가장 관련성 높은 네 개의 구절을 찾고, 브라우저에서 실행되는 소형 언어 모델이 그것들을 두 문장으로 요약합니다. 사용자가 입력하는 어떤 내용도 기기를 벗어나지 않습니다. 그리고 '소형 모델이 무언가를 요약한다'는 것이 실제로는 많은 꾸며낸 헛소리를 숨기고 있는 종류의 문장이기 때문에, 저는 이것이 실제로 제가 작성한 내용에 얼마나 충실한지를 측정했습니다. 알고 보니 소형 모델에는 몇 가지 한계가 있습니다.

작동 방식

페이지는 검색 증강 생성(RAG) 방식으로 구성되어 있으며 모든 부분이 클라이언트 측에서 실행됩니다:

검색(Retrieve). 사용자의 질문은 홈페이지와 동일한 정적 임베딩 검색을 거치지만, 결과를 게시물 단위로 모으는 대신 가장 점수가 높은 구절 네 개를 유지합니다.게이트(Gate). 만약 가장 좋은 구절의 점수가 특정 임계값보다 낮으면 모델이 호출되지 않으며 페이지에는 블로그에서 찾을 수 없다는 메시지가 표시됩니다. 아이디어는 사용자가 데이터가 없는 것에 대해 질문할 경우 애쓰지 않는 것입니다. 왜 이것이 절반만 작동하는지에 대해서는 아래에서 더 자세히 설명하겠습니다.프롬프트(Prompt). 번호가 매겨진 구절들과 함께 시스템 프롬프트가 제공됩니다: '최대 두 문장으로 답변하고, 이 구절들만을 사용하며, 만약 질문에 답하지 못하면 그렇게 밝혀라.'생성(Generate). Web Worker가 transformers.js를 사용하여 WebGPU 또는 브라우저에 WebGPU가 없는 경우 WebAssembly를 통해 CPU에서 모델을 실행하고 페이지에 답변을 스트리밍합니다. 두 개의 완전한 문장이 완성되는 즉시 중지됩니다.

구절들은 먼저 카드 형태로 표시되며, 요약은 그 위에 위치하게 됩니다. 모델을 전혀 로드하지 않고도 검색할 수 있습니다. 단지 구절들만 얻게 될 뿐입니다. 모델을 로드하는 것은 명시적인 클릭이 필요한데, 이는 Hugging Face에서 몇백 메가바이트를 다운로드해야 함을 의미합니다(한 번만; 브라우저에 캐싱됩니다). 또한 캐시를 지우는 버튼도 있습니다.

The download indicator: one square per 4 MB of model

어떤 모델을 사용할까?

독자가 보기 적당한 크기, 즉 기가바이트(GB) 단위가 아닌 수백 메가바이트(MB) 단위의 모델을 원했습니다(혹시 버스에서 읽는다면). 브라우저에서 바로 사용할 수 있는 (ONNX) 빌드를 가진 후보로는 SmolLM2(135M 및 360M 파라미터), Gemma 3 270M, LFM2.5-350M, Qwen2.5-0.5B, 그리고 Qwen3-0.6B가 있었습니다. 비교를 위해 페이지에 절대 배포되지 않을 두 가지 레퍼런스(참조)도 추가했습니다: 구글의 새로운 Gemma 4 모델 중 가장 작은 크기인 다운로드 용량 3.1 GB의 Gemma 4 E2B, 그리고 API를 통해 접근하는 ‘돈을 지불할 사람’ 옵션인 Claude Haiku 5.5입니다.

어떤 것도 실행하기 전에 발견한 한 가지 놀라운 점은 다음과 같습니다: 이 모델들 중 몇몇의 경우 “4비트”(q4) 빌드가 4비트-16비트 부동소수점(q4f16) 빌드보다 더 큰 크기라는 것입니다. 이는 q4 내보내기가 임베딩 테이블을 전체 32비트 정밀도로 유지하기 때문입니다. SmolLM2-360M은 q4일 때 390 MB이고 q4f16일 때는 275 MB이며, 출력 결과는 동일합니다. 아래의 모든 내용은 q4f16을 사용했습니다.

평가 (The eval)

저는 시맨틱 검색(semantic search) 포스트를 위해 수행했던 30개의 질문을 재사용하여 실제 질문(

결과적으로 350MB 이하의 제품 중 이 용도로 쓸 만한 것은 없는 것 같습니다. 단순히 조금 나쁜 정도가 아니라, 충실도가 30개 중 최대 세 번에 불과하며, 여러분이 던지는 거의 모든 질문에 기꺼이 답할 것입니다. MacBook에서 임베딩 관련 패시지 4개와 코딩 에이전트와 함께 Llama 70B를 위해 어떤 GPU를 사야 하는지 물었을 때:

“…Llama 70B를 로컬로 실행하는 가장 좋은 옵션은 NVIDIA GTX 960 또는 GTX 970일 가능성이 높습니다. […] 이들은 또한 높은 메모리 대역폭을 제공하여 Llama 70B가 요구하는 640만 건의 문서와 같은 대량의 데이터를 처리하는 데 이상적입니다.” (SmolLM2-360M)

“…NVIDIA A100 시리즈(예: RTX 3090, RTX 3080, 3070, 3080, 3070M, 3080M)와 같은 고성능 그래픽 카드(GPU)” (Gemma 3 270M)

“…인기 있는 옵션에는 RTX 3090, RTR 5900 또는 개선된 컴퓨팅 효율을 위한 TensorRT 60+와 같은 최신 세대가 포함됩니다.” (LFM2.5-350M)

참고로 Gemma 4 E2B는 “제공된 패시지에는 Llama 70B를 로컬로 실행하기 위해 어떤 GPU를 사야 하는지에 대한 정보가 없습니다.”라고 정확하게 판단했습니다. Google, 수고하셨습니다.

블로그에서 실제로 답변하는 질문에 대해서도 소형 모델들은 내용을 왜곡하는 경향이 있습니다. 여기 제 Bloom 필터 게시물에 대한 가장 기본적인 질문을 LFM2.5로 노트북 GPU에서 초당 73 토큰으로 테스트한 결과입니다:

LFM2.5-350M explaining Bloom filters as a hash table with “true negatives”

빠르고, 유창하고, 틀린. Bloom 필터는 해시 테이블이 아니다: 비트 배열이며, 요소가 '집합에 있을 가능성이 높다'고 간주되려면 k개의 모든 해시 함수가 설정된 비트에 도달해야 한다. 마지막 절은 실제로 정확하다 (누락된 비트는 해당 요소가 추가된 적이 없다는 것을 의미하므로 Bloom 필터는 거짓 음성(false negatives)을 줄 수 없다), 하지만 나머지는 지어낸 것이다. 모델에게 공정하게 하자면, search는 Bloom 필터가 어떻게 작동하는지 설명하는 섹션을 제공하지 않았고; 받은 네 개의 구절은 사용 사례와 대화형 데모에 관한 것이었다. 요약은 읽는 구절만큼만 좋을 수 있다. 내 작은 검색 엔진의 관련성 점수(relevance scoring)에 좀 더 작업할 부분이 있는 것 같다.

Qwen3-0.6B가 흥미롭다. 579 MB로 상당히 크고, 내가 설정한 예산을 초과한다. 반쯤은 충실하며, 이는 기본적으로 동전 던지기와 같다. 하지만, 그것은 거의 보장된 실패라기보다는 동전 던지기에 가까운 가장 작은 모델이므로, 이것이

토큰이 소진될 때까지입니다. 항상 가장 가능성이 높은 다음 토큰만을 선택하고 이를 반복하는 것을 막는 것이 없으면 이런 일이 발생합니다. 작은 모델들은 하나의 패턴에 빠져나오지 못하게 됩니다 (저도 MicroLLMLab을 가지고 놀면서 상당히 자주 목격했습니다). 간단한 해결책은 반복 페널티(repetition penalty)를 적용하는 것입니다 (이 경우 1.15로, 모델이 이미 본 토큰의 사용을 약간 억제합니다). 이것이 충실성(faithfulness)이나 품질 자체를 고치는 것은 아닙니다. 단지 모델들이 더 길고 다양하며 의미 없는 내용을 쓰게 할 뿐입니다. 위에 제시된 모든 수치들은 페널티가 1.15로 설정되었을 때의 값들입니다.

명백히 벗어난 질문을 걸러내는 관련성 게이트(relevance gate)

꾸며낸 답변에 대한 저렴한 해결책처럼 관련성 게이트가 등장했습니다. 검색이 아무것도 관련성 있는 것을 찾지 못하면, 모델에게 묻지 않는 것입니다. 이는 거리가 먼 질문에는 효과적입니다.

보통은 그렇습니다. 현재 가격(경쟁이 치열해서)을 고려할 때, 특별한 이유가 없는 한 (예: 규정 준수, 개인 정보 보호, 에어 갭 배포 등), 거의 가치가 없습니다. 하지만 생각 실험으로 보자면: 3.1 GB 크기의 Gemma 4 E2B는 Haiku와 품질 면에서 비슷합니다. 독자들이 다운로드하도록 하는 대신, 이 모델을 실행하는 데 드는 비용은 얼마일까요? Google Cloud의 NVIDIA L4 같은 가장 저렴하고 합리적인 클라우드 GPU를 사용하면 시간당 약 $0.71이며, 계속 운영하려면 월 $516이 듭니다. 이 블로그가 한 달 동안 보는 독자 수를 고려할 때, 모든 사람이 질문을 한다고 가정해도 질문당 1달러가 넘게 됩니다.

반면에 Haiku는 45개의 평가 질문에 대해 $0.006으로 답변했습니다. 월 500개 질문(꿈만 꾸는 수치일지라도)이라면 약 7센트 정도의 비용이 들 것입니다. 다시 말해, 실제 사용 사례가 있다면 Haiku로 시작하세요.

더 짧을수록 안전하다

Qwen3의 두 문장이 절반의 시간 동안만 정확하다면, 더 많은 말을 하게 하는 것이 도움이 될까요? 저는 Qwen3-0.6B와 Gemma 4 E2B를 사용하여 두 개, 네 개 또는 여섯 개의 문장을 허용하는 간단한 실험을 진행했습니다.

두 모델 모두 공간이 늘어날수록 정확도가 떨어지지만, 더 작은 모델은 급격히 성능이 저하됩니다: Qwen3는 30개 질문 중 정확 답변 비율이 15에서 9로, 다시 5로 떨어집니다. 문장이 하나 추가될 때마다 환각을 일으킬 기회가 늘어납니다. 여섯 개의 문장에서는 GPU에 대한 논의를 완전히 중단하고 대신 모든 구절을 유용하게 요약한 다음, “답변은 사용자가 고성능 GPU가 필요한지 표준 GPU가 필요한지에 따라 달라질 것입니다”라고 결론 내립니다.

Gemma 4도 성능이 떨어지기는 합니다 (28, 26, 24). 하지만 추가 공간을 거의 사용하지 않습니다 (여섯 개를 허용했을 때 약 2.8개 정도) 그리고 블로그가 다루지 않는 질문에 대한 답변을 절대 지어내지 않습니다. 참고로 Gemma 4는 정말 멋진 모델군입니다. 파인튜닝(finetuning)에 아주 좋은 선택지입니다.

다음은 무엇일까요

다음 단계는 소형 모델들이 이 특정 작업에 대해 성능을 개선하는 것입니다. 300 MB 크기의 모델이 모든 것을 알 필요는 없습니다. 단지 네 개의 구절을 읽고 그것들을 요약하거나 질문에 답하지 않는다고 말할 수 있어야 합니다. 이는 파인튜닝(fine-tuning) 문제처럼 들리며, 아마도 다음 게시물에서 다룰 내용일 것입니다.

또 다른 아이디어는 홈페이지 검색창입니다. 만약 이미 'ask my blog'에 모델을 로드했다면, 홈페이지가 자체적으로 아무것도 다운로드하지 않으면서 검색 기능을 개선하는 데 이 모델을 조용히 사용할 수 있습니다. 그동안은: 'ask my blog'에 무언가를 질문하고, 요약을 믿기 전에 제시된 구절들을 확인해 보세요.

이것은 petitgpt에서 영감을 받았습니다. 저는 MicroLLM lab의 코드를 재사용하지 않았습니다(저장소에는 어떤 라이선스인지 명시되어 있지 않습니다). 이 페이지는 transformers.js를 직접 기반으로 구축되었습니다. ↩︎

검색 증강 생성(Retrieval-augmented generation, RAG). 요약하자면, LLM이 추론을 수행하는 데 적절한 컨텍스트를 찾기 위해 검색 도구나 엔진을 사용하는 것입니다. 이는 Claude Code가 코드를 탐색하거나 ChatGPT가 웹을 검색할 때와 같습니다. 제가 가진 게시물 몇 개에 이 정도가 과분할까요? 절대요. 하지만 재미있습니다. ↩︎

무언가를 명명하는 것이 컴퓨터 과학에서 가장 어려운 일이죠, 그렇죠? ↩︎

남아있는 대부분의 의견 불일치는 다음 사항에 관한 것이었습니다:
어떤 종류의 잘못된 답변이었는지 (저는 장황한 헛소리를 비답변(non-answer)이라고 부를 것입니다. 심사위원은 단 하나의 꾸며낸 주장이라도 포함되면 이를 근거 부족(unsupported)으로 간주합니다). 충실성 여부에 대한 질문에 대해 심사위원이 저보다 두 번 더 엄격했고, 두 번 더 관대했습니다. 소형 모델과 나머지들 사이의 격차는 이 노이즈보다 훨씬 큽니다. ↩︎그중 두 개는 WebGPU에서만 작동합니다. CPU 관련 주의사항은 아래를 참조하세요. ↩︎

A

g2-standard-4

인스턴스(L4 하나)를 us-central1 지역에 온디맨드 방식으로, computeprices.com을 통해 2026년 10월 12일에 이용했습니다. ↩︎다만 Chipotle처럼 아무나 추론 비용 청구서를 쌓게 두지는 마세요. 더 나아가, 정적 사이트를 가지고 있다면 부디 Anthropic/OpenAI API 키를 거기에 넣지 마세요.