Соблазн понятен, но в моих кейсах LLM встала на место человека, а не алгоритма. SQL по вопросу аналитика раньше писал разработчик, и это тоже был вероятностный процесс, просто вероятность пряталась в человеке: один и тот же вопрос двум разработчикам даёт два разных запроса. Детерминированно эту задачу не решили за тридцать лет, поэтому её и не автоматизировали вовсе.
Дальше вопрос в обвязке. Когда нужна предсказуемость, формулировка задачи для модели меняется с «сгенерируй ответ» на «выбери из закрытого списка или верни: не нашёл». В боте поддержки у меня так и сделано, и он единственный прошёл все ловушки аудита без выдумок. Там, где модель оставлена свободной, она уверенно сочиняла.
Так что граница проходит не между задачами, а внутри системы: вероятностное ядро и детерминированная рамка вокруг него. Проведёшь её явно, получишь рабочий инструмент, оставишь неявной, получишь генератор правдоподобного мусора.
Чек-лист целиком в статье, ядро промта аудита под спойлером там же. Полная версия промта, с форматом карточки и правилами честности аудитора, лежит в закрепе канала: https://t.me/n_cto
Если прогоните аудит на своём проекте, напишите сюда счёт и самый неожиданный факт. Моя гипотеза: пункты «владелец» и «цена запроса» провалены у большинства. Через месяц выложу повторный аудит своих трёх и посмотрим на дельту.
Хороший вопрос. Короткий ответ: спор в отделе был про три варианта, которые у нас уже существовали, а скила не существовало. Длинный: ветка C с енамами — это по сути и есть автоматически собранный скил (DDL плюс смыслы значений, вытащенные парсером из кода), только без ручной курации.
Следующий шаг ровно такой, как вы описываете: курируемый файл знаний о схеме, куда дописаны описания и бизнес-правила, которых нет ни в базе, ни в енамах. Роль партнёра из статьи, которую не нашёл никто, включая меня, — как раз такое знание. Подозреваю, скил закрыл бы часть из 8 нерешённых вопросов.
Останавливает цена: руками описывать 253 таблицы дорого, и это протухает. Рабочий план: генерировать черновик скила из кода, курировать только горячие таблицы. Если у вас есть опыт со скилом над схемой такого размера — покажите цифры, очень интересно.
Собрал в один файл всё, чтобы повторить эксперимент у себя: методику (execution accuracy, правила зачёта, шаблоны обратной связи), промты веток, скрипт сравнения result set'ов и чек-лист «инварианты для каждой метрики». Лежит в закрепе канала: https://t.me/n_cto
Вопросы по методике задавайте здесь, отвечу. Особенно интересно, если у кого-то MCP-ветка ведёт себя иначе — покажите конфигурацию.
Про чёрный ящик поправлю: код агент как раз читал, из него и собиралось ТЗ. UI-прогон был вторым каналом, чтобы сверить «как написано» с «как работает». Кода не читал человек, в этом и был эксперимент.
Про этапы вы правы, и делали мы именно так, просто в статье это слиплось: в промпте первого этапа улучшения запрещены, сначала as-is и сходство один в один, фичи отдельным заходом после валидации ТЗ с заказчиком. Возьму на заметку, что это стоило проговорить жирнее.
Кейс с потерянными исходниками жёсткий, тут наш метод честно упирается в границу: реверсить можно только поведение и то, что осталось от артефактов. 1000 ошибок компиляции после восстановления звучит как отдельная статья. Прайс выше в 30 с лишним раз: ровно та экономика, из-за которой такие системы лежат нетронутыми годами, пока совсем не прижмёт.
Справедливо, WordPress нейронке знаком до последнего хука, это упрощало дело. Но токены тут ест не «прочитать весь код разом», а пофичный разбор: инвентаризация, домен, потом фича за фичей со сверкой по UI, и в контексте живёт один кусок за раз. На наших двух проектах всё уложилось в стандартную подписку без выжигания лимитов. Самопись на PHP 5.6 с логикой в шаблонах выйдет дороже, спорить не буду, но подозреваю разницу в разы, а не на порядки: UI-сверка дисциплинирует разбор не хуже популярного движка.
Показать не могу, и это честное ограничение псевдонима: два проекта внутренние, живут в корпоративном контуре, третий пока в раннем доступе для своих.
Соблазн понятен, но в моих кейсах LLM встала на место человека, а не алгоритма. SQL по вопросу аналитика раньше писал разработчик, и это тоже был вероятностный процесс, просто вероятность пряталась в человеке: один и тот же вопрос двум разработчикам даёт два разных запроса. Детерминированно эту задачу не решили за тридцать лет, поэтому её и не автоматизировали вовсе.
Дальше вопрос в обвязке. Когда нужна предсказуемость, формулировка задачи для модели меняется с «сгенерируй ответ» на «выбери из закрытого списка или верни: не нашёл». В боте поддержки у меня так и сделано, и он единственный прошёл все ловушки аудита без выдумок. Там, где модель оставлена свободной, она уверенно сочиняла.
Так что граница проходит не между задачами, а внутри системы: вероятностное ядро и детерминированная рамка вокруг него. Проведёшь её явно, получишь рабочий инструмент, оставишь неявной, получишь генератор правдоподобного мусора.
Чек-лист целиком в статье, ядро промта аудита под спойлером там же. Полная версия промта, с форматом карточки и правилами честности аудитора, лежит в закрепе канала: https://t.me/n_cto
Если прогоните аудит на своём проекте, напишите сюда счёт и самый неожиданный факт. Моя гипотеза: пункты «владелец» и «цена запроса» провалены у большинства. Через месяц выложу повторный аудит своих трёх и посмотрим на дельту.
Спасибо за обратную связь! Будут результаты—расскажу на примере
Хороший вопрос. Короткий ответ: спор в отделе был про три варианта, которые у нас уже существовали, а скила не существовало. Длинный: ветка C с енамами — это по сути и есть автоматически собранный скил (DDL плюс смыслы значений, вытащенные парсером из кода), только без ручной курации.
Следующий шаг ровно такой, как вы описываете: курируемый файл знаний о схеме, куда дописаны описания и бизнес-правила, которых нет ни в базе, ни в енамах. Роль партнёра из статьи, которую не нашёл никто, включая меня, — как раз такое знание. Подозреваю, скил закрыл бы часть из 8 нерешённых вопросов.
Останавливает цена: руками описывать 253 таблицы дорого, и это протухает. Рабочий план: генерировать черновик скила из кода, курировать только горячие таблицы. Если у вас есть опыт со скилом над схемой такого размера — покажите цифры, очень интересно.
Собрал в один файл всё, чтобы повторить эксперимент у себя: методику (execution accuracy, правила зачёта, шаблоны обратной связи), промты веток, скрипт сравнения result set'ов и чек-лист «инварианты для каждой метрики». Лежит в закрепе канала: https://t.me/n_cto
Вопросы по методике задавайте здесь, отвечу. Особенно интересно, если у кого-то MCP-ветка ведёт себя иначе — покажите конфигурацию.
Про чёрный ящик поправлю: код агент как раз читал, из него и собиралось ТЗ. UI-прогон был вторым каналом, чтобы сверить «как написано» с «как работает». Кода не читал человек, в этом и был эксперимент.
Про этапы вы правы, и делали мы именно так, просто в статье это слиплось: в промпте первого этапа улучшения запрещены, сначала as-is и сходство один в один, фичи отдельным заходом после валидации ТЗ с заказчиком. Возьму на заметку, что это стоило проговорить жирнее.
Кейс с потерянными исходниками жёсткий, тут наш метод честно упирается в границу: реверсить можно только поведение и то, что осталось от артефактов. 1000 ошибок компиляции после восстановления звучит как отдельная статья. Прайс выше в 30 с лишним раз: ровно та экономика, из-за которой такие системы лежат нетронутыми годами, пока совсем не прижмёт.
Справедливо, WordPress нейронке знаком до последнего хука, это упрощало дело. Но токены тут ест не «прочитать весь код разом», а пофичный разбор: инвентаризация, домен, потом фича за фичей со сверкой по UI, и в контексте живёт один кусок за раз. На наших двух проектах всё уложилось в стандартную подписку без выжигания лимитов. Самопись на PHP 5.6 с логикой в шаблонах выйдет дороже, спорить не буду, но подозреваю разницу в разы, а не на порядки: UI-сверка дисциплинирует разбор не хуже популярного движка.