← Все статьи

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) оформляют многошаговые процессы — суммаризация письма, анализ тональности, черновик ответа — как переиспользуемые компоненты, а не разрозненные вызовы в контроллере.

Инструменты (вызов функций): модель решает, когда дернуть GetOrderStatus, а факты приходят из вашей БД или CRM. Наблюдаемость: при жалобе «ИИ ответил плохо» видно цепочку промпт → контекст → вызовы инструментов → ответ модели и стоимость. В статье также разобран пример постмортема инцидента из Slack, алертов и логов.

Почему это важно

Многие команды на серверной части на Go не хотят тащить отдельный Node.js-сервис «только ради ИИ». Genkit позволяет встроить возможности в существующий сервис и отделить логику сценария от конкретной модели — через полгода с Gemini на Anthropic или локальную модель миграция больнее меньше.

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

На практике

  1. Начните с одного сценария (DefineFlow) с чёткой схемой выхода — не с свободного текста.
  2. Вынесите промпты и версии в конфигурацию Genkit, а не в строки по всему коду.
  3. Факты из БД и внутренних API отдавайте через инструменты, а не через раздувание промпта.
  4. Включите трассировку до первого инцидента в проде — без неё отладка ИИ слепа.
  5. Заложите контур «ИИ → проверка человеком → действие» для рискованных операций.
  6. Планируйте оценку качества так же серьёзно, как модульные тесты после смены модели.

Итог

Genkit на Go — практичный каркас между «одним вызовом API» и зрелой ИИ-системой: схемы, сценарии, инструменты, наблюдаемость. Для инженеров серверной части это способ не раздваивать стек ради ИИ-фич. Примеры кода и установка — в оригинале на Dev.to.