저는 HELIX Engine을 공개했습니다. 이 엔진은 모델 가중치를 수정하거나 설정된 추론 노력을 낮추지 않으면서 코딩 에이전트의 중복 추론을 줄이기 위해 설계된 오픈 소스 컨텍스트, 메모리 및 실행 관리 시스템입니다. 저장소: https://github.com/SuperHelix77/HELIX-1.0 저는 직업상 소아과 의사이며, 여가 시간에 약 1년 동안 추론 효율성에 대해 연구해 왔습니다. 이 프로젝트는 프롬프트 수준 최적화와 RTK 기반 도구 출력 감소에서 시작하여 보다 광범위한 의미론적 실행 아키텍처로 발전했습니다. 핵심 가설은 간단합니다. 에이전트 추론 지출의 상당 부분은 새로운 문제 해결 작업을 수행하는 것보다는 역사적 컨텍스트를 반복적으로 처리하고 결정론적 연산을 조정하는 데서 발생한다는 것입니다.
아키텍처: HELIX는 근본적인 언어 모델을 수정하기보다 에이전트의 실행 워크플로우를 중심으로 작동합니다. 주요 구성 요소는 다음과 같습니다:
- 역사적 컨텍스트 폐기 (Historical context retirement): 완료된 도구 상호작용은 반복적인 활성 컨텍스트 재생에서 제거되지만, 정확한 원본은 복구 가능하게 유지됩니다.
- 증거 보존 (Evidence preservation): 도구 결과는 불변의 원본에 대한 참조가 포함된 압축되고 타입화된 증거 영수증으로 변환됩니다. 손실성 감소(Lossy reductions)가 자동으로 권위 있는 증거가 되지는 않습니다.
- 결정론적 도구 흐름 (Deterministic Tool Flow): 이전에 승인된 기계적 연산은 매 단계마다 별도의 모델 결정이 필요하지 않은 바운디드 워크플로우를 통해 실행될 수 있습니다.
- 영속 메모리 (Persistent memory): 로컬 SQLite 기반 메모리는 작업 관찰 및 명시적인 프로젝트 상태를 저장합니다. 선택적으로 Claude-Mem 통합은 기존 메모리 저장소에서 검색을 지원합니다.
- RTK 통합 (RTK integration): 도구 출력 필터링은 원본 결과에 대한 접근성을 유지하면서 불필요한 텍스트 오버헤드를 줄입니다.
- 실행 모니터링 (Execution monitoring): Electron 애플리케이션은 실행 상태, 메모리, 증거 및 문제 해결에 대한 가시성을 제공합니다.
목표는 모델의 추론(reasoning)을 실행 관련 기록 관리(execution bookkeeping)와 분리하는 것이지만, 이후 결정에 필요한 정보는 유지하는 것입니다. 제가 평가한 벤치마크 방법론은 Sol 6.1 High를 사용하여 50개의 소프트웨어 엔지니어링 작업에 대해 HELIX V3를 과거의 기본(vanilla) 기준선과 비교했습니다. 두 구성 모두 동일한 기반 모델과 추론 노력 설정을 사용했습니다. 평가는 작업을 거치며 지속적인 네이티브 대화(continuous native conversation)를 유지했으며, 필요할 경우 인프라 복구까지 포함했습니다. 실패 시도와 성공적인 재시도는 토큰 계산에 포함되었습니다. 확인된 제공업체 과부하(Confirmed provider overloads)는 두 구성 모두에서 별도로 기록되었습니다. 공식 작업 등급은 보존되었습니다. 최종 감사 결과:
Vanilla:
- 검증된 해결 건수: 38/50
- 주요 모델 요청: 341
- 확인된 입력 토큰: 50,630,785
- 확인된 출력 토큰: 55,283
- 확인된 총 토큰: 50,686,068
HELIX V3:
- 검증된 해결 건수: 34/50
- 주요 모델 요청: 420
- 확인된 입력 토큰: 11,212,326
- 확인된 출력 토큰: 75,814
- 확인된 총 토큰: 11,288,140
측정 결과:
- 확인된 총 제공업체 토큰(known total provider tokens) 소비량 77.73% 감소
- 확인된 입력 토큰(known input tokens) 약 77.85% 감소
- 출력 토큰(output tokens) 37.14% 증가
- 추가 주요 모델 요청: 79회
- 검증된 작업 완료 건수: 4개 감소
이러한 감소는 평가된 워크로드에 대해 약 4.49배 낮은 확인 토큰 지출량에 해당합니다.
제한 사항 및 해석:
결과는 상당한 추론 효율성 개선을 보여주지만, 역량 동등성(capability parity)을 확립하는 것은 아닙니다. HELIX는 34개의 작업을 완료하여 기본 모델의 38개 작업에 비해 적습니다. 이러한 회귀(regression)는 중요하며 여전히 활발한 연구 문제입니다. 또한, HELIX는 모델 요청 빈도와 출력 토큰 소비량을 증가시켰습니다. 초기 진단 분석에 따르면 추가적인 조정 및 추론 오버헤드가 이러한 회귀에 기여할 수 있습니다. 몇 가지 방법론적 제한 사항도 고려해야 합니다: 비교 과정에서 알려진 작업 코호트(known task cohort)와 과거의 기본 기준선이 재사용되었습니다.
이는 새롭거나 무작위화된 동시 A/B 실험이 아니었습니다. HELIX 요청 중 일부는 사용량을 알 수 없었으며, 개발, 컨설팅 및 복구 오버헤드 일부가 측정되지 않았습니다. 제공업체 토큰 수는 실제 구독 할당량 소비 또는 완전히 정산된 API 청구와 동일하지 않습니다. 이 벤치마크는 하나의 모델 구성과 하나의 작업 배포를 평가합니다. 다른 모델과 워크로드로의 일반화는 여전히 검증되지 않은 상태입니다. 히스토리 컨텍스트 폐기는 복구 가능한 증거를 보존하지만, 필요한 경우 모델이 모든 관련 관찰을 검색한다는 것을 보장하지 않습니다. HELIX 벤치마크 중에는 네이티브 컨텍스트 압축이 발생하지 않았습니다. 이는 테스트된 워크로드에 대한 관찰일 뿐, 압축이 보편적으로 제거될 수 있다는 증거는 아닙니다. 이 저장소에는 작업별 결과, 누적 토큰 회계, 방법론 및 문서화된 제한 사항이 포함되어 있습니다. 현재 연구 방향인 HELIX 1.1은 불필요한 추론 지출의 나머지 출처에 초점을 맞추고 있습니다. 즉각적인 연구 영역은 다음과 같습니다: 1. 모델-요청 증폭 V3 벤치마크는 바닐라(vanilla) 대비 420개의 기본 모델 요청을 필요로 했습니다. 현재 실험에서는 필요한 추론이나 증거 경계를 제거하지 않으면서 검증 및 체크포인트 작업을 결합하는 것을 조사하고 있습니다. 2. 추론 오버헤드 컨텍스트 감소가 반드시 추론 지출 감소를 의미하지는 않습니다. 추가적인 모델 매개 조정은 히스토리-컨텍스트 폐기로 인한 절감액을 부분적으로 상쇄할 수 있습니다. 3. 증거 인식 검색 다음 목표는 구조화된 메모리에 작업에 중요한 관찰을 보존하는 동시에 검증을 위해 정확한 기록된 증거를 유지하는 것입니다. 이는 전체 히스토리-컨텍스트 재재생이 필요하지 않은 상태에서 반복적인 조사를 줄일 수 있습니다. 4. 실행 지연 시간 로컬 실험에서는 취소, 프로세스 격리, 복구 및 실패 보고 의미론을 보존하면서 결정론적 도구 디스패치 오버헤드를 줄이는 것을 조사하고 있습니다. 5. 정확성 복구 가장 중요하게 해결되지 않은 요구 사항은 네 가지 문제 풀이 부족(four-solve deficit)을 복구하는 것입니다.
추가적인 토큰 감소만으로는 용납할 수 없는 기능 저하(capability regressions)를 초래한다면 충분하지 않습니다. 장기적인 연구 목표는 95%의 추론 지출(inference-expenditure) 감소로 남아 있지만, 이는 아직 입증되지 않았습니다. 향후 평가에는 Terminal-Bench를 포함한 독립적인 워크로드도 포함될 것입니다. 재현성 및 피드백을 위해 HELIX는 오픈 소스 라이선스로 공개되어 있습니다. 저장소에는 설치 지침, 아키텍처 문서, 벤치마크 아티팩트, 그리고 Electron 모니터링 인터페이스가 포함되어 있습니다. GitHub: https://github.com/SuperHelix7/HELIX-1.0 저는 특히 다음과 같은 기술적 피드백에 관심이 많습니다: 관찰된 절감액이 보지 못한 작업 분포(unseen task distributions)에도 일반화되는지 여부. 역사적 컨텍스트 폐기(historical-context retirement)가 지연된 증거 검색 및 정확도에 어떻게 영향을 미치는지. 추론 능력 약화 없이 모델 요청 증폭(model-request amplification)을 줄이는 방법. 검증된 작업 완료 대비 토큰 효율성을 평가하기 위한 더 나은 실험 설계. 단순히 원시 토큰 수(raw token counts)만 측정하는 것이 아니라 가중치가 적용된 추론 비용(weighted inference cost)을 측정하는 접근 방식. 저의 목표는 토큰 압축이 지능 보존과 동등하다고 주장하는 것이 아닙니다. 그것은 에이전트 워크플로우에서 실제 문제 해결 능력을 유지하면서 얼마나 많은 중복 추론을 제거할 수 있는지 조사하는 것입니다. 현재 결과는 알려진 제공업체 토큰(known provider tokens) 대비 77.73% 적으며, 측정 가능한 정확도 저하가 있습니다. 이 두 가지 발견 모두 프로젝트의 핵심입니다. 독립적인 재현, 방법론적 비판, 구현 수준의 피드백을 환영합니다. submitted by /u/SuperHelix7 to r/OpenAI [link] [comments]
