В погоні за токенами: я перейменував весь репозиторій, і ось що з цього вийшло
Після того як я оптимізував логи CI для AI-агентів, я почав шукати можливості заощадити токени буквально всюди.
І тут мені спала на думку ще одна ідея.
Багато моїх файлів і директорій були названі в 𝗸𝗲𝗯𝗮𝗯-𝗰𝗮𝘀𝗲.
Припущення було простим: якщо - збільшує кількість токенів, то перехід на camelCase для всіх назв потенційно може зменшити обсяг контексту, який доводиться обробляти AI-агенту.
Тож замість того, щоб гадати, я вирішив це виміряти.
Я написав скрипт, який токенізував увесь репозиторій до та після перейменування всіх шляхів із kebab-case на camelCase.
- До: 376 553 токени
- Після: 376 204 токени
Загальна економія: 𝟯𝟰𝟵 токенів.
Якщо чесно, я очікував значно більшого результату.
На перший погляд це виглядає як класична мікрооптимізація.
Але, думаю, на цьому історія не закінчується.
На відміну від коду, назви файлів та директорій мають зовсім інший життєвий цикл у ссессіях розробки з Аі.
Агент бачить їх не один раз.
Вони постійно з’являються в:
- імпортах та експортах;
- списках директорій;
- результатах пошуку;
- git diff;
- stack trace;
- результатах тестів;
- логах форматерів і лінтерів;
- відповідях інструментів IDE.
Інакше кажучи, шляхи до файлів знову і знову потрапляють у робочий контекст агента.
Тому, хоча сам репозиторій став меншим лише на 𝟯𝟰𝟵 токенів, сукупна економія протягом довгої сесії розробки потенційно може бути значно більшою — просто тому, що ті самі шляхи обробляються багато разів.
Цю частину я поки що не вимірював, тому не буду називати жодних конкретних цифр.
Але цей експеримент ще раз нагадав мені про дещо важливіше:
Спочатку вимірюй. Потім оптимізуй.
Деякі оптимізації, які на словах здаються геніальними, на практиці виявляються майже непомітними.
Інші — наприклад, скорочення зайвого виводу інструментів — дають значно більший ефект, ніж можна було очікувати.
Розробка за допомогою AI породжує абсолютно новий клас оптимізацій продуктивності.
І єдиний спосіб зрозуміти, які з них справді мають значення, — вимірювати.
Немає коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів