패밀리카를 검색어로 하여 6개 수집 도구를 돌려봤다 — Google이 막은 자리와 다음 학습 방향

이미지
패밀리카를 검색어로 하여 6개 수집 도구를 돌려봤다 — Google이 막은 자리와 다음 학습 방향 trend-scout 를 1년 운영했다. 다음 단계를 결정해야 할 시점이 왔다. 내 수집 도구를 한 단계 더 깊이 키울지, 아니면 더 넓게 가져갈지. 결정하기 전에 지금 가진 도구가 어디까지 풀어내고 어디서 막히는지 한번 측정해 볼 필요가 있었다. ​ 검색어를 “3인가족 패밀리카 추천”으로 잡았다. 여기에 사이트 6곳을 도구 6개로 돌려보는 매트릭스를 만들었다. 결과는 명확했다. Google을 통한 자료 수집은 6개 도구가 모두 실패했다. 반대로 Naver는 우회 도구 없이도 본문에 제품명이 9건 그대로 노출됐다. 이 결과가 다음 학습 방향을 정해줬다 — 깊이가 아니라 넓이. 이 글은 그 측정 과정과 거기서 본 것들을 정리한 글이다. 1. 지금의 trend-scout 구성과 측정 준비 trend-scout는 X·Threads·Google Trends 세 곳을 데이터 출처로 삼는다. 한 달에 비용은 0원, 유지 시간은 2~4시간 정도로 굴리는 사이드 수집기다. ​ 이전 글 엔드포인트는 죽는다 에서 정리한 운영 규율 세 가지가 있었다. 엔드포인트가 평균 2~3개월이면 죽는다는 점. 출처를 분산해야 한다는 점. 죽음 신호를 자동으로 감지해야 한다는 점. 1년 동안 굴리면서 얻은 학습이었다. ​ 다음에 어디로 학습을 끌고 갈지 후보가 둘 있었다. (깊이) 한 사이트에 우회 계층을 더 쌓는다 — TLS 위장, 브라우저 자동화, CAPTCHA 풀이 도구. (넓이) 출처를 더 넓힌다 — 한국 검색, 커뮤니티, 자동차 전문 사이트. 깊이 쪽으로 가려면 지금 도구가 어디서 막히는지부터 알아야 했다. 그래서 한국어 검색어를 정해 두고, 표준 사이트 6곳에 던져 도구 6개로 풀어 보는 시도를 했다. 측정 준비 검색어 : “3인가족 패밀리카 추천” 사이트 6곳 : Google 웹 검색, Google 이미지 ...

Benchmark가 측정한 건 모델이 아니라 채점기였다 — Honcho/Hindsight 3 라운드 측정 후기

이미지
내 환경(Hermes)의 메모리 provider 두 개(Honcho·Hindsight)를 3 라운드에 걸쳐 비교했다. 1차 10/10 만점, 2차 7점대, 3차 4점대로 점수가 압축됐다. 처음엔 “task가 어려워져서”라고 봤다. 직접 답변을 보니 다른 이유였다. 요약 : 점수 10 → 7 → 4 압축의 진짜 원인은 task 난이도가 아니라 regex scorer false positive. approval_boundary 3.5점 답변이 manual review 5.0이었고, 5.0점 답변엔 risky implications가 남아 있었다. wrapper guardrail 패치까지 진행한 후기. 이런 적 있다면 글이 도움이 된다 도구·모델 비교 글에서 점수가 비슷하게 나와 어느 게 더 나은지 판단 못 한 적이 있다. LLM 답변 채점할 때 regex나 키워드 매칭이 진짜 평가를 한다고 믿어본 적이 있다. benchmark가 모델 약점이 아니라 측정 기구의 약점을 드러내는 건 처음 봤다. 측정 setup — Hermes 안에서 Hermes는 내 1인 운영 자동화 환경이다. 컴포넌트는 다음과 같다. ALIVE : canonical source-of-truth. 프로젝트 상태·결정·산출물 기록 Hermes core memory : compact durable preferences Honcho lab profile : Plastic Labs의 오픈소스 메모리 라이브러리. user-agent modeling, boundary discipline 실험용 Hindsight lab profile : semantic recall, entity graph 실험용 (내 환경 자체 구성) default Discord gateway : 사용자 I/O 메인 채널 Honcho는 stateful agent용 외부 오픈소스다. 내 환경에서는 lab profile로만 띄워두고 default gateway는 별도 inference로 운영한다. 둘 다 ...

하네스 엔지니어링 측정 2편 — Claude에 AGENTS.md 명시 인용했더니 fail-fast가 강해졌다

1편(어제)에서 N=1로 측정해서 결론을 냈다. “Codex가 fail-fast 약하다”가 아니라 “AGENTS.md 비우면 Codex도 Claude도 똑같이 약하다”였다. 지적이 들어왔다. N=1은 우연일 수 있다. Claude에 AGENTS.md 명시 인용을 직접 해본 적은 없었다. 12회 측정해서 다시 확인했다. 결론은 더 단단해졌다. 그리고 1편이 놓친 변수 하나가 새로 보였다. 요약 : Codex × Claude × 하네스 0/강제 4 condition을 각 3회씩 12회 측정. 모델 효과는 거의 0(가로축 1.0 vs 1.0, 2.83 vs 2.5), 하네스 효과는 큼(세로축 1.0 → 2.5+). Claude도 AGENTS.md를 prompt에 명시 인용하면 fail-fast 1.0 → 2.5로 올라간다. 단 1편의 Claude 채점 “중”은 prompt position 효과(메인 세션 system prompt 자동 로드)였을 가능성이 새로 보였다. 1편이 명시한 5가지 한계 중 통제한 3가지 측정 1편 본문 끝에 한계 5가지를 적었다. 그 중 2편에서 통제 가능한 것은 3가지였다. Sampling 우연 미통제 (N=1) → 12회 측정으로 분산 확인 Prompt position 미분리 → C3 격리 환경 추가로 부분 분리 Claude에 AGENTS.md 명시 인용 미측정 → C4 condition으로 직접 측정 나머지 2가지(컨벤션 vs 코드 품질, 일반화)는 이번에도 미해소다. 측정 setup, 4 condition × 3회 = 12회 같은 명세 verify_published_post() 를 4 condition으로 각 3회씩 측정했다. Condition 모델 하네스 C1 Codex 없음 (AGENTS.md 비움) C2 Codex AGENTS.md 자동 로드 C3 Claude spec만, 격리 Task agen...