Полный текст и все выпуски тут:
➡️ССЫЛКА
🟢ИИ в реальной работе
🟢Перестраиваю свою работу и работу компании с помощью ИИ. Опыт заместителя генерального директора - для CEO, собственников и руководителей.
~⏱️ 9–11 минут на чтение, если вникать.
🟢 Ниже - правила, которые сейчас закладываю в свою ИИ. Ответ на вопрос, почему ИИ может галлюцинировать и как это поправить. Также полезно владельцам диктофонов с искусственным интеллектом - увидеть риски использования этого инструмента.
🟢Данные и обязательные контексты
1. ИИ наследует качество данных.
Дубли, пропуски, устаревшие значения и противоречия становятся частью результата. ИИ просто начинает обрабатывать этот бардак быстрее и в значительно большем объёме.
2. Разовая очистка данных не решает проблему.
Нужен полноценный data management: владелец данных, источник истины, правила ввода, обновления, проверки, архивирования и удаления. Начать следует с освоения вот этого «DAMA-DMBOK: Свод знаний по управлению данными. Второе издание»
3. Данными, информацией и знаниями нельзя управлять одинаково.
Данные - это факты. Информация - их интерпретация. Знания - подтверждённые правила, выводы и методики, на базе которых уже можно принимать решения. У них должны быть разные статусы, владельцы и жизненные циклы.
4. Контекст должен трассироваться сверху вниз.
Бизнес-идея → бизнес-модель → бизнес-архитектура → стратегия → проекты → контекст департаментов → процессы → задачи.
Если этой связи нет, ИИ не понимает, почему компания делает то, что делает и даёт поверхностные ответы, которые кажутся глубокими.
5. Контексты департаментов без стратегического уровня ограничивают ИИ.
Он может качественно отвечать по HR, финансам или юридическим вопросам, но будет оптимизировать отдельный участок, не учитывая общую логику бизнеса.
6. У каждого обязательного контекста должен быть паспорт.
Владелец, источник, область применения, уровень достоверности и статус согласования. Особенно в развивающемся бизнесе.
7. У контекста должен быть срок актуальности.
Устаревший контекст опаснее отсутствующего: ИИ воспринимает его как действующий и уверенно строит на нём дальнейшие выводы.
8. Общие и специализированные контексты должны наследоваться по правилам.
Общий контекст компании используется всегда. Контексты департаментов подключаются по релевантности. Бесконтрольное смешивание HR, финансов, юридического блока и других направлений быстро создаёт противоречия и галлюцинации.
9. Анализ рисков и остальные цели по квадрату параметров (производительность, результативность, эффективность) должны быть частью обязательного контекста.
По каждому заказчику, проекту и значимому процессу: финансовые, юридические, операционные, репутационные и информационные риски и достижимость целей по остальном параметрам квадрата. Иначе ИИ будет оптимизировать скорость и результат, не понимая цену ошибки.
10. ИИ должен знать используемый концепт.
Для анализа процесса ему нужны методики BPMN и управления процессами. Для проекта - PMI или другой методический контур. Для финансов - финансовая модель и правила управленческого учёта. Без методики ИИ выдаёт качественно сформулированный здравый смысл, а не профессиональный результат.
🟢Промты, Skills и архитектура
11. Каталог промтов нужен, но его недостаточно.
У промта должны быть назначение, владелец, версия, область применения, тесты и история изменений. Но промт остаётся только инструкцией на входе.
12. Главный актив - библиотека специализированных Skills.
Skill включает условия вызова, входные данные, обязательные контексты, методики, алгоритм выполнения, проверки результата, формат выдачи, исключения и действия при ошибке. Их уже продают локально. Скоро 100% появится рынок Skills.
13. Skill стоит создавать на начальном этапе для высокочастотных операций.
Создать хороший скилл - тяжело. Если делать их пачку сразу - это сильно много времени отнимет. Даже у команды.
14. Повторяющийся сценарий нужно превращать в сервис.
Не отдельный скрипт для каждого отчёта, парсинга или презентации, а единый механизм с подключаемыми источниками, правилами и форматами результата.
15. Новый постоянный компонент нужно проектировать с расчётом на рост в десять раз.
Это относится к структуре данных, идентификаторам, интерфейсам, правам доступа, журналированию и мониторингу. Не к количеству функций первой версии.
16. Глобальная архитектура должна сочетаться с локальным MVP.
Сначала определяется место компонента в общей системе и путь масштабирования. Затем реализуется минимальный рабочий сценарий с конкретной измеримой ценностью.
17. Объём архитектурной разработки нужно ограничивать заранее.
Без границ, критериев готовности и списка того, что сознательно не входит в текущую версию, легко уйти в создание суперсистемы вместо работающего продукта.
🟢Интеграции и эксплуатация
18. Интеграция начинается с бизнес-сценария и метрики.
Подключить Miro, Tilda, VK, Bitrix24, Todoist, календарь или MCP - ещё не результат. До подключения нужно понимать, какой процесс изменится, кто будет пользоваться и как измеряется ценность.
19. До разработки собственного приложения лучше проверить сценарии на существующих интерфейсах.
Telegram, корпоративные системы, браузер и API позволяют проверить реальное использование. Собственное приложение имеет смысл строить после подтверждения устойчивого спроса и ограничений готовых решений.
20. Нужен единый реестр всех интеграций.
Назначение, владелец, источник и получатель данных, права доступа, API, лимиты, стоимость, зависимости, секреты, режим отказа, порядок восстановления и удаления.
21. Нужно исходить из того, что любая интеграция будет периодически ломаться.
VPN, Telegram, авторизация, API, внешние сервисы и форматы данных - нестабильные стыки. Для каждого нужны повторные попытки, очередь, алерт, резервный маршрут и ручной режим.
22. Количество интеграций увеличивает эксплуатационную нагрузку нелинейно.
Каждый новый сервис добавляет зависимости, лимиты, разрешения, секреты, обновления и дополнительные варианты отказа. Само количество интеграций не является показателем зрелости AI-системы.
23. Поддержка системы - отдельная постоянная функция.
У меня уже сейчас на неё уходит минимум час в день: проверить отчёты, восстановить интеграцию, обновить контекст, исправить источник, провести аудит репозитория, проверить бэкапы.
Это время нужно сразу включать в календарь, бюджет и оценку стоимости владения.
24. В оценку интеграции нужно включать весь жизненный цикл.
Исследование, доступы, архитектура, разработка, тестирование, стабилизация, документация, мониторинг, поддержка и последующее отключение. Оценка только времени написания кода почти всегда будет заниженной.
........
Полный текст и все выпуски тут:
➡️ССЫЛКА
🟢Какой профессиональный профиль нужен для развития такой системы
Одного навыка написания промтов недостаточно.
Нужны:
понимание бизнес-идеи\модели\архитектуры и стратегии;
процессное и архитектурное мышление;
data management;
продуктовый подход;
умение работать с API и интеграциями;
информационная безопасность;
экономика и оценка ценности;
управление рисками;
способность быстро принимать решения.
🟢Главный вывод: работа с ИИ достаточно быстро превращается в управление данными, контекстами, знаниями, архитектурой, рисками и эксплуатацией.
Модель важна. Но качество результата всё сильнее определяется системой, которую вокруг неё построили.
➡️Выпуск №1: с чем столкнулся!?
➡️Выпуск №2: какие задачи решаю уже сейчас, сколько времени сэкономил, какие навыки у ИИ развил
⚠️⚠️Тот, кто помог мне стартовать в работе с ИИ. Николай Емельяненко https://t.me/from_nick ⚠️⚠️
Всем успеха.
MAX
ВК
VC
Сайт
Глобальная база знаний: https://miro.com/app/board/uXjVPMeMjGI=/
#ИИ #AI #архитектура #DataManagement #Skills #шаблоны