← Усі статті

Genkit на Go: як зібрати ШІ-застосунок, а не демо з одним промптом

Google Genkit для Go: схеми відповідей, багатокрокові сценарії, інструменти, спостережуваність і зміна моделей без переписування логіки.

Зміст

Коротко

Викликати LLM з коду просто; побудувати надійний продукт — ні. На Dev.to розібрали Genkit від Google для Go: каркас навколо промптів, структурованих відповідей, ланцюжків кроків і налагодження, щоб не плодити свій «міні-фреймворк» навколо кожного провайдера.

Що сталося

Автор, який робить ШІ-рев'ю коду на кожен коміт, описує типову еволюцію. Спочатку достатньо response := callLLM(prompt). Потім з'являються повтори при збоях, версії промптів, JSON на виході, виклики інструментів, трасування, метрики й ручна перевірка — і в репозиторії росте шар інфраструктури лише під ШІ.

Genkit позиціонується як «Spring Boot для ШІ-сценаріїв», а не ще один SDK. Для Go: go get github.com/firebase/genkit/go/ai, плагін провайдера (наприклад Gemini), ініціалізація через genkit.Init і перший виклик g.Generate. Далі цінність — у структурі.

Структурований вихід: замість парсингу тексту «Category: … Priority: …» задається Go-структура з JSON-тегами й схема в запиті — класифікація тикетів, витяг полів з листів, маршрутизація в підтримку. Flows (genkit.DefineFlow) оформлюють багатокрокові процеси — сумаризація листа, аналіз тональності, чернетка відповіді — як компоненти, що перевикористовуються, а не розрізнені виклики в контролері.

Інструменти (tool calling): модель вирішує, коли викликати GetOrderStatus, а факти приходять із вашої БД або CRM. Спостережуваність: при скарзі «ШІ відповів погано» видно ланцюжок промпт → контекст → виклики інструментів → відповідь моделі й вартість. У статті також розібрано приклад постмортему інциденту з Slack, алертів і логів.

Чому це важливо

Багато команд на бекенді на Go не хочуть тягнути окремий Node-сервіс «лише заради ШІ». Genkit дозволяє вбудувати можливості в існуючий сервіс і відокремити логіку сценарію від конкретної моделі — через півроку з Gemini на Anthropic або локальну модель міграція болить менше.

Автор попереджає про типові помилки: використовувати Genkit лише як обгортку над Generate, автоматизувати все без людини в контурі й не тестувати сценарії після зміни промпта чи моделі. Для продакшену важливіші сценарії й інструменти, ніж погоня за найновішою моделлю.

На практиці

  1. Почніть з одного flow із чіткою схемою виходу — не з вільного тексту.
  2. Винесіть промпти й версії в конфігурацію Genkit, а не в рядки по всьому коду.
  3. Факти з БД і внутрішніх API віддавайте через інструменти, а не через роздування промпта.
  4. Увімкніть трасування до першого інциденту в проді — без нього налагодження ШІ сліпе.
  5. Заложте контур «ШІ → перевірка людиною → дія» для ризикованих операцій.
  6. Плануйте оцінку якості (eval) так само серйозно, як unit-тести після зміни моделі.

Підсумок

Genkit на Go — практичний каркас між «одним викликом API» і зрілою ШІ-системою: схеми, flows, tools, observability. Для backend-інженерів це спосіб не роздвоювати стек заради ШІ-фіч. Приклади коду й установка — в оригіналі на Dev.to.