BGE-M3 Dense의 Recall@5는 0.80이었습니다. multilingual-e5-small의 0.733333보다 높았습니다. 점수만 보면 BGE-M3를 고르면 됐습니다. 그렇게 결정하지 않았습니다. 이 프로젝트의 검색기는 관광지에서 짧은 질문을 처리하는 API의 앞단에 놓입니다. 검색 품질뿐 아니라 상위 순위, 응답시간, no-answer...

검색 실패가 나오면 청킹부터 의심하기 쉽습니다. 나도 처음에는 child 크기나 overlap을 바꾸면 실패 사례가 줄어들 것으로 생각했습니다. 하지만 청킹을 바꿀 때마다 corpus와 검색 기준선이 함께 달라졌습니다. 이후 Dense, Hybrid, Reranker 결과도 같은 조건으로 비교하기 어려워졌습니다. 그래서 Retriever를 BM25로...

PDF에서 텍스트를 추출했다고 바로 RAG에 넣을 수 있는 것은 아니었습니다. 검색 결과가 맞더라도 답변에서 원문 페이지를 되찾지 못하면 citation을 만들 수 없었습니다. 반대로 페이지 번호만 남기고 문서 구조를 잃으면 같은 인물과 사건이 여러 장에 걸쳐 등장할 때 검색 단위가 흐려졌습니다. 그래서 전처리의 목표를 “텍스트를 많이 추출하는 것”...

초기 기록에는 한국사 도서 7권과 YouTube 자막을 함께 쓰고, BGE 계열 임베딩과 Hybrid Retrieval, 도메인 Reranker, Gemini 생성 모델까지 연결하는 구상이 남아 있습니다. 당시에는 파이프라인에 많은 기능을 넣는 것이 완성도라고 생각했습니다. 현재 저장소의 방향은 다릅니다. 음성 관광 앱 전체를 한 번에 만들지 않고,...

처음에는 서울 관광지에서 질문하면 바로 역사 이야기를 들려주는 음성 도슨트를 만들려고 했습니다. 경복궁 앞에서 “여기는 왜 지었어?”라고 물으면 장소를 알아보고, 짧은 설명을 음성으로 돌려주는 서비스였습니다. 막상 만들기 시작하니 음성보다 먼저 해결해야 할 문제가 보였습니다. 생성된 설명이 그럴듯하더라도 어느 책의 어느 부분을 근거로 했는지 찾을 수...

공부한 내용을 주제별로만 모아두면 금방 흩어졌습니다. 그래서 이번에는 개념을 어떻게 실습 가능한 설계 기준으로 바꿀 수 있는지에 맞춰 다시 묶어봤습니다. 처음에는 RAG, OCR, Agent, 평가 지표를 각각 따로 봤습니다. 그러나 작은 예제를 직접 만들어보면 질문이 바뀝니다. “이 개념이 무엇인가”보다 “이 개념을 어디에 붙여야 실패를 줄일 수 ...

LLM 서비스를 처음 볼 때는 모델 호출 API를 중심으로 생각했습니다. 그러나 작은 실습으로 흐름을 다시 만들어보니 실제 차이는 모델보다 데이터 흐름, 상태 관리, 저장소 분리, 평가 위치에서 더 크게 났습니다. 같은 LLM을 사용해도 원문을 어떻게 보관하는지, 검색 결과를 어떻게 남기는지, 평가를 어느 단계에서 수행하는지에 따라 서비스의 신뢰도가...

Agent를 공부하면서 처음에는 “LLM이 도구를 쓰면 Agent”라고 생각했습니다. 그러나 흐름을 직접 나눠보니 도구 호출은 시작일 뿐이었습니다. 실제로 중요한 것은 도구를 언제 호출할지, 결과를 어떻게 검증할지, 여러 역할을 나눌 때 latency와 비용을 어떻게 감당할지였습니다. flowchart LR W["Workflow<br/&g...

LLM 서비스 평가를 정리하면서 남은 생각은 “평가 지표가 많다”가 아니었습니다. 같은 출력도 무엇을 보려는지에 따라 지표가 달라진다는 점이었습니다. 요약 품질, 업무 리포트 품질, RAG 답변의 근거성을 볼 때는 평가 질문이 다릅니다. flowchart TD O["LLM Output<br/>요약, 리포트, QA 답변"] -->...

RAG 평가에서 가장 많이 헷갈린 부분은 “답변이 틀렸다”를 하나의 실패로 보는 습관이었습니다. 답변이 틀린 이유는 두 가지로 나뉩니다. 검색이 근거를 찾지 못했거나, 검색은 맞았지만 생성이 근거를 잘못 사용했을 수 있습니다. 이 둘을 나누지 않으면 개선 방향도 흐려집니다. flowchart LR Q["Question"] --> RET["...