Зміст
Коротко
Відкрита LLM (велика мовна модель) у робочій системі швидко перестає бути питанням «яка модель найкраща». Команда мусить подбати про відтворювані налаштування, коректний JSON, контроль кожного звернення до моделі та відповідність моделі наявному обладнанню.
Автори матеріалу на Habr сформулювали вісім уроків із власної експлуатації llama.cpp, Gemma та Qwen. Основна думка: властивості, критичні для бізнес-процесу, не варто залишати на розсуд імовірнісної моделі — їх має забезпечувати інфраструктура.
Що сталося
У матеріалі йдеться про відкриті моделі для класифікації заявок, обробки документів і діалогових систем із викликом інструментів. Перші досліди починалися з Ollama, але потреби продакшену згодом привели авторів до llama.cpp, де можна точніше керувати параметрами виводу та використанням пам’яті GPU.
За такий контроль доводиться платити власною конфігурацією. Натомість команда може зафіксувати версії ваг, розподілити тензори відповідно до конкретної відеокарти та повторити перевірену конфігурацію, а не покладатися на приховані налаштування за замовчуванням.
Автори також відмовилися від пошуку однієї універсальної моделі. Gemma у їхній схемі формує зрозумілий людині текст, а Qwen відповідає за покроковий розбір, класифікацію та виклики інструментів. Поділ обов’язків виявився надійнішим, ніж спроба навчити одну модель однаково добре виконувати всі ролі.
Чому це важливо
Рейтинги та порівняльні тести показують лише усереднений результат. У реальній системі модель ще має працювати потрібною мовою, вміщуватися у відеопам’ять із прийнятним квантуванням, вкладатися в допустиму затримку та давати якісний результат на власних прикладах команди.
Непомітним джерелом помилок є шаблон діалогу. Gemma і Qwen навчалися на різній службовій розмітці повідомлень. Якщо перенести інструкцію з іншої моделі без адаптації, помилки може не бути — натомість непомітно погіршиться якість відповіді.
Подібний компроміс мають і фреймворки для агентів ШІ. Вони допомагають швидко зібрати складну мінливу логіку з розгалуженнями, проте у сталому процесі можуть приховати повторні спроби та додаткові звернення. Коли важливий кожен виклик, явна послідовність у власному коді простіша для спостереження й перевірки.
На практиці
- Починайте із завдання. Спершу визначте мову, якість, затримку, контекст і обмеження пам’яті, а вже потім порівнюйте моделі.
- Розділяйте ролі моделей. Окремо оцінюйте вилучення даних, класифікацію, міркування та текст для користувача.
- Фіксуйте налаштування виводу. Зберігайте версію ваг, квантування, шаблон діалогу, температуру та розподіл пам’яті разом із кодом.
- Гарантуйте структурований результат.
llama.cppможе обмежити генерацію граматикоюGBNFабо схемоюJSON Schema, а не лише проханням «поверни JSON». - Перевіряйте не тільки форму. Граматика гарантує синтаксис, але не правильність значень і не захищає від обриву відповіді через ліміт токенів.
- Добирайте температуру для етапу. Вилучення даних і вибір дії потребують передбачуваності, а текст для людини допускає більше варіативності.
- Застосовуйте фреймворки вибірково. Вони доречні для складних сценаріїв, що часто змінюються; для сталих ланцюжків краще прозорий код.
- Вимірюйте кожну зміну. Нова модель, інструкція чи шаблон — це нова конфігурація, яку слід перевірити на регресії.
Підсумок
Відкриті ШІ-моделі дають контроль над даними, передбачуванішу вартість на великих обсягах і незалежність від зовнішнього API. Водночас вони не скасовують інженерну роботу з обслуговування, інструкцій, формату відповіді та спостереження за системою.
Для короткого прототипу зручний запуск часто є правильним вибором. У системі, що впливає на бізнес-процес, готовність до продакшену з’являється тоді, коли важлива поведінка описана явно, виміряна та забезпечена поза межами моделі.