최근 Anthropic은 Claude가 생성한 콘텐츠(텍스트)에 '워터마크'를 도입한다고 발표했다.많은 사람들은 워터마크를 눈에 보이지 않는 문자나 공백 문자를 콘텐츠에 몰래 심어두는 방식이라고 오해하는데, 실제로는 그렇지 않다.단순하게 설명하면, 텍스트 생성에서 워터마킹은 문체를 편향시키는 것과 비슷하다.Anthropic은 Claude 워터마크의 정확한 메커니즘을 공개하지 않았기 때문에, 어떤 방식으로 문체를 편향시키는지는 확실하지 않다.이번 글에서 텍스트 워터마크에 대해 간략히 소개하고자 한다. 왜 워터마크를 추가했는가?직접적인 이유는 EU AI 법 제50조이다.2026년 8월 2일부터 생성형 AI 시스템 제공자는 AI가 생성하거나 조작한 텍스트·이미지·오디오·영상을 기계가 읽고 판별할 수 있는 ..

노벨 물리학상 수상자 리처드 파인만은 스스로를 천재라기보다, '생각하는 법을 치열하게 훈련한 평범한 사람'에 가깝게 여겼다고 한다.그가 학문에서 뛰어난 성과를 낸 데에는 타고난 머리뿐 아니라, 어려운 개념에서 불필요한 것을 걷어내고 핵심을 보려 한 사고 습관도 한 요인이었을 듯하다.그는 남이 정리해 둔 답을 외우는 데 그치기보다, 원리를 직접 살펴보고 처음부터 다시 세워 보면서 자신이 정말 아는지 확인했다. 다음 문장은 그의 사고 기준을 잘 보여준다. "내가 직접 만들 수 없다면, 나는 그것을 이해한 것이 아니다 (What I cannot create, I do not understand)." 봤으니 안다고 넘기지 않고, 직접 만들어 낼 수 있을 때까지 파고든 것이다. 이런 태도는 그의 일하는 방식에서 ..

들어가며지식 관리 분야에서 가장 주목받는 방식 중 하나는 단연 개인 위키(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..