#Ollama
14개의 포스트
뉴스에서 육하원칙 뽑기 — 자르기·쓰기·고르기, 한국어 기사 72건으로 짠 추출 설계도
기자는 기사 첫 문장에서 여섯 질문에 답합니다. 누가, 무엇을, 언제, 어디서, 왜, 어떻게. 그걸 기계가 꺼내게 하는 손은 2026년에 네 종류입니다. 독해 모델은 자르고, 임베딩은 찾고, LLM은 쓰고, 판정 모델은 고릅니다. 연합뉴스 7개 섹션의 당일 기사 60건과 네이버 뉴스 12건, 합쳐 72건 432칸에 같은 정의서를 주고 스무 가지가 넘는 조합을 돌렸습니다. KorQuAD 독해 모델은 '이 사건의 주체는?' 같은 범용 질문에 '다소', '이미'를 잘라 와 평균 0.18에 그쳤고, 사고를 끈 Gemini 3.8 Flash가 0.86, 로컬 Qwen3.5 9B가 0.69였습니다. 판정 모델에게 후보 중 하나를 고르게 하면 정답이 후보 안에 있는데도(상한 0.9 이상) 단독 쓰기보다 낮았습니다. 반대로 '기사에 이유가 명시돼 있는가'를 따로 물으면 Nimble이 AUROC 0.85로 가려냈고, 이것을 Flash 뒤에 붙이자 '왜'가 0.73에서 0.79로, 쓰기 모델 셋의 다수결로는 0.85로 올랐습니다. 이 과제의 절반은 답을 찾는 일이고 나머지 절반은 '없다'고 말하는 일입니다. 방법별 점수표·기사별 탐색기·판정 앙상블·부재 탐지·파이프라인 설계기 위젯 5개와 삽화 6장.
지도와 심판 — 임베딩과 판정 모델, 언제 무엇을 쓰나: 업무 12가지와 조합 실측 (로컬 모델 실측 3편)
1편에서 임베딩 모델 아홉 개를, 2편에서 판정 모델 세 개를 같은 맥에서 한국어로 쟀습니다. 3편은 그 둘을 한 자리에 놓고 묻습니다. 어느 일에 어느 쪽을 쓰나. 임베딩은 지도입니다. 수백만 건 중 어디를 볼지 알려 주고, 좌표를 저장해 두고 재사용합니다. 판정 모델은 심판입니다. 눈앞의 후보 몇 개 중 무엇이 맞는지, 규정에 비춰 되는지 안 되는지를 확률과 함께 말합니다. 이 글은 네 가지 질문으로 두 자리를 가르는 진단표, 고객 문의 라우팅·환불 규정·감성 점수·인젝션 탐지·도구 호출 가드·민원 배정·LLM 라우팅 일곱 업무의 실측(판정 모델 세 개 대 임베딩 유사도 대 27B 채팅 모델), 코어닷투데이가 실제로 만나는 업무 열두 가지의 추천 조합·예시·함정, 그리고 '작은 임베딩 + 판정 모델이 큰 임베딩을 따라잡는가'를 1편의 모델 다섯으로 확인한 조합 실험을 담았습니다. 마지막은 메모리·지연·비용·데이터 반출을 한 표로 놓은 운영 체크리스트입니다. 인터랙티브 4개와 삽화 6장.
원본 대 복제품 — Jev와 tev1·Nimble을 같은 한국어 문제 5,000개로 직접 붙이다 (로컬 모델 실측 4편)
2편에서 로컬 판정 모델 tev1·Nimble을 한국어로 쟀을 때 비교 대상인 Jev의 수치는 6편에서 빌려 온 것이었습니다. 코퍼스도 589건이었고 묻는 방식도 달랐습니다. 이 글은 그 빚을 갚습니다. TypeSafe의 Jev 1.13 API를 같은 날, 같은 660건·85문항·625건·93문항에, 글자 하나 다르지 않은 같은 프롬프트로 직접 돌려 로컬 모델 셋과 나란히 놓았습니다. 리랭커 자리(쌍별·한꺼번에, 지시문 두 가지), 작은 임베딩 다섯에 붙인 조합, 분류 625건, 실무 과제 7종, 보정 곡선, 그리고 '둘이 같은 문항을 틀리는가'까지 봤습니다. 결론은 둘입니다. 원본은 묻는 방식을 가리지 않는데 복제품은 가린다. 그리고 복제품이 원본의 자리를 대신하는 과제와 못 대신하는 과제가 분명히 나뉜다. 비용·지연·데이터 반출을 한 계산기로 놓고 어느 쪽을 고를지로 끝냅니다. 인터랙티브 5개와 삽화 4장.
글자를 쓰지 않는 로컬 모델 — Ollama 판정 모델 tev1·Nimble을 한국어로 시험하다 (로컬 모델 실측 2편)
ollama list에 낯선 이름 둘이 있었습니다. tev1:4b와 nimble. ollama show를 쳐 보니 Capabilities에 embedding도 completion도 아닌 'decision'이 적혀 있고, 시스템 프롬프트는 '선택지 중 하나를 고르고 글자 하나만 돌려줘라'였습니다. 9월 15일 TypeSafe가 Jev를 내놓은 뒤 2주 만에 Bespoke Labs(Nimble 9B)와 Together AI(tev1 4B·0.8B)가 열린 가중치로 같은 모양의 모델을 냈고, 9월 29일 Ollama가 /v1/systemone 엔드포인트로 그것을 받아들였고, 10월 1일 클라우드플레어가 27B짜리 Clef를 보탰습니다. 이 글은 그 판정 모델이 무엇이고 왜 빠른지(한 번의 전방 패스에서 선택지 글자의 확률만 읽는다)를 그림으로 풀고, 세 모델의 출신과 학습 레시피를 뜯어본 뒤, 1편과 같은 한국어 코퍼스로 리랭커 자리(85문항 × 10문서)와 분류 자리(625건)에 세워 TypeSafe의 Jev(4편에서 같은 조건으로 직접 실측), 임베딩 이웃 투표, 27B 채팅 모델과 비교했습니다. 결론은 '9B Nimble은 한국어로도 Jev의 자리를 대신하고, 0.8B는 아직 아니다'입니다. 확률이 얼마나 믿을 만한지, 한 번 호출에 몇 ms인지, 한국어 문의 라우팅·규정 적용·감정 점수 같은 실무 과제 7종의 성적도 함께 적었습니다. 인터랙티브 6개와 삽화 7장.
맥 한 대에 임베딩 모델 아홉 개 — Qwen3·BGE-M3·Nomic·Arctic·EmbeddingGemma 1·2를 한국어로 다시 재다 (로컬 모델 실측 1편)
10월 1일 다섯 모델을 쟀던 글 뒤로 열흘 사이에 많은 것이 바뀌었습니다. 구글이 EmbeddingGemma 2를 냈고, Ollama 0.40이 애플 실리콘에서 MLX 러너를 기본으로 켰고, 같은 맥에 올라 있는 임베딩 모델이 아홉 개가 됐습니다. 이 글은 그 아홉 개 — Qwen3-Embedding 8B·4B·0.6B, BGE-M3, Nomic Embed v2 MoE, Snowflake Arctic Embed 2.0, EmbeddingGemma 300M, EmbeddingGemma 2 740M·440M — 를 코어닷투데이 문서 660건과 한국어 질문 85개로 같은 조건에서 다시 쟀습니다. 모델마다 '무엇을 하려고 만든 모델인지'를 뼈대(인코더·디코더·온디바이스) 기준으로 쉽게 풀고, 결과에서 가장 놀라운 한 줄 — 308M짜리 1세대 EmbeddingGemma가 4B 모델과 같은 점수를 냈고 2세대는 그보다 낮았다 — 이 왜 나왔는지, 접두어 한 줄이 0.08을 바꾸는 이유, 같은 문서를 토크나이저가 얼마나 다르게 쪼개는지, 벡터를 256차원으로 잘라도 되는지를 실제 값으로 보여 줍니다. 인터랙티브 7개와 삽화 6장. 2편은 글자를 쓰지 않는 판정 모델 tev1·Nimble, 3편은 두 종류를 언제 어떻게 쓰나입니다.
'지난달 글'은 누가 계산하나 — 시간 표현과 검색, 계산하게 할 것인가 고르게 할 것인가 (한국어 검색 스택 11편)
8편에서 '2026년 4월에 올라온 RAG 글'은 정규식 몇 줄로 풀렸습니다. 날짜가 숫자로 적혀 있었기 때문입니다. 그런데 사람은 그렇게 묻지 않습니다. '지난달 RAG 글', '올봄에 쓴 보안 글', '도커 첫걸음 시리즈가 나온 다음에 쓴 Git 글'. 이 글은 오늘을 2026년 10월 14일로 고정하고 이런 질문 38개로, 시간 표현을 날짜 범위로 바꾸는 일을 누구에게 맡겨야 하는지 쟀습니다. 정규식은 하나도 읽지 못했습니다. 로컬 LLM은 날짜를 직접 계산해 nDCG@10 0.735까지 올렸지만 '두 달 전'을 하루짜리 날짜로 읽어 결과가 텅 빈 질문을 만들었습니다. Jev에게 글마다 날짜를 판정시키면 '지난달'은 완벽했지만 '지난 분기'는 56%였습니다. 같은 Jev가 코드가 펼쳐 준 기간 후보 20개 중에서 고르게 하자 26개를 전부 맞혔고, 사건 기준 질문은 검색이 기준 글을 찾게 한 설계가 0.832로 상한선(0.851)에 다가갔습니다. 계산은 코드가, 판단은 Jev가, 찾기는 검색이. Jev 2,627회 호출에 0.06달러. 인터랙티브 4개와 삽화 7장.
'빼고'를 공짜로 고칠 수 있나 — 임베딩 트릭 대 Jev, 한국어 제외 질문 50개 실측 (한국어 검색 스택 9편)
8편에서 '쿠버네티스는 빼고 도커만'이라고 물으면 임베딩이 상위 10개의 절반을 쿠버네티스 글로 채운다는 것을 봤고, Jev가 그것을 고쳤습니다. 그런데 8월과 9월에 나온 두 논문(EXCISE, E-SENS)은 학습도 큰 모델도 없이 이 문제를 줄이는 방법을 내놓았습니다. 이 글은 한국어 제외 질문 50개(표지어가 분명한 30개, 돌려 말한 10개, 두 가지를 동시에 빼는 10개)로 그 공짜 방법들과 Jev를 정면으로 비교했습니다. 가장 큰 한 걸음은 놀랍도록 단순했습니다. 질문에서 빼라는 말을 떼어 내기만 해도 nDCG@10이 0.245에서 0.555로 뛰었습니다. 빼라는 단어가 든 글을 아래로 내리는 공짜 규칙은 0.676으로 8편의 Jev 방식(0.672)과 같은 자리까지 올라왔습니다. 하지만 그 규칙은 평범한 질문을 제외 질문으로 오인했을 때 정답을 100위로 보내는 위험도 있었습니다. 글자 강등으로 정리한 상위 20개만 Jev가 판정하는 조합이 0.790으로 가장 높았지만 강등의 위험을 그대로 물려받았고, 원래 질문과 뗀 질문의 후보를 합쳐 Jev에 주면(0.759) 평범한 질문을 하나도 해치지 않았습니다. Jev 3,405회 호출에 0.1달러. 인터랙티브 5개와 삽화 7장.
도구는 넷, 자리는 넷 — BM25·임베딩·Jev·코드를 적재적소에 쓰는 한국어 검색 실측 (한국어 검색 스택 8편)
6편에서 Jev는 리랭커로 강했고, 7편에서는 환각 검문소로 강했습니다. 그렇다면 검색의 모든 단계를 Jev에 맡기면 될까요? 이 글은 한국어 질문 134개를 다섯 가족(키워드·의미·제외 조건·두 주제·날짜·카테고리)으로 나눠 BM25, 임베딩 둘, 하이브리드, Jev, 그리고 정규식 몇 줄짜리 코드 필터를 열세 가지 방식으로 조합해 실측했습니다. 질문의 종류가 바뀌면 이기는 도구가 바뀌었습니다. '쿠버네티스는 빼고'라고 하면 임베딩과 BM25는 쿠버네티스 글을 상위 10개의 절반쯤 가져왔고 Jev가 그것을 19%로 줄였습니다. 날짜 질문에서는 Jev가 날짜 판정 807쌍을 전부 맞혔는데도 코드 필터에 졌습니다. 판정이 아니라 후보가 문제였기 때문입니다. 각 도구를 제자리에 둔 설계는 모든 질문에 Jev를 쓰는 방식보다 점수가 높으면서 Jev 호출은 40%였습니다. Jev 9,521회 호출에 0.26달러. 인터랙티브 5개와 삽화 7장.
임베딩은 '아니다'를 못 읽는다 — Jev를 RAG 환각 검문소에 세우다 (한국어 검색 스택 7편)
임베딩 모델은 '매출이 30% 늘었다'와 '매출이 30% 줄었다'를 거의 같은 문장으로 봅니다. 검색에는 맞는 판단이지만, RAG 답변의 마지막 관문에서는 치명적입니다. 이 글은 6편에 이어 TypeSafe의 Jev를 한국어 검색 파이프라인의 새 자리, 답변 뒤의 '환각 검문소'에 세웁니다. 코어닷투데이 블로그 문단 87개로 참 주장 257개와 숫자·방향·주체를 바꾸거나 없는 사실을 덧붙인 거짓 주장 344개를 만들고, 임베딩 둘·크로스 인코더·NLI 모델·로컬 LLM 둘·Jev에게 같은 601쌍을 판정시켰습니다. 참 주장의 90%를 통과시키는 임계값에서 BGE-M3 코사인은 숫자를 바꾼 거짓의 3%만 잡았고, Jev는 100%를 잡았습니다(AUROC 0.995). 0.3B NLI 모델이 의외의 복병이었고(0.959), 숫자를 1만 바꿔도 잡던 Jev는 문서의 숫자로 계산해야 하는 주장에서 약해졌습니다. 601번 검문에 0.021달러. 인터랙티브 7개와 삽화 8장.
임베딩 다섯과 판정 모델 하나 — TypeSafe Jev를 한국어 검색 파이프라인에 세워 보다 (한국어 검색 스택 6편)
지난 특집에서 TypeSafe의 Jev를 '글자를 포기한 모델'이라고 소개했습니다. 벡터도 문장도 내놓지 않고, 상태와 질문을 받아 확률이 붙은 결정만 돌려주는 모델입니다. 그렇다면 임베딩 모델과 비교할 수 있을까요? 같은 자리에 놓으면 안 됩니다. 임베딩은 '문서 100만 개 중 어디를 볼까'를 정하고, Jev는 '이 열 장 중 어느 것이 답인가'를 판정합니다. 이 글은 그 자리를 정확히 나눈 뒤, 1~5편의 한국어 코퍼스(589건, 질문 85개)로 Jev를 검색 파이프라인의 세 자리에 세워 실측했습니다. 리랭커로는 8B 임베딩의 상위 10개를 0.889에서 0.929로 올렸고(같은 자리에서 568M 크로스 인코더는 0.864로 떨어뜨렸습니다), 한국어 지시문이 영어보다 조금 더 좋았고, 확률은 대체로 보정돼 있었고, 4,213번 호출에 0.16달러가 들었습니다. 반면 카테고리 분류에서는 임베딩 이웃 투표가 이겼습니다. 인터랙티브 5개와 삽화 10장.
마트료시카 임베딩 — 벡터를 앞에서부터 잘라도 되는 이유와, 잘랐을 때 실제로 남는 것 (한국어 검색 스택 3편)
Qwen3-Embedding-8B의 벡터는 숫자 4,096개입니다. 5,000만 청크를 float32로 저장하면 벡터만 819GB입니다. 그런데 이 벡터의 앞 256개만 남기고 나머지를 버려도 검색 품질의 93%가 남는다면? 그것이 마트료시카 임베딩입니다. 2022년 논문 「Matryoshka Representation Learning」이 제안하고 OpenAI text-embedding-3, Nomic v2, Qwen3 Embedding이 채택한 이 기법은 '중요한 정보를 벡터의 앞쪽에 몰아넣도록' 학습해, 러시아 인형처럼 큰 벡터 안에 작은 벡터가 들어 있게 만듭니다. 이 글은 원리를 장난감 모형으로 손에 잡히게 설명하고, 같은 한국어 코퍼스로 Qwen3 4B·8B와 Nomic v2를 32차원까지 잘라 가며 잰 실측 곡선, 저장 비용 계산기, 그리고 '짧게 걸러서 길게 고르는' 두 단계 적응형 검색이 전체 차원의 품질을 얼마나 되찾는지를 보여 줍니다. 인터랙티브 4개와 삽화 7장.
키워드와 의미, 둘 다 쓴다 — BM25·벡터·RRF·리랭커, 논문과 실측으로 보는 하이브리드 검색 (한국어 검색 스택 2편)
원문 메모의 그림은 이랬습니다. BM25와 벡터 검색을 나란히 돌리고, 결과를 RRF로 합치고, 리랭커로 다시 고른다. 이 글은 그 그림의 각 칸을 논문과 실측으로 채웁니다. 2009년 SIGIR의 두 쪽짜리 논문이 제안한 RRF는 점수 대신 등수만 쓰는 단순한 공식인데 왜 통하는지, k=60은 어디서 왔는지, 2023년 TOIS 논문은 왜 '점수 융합이 RRF보다 낫다'고 했는지, 2025년의 '약한 고리' 발견은 무엇인지. 그리고 1편의 한국어 코퍼스로 직접 재 보니, 등가중 RRF는 벡터 단독보다 오히려 나빴고 이유는 BM25가 약한 고리였기 때문이었습니다. 반면 강한 임베딩 둘(Qwen3-8B + BGE-M3)을 RRF로 합치자 어느 쪽 단독보다 좋아졌습니다. 리랭커는 '따로 읽고 비교'하는 바이 인코더와 '같이 읽고 판정'하는 크로스 인코더의 차이로 풀고, 로컬 LLM을 리랭커로 써서 상위 10개의 순서가 얼마나 바뀌는지 잽니다. 인터랙티브 5개와 삽화 8장.