Pi-Agent-Kernel: 집중적인 코드 검색, 근거 기반 수정, 안전성 검사

흥미로운 아이디어네요! 제 환경에서 써봤는데 기대했던 만큼의 절감 효과는 없었어요. 특정 워크로드에서 효과가 좋은가요? 평가를 한 번밖에 안 해봐서 차트는 일단 참고만 해주세요. 더 돌려볼 예정입니다. 꽤 괜찮은 아이디어라 좀 더 깊게 테스트해보고 싶네요! 수정 - SWE-Bench 작업 일부를 포함해서 그래프 업데이트함, 초기 결과는 꽤 유망해 보임! 오늘 가능한 대로 계속 평가할 예정. 수정 또 함 - SWE 2회차 완료 후 차트 업데이트함.

SWE-bench나 레포 버그 수정 같은 벤치마크를 돌려주시면 정말 감사하겠습니다. README에 있는 차트에 대해 짧게 설명하자면, 그 결과는 다른 스킬이나 확장 프로그램(SpecPi나 Jev) 없이 순수하게 Pi + Agent Kernel만 사용한 거예요. 어디서 효과가 좋은지 물으셨는데, 이건 특히 테스트 스위트가 방대한 중대형 코드베이스를 위해 만들어졌어요. 반대로 Terminal-Bench 작업은 코드베이스가 작거나 아예 없어서 그런 기능들이 놀게 되죠. 개발하면서 관찰한 바로는, 작은 터미널 작업에서는 도구 스키마나 시스템 지시사항으로 인한 오버헤드가 없는 vanilla Pi가 Agent Kernel을 확실히 이길 수 있습니다.

알겠습니다. SWE-bench 환경 설정 중이에요. 비교 결과가 나오려면 시간이 좀 걸리겠지만요. 터미널 벤치에서는 시스템이 꽤 여러 번 작동했는데, 말씀하신 대로 이건 대규모 코드베이스 작업이 아니니까요. SpecPi + Jev는 제가 테스트랑 평가를 거쳐서 만든 제 개인적인 설정인데... 당신 패키지와 충돌하는 건 없어서 제 용도에 맞춰 비교해보기에 흥미롭네요. 초기 데이터 나오면 원문 포스트 업데이트할게요.

솔직히 말해서, 코드를 잠깐 훑어봤는데 꽤 집중적으로 잘 만든 것 같긴 해요. 근데 설명 읽으면서 이런 생각이 들더라고요: '토큰 사용량을 절반으로 줄였다고? 그럼 RTK, caveman, headroom, context-mode, ponytail에 이것까지 다 설치하면 토큰 사용량이 마이너스가 될 수도 있겠네? 그럼 내가 Anthropic에 토큰을 퍼주는 꼴이 되는 건가?' 물론 당신도 '제품'을 어떻게든 팔아야 한다는 건 이해합니다. vanilla Pi가 당신 솔루션보다 왜 그렇게 점수가 낮게 나왔는지 꽤 궁금하네요. LLM의 비결정성을 완화하려면 같은 문제로 통제 실험을 더 많이 해보는 게 좋을 것 같아요. * * * 여담인데, 터미널 색깔이 원래 그렇게 나오면 안 될 텐데요. .bashrc에 export COLORTERM=truecolor 추가하세요.

툴 출력을 압축할 때는 정말 조심해야 함. 어떤 모델들은 툴 호출을 더 남발하게 만들어서 컨텍스트를 더 낭비하게 되거든.

툴 출력을 어떻게 수정하는지 전후 비교를 보여줄 필요가 있음.