들어가며지식 관리 분야에서 가장 주목받는 방식 중 하나는 단연 개인 위키(Personal Wiki) 입니다.위키는 단순히 문서를 저장하는 것을 넘어, 개념 간 연결을 통해 지식을 복리로 쌓아가는 시스템입니다. 하지만 위키를 직접 운영해보면 생각보다 손이 많이 간다는 걸 깨닫게 됩니다.새 문서를 읽으면 기존 페이지를 업데이트해야 하고, 용어집을 관리해야 하며, 중복되거나 모순된 내용을 정기적으로 점검해야 합니다. 교차 참조까지 직접 연결하다 보면 "지식을 쌓는 것"보다 "위키를 유지하는 것"에 더 많은 시간을 쓰게 됩니다. 결국 위키는 항상 같은 이유로 방치됩니다. 유지보수가 너무 귀찮아서. 그런데 최근 Andrej Karpathy가 이 귀찮은 과정을 AI에게 통째로 넘기는 아이디어를 공개했습니다. 바로 ..

들어가며AI 에이전트를 개발하고 있다면 누구나 공감할 고민이 있습니다. "이게 정말 개선 된 게 맞나?" 단순한 챗봇을 넘어 도구를 사용하고 복잡한 작업을 수행하는 '에이전트'는 그 자율성 때문에 평가하기가 매우 까다롭습니다. 최근 Claude를 만든 Anthropic 팀이 자신들의 경험과 고객사(Descript, Notion 등)의 사례를 바탕으로 AI 에이전트 평가(Evaluation) 방법론을 상세히 공개했습니다. 이번 글은 그 내용을 바탕으로 Anthropic이 제시한 AI 에이전트 평가 방식이 어떤 고민에서 출발했고, 어떤 접근들을 사용하고 있는지 가볍게 정리해보려 합니다. AI 에이전트 평가, 생각보다 까다로운 이유요즘 AI 에이전트(Agent)가 여기 저기서 주목받고있습니다. 자율성도 ..

들어가며최근 공개되는 오픈소스 언어모델들의 스펙 시트를 살펴보면, 입력 토큰의 최대 길이가 128k에서 256k에 달하는 경우를 흔히 목격하게 됩니다. 하지만 30B 이하의 매개변수를 가진 경량 모델들이 과연 해당 길이에서 유의미한 정보 처리 능력을 갖추고 있는지에 대해서는 늘 의구심이 뒤따랐습니다. 특히 한국어 환경에서의 실효성은 검증된 바가 적기에, 개인적인 궁금증을 해소하고자 시중의 모델들을 대상으로 직접 실험을 수행하였습니다. 테스트 설계 및 대상테스트는 아래 github repo를 참고하였으며, 데이터셋은 한국어로 새로 생성하였고, 코드 일부를 수정하여 테스트를 진행하였습니다. LLMTest_NeedleInAHaystack GitHub - gkamradt/LLMTest_NeedleInA..

Reranker, Query Expansion, Hybrid Search는 정말 필요한가?이전 글까지 해서 Chunking → Embedding이라는 RAG 검색 파이프라인의 핵심 요소들을 하나씩 살펴봤다.원래는 이다음으로 “검색 결과를 기반으로 실제 답변을 생성했을 때 품질이 얼마나 달라지는지”까지 테스트해보려 했는데솔직히 말하면, "굳이 답변생성 비교까지 해야 의미가 있을까?"라는 생각이 들었다. 이미 검색 단계에서 성능 차이가 명확히 갈리고,답변 생성은 결국 LLM 성능 + 프롬프트 영향이 너무 커서 검색 전략 자체의 비교가 흐려질 가능성이 컸다. 그래서 이번 글에서는 RAG의 검색 품질을 마지막으로 끌어올리는 단계에 집중하고 이번 시리즈를 마무리하려고한다.RerankingQuery Transfer..

지난 글에서 '요리 재료 손질'에 비유했던 Chunking을 통해 데이터를 잘 썰어두었다면, 이제 이 재료들을 어떤 기준으로 분류하고 창고(Vector DB)에 저장할지 결정할 차례다. RAG의 두 번째 핵심 요소, 바로 Embedding이다. 좋은 임베딩은 문서와 질문을 의미 공간에서 정교하게 매칭하여 관련 컨텍스트를 정확히 찾아냅니다. 이번 글에서는 여러 상용/오픈소스 임베딩 모델을 비교한 MRR / Precision@K 테스트 결과를 기반으로 모델별 특성과 활용 방향을 분석합니다. 테스트는 이전과 동일한 문서/질문 셋에 대해 vector 검색 + LLM-as-a-judge 평가로 진행됨. 테스트 결과 요약이번에도 역시 Gemini 2.5 Flash를 Judge로 활용하여, 검색된 결과가 질문에..

지난 글에이어서 이제 본격적으로 RAG를 구성하는 요소를 하나하나 뜯어볼 차례다. 첫 번째는 바로 Chunking이다. RAG 파이프라인에서 가장 앞단에 있고, 개인적으로는 “Garbage In, Garbage Out을 가장 먼저 결정짓는 요소” 라고 생각한다. 아무리 모델이 좋아도, 아무리 검색 성능이 좋다고 해도, 문서가 이상하게 잘려 있으면 답은 없다. 이번 글에서는 가장 단순한 chunking 기법부터 비교적 최신(?)에 공개된 기법까지 다양하게 비교하고 분석해 보고자 한다. Chunking, 왜 중요할까?RAG 파이프라인에서 Chunking을 비유하자면 요리 재료 손질에 가깝다.감잣국을 끓이는데 감자를 통째로 넣으면→ 속도 안 익고, 먹기도 불편하다 (Too Large Chunk)반대로 감자..