Tag: Empirical
All the articles with the tag "Empirical".
-
임베딩 필터를 걷어내니, 중복이 오히려 더 많이 잡혔다
LLM이 만든 형제 노트의 중복을 잡던 임베딩 후보 필터를 걷어내고 노트 전체를 한 번에 LLM에 맡겼다. 허브 노트 예외 조항 하나로 정밀도가 55%에서 100%가 됐고, 깨끗하다던 묶음에서도 중복이 나왔다.
-
임베딩 모델을 바꾸니 순서가 뒤집혔다
OpenAI 임베딩 모델을 text-embedding-3-small에서 large로 바꾸자, 코사인 유사도 0.72~0.80에 뒤섞여 있던 진짜 중복 문단과 우연히 비슷한 문장의 순서가 뒤집혔다.
-
LLM이 만든 형제 노트끼리 같은 문단을 그대로 베끼고 있었다
Obsidian 플러그인 테스트를 실제 기사로 바꾸자, LLM이 기사 한 편으로 만든 형제 노트끼리 같은 문단을 그대로 복사하는 버그가 드러났다. 임베딩 기반 중복 탐지도 이 중복은 못 잡았다.
-
검증은 다른 쌍으로 했는데, 원래 그 사례는 다시 안 봤다
Obsidian 플러그인의 LLM 병합 판단 프롬프트에서 오탐을 고치고 GitHub 이슈까지 닫았는데, 정작 오탐을 일으켰던 원래 사례는 그 사이 한 번도 다시 테스트하지 않았다. 며칠 뒤 실제 vault 전체 조건으로 돌려보니 판단이 뒤집혔고, 실제로 병합해보니 원래 판단 자체가 틀렸을 가능성이 높았던 기록.
-
리스트 밀도 상위 4개 중, 서브에이전트가 2개를 놓쳤다
Claude Code 서브에이전트에게 맡긴 전수 감사가 56개 파일 중 2개를 CLEAN으로 잘못 보고했다. 불릿 리스트가 많은 파일에서 '다 읽었다'는 판정이 항목별 대조가 아니라 뭉뚱그린 훑어보기였다는 걸 프롬프트 A/B 테스트로 확인하고, 체크리스트를 강제하는 프롬프트로 고친 기록.
-
틀렸는데, 확신은 0.9였다
TypeSafe Jev의 오픈소스 재현판 Laya를 Obsidian 플러그인의 중복 노트 판단에 붙여봤다(Jev는 계정이 열리지 않아 문서로만 비교). CPU 속도와 정확도 78%, 파인튜닝 가능성까지 실측해 보니, 진짜 문제는 틀린 답에 0.9 confidence를 붙이는 캘리브레이션 붕괴였다.
-
웹 검색을 언제 같이 쓸지 설계하다가, 매번 질문 하나에 무너졌다
보관함(vault)에 답이 있어도 최신 정보가 필요하면 웹 검색을 같이 쓰는 기능을 설계한 대화다. 자동 트리거, 날짜 비교, 3단계 호출, 인용 표시 활용까지 낸 제안마다 질문 하나에 무너졌고, 결국 제일 단순한 답으로 돌아왔다. 코드는 한 줄도 안 쓴 순수 설계 논의였다.
-
몇 주 뒤, 그 감사 장치가 못 보는 경우를 찾았다
예전에 32번 중 32번을 다 맞혔던 병합 감사 장치가, 실전에서 상위 개념 노트와 그 하위 유형 노트를 동일 대상으로 오판했다. 원인은 판단력이 아니라 설계 자체 — 그 감사는 처음부터 이 종류의 오판을 잡도록 만들어진 게 아니었다.
-
30분에서 1분까지, 얼마나 줄일 수 있는지 끝까지 밀어봤다
근본 원인은 이미 잡았으니 이제 최적화 차례였다. 휴식을 절반씩 줄여나가면서, 동시에 이미 두 IP를 같이 쓰고 있던 구조를 그대로 병렬로 돌려봤다. 30분 걸리던 걸 13분까지 줄이는 동안, 내가 놓칠 뻔한 걸 두 번 다 사용자가 먼저 잡아냈다.
-
가장 많이 죽던 자리를 그대로 두고 다시 돌렸는데, 이번엔 다 살았다
21개 타깃을 3~4개씩 6배치로 쪼개고 배치 사이에 30분씩 진짜로 쉬어봤다. 매번 거의 전멸하던 그룹을 일부러 그대로 마지막 배치에 남겨뒀는데, 이번엔 그 배치까지 포함해서 21개 타깃 전부 403이 단 한 건도 없었다.