Документы и входящие запросы
Письма, ТЗ, спецификации и свободный текст превращаются в структуру: что требуется, чего не хватает, где условия противоречат друг другу. Специалист получает материал для ответа, а не чёрный ящик вместо себя.
Разработка · Исследование · Интеграция
Я разрабатываю LLM-функции для рабочих процессов: от разбора сложного входящего запроса до проверки результата и интеграции с действующими сервисами.
Когда нельзя ограничиться красивым ответом в чате — нужны данные, ограничения, тесты и ответственность за то, что произойдёт после ответа модели.
Схема не про «автоматизировать всё». Она про то, где модель полезна, а где ей нельзя принимать решение одной.
01 / Практика
Начинаю не с выбора модели, а с участка работы, где сейчас теряются время, точность или контроль.
Письма, ТЗ, спецификации и свободный текст превращаются в структуру: что требуется, чего не хватает, где условия противоречат друг другу. Специалист получает материал для ответа, а не чёрный ящик вместо себя.
Разбираю, почему система ошибается: данные, поиск, логика переходов, промпт, интеграция или сама постановка задачи. Собираю проверочные сценарии и исправляю то, что подтверждено ими.
Сравниваю качество, задержку и цену инференса. Исследую сжатие и локальное развёртывание, когда важны контроль данных или экономика большого потока запросов.
Пример возможного пилота
Клиент прислал письмо и вложение. Менеджер ответил, но не заметил ограничение в ТЗ. Такая ошибка не исправляется обещанием «умного чат-бота».
В пилоте можно проверить более узкую вещь: извлечь требования из входящих материалов, подсветить пробелы и сверить черновик КП с исходным запросом. Цену, сроки и обязательства подтверждают существующие системы и ответственный человек.
Это пример задачи для диагностики, не заявление о готовом продукте или результате у конкретного клиента.02 / Работы
Клиентская и внутренняя системы, собственные проекты, исследование. У каждого — свой статус и своя граница публичности.
Развивал backend системы, которая принимает текстовые и голосовые запросы, собирает параметры изделия по редактируемому сценарию и работает со справочниками и API CRM. Модель помогает понять свободную речь; допустимые переходы, состояние диалога и бизнес-значимые действия ограничены кодом.
Код, данные и имя заказчика не публикую. Метрик внедрения здесь нет; создание черновика КП не выдаю за полностью проверенный автоматический расчёт цены.
Спроектировал и разработал закрытую систему, где у каждого сотрудника свой агент, подключённый к общему контуру. У агента есть личные навыки, а у команды — общие. Помощник работает с внутренней документацией: например, на вопрос о доступе к сервису находит нужный порядок действий и подсказывает, к кому обратиться.
Система готова. Название компании, внутренние документы, код и показатели использования не публикую.
Сравнил методы low-bit сжатия в воспроизводимом протоколе и описал не только результат, но и его пределы. Артефакт первой версии — 2,05 GiB; по качеству и скорости он пока уступает стандартному Q3_K_M. Публикация показывает ход проверки, а не обещает прорыв.
Собрал образовательную базу в Obsidian: около 900 вопросов связаны с 300+ практическими ТЗ, а весь корпус насчитывает порядка 31 тысячи Markdown-файлов. Темы — от RAG и оценки качества до инфраструктуры, локального инференса и экономики AI. Это инструмент для собственного обучения и навигации по предмету, не продаваемый курс.
Материалы готовились с помощью LLM через OpenRouter; их масштаб не равен ручной верификации каждого текста. Для внешней публикации отдельные разделы требуют редакторской проверки.
Голосовой Telegram-прототип для репетиции непростого разговора. Пользователь делает попытку, получает конкретную обратную связь и пробует снова. Внутри — распознавание речи, многоходовый сценарий, тесты ответов модели, repair и запасной ответ при сбое.
Подготовлен к закрытым испытаниям; публичного запуска и продуктовых метрик пока нет.
03 / Подход
У меня больше десяти лет опыта в backend-разработке, эксплуатации сервисов и собственных проектах. С моделью работаю так же, как с любой сложной частью продукта: проверяю входы, выходы и сбои.
Смотрю, кто пользуется результатом, сколько стоит ошибка и можно ли вообще измерить улучшение.
Берём разрешённые данные, фиксируем текущий уровень и критерии приёмки. Если LLM здесь лишняя, я так и скажу.
Данные, доступы, наблюдаемость, стоимость и интеграции закладываются до того, как прототип начинают считать продуктом.
04 / Связь
Хватит короткого описания процесса: что приходит на вход, что отнимает время или приводит к ошибкам и кто проверяет результат. Отвечу, вижу ли здесь инженерную задачу и с чего разумно начать.
AetSeihe@yandex.ruПисьмо читаю лично. Детали клиентских проектов обсуждаю только в согласованных границах.