단순한 재미와 호기심으로, 저는 제 Fable 5 토큰을 사용하여 추론 엔진 (inference engine) + Python 에이전트를 개발했습니다. 사양은 제 M2 MacBook에서 Qwen 3.5 9B를 로컬로 실행하는 것이었습니다. 과학 문헌에는 많은 아이디어가 떠돌고 있지만, 아직 실제로 이를 하나로 결합한 사람은 없었습니다. 아직 실험 단계에 있지만, 아주 훌륭하게 작동합니다. 개발을 계속할 계획은 없습니다. 현재 상태로도 제가 필요로 하는 기능을 정확히 수행하기 때문입니다. 이 프로젝트를 통해 저는 llama.cpp, OpenCode, Pi, ollama, 그리고 Qwopus 및 Ornith 팀의 개발자들이 고려조차 하지 않는 특정 개념들을 반박할 수 있었습니다. 다음은 이러한 점들에 대한 간략한 요약입니다. 원하신다면 더 자세히 설명해 드릴 수 있습니다:

강제된 BPE 토큰 (Forced BPE Tokens): 도구 이름과 호출 형식은 훈련 단계에서 사전에 결정되었습니다. 토큰 사전 (token dictionary)을 자세히 살펴보면, 더 적은 토큰 수를 사용하여 모델이 이를 방출하도록 BPE 어휘 (vocabulary)가 강제되었음이 분명합니다.

미세 조정 구문 충돌 (Fine-Tuning Syntax Conflicts): 만약 Qwen 3.5 9B를 미세 조정 (fine-tuning) 하는 것이 과적합 (overfitting)으로 이어진다면, 모델은 시스템 프롬프트 (system prompt)에서 제안된 일반적인 도구 호출 (tool calls)을 방출하는 유연성을 잃게 됩니다. Qwen의 네이티브 도구 호출은 XML 형식을 사용합니다. 만약 미세 조정이 JSON 도구 호출을 사용하여 수행된다면, 모델은 완전히 망가집니다.

피드백 기반 도구 출력 (Feedback-Driven Tool Outputs): 도구 호출은 후속 작업을 안내할 수 있는 올바른 실행 출력을 생성해야 합니다. 예를 들어, 모델이 코드를 생성하면 LSP 진단 (LSP diagnostics) 및 구문 분석 (syntax analysis)을 피드백으로 제공하는 것이 모델에게 다음 논리적 수정 사항을 제안하는 데 도움이 됩니다.

에이전트 오케스트레이션 (Agent Orchestration): 사용 가능한 도구가 너무 많은 소형 모델은 장난감이 너무 많은 아이와 같습니다. 무엇을 가지고 놀아야 할지 몰라 결국 엉망진창이 되고 맙니다. 각 에이전트가 제한된 도구 세트를 가지고 다른 에이전트로부터 전달된 요약본을 활용하는 별도의 컨텍스트 (context)를 갖는 에이전트 오케스트레이션이 해결책입니다.

앵커 기반 편집 (Anchor-Based Editing): 앵커 기반 파일 편집은 토큰 효율적 (token-efficient)입니다.

이 편집 도구들은 기존의 "기존 문자열을 새 문자열로 교체"하는 방식 대신 <줄 번호><체크섬>|<코드> 앵커(예: 12af| return x)를 활용하며, 이는 동일한 편집에 대해 눈에 띄게 적은 토큰을 소모합니다. 줄 번호 바로 뒤에는 구분자 없이 해당 줄 내용의 2자리 16진수 체크섬(checksum)이 뒤따릅니다. 이 체크섬을 통해 편집 시 자신이 읽었던 줄을 여전히 대상으로 하고 있는지 확인할 수 있으며, 이 압축된 형태는 모델 자체의 BPE 어휘(vocabulary)에서 저렴하게 토큰화됩니다. https://github.com/EmilioSchi/qwowl35/ /u/Snoo-81733 님이 제출함 [링크] [댓글]