Transcription
В этом видео я собираюсь раскрыть всю стратегию нашей компании по разработке ИИ, от создания до развертывания пользовательских ИИ-решений. Я проведу вас через весь наш процесс, от этапа исследования до вывода реальных приложений в продакшн. Так что это для вас, если вы начинающий фрилансер, независимый разработчик, хотите создавать пользовательские решения и либо хотите взять то, над чем вы работаете прямо сейчас, и вывести это в продакшн, либо потенциально также продавать это как решение.
Теперь, конечно, все это также применимо, когда вы работаете по найму с 9 до 5 и хотите сделать это в своей компании, но обычно это означает, что задачи, которые я буду рассматривать, и процесс разделены между несколькими людьми и обычно разными командами. Итак, с этим контекстом, давайте приступим.
Для тех из вас, кто меня не знает, меня зовут Дэйв Аблер. У меня более 10 лет опыта в области ИИ. Мы реализовали более 50 пользовательских B2B ИИ-решений. Я начал свою карьеру, работая больше как специалист по данным, и начинал просто как фрилансер, а затем это как бы выросло в то, что я брал на себя больше проектов, больше работы. Я начал работать с людьми. Я взял соучредителей, и так это медленно как бы эволюционировало от меня, как от одинокого фрилансера-специалиста по данным, до управления компанией по разработке ИИ под названием Data Luminina.
Итак, что мы будем охватывать? Мы будем охватывать, как мы создаем пользовательские ИИ-решения для наших компаний. Так что наш стек, я думаю, это важно. Мы всегда строим с использованием Python в качестве нашего языка программирования. Это всегда наш бэкенд-язык. Я расскажу больше о других инструментах и технологиях, которые мы с ним сочетаем. Но мы инженеры Python. Это наше поле деятельности. Оттуда мы всегда начинаем.
Так что это будет полный процесс от исследования до продакшна. И большинство пилотных проектов GenAI, большинство инструментов и проектов, которые люди настраивают с LLM, по-прежнему терпят неудачу. Они по-прежнему не достигают измеримого воздействия, потому что это все еще сложно. Модели становятся все более способными. Я повторяю это на этом канале уже последние 3 года. Так что, в данный момент, я звучу как заезженная пластинка, но сделать это правильно в масштабе по-прежнему чертовски сложно. Так что это также будет основной фокус этой презентации. Как на самом деле создать что-то, что действительно пройдет проверку и что вы действительно сможете вывести в продакшн? И стоит знать, что это почти никогда не модель, а всегда скорее исполнение или отправная точка, откуда вы исходите.
Теперь это связано с объемом, типом проектов, которые вы выбираете. Итак, давайте продолжим, и мы начнем с исследования и выбора вариантов использования. Это отправная точка, где вы либо выигрываете, либо проигрываете проект. Я начну действительно с того момента, когда потенциальный клиент проявляет интерес к работе с вами, или если вы находитесь в компании. Это может быть буквально какой-то менеджер, который запрашивает типичный, типичный запрос. Я не буду охватывать генерацию лидов и все такое в этом видео. Если вам это интересно, дайте мне знать. Я могу осветить это отдельно. Но мы начнем с ознакомительного звонка. Это всегда наша отправная точка, где, по сути, как работает процесс: я публикую много контента онлайн на YouTube, в LinkedIn, и за годы я развил свой личный бренд. Так что теперь у нас много входящих запросов. Так что большинство клиентов, с которыми мы работаем, либо являются нашими существующими клиентами, с которыми мы продолжаем работать, либо входящие клиенты, которые буквально обращаются к нам и говорят: "Привет, Дэйв, я смотрел твои видео. У нас есть проект, с которым, я думаю, ты мог бы нам помочь. Дай знать, если мы сможем работать вместе". Так что это тогда отправная точка, и мы начинаем с этого ознакомительного звонка.
Цель там — раскрыть, в чем на самом деле заключается проблема, а не то, что, по их мнению, им нужно. Это часто может быть сложно в начале. Мы особенно заметили, что, когда LLM только появились, у нас было так много клиентов, которые приходили к нам с конкретным запросом, например: "Привет, мы думаем, что ИИ может сделать это прямо сейчас. Можете ли вы помочь нам это реализовать?" И тогда вы начинаете с этой предвзятой отправной точки, где вы не проводите полную должную осмотрительность, чтобы на самом деле выяснить: "Хорошо, это действительно правильный случай, на котором стоит сосредоточиться?" И часто эти случаи, которые клиенты сами представляли, были либо слишком сложными, либо слишком большими по объему, либо ROI не был ясен.
Так что это действительно то, где вам нужно потратить некоторое время и особенно поговорить о вопросе ROI, потому что создание пользовательского программного обеспечения, даже несмотря на то, что мы можем значительно увеличить скорость, с которой мы можем доставлять прямо сейчас, все равно стоит больших денег. Так что вы действительно хотите убедиться: "Посмотрите, есть ли реальный ROI за этим решением, которое мы собираемся создать?" Вот где вы хотите начать. Вы хотите быть предельно честным.
Затем, конечно, простые вещи, очевидные вещи, верно? Начните с самых простых, высокоэффективных вариантов использования. Легче сказать, чем сделать. В большинстве организаций есть так много низко висящих фруктов, и они совершенно не осознают этого. Так, например, обычно они приходят к нам с большими, насущными проблемами. Так, например, сейчас мы работаем над конвейером обработки документов. Это действительно большая, насущная проблема, потому что почти все сотрудники, работающие в компании, должны как бы обрабатывать эти документы, и они должны соблюдать определенный набор стандартов. Теперь это отличный вариант использования, но вы также можете понять, что количество сотрудников, количество документов, различные типы документов могут привести к такому количеству крайних случаев и ошибок потенциально в производственном приложении, где если вы действительно, например, увеличите масштаб, например, конкретного сотрудника и как бы будете следить за ним в течение дня, чтобы выяснить, что он на самом деле делает, вы найдете часто скрытые процессы, которые могут быть автоматизированы с помощью простой автоматизации, простых интеграций, часто даже не требующих ИИ поверх этого.
Так что я рисую картину здесь, как бы двух концов спектра, где вы можете использовать простые, как бы N8N или Zapier, подобные соединения между ними, где вы перемещаете данные с небольшой автоматизацией и как бы решением на основе LLM, которое обрабатывает документы всей организации. Так что вы можете подумать, что есть, конечно, много промежуточного, но это действительно важно, чтобы начать открывать разговор, чтобы действительно выяснить: "Посмотрите, помимо больших кусков, на которых мы можем захотеть сосредоточиться, какие простые решения могут также иметь действительно высокое воздействие?" Так что всегда выбирайте быстрые победы над лунными выстрелами. Это то, о чем вы говорите во время ознакомительного звонка. Вы углубляетесь.
Теперь, некоторые тревожные сигналы, на которые стоит обратить внимание во время процесса исследования, потому что вы не хотите работать со всеми клиентами. Просто мотивация "мы хотим ИИ, потому что все это делают" может быть отличной отправной точкой для начала разговора. Но опять же, действительно вернитесь к вопросу ROI. Что мы автоматизируем? Вы также хотите убедиться, что есть четкие критерии успеха. Так что некоторые проекты, даже если на бумаге они кажутся отличными, если нет реального способа отслеживать воздействие или определять, что хорошо, а что плохо, и как корректировать курс со временем, создание пользовательских ИИ-решений с этим очень сложно.
Также некоторые клиенты ожидают чудес с первого дня, особенно если вы углубляетесь в более сложные решения и сборки. Когда вы включаете LLM в эту смесь, вы не достигнете 100% успеха с первого дня. И иногда 80% сборки, которую вы доставляете в течение первых нескольких итераций, недостаточно, чтобы уже вывести ее в продакшн, потому что для некоторых задач 80% просто недостаточно. Так что вам нужно быть очень осведомленным о том, как с этим справиться. Мы рассмотрим это позже в этой презентации, но обучение клиента этому критически важно. Опять же, это зависит от варианта использования. Для некоторых это доказано. Это намного очевиднее, но для некоторых вам нужно убедиться: "Посмотрите, мы сделаем это, но просто убедитесь, что это отправная точка. И оттуда нам нужно итерировать". И, конечно же, данные, верно? Так что наличие правильного доступа, проверки безопасности, чтобы вы знали, что вы действительно можете создавать и развертывать необходимые вещи, все разрешения.
Вот что охватывается на ознакомительном звонке, а затем типичные проекты, которые мы берем на себя. Мы много занимаемся обработкой документов, генерацией контента, поддержкой клиентов, помощью с внутренней базой знаний и извлечением данных. Это все проекты, над которыми мы работали за последние два года, которые продолжают возвращаться. Мы, как правило, всегда можем отнести проект, над которым мы работаем, к одной из этих категорий.
Итак, когда мы проходим этот процесс, верно? Так что ознакомительный звонок обычно начинается с 45-минутного звонка, мы углубляемся в то, в чем проблема, чем мы можем помочь, мы углубляемся, а затем мы проводим их через оценку вариантов использования. Так что, прежде чем мы как бы скажем: "Посмотрите, это то, что мы хотим углубить", мы действительно хотим проверить: "Посмотрите, это просто и повторяемо? То есть, можем ли мы на самом деле автоматизировать это, или нам нужно уменьшить объем? Есть ли у него четкие правила успеха/неудачи, которые мы можем проверить? Могут ли ошибки быть переданы человеку?" Это также может быть важно, связано с 80% как бы отправной точки, верно? Так что мы делаем это много в обслуживании клиентов. Мы определяем 80% заявок, которые мы можем обработать, и передаем 20% заявок, которые мы не можем обработать, но которые мы можем классифицировать. Мы передаем их людям. Это отличный пример того, как вы можете что-то построить. Когда это возможно, это хорошо. Но это зависит от типа системы, которую вы автоматизируете.
Теперь также человек в цикле. Это несколько отличается от эскалации человеку, но человек в цикле — это скорее то, где у вас может быть буквально всегда необходимый шаг с участием человека, где кто-то должен просмотреть или утвердить процесс, где это, по сути, эскалация, где автоматизация останавливается. Это также может быть полезно для более быстрого запуска, когда у вас есть этот дополнительный контроль. И затем большая проблема — влияние ошибок. Что происходит, если ИИ ошибается? Это также очень важно, потому что для некоторых вариантов использования ответ, по сути, не так уж плох. Например, если ИИ допускает ошибку в этом случае, никаких проблем, потому что, например, кто-то позже в процессе это заметит. Но если это непосредственно ориентировано на клиента, критически важные процессы, это, конечно, становится более важным.
Хорошо. Итак, давайте углубимся немного в разговор об точности. Это действительно одна из самых сложных частей обучения клиента. Мы уже говорили об этом, но я хочу подчеркнуть это еще раз. Ваша первая сборка обычно достигает 70 или 80% точности. После итерации вы обычно можете достичь 90%. И большинство клиентов, не все, но некоторые клиенты ожидают, что вы сможете достичь этих 99% с первого дня в первой итерации, потому что они привыкли создавать детерминированное программное обеспечение, работая с традиционными компаниями-разработчиками программного обеспечения. Некоторые компании делают это уже десятилетиями. Мы создаем программное обеспечение десятилетиями. Но создание с использованием LLM требует совершенно другого парадигмы. Так что это очень важно сделать, и мы допустили много ошибок в начале, когда мы не были достаточно ясны в этом. Мы также были слишком взволнованы технологией, и это всегда возвращается к вам, и даже несмотря на то, что для некоторых проектов это все еще сложно, когда у вас есть эти обсуждения, где вы фактически создали что-то действительно классное, что находится в этом диапазоне, но для клиента это просто не кажется достаточным.
Так что последняя часть также непропорционально сложна, и именно поэтому большинство проектов терпят неудачу. Так что вы должны рассматривать это как итеративную разработку, а не одноразовое совершенство. Так что будьте ясны в этом. Доставляйте быстро, объясняйте, что это еще не будет готово. И посмотрите, как вы можете создать циклы обратной связи, где клиенту легко предоставить вам обратную связь, а затем вы возвращаете ее в процесс разработки. И ИИ удивителен для этого, обрабатывая такой большой объем обратной связи, а затем создавая или возвращая ее в кодовую базу и создавая PR для этого, которые затем вы можете протестировать. Так что будьте честны: вот как выглядит V1, и вот наш план по его улучшению.
Теперь также стоит учесть, что это потребует участия клиента. Так что в большинстве случаев клиент и кто-то с предметными знаниями могут оценить, как выглядит хорошо. Это не всегда так. Иногда команда разработчиков также может это сделать. Но если требуются предметные знания, вы хотите убедиться, что вы объясняете с самого начала, что потребуется участие в виде времени и ресурсов, потому что в противном случае вы можете оказаться в ситуации, когда вы говорите: "Мы передаем на аутсорсинг агентству, потому что у нас нет внутренних возможностей, верно?" Но теперь нам все равно придется активно участвовать в проекте. Так что опять же, это все просто установка четких ожиданий с самого начала.
Хорошо, тогда давайте перейдем к определению объема и приоритизации. Это одна из самых сложных вещей в индустрии технологий в целом, и она становится еще сложнее, когда вы включаете ИИ. Так что именно здесь вы как бы создадите предложение. Итак, после ознакомительного звонка иногда другой звонок будет обычно создавать предложение, которое является просто документом, описывающим практически все, что мы собираемся сделать. И первое и самое важное — решить, что оно будет делать, а что не будет.
Так что распространенные проблемы, с которыми вы можете столкнуться здесь, это то, что вы что-то создаете, а клиент практически говорит: "Эй, а может ли оно также делать X? Можете ли вы добавить это в начале процесса?" Затем еще одна вещь — недооценка непредсказуемости. Так что начинать откуда-то, и опять же, это все еще часто возвращается к нам, когда мы как бы были немного слишком уверены в том, что может сделать LLM, а затем выясняли, что в масштабе это ломается. Конечно, у нас всегда есть крайние случаи, которые могут быть сложными, и чрезмерное создание первой версии также может быть сложным, потому что обычно для большинства решений у вас есть, как бы, одна метрика, которую вам нужно достичь, и если вы ее не достигнете, практически все решение не работает. И иногда вы обнаружите, что можете как бы чрезмерно проектировать, конечно, части приложения, например, на фронтенде, на интеграции и на всем остальном, в то время как основные метрики еще не установлены. Так что убедитесь, что вы критически определяете объем в начале, чтобы вы знали, каков наш KPI, на что мы оптимизируем.
Итак, обычно мы начинаем с, как бы, одного основного рабочего процесса: что мы собираемся автоматизировать? Как выглядит ввод? Как должен выглядеть вывод? А затем мы можем перечислить обязательные и желательные функции, и мы рано выявляем технический риск и устанавливаем четкие критерии приемки.
Теперь, как правило, наши первые типы проектов попадают в две категории. Итак, мы либо оформляем их как концепцию доказательства, либо как MVP, и разница между ними немного тонка. Концепция доказательства, по сути, означает: "Эй, посмотрите, это захватывающий проект. Мы уверены, что сможем что-то для вас создать, но мы пока не на 100% уверены, достигнет ли текущее состояние ИИ и то, как мы строим вещи, KPI и метрик, которые вы хотите". Так что мы докажем это. Поэтому мы называем это концепцией доказательства. Нам нужно доказательство. Сначала что-то работает. Если мы уже знаем, что что-то будет работать, потому что мы уже что-то создали в прошлом, или это более простое решение, мы определим объем первой итерации как минимально жизнеспособный продукт.
Теперь одно из самых важных различий, которое нужно сделать также в вашем общении: концепция доказательства, как правило, не является чем-то, что добавляет ценность. Это обычно локальная демонстрация, локальный скрипт, демонстрация того, что если мы возьмем эти входные данные, пропустим их через систему, вот вывод. И тогда вы и клиент соглашаетесь с этим, когда они говорят: "Это хорошо. Это то, что нужно". И если это не то, что нужно, мы проводим анализ пробелов, смотрим, как мы можем туда добраться. Но обычно это то, где клиент отправляет как бы первые деньги или счет, а вывод, как правило, является демо и отчетом. Так что будьте откровенны об этом, потому что иногда клиент ожидает, что это уже рабочее решение. Но это не так с MVP. Это другое. MVP — наша цель всегда — создать что-то реальное и ощутимое, что действительно добавляет ценность. Каков минимально жизнеспособный продукт, который мы можем доставить, развернуть, передать, поместить куда-то, где он может фактически принести эту ценность? Так что это очень важно в определении объема и приоритизации, и как мы к этому подходим.
Хорошо. Теперь давайте поговорим о предложении. Что мы туда помещаем? Итак, что входит в наши предложения? У нас есть примерно стандартный документ, который мы всегда используем. Итак, мы начинаем с постановки проблемы. Так что сформулируйте это словами клиента. Это то, что мы узнали во время ознакомительных звонков, верно? Так что перефразируйте это еще раз. Какую проблему мы решаем? Затем мы переходим к предлагаемому решению с границами объема. Так что можно сказать: "Вы сталкиваетесь с XYZ. Вот что мы собираемся сделать, чтобы решить это". А затем вы можете перейти к более детальному техническому подходу. Так что вы можете сделать архитектурные диаграммы. Вы можете перейти к функциям и возможностям. Зависит от сложности проекта, насколько глубоко мы будем копать здесь, а затем что включено, а что нет, критерии успеха и измерения, а затем, конечно, вы как бы заканчиваете, завершая графиками и ценами.
Итак, как мы сейчас предпочитаем структурировать наши спринты: мы всегда начинаем с двухнедельных спринтов. Так что индустрия технологий очень сложна. Вы можете брать проекты, где вы говорите: "Эй, мы построим все это, и вы определите объем на, я не знаю, 10 недель, и вы начнете это строить". Это один подход. Мы часто находим, что это лучше работает для нашего подхода, где мы просто начинаем с двухнедельного спринта. Это как: "Посмотрите, что мы можем сделать за двухнедельный спринт?" Либо с точки зрения MVP, либо что нам нужно доказать, а затем мы оценим это в размере от 10 000 до 20 000 евро за спринт. Вот как мы это настраиваем. Это также позволяет нам делать и планировать наши спринты соответственно. Мы можем делать несколько спринтов одновременно, в зависимости от нашей мощности. В настоящее время, кстати, я не упоминал, но мы управляем небольшой командой прямо сейчас. Я управляю Data Luminina Solutions, агентством, с одним другим соучредителем, а затем это просто субподрядчики, в зависимости от контрактов, над которыми мы работаем. Иногда это просто я и мой соучредитель, и мы делаем это очень намеренно прямо сейчас, потому что мы не хотим масштабироваться с количеством сотрудников. Мы пробовали это в прошлом году. Это один из способов сделать это, но это не совсем тот тип бизнеса, который я хочу строить. Мы теперь масштабируемся за счет ИИ, потому что это просто безумие. Скоро я расскажу больше о нашем конкретном процессе работы с облачным кодом и о том, как мы это делаем. Но это дает вам отправную точку, чтобы увидеть: "Посмотрите, мы можем делать эти спринты по 10-20 тысяч евро, в зависимости от размера и сложности, с небольшой командой мы можем проводить несколько спринтов подряд". Это отличная бизнес-модель, и да, что мы будем оценивать или что мы будем указывать в ценах, это также текущие расходы. Это то, что новички часто забывают, говоря: "Эй, я построю этот чат-бот для вас за 5 тысяч, хорошо, но что происходит потом?"
Будете ли вы развертывать его в своей среде? Будете ли вы развертывать его в среде клиента? Каковы связанные с этим затраты на инфраструктуру? Используете ли вы LLM? Каковы затраты на API? Как это выглядит? Дайте примерную оценку, потому что очень трудно предсказать это заранее полностью, но дайте примерную оценку, скажем: "Эй, помимо этих первоначальных затрат, вот текущие затраты на это решение". И тогда, как я уже сказал, мы всегда сначала оформляем его как MVP или концепцию доказательства.
Итак, у нас есть этот документ, предложение. Мы отправляем его клиенту, и мы обычно планируем еще одну встречу по предложению, где мы вместе рассматриваем предложение, чтобы выяснить, нужно ли нам внести какие-либо изменения, все ли мы на одной волне и так далее. Круто.
Теперь, как мы структурируем наши спринты. Итак, две недели, мы всегда следуем этому процессу. Итак, две недели, день первый — настройка архитектуры. Это действительно каркас, создание проекта, настройка всего. Затем дни с третьего по восьмой — это, по сути, основная разработка. Создание рабочего процесса, интеграция LLM, итерация по качеству, а затем финальные дни — тестирование, полировка и демонстрация. Иногда мы уже отправляем что-то клиенту. Это, как правило, то, как выглядит двухнедельный спринт.
И тогда в начале для новых клиентов мы всегда проводим стартовое совещание. Итак, обычно мы всегда начинаем новые спринты в понедельник. Так что, в идеале, как бы в понедельник днем, что-то вроде этого, у нас будет стартовое совещание с клиентом, чтобы просто прийти к общему пониманию, обсудить, как мы будем общаться, установить правильные ожидания. Очень важно. И тогда мы всегда настаиваем на асинхронных обновлениях. Мы не хотим проводить стендапы. Я оптимизирую весь свой бизнес для минимального количества встреч. Так что иногда клиенты говорят: "Эй, должны ли мы провести стендап?" "Нет, нет, нет". Так что иногда приходится немного оттолкнуть. Мы хотим делать асинхронные обновления как можно больше, а затем, конечно, в конце мы проведем еще одну демонстрацию, и здесь мы снова созвонимся и проверим, как идут дела, и спланируем, как будут выглядеть дела для следующего спринта.
Теперь, как правило, вы обнаружите, что это как бы некоторые из выводов, которые вы получаете, когда управляете компанией по разработке, верно? В идеальном мире вы как бы начнете с нового проекта, и посмотрим, вы начнете, так что у вас будет первый спринт здесь, это как бы, давайте назовем это спринт номер один, вы видите это, да? И тогда как бы вы переходите к следующему, и это будет спринт номер два, верно? Так что в идеальном мире это будет выглядеть так. Но часто, почти всегда, вы обнаружите в реальном мире, что происходит после того, как вы доставите, как бы, спринт один, то есть вы доставляете клиенту, клиент теперь как бы внутренне как бы исчезает, говоря: "Да, мы проверяем вещи и тестируем их внутренне". И дело в том, что люди и компании всегда заняты. Так что работа, которую вы делаете, даже если она является приоритетом, доказано, что она принесет ROI, как только вы как бы отключитесь от звонка с ними, они вернутся к обычному бизнесу, и компании, особенно когда они растут, просто двигаются медленно, и они не привыкли к тому, как мы можем работать, особенно сейчас с ИИ, мы можем очень быстро выпускать продукты, а затем им просто нужно тестировать, и им нужно внутренне оценить: "Хорошо, что у нас есть прямо сейчас?" И обычно тогда происходит то, что потребуется некоторое время, прежде чем вы сможете спланировать еще один спринт. Скажем, спринт два, и это может занять от двух, иногда, о, простите, иногда даже до восьми недель, когда люди просто исчезают, а кто-то в отпуске, и это действительно сложно для вашего денежного потока как компании-разработчика, или если вы делаете это самостоятельно, как я начинал как фрилансер, потому что когда вы находитесь в начальной точке здесь, все клиенты очень взволнованы, и они говорят: "Да, мы построим эту удивительную вещь, и будет ли это работать?" Это превратится в это, будет больше проектов, и так начинаются все проекты. Но затем они как бы сталкиваются с реальностью. Обычно это выходит и говорит: "О, посмотрите, сейчас мы на 80%". Хорошо, это работает, и вы просите их собрать обратную связь, и это занимает больше времени, чем они ожидают, и теперь это может стать немного сложным.
Теперь, как я уже сказал, это не всегда так, но особенно если вы работаете с малыми и средними компаниями, где либо непосредственно основатели более активно участвуют, они заняты, и им нужно переоценить, и им нужно переприоритезировать, и это может быть, как я уже сказал, действительно сложная вещь. Так что, как мы это смягчаем, обычно мы как бы немного перепланируем, где, даже если клиент сказал: "Да, мы продолжим напрямую со следующим спринтом", у нас уже есть другой клиент или новый проект в очереди. И если, по какой-либо причине, они происходят одновременно, что иногда случается, это становится действительно занято, но в наши дни с облачным кодом и привлечением другого субподрядчика, например, по проекту, это все еще управляемо, это все еще возможно, но иначе у вас просто есть эти большие пробелы. Так что это просто то, что нужно иметь в виду, когда вы работаете по спринтовой модели. Это повторяется. Это работает, но эти пробелы — это просто вызов, с которым вам нужно работать. Хорошо. Хорошо.
Тогда давайте рассмотрим наш стек. Итак, как мы строим вещи? Я быстро пройдусь по этому, потому что это довольно простой стек. Итак, наш бэкенд всегда основан на Python. Так что мы построили все это на архитектуре GenAI Launchpad, которую я указал здесь. Это больше, чем просто фреймворк, это целая инфраструктура и фреймворк в сочетании, которые мы построили в Data Luminina. Он доступен, вы можете проверить его, если хотите. Это launchpad.dataluminina.com. Мы предлагаем это как платный продукт, но это, по сути, вся бэкенд-система, которую мы используем для всех наших клиентских проектов. Он поставляется с FastAPI, Celery, базами данных PostgreSQL. Мы обычно используем для этого саморазмещенный Superbase, а затем как бы Redis и Celery работают вместе, потому что мы используем Redis как промежуточное хранилище, где мы планируем наши задачи, и именно так мы строим наши бэкенды. Опять же, мы используем наш GenAI Launchpad для этого, и это одна из ключевых вещей, которые нужно понять. В том, что мы делаем, нет ничего особенного, кроме того, что все стандартизировано. Это действительно наш секрет способности иметь такой быстрый оборот, активно использовать ИИ и иметь последовательный тип качества.
Так что для каждого нового клиентского проекта мы просто форкаем этот репозиторий, и оттуда мы начинаем. Так что я уже знаю, что вся конфигурация Docker настроена. Я знаю, что я могу запустить несколько простых bash-скриптов, которые у нас есть. Он запустит локальную среду разработки. Так что Docker запустится. Там есть база данных. Аутентификация настроена. Если нам нужны какие-либо возможности поиска по вектору, они там есть. У нас есть целый Python-модуль для создания рабочих процессов на основе векторов. Он подключен к Pydantic AI, и самое главное — структура файлов. Так что, как бы, как устроен проект, также стандартизирован в этом, потому что мы используем это, это целый репозиторий. Так что для каждого проекта, на который я как бы переключаюсь, я могу сразу увидеть, я точно знаю, где находятся вещи, потому что все папки и даже файлы, все одинаково. Так что это, по сути, единственный способ работать над несколькими проектами одновременно, потому что иначе это становится слишком беспорядочно.
Теперь мы делаем много бэкенд-работы, но когда нам нужен фронтенд, это наш предпочтительный стек. Next.js с Tailwind CSS интегрируется очень хорошо, когда мы работаем с Superbase для аутентификации. Вот как мы это настраиваем. Это в основном мой соучредитель, Юрус. Я действительно только как бы бэкенд-инженер. Я сейчас как бы кодирую с этим, и это идет очень хорошо, но большую часть вещей настраивает Юрус. И тогда обычно, почти всегда, для поставщиков LLM мы используем Azure OpenAI. Не очень доволен этим. Это как бы раздражает. Они меняют свой интерфейс почти каждый месяц, и квотой трудно управлять. Но для большинства наших клиентов это, как бы, единственный способ, которым мы можем соблюдать требования к данным и безопасности. Так что мы используем Azure OpenAI для получения конечных точек API LLM.
Большой вывод: тот же стек, те же шаблоны, тот же процесс развертывания для каждого проекта. Вот что мы делаем. Хорошо.
Тестирование и оценка, одна из самых критических вещей, верно? Во-первых, у меня есть полное видео на YouTube, полный курс по этому, как систематически настраивать LLM-тесты. Я быстро рассмотрю это здесь, но для каждого проекта мы убеждаемся, что мы настраиваем модульные тесты, мы проводим интеграционные тесты, а затем также очень важно, мы проводим LLM-тесты, которые мы обычно также настраиваем в начале, просто проводя модульные тесты. Как это работает? Ну, когда мы используем наш Launchpad, практически каждый вывод шага обработки — это модель Pydantic со структурированным выводом, и тогда то, что мы можем сделать вокруг наших LLM-файлов. Мы знаем данные, которые поступают. Мы знаем на определенных шагах, какой вывод мы ожидаем. Так что в начале мы настраиваем это с помощью ИИ, обычно. Мы помечаем некоторые фиктивные данные, но затем позже мы постоянно извлекаем необработанные записи из базы данных. Каков был входящий полезный груз? Мы помещаем его локально в проект, а затем создаем маршрут оценки LLM, где мы говорим: "Эй, если вы возьмете это JSON-событие, необработанный JSON, пропустите его через наш рабочий процесс, тогда мы знаем, что на шаге пять вывод должен быть таким, и, например, если есть эскалация или эскалация, например, должна быть истинной для этого конкретного события", и вот как вы можете их настроить.
В последнее время мы также делаем, это очень круто. Мы создаем настоящие навыки. Так что skills.md с облачным кодом для создания этого. Так что, когда клиент практически говорит: "Эй, вот проблема", у нас есть скрипт, который может извлечь этот конкретный билет или идентификатор из базы данных, поместить его локально в проект, а затем как бы провести оценку того, что идет не так. Но это очень важно. Опять же, если вы хотите узнать больше, посмотрите другое видео на YouTube, которое у меня есть по этому поводу.
Хорошо, тогда давайте поговорим о рабочем процессе разработки. Как мы к этому подходим? Итак, как я уже сказал, мы активно используем облачный код. В прошлом году мы хотели масштабироваться с большим количеством разработчиков, все больше и больше людей, но это уже не нужно прямо сейчас. И для того масштаба, в котором мы ведем эту компанию, которая в настоящее время составляет много шестизначные суммы, мы не хотим или не должны масштабироваться с большим количеством людей. Вы можете, но будет этот пробел, скажем, вот где мы сейчас. И если вы как бы хотите быть здесь, где я не знаю, вы, скажем, с 12 или около того, 12-20 разработчиками, вы будете агентством или бутик-фирмой разумного размера. Так что, скажем, в настоящее время мы находимся здесь, а здесь вы как бы делаете чуть меньше миллиона, скажем, долларов США, а здесь вы хотите сказать, что хотите достичь 10 миллионов или что-то в этом роде с вашей компанией, вы можете туда добраться, и это возможно, но начало здесь будет очень беспорядочным, потому что когда вы переходите от очень маленькой компании, активно участвующей, и как бы просто работающей как преувеличенные фрилансеры, переход к полноценной компании-разработчику очень отличается. Ваши роли и обязанности будут выглядеть очень по-разному.
Так что сначала вам придется пройти через грязь здесь, где вам нужно находить и нанимать людей, вам нужно их обучать, вам нужно их удерживать, и именно здесь становится очень напряженно. Так что стресс будет расти, потому что вы по-прежнему несете ответственность за все проекты. Вам теперь также приходится контролировать всех людей. Они недостаточно хороши и недостаточно обучены, чтобы следовать всем вашим стандартам, но вам приходится платить им зарплату. Так что сначала вы обнаружите, что прибыль действительно упадет, а уровень стресса возрастет. Так что это прибыль, это стресс. Так что вы можете видеть, что это как бы сложная ситуация, через которую вам придется пройти. Теперь вы определенно можете добраться до другого конца, но это не то, что мы хотим делать.
Так что давайте посмотрим, если я, мы полностью довольны ведением этой компании по разработке в текущем масштабе и размере, и вместо этого мы хотим сосредоточиться на программном обеспечении. Так что мы чувствуем, что сейчас еще есть, как бы, двухлетнее окно, когда вы действительно можете получать прибыль от программного обеспечения, а за его пределами я не знаю, как это будет выглядеть с ИИ, но вещи будут другими, но мы скорее хотим создать продукт, над которым мы уже работаем прямо сейчас. Так что вместо масштабирования агентства и принятия на себя большего количества клиентской работы, мы хотим создавать наши собственные внутренние инструменты. Теперь, конечно, у меня также есть вся образовательная сторона Data Luminina, YouTube, курсы и все такое. Так что у нас много всего происходит, но именно так мы это приоритизируем.
Так что это был небольшой отступ, чтобы понять: "Хорошо, как мы структурируем наши команды?" Очень мало людей, мы активно используем облачный код, и это наш основной инструмент разработки для всех проектов, и мы можем буквально создавать в пять-десять раз больше, чем три года назад. Я могу уверенно сказать, и в целом сейчас мы можем практически взять предложения, и этого обычно достаточно, чтобы взять это, поместить в markdown, и с нашим фреймворком GenAI Launchpad мы уже можем получить примерную настройку того, как выглядит проект, но это лучше всего работает со стандартизированными кодовыми базами, поэтому я продолжаю подчеркивать, что мы всегда начинаем с того, где мы находимся, этот фреймворк, так что все выглядит одинаково. Хорошо, так что это было также здесь на слайде, Launchpad. Это то, что мы делаем.
Так что, буквально, если вы посмотрите на это, то, что раньше занимало у нас два месяца, теперь мы можем выпустить за две недели. Именно поэтому мы можем создавать или проводить эти двухнедельные спринты. Хорошо.
Теперь давайте поговорим о нашей настройке облачного кода. Теперь есть, на самом деле не так много секретного соуса, которым я могу поделиться, потому что, как и Борис, один из членов Entropic, который создал Entropic, который также сказал: "Я просто использую его. Он очень хорошо работает из коробки". Это также мое ощущение по этому поводу. Я знаю, что есть люди, которые сходят с ума по рабочим деревьям, навыкам и субагентам и этим сумасшедшим системам. Я просто использую облачный код. Вот практически все, что я делаю. Это довольно стандартная настройка. Opus 4.6 прямо сейчас на день записи. В будущем может быть иначе. Это модель прямо сейчас. И я буквально чувствую, что обвязка вокруг нее улучшается еженедельно, и Entropic также не сидит на месте. И я обычно предпочитаю работать с одной-тремя сессиями одновременно. Я хочу оставаться под контролем. Я не делаю, как бы, 10 агентов и рабочие деревья и все такое. Обычно только один или два, иногда до трех сессий одновременно. Если я не могу сделать это в той же ветке, где вам нужны рабочие деревья, то это слишком много для меня, потому что я не могу контролировать, что она делает. Так что я всегда сначала использую режим планирования, затем выполняю. Вы просто всегда должны помнить о контекстном окне. Каждая сессия начинается заново. Так что убедитесь, что вы структурируете свою документацию вокруг этого. Это самое важное, что нужно иметь в виду при работе с этими инструментами. Так что убедитесь, что ваши файлы cloudmd обновлены. Это все стандартные вещи, верно? Вы можете использовать файлы cloudmd также во вложенных папках. Это важно. Позвольте ИИ создавать документы. Так что у нас всегда есть папка docs, на которую мы ссылаемся. И помните, когда, потому что каждая сессия начинается заново, вы создаете новую вкладку, верно? Она ничего не знает. Она ничего не знает о вашей кодовой базе. Так что, когда я начинаю заново, я как бы, "Хорошо, мы собираемся выполнить новую задачу". Я обычно как бы немного подготавливаю ее. Например: "Эй, вот над чем мы собираемся работать. Сначала прочитайте эти два документа, а затем посмотрите на эти два файла". Так что я уже намекнул, куда нужно идти, потому что если вы просто спросите ее: "Эй, создай это в новой сессии", она переиндексирует вашу кодовую базу, и она сама будет думать и пытаться искать все. Так что, когда у нее будет достаточно контекста, вы можете быть уже на 50%, а затем вы начнете работать над этим, и вы довольно быстро снова достигнете контекстного окна, и проблема начнется снова. Так что будьте конкретны, говоря, куда ей следует смотреть сейчас.
Теперь две вещи, с которыми я все больше и больше экспериментирую, или как бы, с чем я сейчас работаю. Во-первых, это суперспособности. Это навык, который вы можете найти, если вы используете облачный код, суперспособности. Это набор навыков, который хорош для действительно больших, как бы, длительных задач. Так что там есть планирующий агент, исполнительный агент и рабочий процесс разработки субагента. В этом есть больше, но это как бы цикл, который я использую. Так что я настоятельно рекомендую попробовать. Мне это нравится до сих пор. И что еще круто, у Entropic также есть официальный инструмент для создания навыков, что очень мета, я знаю, но вы можете буквально сказать: "Эй, это то, что я хочу сделать", и если я когда-нибудь обнаружу, что делаю что-то в проекте более двух или трех раз, я теперь стараюсь создать вокруг этого навык. Это очень мощные вещи. Хорошо.
Теперь давайте перейдем к развертыванию и инфраструктуре. Как мы берем все, что мы построили, а затем как мы это развертываем? Где мы это размещаем? Каков стек? Хорошо. Итак, это наш процесс. Итак, мы работаем локально. Мы отправляем все в GitHub. Затем через конвейер CI/CD мы размещаем все на виртуальной машине Hetzner. Так что Hetzner — это облачный провайдер. Мы просто получаем виртуальную машину bare metal, никаких управляемых сервисов. Мы просто как бы клонируем репозиторий туда и запускаем команды запуска Docker. Вот как мы развертываем. Так что обычно это начинается так. И тогда, если мы хотим сделать CI/CD, мы настраиваем конвейер CI/CD на основе пула, где GitHub Action запускает развертывание. А затем у нас есть скрипт, работающий на виртуальной машине Hetzner, который как бы извлекает данные туда, а не отправляет их. И тогда мы убеждаемся, что мы настраиваем все наши URL-адреса, все наши развертывания через Caddy с обратным прокси. Так что по умолчанию, если вы развертываете на виртуальной машине bare metal, она будет развернута под IP-адресом этой виртуальной машины. И, конечно, вам нужен хороший URL, верно? Вот где мы используем Caddy. И тогда ваше приложение практически будет жить и доступно с автоматическим HTTPS, добавленным к нему, потому что Caddy это исправляет. Так что это, как бы, наш стек. Hetzner для всего. Они очень дешевые. Они надежные. Мы используем это уже много лет. Сначала мы использовали Microsoft Azure, AWS. Больше не можем с этим справиться. Это буквально в 10 раз дешевле. Docker Compose. Так что контейнеризация с первого дня. Это уже с настройки. Так что стартовый проект, который мы использовали с Launchpad. Вот почему мы можем легко это настроить. Это я уже покрыл. Так что вот как мы развертываем наши решения, если мы можем решить, как их развернуть. Если мы развертываем их в нашей среде, иногда клиент говорит: "Эй, вы можете построить это и развернуть в нашей среде". И вот где иногда нам нужно вмешаться. Обычно здесь, в Нидерландах, это либо Azure, либо AWS, крупные игроки, верно? AWS или GCP. Все работает примерно одинаково. Если вы знаете, как развернуть на виртуальной машине bare metal на Hetzner, вы также можете разобраться, как это сделать. Круто.
Тогда давайте поговорим о безопасности. Очень важно. Так что для всех наших развертываний мы хотим блокировать все IP по умолчанию. Так что это то, что особенно для людей, которые новее в развертывании, CSD, разработке программного обеспечения в целом. Если вы понятия не имеете, что вы здесь делаете, по умолчанию практически всегда вы подвергаетесь риску, и практически каждый может попытаться атаковать вас. Так что вы действительно хотите принять дополнительные меры для этого. Так что, как мы это настраиваем, мы всегда защищаем наши развертывания с помощью блокировки IP, а затем мы используем инструмент Nlayer, где у меня и команды есть выделенный IP. Так что это, по сути, VPN, где, если я его включаю, я получаю выделенный IP. Он фиксированный. Он статический. Так что мы можем внести его в белый список в нашей, например, базе данных. Так что, если я хочу работать локально и хочу подключиться к нашей производственной базе данных, это можно сделать только через этот VPN. Мы разрешаем базе данных взаимодействовать с сервером только в том случае, если она не находится на сервере. Иногда, обычно это в том же развертывании, но только внутри, или если мы затем делаем локальную разработку через наш собственный статический IP. Так что вы хотите блокировать все по умолчанию, а затем вносить в белый список сервисы, такие как фронтенды или интеграции, которым нужен доступ. Затем вы хотите установить брандмауэр на вашем, да, брандмауэр на вашем развертывании, а также на вашем сервере, и практически иметь открытыми только порты 80 и 443 для сетевого трафика. Все остальное остается за брандмауэром, и используйте частные сети внутри, когда это возможно, в вашем развертывании. Так что это, как бы, поверхностно, и опять же, Юрус — наш эксперт по безопасности. Он всегда охватывает все это, но это действительно, как бы, минимальный набор, который вам нужно проверить, когда вы развертываете клиентские решения.
Хорошо, тогда давайте поговорим о мониторинге и наблюдаемости, также одна из тех вещей, которые очень важны. Знайте, что делает ваш ИИ в продакшне. Так что у нас есть два секретных оружия для этого. Так что первое — это Langfuse для всех наших трассировок LLM. У нас также есть наш Launchpad, полностью подключенный к Langfuse, так что всякий раз, когда мы создаем рабочий процесс, он автоматически отслеживает все в Langfuse. Так что это очень полезно. И
Затем мы используем Sentry для отслеживания ошибок. Так что это мониторит наше приложение. Так что это, как правило, вокруг нашего конечного API Fast API. Так что всякий раз, когда данные проходят через систему, и у вас возникает какая-либо ошибка, она проявится. У нас это подключено к каналу Slack. Так что всякий раз, когда что-то не так, мы получаем уведомление в Slack, чтобы мы могли внести коррективы. Langfuse занимается исключительно выходными данными LLM, гарантируя, что все работает, оптимизируя запросы, и вот как это выглядит в Langfuse, например. Итак, вот реальный скриншот от одного из наших клиентов. Это один из самых сложных проектов, над которым мы работаем и оптимизируем уже более полутора лет. Это конвейер поддержки клиентов. И здесь вы можете увидеть, как поступают все трассировки. Так что это буквально с сегодняшнего дня. Я сделал скриншот. Так что вы можете увидеть, что примерно каждые 20 или 15 минут поступает запрос, обрабатывается, а затем у нас есть весь этот конвейер здесь, который начинается с серии проверок. Это все очень детерминировано, но все залогировано. Так что мы можем видеть, что происходит. А затем здесь вы можете увидеть, что мы используем узел агента. Так что ChatGPT 2.5, в данном случае чат, для выполнения некоторого анализа. А затем мы решаем, куда это должно течь в DAG, и у нас есть несколько вызовов LLM, и вы можете увидеть, что это продолжится и вниз. Вот как мы можем с очень точной детализацией, когда клиент говорит, что что-то не так, мы можем буквально углубиться до шага, где у нас есть весь контекст, запрос и то, что произошло за кулисами. Это обязательно для всех проектов, иначе вы буквально летаете вслепую. А затем здесь пример Sentry. Это тоже скриншот, который я сделал сегодня утром, где это просто обработка ошибок. Так что, когда вы работаете локально и получаете ошибку в терминале, вы можете сразу ее заметить, верно? Когда вы помещаете это на сервер и работаете с асинхронными событиями, ваш сервер не упадет, если он столкнется с чем-то подобным, ваш конечный API останется доступным. Он просто не обработал это конкретное событие. Так что, если вы не настроите никакого логирования, вы понятия не имеете, что происходит за кулисами. Вот где может помочь Sentry. Так что здесь вы можете увидеть типичный тип вещей, у нас была ошибка типа. Так что я импортировал некоторые отзывы с помощью веб-хука. Так что объект данных веб-хука senda не является подстрочным. Так что вы можете буквально увидеть, как Sentry помечает это в этом конкретном рабочем процессе. Так что узел upsert testimonial node.py, строка 66, здесь вы можете увидеть, что он не является подстрочным. Так что он попытался взять event data new, и, вероятно, это уже было вместо словаря, это, вероятно, была модель Pydantic или что-то в этом роде, а затем крутая вещь в том, что вы можете буквально взять это все, вы можете скопировать это как markdown. Так что посмотрите, вы можете увидеть это здесь, скопировать как, и вы можете скопировать это как markdown, и угадайте, что вы можете с этим сделать? Вы можете вставить это в облачный код, и он исправит это на месте. Так что это также очень полезно для обработки ошибок.
Хорошо, давайте поговорим об изменении экономики разработки с помощью ИИ. Так что означает ли это в 2026 году работать фриланс-разработчиком или управлять компанией по разработке ИИ? Так что это, как правило, наша текущая настройка, верно? Мы делаем от 10 до 20 тысяч за двухнедельный спринт, но мы можем буквально в 5-10 раз увеличить наш объем по сравнению с тремя годами назад. Так что экономика единицы меняется. Так что на протяжении десятилетий, действительно, технологическая индустрия в основном работала по ценам, основанным на времени, почасовой оплате, дневной оплате. Вот что вы получаете. Но это начинает становиться немного сложным, потому что вы можете сделать так много больше. Вы можете использовать ИИ-агентов, которые работают в фоновом режиме. Вы можете буквально запустить 10 агентов, пойти в спортзал. Вы можете вернуться, и они практически выполнили работу за неделю. Так как же вы с этим справитесь? Так что мы сейчас в пробеле. Для большинства компаний они все еще понимают, какова цена программного обеспечения и сколько стоят вещи. Так что я чувствую, что сейчас мы находимся в идеальном месте, потому что теперь вы все еще можете устанавливать такие цены, и компании все еще полностью согласны с этим. Вы можете просто делать это намного быстрее и, следовательно, предоставлять больше ценности. Так что, как мы к этому подходим, вместо того, чтобы участвовать в гонке на дно и говорить: "Эй, мы можем построить всю эту систему для вас за 3 тысячи, мы практически сохраняем ту же цену. Мы знаем, что можем доставить намного быстрее. Вы никогда не знаете, сколько времени это займет, потому что это тоже странно с агентами, верно? Иногда они просто рвут его, и работа за день может быть выполнена за один запрос." Так что это тоже, нам еще предстоит это выяснить. И вот как мы это делаем: мы используем скорость, чтобы работать над большим количеством проектов, не занижая цену и просто предоставляя больше ценности, потому что это в конечном итоге то, что мы можем сделать. Мы можем теперь доставить за две недели намного больше, чем раньше, и запросы вроде "Эй, может ли он также делать X или Y" теперь намного проще реализовать. Так что мы просто перевыполняем работу в этом смысле. Но конкуренты и рынок, они, конечно, адаптируются. Как я уже сказал, поэтому я чувствую, что мы сейчас находимся в золотом веке, потому что инструменты настолько хороши, но рынок еще не догнал. Вот почему сейчас очень выгодно быть независимым разработчиком, фрилансером, управлять своей компанией по разработке ИИ, потому что вы можете просто делать это даже рядом со своей работой, например, по выходным или вечерам, потому что, возможно, в течение вашего рабочего дня вы можете просто запустить несколько агентов, которые будут работать над вашими клиентскими проектами. Так что да, это текущая ситуация, и давайте поговорим немного о долгосрочной перспективе, потому что сейчас мы в основном говорили о первом стартовом моменте с клиентами, верно? Первый, так сказать, двухнедельный спринт, а затем продолжение оттуда. Но то, что вы хотите сделать, и вот где вы зарабатываете реальные деньги в программном обеспечении, это стать, так сказать, их программным партнером или даже партнером по разработке ИИ, потому что начало всегда самое сложное, действительно. У вас есть проблемы с определением масштаба, с установкой ожиданий. Переход от нуля к одному сложнее, чем переход от, скажем, одного к, "Можете ли вы добавить пару новых функций?" Так что это действительно то, на чем вы хотите сосредоточиться. Как только доверие построено, новые проекты приходят естественно. У нас есть клиенты, с которыми мы работаем уже 5 лет, и это продолжается. Технические проекты, программное обеспечение никогда не бывает закончено. Есть обслуживание, есть новые функции, есть обновления. Так что вы хотите иметь эти повторяющиеся спринты, которые также являются предсказуемым доходом. И это действительно одна из самых важных вещей. Так что, например, если вы начинаете, если вы думаете о начале, вам не нужно много клиентов. Это также то, чему я учу фрилансеров в своей программе. Если вы разработчик любого типа или специалист по данным, посмотрите, это все может быть в области аналитики, специалиста по данным, инженера машинного обучения, разработчика программного обеспечения, инженера ИИ, инженера данных, все это попадает в одну категорию, когда речь идет о том, как вы работаете и какие типы проектов вы можете брать. Если вы найдете одного большого клиента, с которым вы можете работать, это может принести вам шестизначную сумму. Мы часто видим это или видим, как это происходит в нашем сообществе. Как я уже сказал, если люди полностью доступны и говорят: "Эй, я хочу заключить один большой контракт с клиентом, это может сразу же принести им шестизначную сумму в качестве фрилансера. Это долгосрочная игра, которую вы хотите играть в технологиях. Вы не хотите перепрыгивать с проекта на проект и поддерживать всех этих клиентов, как это делает, например, юридическая фирма или дизайнерское агентство. У вас есть все эти мелкие запросы здесь и там. В технологиях все очень по-другому, и в долгосрочной перспективе вы также можете взимать плату за обслуживание, плату за обслуживание и выставлять счета за текущие расходы на передние API. Вот где вы можете добавить дополнительный, так сказать, повторяющийся доход поверх вашей работы. Так что это долгосрочная игра, которую вы хотите играть. Круто. Хорошо, я пропустил это. Давайте перейдем к полному обзору архитектуры. Итак, вот еще один, так сказать, обзор, который объединяет все это, потому что название этой презентации было "Как мы создаем и развертываем пользовательские ИИ-решения". Вот оно. Я провел вас через весь процесс, и вот это визуализировано еще раз на диаграмме. И эту архитектуру вы можете автоматизировать практически все, что вы можете себе представить, используя этот стек. Мы никогда за годы работы с этим, поэтому мы оптимизировали его для этого, мы никогда не достигали предела, где это, так сказать, ломается. Теперь иногда возникают вопросы, например, что насчет Kubernetes? Масштабируется ли Python? Мы не работаем с проектами такого размера. Так что для нас это никогда не было необходимо. Эта настройка, особенно с Celery между ними. Большинство людей недооценивают, насколько далеко вы можете масштабировать такую систему на одном виртуальном сервере, который вы также можете увеличить в размере, прежде чем вам придется беспокоиться о чем-либо, связанном с Kubernetes. Так что это полная архитектура. Теперь, что вам следует иметь в виду, если вы, например, рассматриваете возможность начать карьеру фрилансера, любой разработчик, вы хотите создать свою собственную вещь. ИИ будет меняться каждый месяц, но ваш процесс не должен, и основной технологический стек, который вы используете, и шаблоны, которые вы используете в этом стеке, также не должны. Мы используем этот же стек буквально 2 года, например, LLM меняются, но проекты, которые сейчас работают в продакшене для наших клиентов, они все еще работают. Мы просто меняем модель. Так что постройте систему один раз и убедитесь, что она может адаптироваться к новым моделям и технологиям. Но все остальное, например, ваш бэкэнд Fast API, Redis, Celery, PostgreSQL, ваш фронтенд, все это стабильно десятилетиями, просто работает. Так что не пытайтесь изобретать велосипед. Потому что, если вы не получите ясности относительно того, как это выглядит для вашего приложения, если вы будете кодировать свое приложение "на лету" и спросите: "Эй, можешь ли ты построить мне эту функцию?" Это может, так сказать, выйти из-под контроля и начать создавать для вас свою собственную целую вещь, чего вы не хотите. Предоставляя это как объем, предоставляя это как основу, мы знаем, что наши агенты по кодированию также не выходят из-под контроля. И поскольку мы работаем с этим стеком уже несколько лет, мы также можем мгновенно заметить, когда что-то не так. Мы можем просматривать PR. Мы можем проверять вещи. Нет, нет, нет. Это не туда. Это должно идти в ту папку с таким соглашением об именовании. Это действительно наш секретный соус, как мы можем делать то, что мы сейчас делаем с Data Lumina Solutions. Так что имейте это в виду. Итак, на этом мы подошли к концу презентации. Это был, так сказать, полный взгляд за кулисы, который я хотел вам дать. Теперь, если вы следили за мной и хотите научиться делать это самостоятельно, у меня есть два варианта для вас. Итак, во-первых, как вы знаете, я почти все отдаю бесплатно на этом YouTube-канале, но у меня есть две платные программы. Так что это бесстыдная самореклама. Но если вы хотите работать вместе со мной и моей командой, вы действительно хотите изучить, не просто то, что мы здесь охватили, а от А до Я, весь процесс с шаблонами, репозиториями и всем таким. Во-первых, у нас есть GenAI Accelerator, который является нашей технической программой. Так что это буквально научит вас, как стать инженером ИИ, и всему, что я практически поделился в этом видео. И у нас есть другая программа, которая называется Data Freelancer. Она научит вас, как начать карьеру фрилансера. Вам нужен технический опыт. Позвольте мне быть ясным. Вам нужны навыки. Вы должны быть либо специалистом по данным с опытом работы с данными, либо разработчиком программного обеспечения, чем угодно между ними. И если вы хотите найти свой первый проект, своего первого клиента, но вы не знаете, с чего начать, вы можете проверить Data Freelancer. Так что обе ссылки на эти программы будут в описании. Как я уже сказал, вы можете найти почти все бесплатно на моем YouTube, но если вы хотите получить короткий путь и хотите работать с моей командой, вы можете проверить их. И на этом мы подошли к концу этого видео. Я надеюсь, что вы нашли его ценным. Немного взгляда за кулисы. Мне тоже было очень весело его делать. Я делаю много обучающих видео по программированию, но я хочу поделиться немного больше тем, что мы делаем за кулисами. Так что, если вы нашли это полезным, пожалуйста, поставьте лайк и, конечно же, подпишитесь. А затем я покажу два видео здесь на экране, которые, я думаю, вам