Я никуда не пропал. Упорно работаю над проблемой создания надежного и ресурсоэффективного конвейера для автоматизации выпуска документации (changelogs, release notes).

Подготовил три документы, их основная задача: описать, как интегрировать малые языковые модели (SLLM) в рабочие процессы с ограниченным объемом VRAM, обеспечивая при этом высокую надежность и соответствие строгим производственным стандартам.

Оригиналы смотреть здесь: https://github.com/lefthand67/ai_engineering_handbook/tree/main/mlops/git_workflows

📄 1. Стандарты рабочего процесса Git для продакшена production_git_workflow_standards.md

• Документ определяет обязательные соглашения для ветвления и коммитинга в продакшен-процессах.

• Основное внимание уделяется:

  • Префиксам для именования веток (например, feature/, bugfix/).

  • Форматированию заголовков коммитов (например, семантические типы, такие как feat:, fix:).

  • Архитектурному тегированию (ArchTag) для структурных изменений (например, refactor:, perf:).

• Документ предписывает:

  • Атомарные коммиты с ясным намерением.

  • Чистые истории коммитов для прослеживаемости и бисекции.

  • Стратегии “squash-and-merge” (сжать и слить), чтобы избежать незавершенных (WIP) коммитов в основных ветках.

📄 2. Архитектура конвейера документации релизов на базе SLLM sllm_backed_release_documentation_pipeline_architecture.md

• Описывается техническая архитектура использования малых языковых моделей (SLLM) для генерации официальной проектной документации (например, журналов изменений и примечаний к релизу).

• Основное внимание уделяется оптимизации сред с ограниченными ресурсами, где используются локальные инструменты ИИ с ограниченным объемом VRAM (12–48 ГиБ).

• Ключевой принцип — разделение задач:

  • Использовать легковесные инструменты для парсинга, фильтрации и агрегации.

  • Использовать SLLM только для финального шага преобразования и суммаризации.

• Определяется трехступенчатый конвейер:

  1. Контроль коммитов (структурированные коммиты с использованием Conventional Commits).

  2. Агрегация журнала изменений (с использованием инструментов, не основанных на LLM, таких как git-chglog).

  3. Трансформация примечаний к релизу (с использованием SLLM с системными промптами для адаптации тона и аудитории).

  • Ключевые темы: оптимизация ресурсов, разделение обязанностей и отказ от монолитной обработки. (продолжение следует...)

(продолжение) 📄 3. Постмортем: Недетерминизм SLLM при генерации коммитов post-mortem_sllm_non-determinism_in_commit_generation.md

• Отчет post-mortem, анализирующий неудачу использования SLLM размером 1B-3B для генерации структурированных сообщений коммитов в высокочастотной, ограниченной задаче.

• Причинами сбоя стали:

  • Низкая точность следования инструкциям у малых моделей.

  • Неспособность поддерживать сложные ограничения (например, правила форматирования).

  • Недетерминированный вывод, приводящий к нарушениям на шлюзах CI/CD и архитектурных стандартах.

  • Решением стала замена SLLM на детерминированный инструмент CLI (gitlint) для контроля коммитов, с резервированием SLLM для последующих этапов. Этот процесс в работе.

🌳 Общие темы, прослеживаемые во всех документах:

1. Ограничения ресурсов: Акцент на оптимизации малых моделей (SLLM) и локальных стеков инструментов ИИ с ограниченным объемом VRAM.

2. Разделение и Специализация:

   • Использовать минимально эффективный компонент для каждой задачи (люди, инструменты или SLLM).

   • Избегать монолитной обработки; отделять детерминированные задачи от генеративных.

3. Детерминизм и Надёжность:

   • Требование использования шлюзов CI/CD, хуков pre-commit и ручных аудитов для обеспечения надёжности.

   • Использовать инструменты, не основанные на LLM, для парсинга и структурирования, прежде чем привлекать SLLM.

4. Семантические Соглашения:

   • Обеспечивать согласованные сообщения коммитов, имена веток и архитектурные теги для прослеживаемости.

5. Анализ Post-Mortem:

   • Документировать сбои (например, недетерминизм SLLM) для принятия обоснованных архитектурных решений.

✍️ Ключевые выводы:

• Документы представляют собой структурированный подход к интеграции инструментов ИИ в рабочие процессы MLOps с ограниченными ресурсами, при этом поддерживая надёжность и детерминизм.

• Они подчеркивают использование правильного инструмента для каждой задачи с чётким разделением между детерминированными функциями парсинга/валидации (обрабатываемыми легковесными инструментами) и генеративной трансформацией (обрабатываемой SLLM).