Оберіть AI-модель для сесій налагодження
StatusRivet потребує моделі для аналізу, і ви вирішуєте, де вона працює: хмарний постачальник через стандартний API-ендпоінт, модель на вашому ПК або вбудована модель. Ця сторінка пояснює три варіанти та як протестувати з'єднання.
Три варіанти розміщення моделі
Хмарний AI-постачальник
Хмарний AI-постачальник підходить для великих кодових баз та довгих журналів. Вкажіть стандартний API-ендпоінт та свій ключ. Ключ залишається локальним. Кожен запит надходить до обраного постачальника, включаючи текст будь-якого файлу або журналу, який агент читає для цього кроку, тому прочитайте політику постачальника перед надсиланням вихідного коду, який не є відкритим. Залишайте роботу з програмним забезпеченням, яке ви написали або маєте право налагоджувати. Постачальник може стягувати плату за використання згідно з власними умовами, а StatusRivet є незалежним від кожного постачальника. Обирайте його, коли ваші журнали та вихідні файли потребують великого контекстного вікна.
Модель на вашому ПК
Модель на вашому ПК підходить для коду, який не можна надсилати кудись. Ваш ПК виконує роботу. Вкажіть StatusRivet на локальний ендпоінт, і запити надходитимуть на вашу власну машину, тому нічого не залишає її. Компроміс — це апаратне забезпечення: швидкість та контекстне вікно залежать від того, що може запустити ваш ПК, а довгий журнал може не вміститися. Використовуйте кнопку «Тест», щоб перевірити вікно перед довгою сесією. Оновлення або заміна моделі — ваше завдання. Це добре підходить для лабораторних машин та неопублікованих драйверів, якщо ви приймаєте ці обмеження.
Вбудована модель
Вбудована модель готова до використання без власного ендпоінта, тому це найкоротший шлях від встановлення до першого чату. Ендпоінт не потрібен. Використовуйте її, щоб спробувати режими затвердження, прочитати короткий журнал і побачити, як виглядає карта diff, перш ніж налаштовувати щось інше. Коли завданню потрібно більше, підключіть хмарного AI-постачальника або модель на вашому ПК і запустіть той самий чат знову, щоб порівняти відповіді. Перевіряйте кожну diff однаково, незалежно від того, яка модель її згенерувала.
Протестуйте з'єднання перед довгою сесією
Натисніть кнопку «Тест» поруч із ендпоінтом, щоб перевірити з'єднання. Результат показує час відповіді та контекстне вікно цієї моделі. Час відповіді показує, чи відповідає ендпоінт на швидкості, з якою ви можете працювати. Контекстне вікно показує, скільки журналу або вихідного файлу вміщується в один запит, що важливо, коли довгий стек викликів є частиною запиту. Запустіть тест знову після зміни ендпоінта або моделі. Невдалий тест вказує на з'єднання, а не на ваш код. Спочатку виправте це.
Оберіть розмір моделі для завдання
Використовуйте більшу модель для складного аналізу, наприклад, відстеження помилки через кілька модулів або перегляду більшої зміни, і меншу для невеликих редагувань, таких як додавання перевірки на null. Навичка run_on_model дозволяє агенту надіслати один складний крок до більшої моделі, тоді як решта сесії залишається на меншій. Це тримає звичайні кроки на меншій моделі, поки складний крок отримує більше потужності. Обирайте за завданням, а не за звичкою, і використовуйте кнопку «Тест», щоб порівняти контекстні вікна, перш ніж вставляти довгий журнал збоїв. Спочатку вмістіть журнал.
Якість моделей варіюється між постачальниками та версіями, тому сприймайте кожну відповідь як чернетку. Чернетки потребують перевірки. Прочитайте diff, зберіть знову за допомогою вашої команди збірки та запустіть вашу команду тестування, перш ніж залишати зміну. Запитати спочатку (Ask first) призупиняє дії, що щось змінюють, що дає вам місце для зупинки та читання. Планувати лише (Plan only) записує план і не запускає нічого, що допомагає, коли ви хочете побачити кроки, перш ніж увімкнути Auto-run або Ask first. Агент працює з текстовим виводом, тому результат такий самий, як і журнали, які ви надаєте йому.
