TL;DR

  • 자유 형식 프롬프트와 LLM 작성 스킬은 성능을 악화시킬 수 있지만, LLM이 도메인 특화 언어(DSL)를 편집하고 이를 실제 설정이나 작업 형식으로 변환하는 방식은 효과적임.
  • captain-hook은 사용자의 수정 내용을 기록해 DSL 규칙으로 만들고 Claude Code 훅에 반영하는 지속 개선 루프를 구현함.
  • Aneta의 컨텍스트 컴파일러는 통합 중간 표현(IR)에 캐시 인식 최적화를 적용해 비용·품질·속도 목표에 맞춰 LLM 입력을 생성함.
  • 이미지 포함 여부를 매번 사이드카 LLM에 묻는 대신, 사이드카가 작성한 DSL 함수를 실행하면 정확도를 대부분 유지하면서 응답 지연을 약 4,100ms에서 20ms로 줄일 수 있음.
  • 제안된 접근법은 LLM의 코드 작성 능력을 활용해, 자연어 판단과 실제 시스템 동작 사이를 작고 검증 가능한 DSL로 연결함.

DSL로 훅 규칙을 편집하는 지속 개선 루프

  • LLM이 자기 프롬프트를 자유 형식으로 작성하게 하는 방식은 이미 여러 차례 문제가 입증됐고, LLM이 작성한 스킬도 결과를 악화시킴. 반면 다음 토큰 예측 모델은 코드 작성에 강점을 보임.
  • 다른 영역의 작업에 LLM을 적용할 때 사용하는 패턴은 현재 상태를 DSL로 표현하고, LLM이 DSL을 조작한 뒤 결과를 원래 영역으로 변환하는 방식임. 이 패턴은 해당 영역 내부 작업에도 효과적임.
  • captain-hook은 대화 기록을 살펴 사용자가 수정한 내용을 찾고, 그 규칙을 DSL로 기록해 Claude Code 훅으로 변환하는 지속 개선 루프를 제공함.
  • 훅은 .claude/settings.json의 중첩된 JSON에 저장되지만, 모델은 JSON을 직접 수정하지 않고 hooks.py의 간단한 DSL만 편집함.
  • 예를 들어 rm 명령을 막고 trash를 사용하도록 안내하거나, 저장소 루트에서 pnpm install을 실행하지 못하게 하고 워크스페이스로 이동하도록 안내하는 규칙을 표현함.
  • DSL 규칙을 다시 변환하면 해당 훅이 settings.json에 기록됨.
  • 사용자가 저장소 루트에서 pnpm install을 실행하지 말라고 지시하면, 세션 종료 시점에 검토기가 규칙 후보를 확인함. 검토기는 사용자의 지시를 곧바로 규칙으로 확정하지 않고 계속 집계함.

컨텍스트 컴파일러의 통합 표현과 최적화

  • Aneta의 컨텍스트 컴파일러는 데이터·프롬프트·예시를 통합 중간 표현(IR)으로 나타내고, 해당 IR에 캐시 인식 최적화 패스를 적용한 뒤 호출 대상 LLM에 맞는 형식으로 출력함.
  • IR을 구성할 때 각 컨텍스트 조각을 상세형과 축약형 모두로 렌더링하는 클로저를 캡처함. 최적화 패스는 표준 압축 기법과 함께 두 표현 중 하나를 선택함.
  • 각 패스는 최적화 목표에 따라 토큰 절감량과 캐시 무효화 비용을 비교함. 목표는 비용, 품질, 속도 또는 이들의 선형 조합임.
  • 예시 입력에서는 새 도구 결과를 축약해 660토큰을 절약하고 캐시 손실은 없으며, 예시와 표를 축약하면 3,520토큰을 절약하는 대신 캐시 토큰 7,884개를 잃음. 해당 턴에 필요하지 않은 그림 1·2를 24토큰짜리 설명으로 바꾸면 2,898토큰을 절약하고 캐시 토큰 3,584개를 잃음.
  • 비용 최적화는 캐시 토큰이 새 토큰보다 훨씬 저렴하므로 캐시를 건드리지 않는 패스만 실행함. 요청별 수치는 다음과 같음.
  • 최적화 전: 전체 9,464토큰, 캐시에서 읽은 토큰 8,564개.
  • 비용(COST): 전체 8,804토큰, 캐시에서 읽은 토큰 8,564개.
  • 품질(QUALITY): 전체 6,566토큰, 캐시에서 읽은 토큰 4,980개.
  • 속도(SPEED): 전체 2,386토큰, 캐시에서 읽은 토큰 680개.
  • 이미지 최적화도 중요한 대상임. 이미지는 과학 질의에 필요한 경우가 많고 OCR만으로는 충분한 정확도를 얻기 어렵지만, 이미지를 무조건 포함하면 컨텍스트가 커지고 품질이 저하됨.
  • 속도 또는 품질 모드에서는 컴파일러가 이미지를 선택적으로 제외하고, 이후 필요하다고 판단한 LLM이 이미지를 요청할 수 있는 도구를 제공함.

이미지 재전송 비용과 포함 판단

  • 이미지를 매 턴 다시 보내는 비용은 큼. 1,000×1,000픽셀 그림은 36×36 패치, 즉 1,296토큰으로 처리됨.
  • 매 3턴마다 새 그림이 추가되는 9턴 대화에 그림 3개가 있다면, 모든 그림을 매번 재전송하는 방식은 23,328토큰, 각 턴에 필요한 그림만 보내는 방식은 11,664토큰을 사용함. 모든 그림을 재전송하면 토큰 비용이 2배임.
  • 마지막으로 그림을 언급한 시점 같은 간단한 휴리스틱은 심층 연구에서 빠르게 한계를 드러냄. 매 턴 결정을 내리는 Haiku급 이하의 소형 사이드카 LLM은 품질 모드에서 예상보다 잘 작동하지만, 속도 모드에는 지연이 지나치게 큼.
  • 사이드카의 판단을 분석하면, 대화의 정적 요약이 주어졌을 때 그림 포함 여부는 전송할 메시지에 대한 순수 함수로 표현할 수 있음.
  • 10개 메시지 예시에서 “메시지 또는 직전 두 메시지에 ‘chart’가 있으면 그림을 포함”하는 휴리스틱은 3건을 틀리고 메시지당 1ms 미만이 걸림. 사이드카는 10건 모두 맞히지만 메시지마다 약 4,100ms가 추가됨.

사이드카가 작성하는 DSL 함수

  • 속도 모드에서 그림 포함 여부를 결정하기 위해 사이드카 LLM에 작은 함수를 작성하게 하고, 제한된 헬퍼를 제공함.
  • 사용할 수 있는 헬퍼는 자연어 추론 점수(nli_scores), 텍스트 유사도(text_similarity), 텍스트 개체(text_entities)와 토큰(text_tokens) 추출, 일반 LLM 호출(call_llm), 지정된 형식의 LLM 호출(call_llm_typed)임.
  • 사이드카는 이미지마다 메시지 점수 함수를 한 번 작성하고, 샌드박스는 실행할 수 없는 코드를 반환함. 첫 초안은 중첩 함수 bonus()를 포함해 거부됐고, 사이드카가 보너스 계산을 함수 안에 직접 넣은 두 번째 초안은 통과함. 결과 함수는 15줄에서 11줄로 줄어듦.
  • 실제 점수 함수는 메시지와 이미지 설명 사이의 유사도 및 추론 점수를 각각 0.5 가중치로 결합함. 메시지에 chart, graph, data 중 하나가 있으면 점수에 15점을 더하고, 최종 점수는 최대 100점으로 제한함.
  • 점수가 65점 이상이면 그림을 포함함. 예를 들어 “which phase dominates in the division chart?”는 유사도 0.625, 추론 점수 0.5로 기본 점수 56점을 얻고, chart 가산점 15점을 받아 71점으로 그림 포함 기준을 넘음.
  • 예시 메시지 점수는 다음과 같음.
  • “which phase dominates in the division chart?”: 71점, 포함.
  • “pull the raw data behind the bar chart”: 96점, 포함.
  • “compare that to the s bar”: 56점, 제외.
  • “summarize the assay protocol”: 18점, 제외.
  • “cite the methods section”: 12점, 제외.
  • 각 이미지가 대화에 전송될 때마다 대화 기록과 이미지에서 함수를 비동기적으로 생성하고, 준비된 Monty 인터프리터에서 실행하는 방식으로 구현함. 메시지와 이미지에서 점수를 계산하는 함수는 이미지마다 생성됨.

생성된 점수 함수의 성능

  • 같은 10개 메시지에 생성된 점수 함수를 적용하면 오판은 1건으로 줄어듦. 메시지당 지연은 약 20ms로, 사이드카의 4,100ms보다 훨씬 짧음.
  • 점수 함수는 6번 메시지인 “compare that to the s bar”에서만 틀림. 휴리스틱은 3건, 사이드카는 0건을 틀렸으며, 각각의 메시지당 지연은 1ms 미만, 약 4,100ms, 약 20ms임.
  • 이 접근법은 긴 연구 대화에 더 많은 이미지를 포함하면서도 매 턴마다 사이드카 LLM의 판단을 기다리지 않게 함. LLM에는 더 많은 DSL을 제공하는 것이 핵심 제안임.