Разработка · Исследование · Интеграция

Модель — только часть системы.

Я разрабатываю LLM-функции для рабочих процессов: от разбора сложного входящего запроса до проверки результата и интеграции с действующими сервисами.

Когда нельзя ограничиться красивым ответом в чате — нужны данные, ограничения, тесты и ответственность за то, что произойдёт после ответа модели.

Рабочий контур01 / 04

Схема не про «автоматизировать всё». Она про то, где модель полезна, а где ей нельзя принимать решение одной.

Ростов-на-Дону · работаю с командами из других городовBackend / DevOps / Applied LLM

За что
берусь

Начинаю не с выбора модели, а с участка работы, где сейчас теряются время, точность или контроль.

01

Документы и входящие запросы

Письма, ТЗ, спецификации и свободный текст превращаются в структуру: что требуется, чего не хватает, где условия противоречат друг другу. Специалист получает материал для ответа, а не чёрный ящик вместо себя.

02

Существующие боты, RAG и агенты

Разбираю, почему система ошибается: данные, поиск, логика переходов, промпт, интеграция или сама постановка задачи. Собираю проверочные сценарии и исправляю то, что подтверждено ими.

03

Модели и стоимость эксплуатации

Сравниваю качество, задержку и цену инференса. Исследую сжатие и локальное развёртывание, когда важны контроль данных или экономика большого потока запросов.

Заявка пришла.
Что потерялось по дороге?

Клиент прислал письмо и вложение. Менеджер ответил, но не заметил ограничение в ТЗ. Такая ошибка не исправляется обещанием «умного чат-бота».

В пилоте можно проверить более узкую вещь: извлечь требования из входящих материалов, подсветить пробелы и сверить черновик КП с исходным запросом. Цену, сроки и обязательства подтверждают существующие системы и ответственный человек.

Это пример задачи для диагностики, не заявление о готовом продукте или результате у конкретного клиента.

Проекты, за которыми
есть работа

Клиентская и внутренняя системы, собственные проекты, исследование. У каждого — свой статус и своя граница публичности.

01 / Прикладная разработкаЗакрытая клиентская система

Ассистент для заказов изделий из камня

Развивал backend системы, которая принимает текстовые и голосовые запросы, собирает параметры изделия по редактируемому сценарию и работает со справочниками и API CRM. Модель помогает понять свободную речь; допустимые переходы, состояние диалога и бизнес-значимые действия ограничены кодом.

  • FastAPI и сценарный граф
  • Распознавание голоса
  • CRM-интеграция
  • Регрессионные проверки диалогов

Код, данные и имя заказчика не публикую. Метрик внедрения здесь нет; создание черновика КП не выдаю за полностью проверенный автоматический расчёт цены.

Внутренний инструмент02 / Готовая система

Персональные агенты для сотрудников

Спроектировал и разработал закрытую систему, где у каждого сотрудника свой агент, подключённый к общему контуру. У агента есть личные навыки, а у команды — общие. Помощник работает с внутренней документацией: например, на вопрос о доступе к сервису находит нужный порядок действий и подсказывает, к кому обратиться.

Система готова. Название компании, внутренние документы, код и показатели использования не публикую.

Исследование03 / Публикация

PCST: экстремальное сжатие LLaMA 7B без дообучения

Сравнил методы low-bit сжатия в воспроизводимом протоколе и описал не только результат, но и его пределы. Артефакт первой версии — 2,05 GiB; по качеству и скорости он пока уступает стандартному Q3_K_M. Публикация показывает ход проверки, а не обещает прорыв.

Система знаний04 / Личный проект

Aivaro — карта AI-инженерии

Собрал образовательную базу в Obsidian: около 900 вопросов связаны с 300+ практическими ТЗ, а весь корпус насчитывает порядка 31 тысячи Markdown-файлов. Темы — от RAG и оценки качества до инфраструктуры, локального инференса и экономики AI. Это инструмент для собственного обучения и навигации по предмету, не продаваемый курс.

Материалы готовились с помощью LLM через OpenRouter; их масштаб не равен ручной верификации каждого текста. Для внешней публикации отдельные разделы требуют редакторской проверки.

Личный продукт05 / Прототип

Тренер сложных разговоров

Голосовой Telegram-прототип для репетиции непростого разговора. Пользователь делает попытку, получает конкретную обратную связь и пробует снова. Внутри — распознавание речи, многоходовый сценарий, тесты ответов модели, repair и запасной ответ при сбое.

Подготовлен к закрытым испытаниям; публичного запуска и продуктовых метрик пока нет.

Сначала понять
задачу

У меня больше десяти лет опыта в backend-разработке, эксплуатации сервисов и собственных проектах. С моделью работаю так же, как с любой сложной частью продукта: проверяю входы, выходы и сбои.

01

Разобраться с процессом

Смотрю, кто пользуется результатом, сколько стоит ошибка и можно ли вообще измерить улучшение.

02

Проверить на примерах

Берём разрешённые данные, фиксируем текущий уровень и критерии приёмки. Если LLM здесь лишняя, я так и скажу.

03

Собрать рабочий контур

Данные, доступы, наблюдаемость, стоимость и интеграции закладываются до того, как прототип начинают считать продуктом.

Есть задача?
Расскажите как есть.

Хватит короткого описания процесса: что приходит на вход, что отнимает время или приводит к ошибкам и кто проверяет результат. Отвечу, вижу ли здесь инженерную задачу и с чего разумно начать.

AetSeihe@yandex.ru

Письмо читаю лично. Детали клиентских проектов обсуждаю только в согласованных границах.