Как вы знаете, я сейчас руковожу разработкой в AI-Центр Т-Банка. Мы делаем очень крутые AI first продукты и платформы. Мне часто говорят, что тут одни ML-задачи, это совсем не так. Немного расскажу.
Технологически все выглядит примерно так — у нас микросервисы. Мы пишем на Python и Golang. Используем как стандартные PG, Redis и прочее, так и специфические вещи вроде векторных БД (см. Milvus). Решаем крутые инженерные задачки вроде как гонять огромные потоки аудио через микросервисы с минимальной задержкой. Или что такое LLM-платформа и как ее построить таким образом, чтобы можно было на базе этого создавать продукты с минимальным TTM.
Мы создаем Вселенную AI-ассистентов — это финансовый, инвестиционный, шоппинг и другие ассистенты. Мы строим для этого целую LLM-платформу на базе нашего семейства языковых моделей.
Мы разрабатываем новое поколение пользовательской поддержки — это наш смелый стартаперский эксперимент по внедрению LLM в обслуживание клиентов, продажи и коллекшен. Результаты этой работы ощутят миллионы клиентов и десятки тысяч сотрудников. Мы меняем то, как работает большая компания, а возможно, и вся индустрия.
А еще куча всего: голосовые технологии, компьютерное зрение, рекомендательные платформы.
Все это разработка на передовой технологий, где какие-нибудь все меняющие новости происходят почти каждый месяц.
И если что, помимо ML-инженеров, мы в поиске как сильных backend и mobile инженеров, так и руководителей разработки. Если чувствуете в себе силы или есть вопросы — заходите ко мне в личку @skogorev.
Технологически все выглядит примерно так — у нас микросервисы. Мы пишем на Python и Golang. Используем как стандартные PG, Redis и прочее, так и специфические вещи вроде векторных БД (см. Milvus). Решаем крутые инженерные задачки вроде как гонять огромные потоки аудио через микросервисы с минимальной задержкой. Или что такое LLM-платформа и как ее построить таким образом, чтобы можно было на базе этого создавать продукты с минимальным TTM.
Мы создаем Вселенную AI-ассистентов — это финансовый, инвестиционный, шоппинг и другие ассистенты. Мы строим для этого целую LLM-платформу на базе нашего семейства языковых моделей.
Мы разрабатываем новое поколение пользовательской поддержки — это наш смелый стартаперский эксперимент по внедрению LLM в обслуживание клиентов, продажи и коллекшен. Результаты этой работы ощутят миллионы клиентов и десятки тысяч сотрудников. Мы меняем то, как работает большая компания, а возможно, и вся индустрия.
А еще куча всего: голосовые технологии, компьютерное зрение, рекомендательные платформы.
Все это разработка на передовой технологий, где какие-нибудь все меняющие новости происходят почти каждый месяц.
И если что, помимо ML-инженеров, мы в поиске как сильных backend и mobile инженеров, так и руководителей разработки. Если чувствуете в себе силы или есть вопросы — заходите ко мне в личку @skogorev.
👍18🔥11😢5👎1
Оверинжиниринг в архитектурных решениях.
Overengineering — это процесс разработки решения, которое усложнено таким образом, что не представляет ценности или могло бы быть реализовано проще. Если совсем простыми словами, то это когда можно сделать просто, но делается сложно.
Есть очень много причин, почему люди начинают оверинжинирить — это и неправильная формулировка ФТ и НФТ, и неправильные фокусы (например, на платформенность всего и вся), и даже незрелость команды.
Пример задачи, которую легко переоверинжинирить.
Есть функциональность — микросервисы-системы выгружают снапшот каталога продуктов из микросервиса каталога продуктов. В какой-то момент каталог раздувается и снапшот начинает выгружаться уже 5 секунд, нужно реализовать быструю выгрузку изменений из каталога.
Как решить?
Почему оверинжиниринг — это плохо:
— Излишняя стоимость решения. Более сложное решение делается дольше и обходится дороже в разработке без видимых на то причин.
— Излишняя стоимость поддержки. Я не говорю "сложнее поддерживать", потому что "сложнее" — субъективная оценка, но то, что на поддержку и развитие будет уходить больше времени, или потребуется более высокая квалификация инженера — увеличивает бюджет проекта.
Как можно предотвращать появление переуплотненных решений:
У нас в команде есть архитектурное ревью. В какой-то момент мы сформулировали чеклист к изменениям, которые проходят ревью. Я приведу некоторые вопросы из этого чеклиста, которые направлены на то, чтобы избегать оверинжиниринга решений:
— Какую бизнес-проблему мы решаем? Правильно ли, что эту проблему нужно решать именно такими ФТ и НФТ, а не на другом уровне/другой системе? Как еще можно решить эту бизнес-проблему?
— Правда ли, что текущие ФТ и НФТ решают бизнес-задачу? Не могут ли они быть более слабыми/более сильными, что сильно упростило бы решение или снизило стоимость решения?
— Правда ли, что исходя из контекста и ограничений по срокам, выбрано самое оптимальное техническое решение? Какие решения мы не рассмотрели совсем?
— Сколько новых точек отказа появляется в системе? Можно обойтись без них?
— Сколько новых сущностей/абстракций появляется в системе? Можно ли обойтись без них?
— Правда ли, что в компании/соседней команде нет решения, которое можно заиспользовать? Правда ли, что есть весомые аргументы не использовать уже готовые решения?
Если есть что добавить — пишите в комментариях.
https://www.mindtheproduct.com/overengineering-can-kill-your-product/
Overengineering — это процесс разработки решения, которое усложнено таким образом, что не представляет ценности или могло бы быть реализовано проще. Если совсем простыми словами, то это когда можно сделать просто, но делается сложно.
Есть очень много причин, почему люди начинают оверинжинирить — это и неправильная формулировка ФТ и НФТ, и неправильные фокусы (например, на платформенность всего и вся), и даже незрелость команды.
Пример задачи, которую легко переоверинжинирить.
Есть функциональность — микросервисы-системы выгружают снапшот каталога продуктов из микросервиса каталога продуктов. В какой-то момент каталог раздувается и снапшот начинает выгружаться уже 5 секунд, нужно реализовать быструю выгрузку изменений из каталога.
Как решить?
Почему оверинжиниринг — это плохо:
— Излишняя стоимость решения. Более сложное решение делается дольше и обходится дороже в разработке без видимых на то причин.
— Излишняя стоимость поддержки. Я не говорю "сложнее поддерживать", потому что "сложнее" — субъективная оценка, но то, что на поддержку и развитие будет уходить больше времени, или потребуется более высокая квалификация инженера — увеличивает бюджет проекта.
Как можно предотвращать появление переуплотненных решений:
У нас в команде есть архитектурное ревью. В какой-то момент мы сформулировали чеклист к изменениям, которые проходят ревью. Я приведу некоторые вопросы из этого чеклиста, которые направлены на то, чтобы избегать оверинжиниринга решений:
— Какую бизнес-проблему мы решаем? Правильно ли, что эту проблему нужно решать именно такими ФТ и НФТ, а не на другом уровне/другой системе? Как еще можно решить эту бизнес-проблему?
— Правда ли, что текущие ФТ и НФТ решают бизнес-задачу? Не могут ли они быть более слабыми/более сильными, что сильно упростило бы решение или снизило стоимость решения?
— Правда ли, что исходя из контекста и ограничений по срокам, выбрано самое оптимальное техническое решение? Какие решения мы не рассмотрели совсем?
— Сколько новых точек отказа появляется в системе? Можно обойтись без них?
— Сколько новых сущностей/абстракций появляется в системе? Можно ли обойтись без них?
— Правда ли, что в компании/соседней команде нет решения, которое можно заиспользовать? Правда ли, что есть весомые аргументы не использовать уже готовые решения?
Если есть что добавить — пишите в комментариях.
https://www.mindtheproduct.com/overengineering-can-kill-your-product/
Mind the Product
Overengineering can kill your product
In today's post, Simón Muñoz speaks about one of the most prevalent issues when creating products: overengineering them.
👍14🔥1
Топ-10 угроз безопасности приложений, основанных на LLM и генеративном ИИ (OWASP Foundation).
С ростом популярности решений на базе LLM и генеративного ИИ растет и количество потенциальных уязвимостей. Как первые сайты на php упускали из расчета, что пользователь может ввести логин "; DROP TABLE USERS". Так и сейчас — продукты на основе ИИ растут быстрее, чем исследования в области безопасности таких решений.
Некоммерческая организация OWASP Foundation выпускает "OWASP TOP-10" — это отчет, составленный группой экспертов по безопасности со всего мира, об известных проблемах безопасности приложений с акцентом на 10 самых важных. На них ссылаются создатели основных стандартов кибербезопасности и такие организации, как MITRE, PCI DSS и DISA.
В этом году OWASP выпустили ТОП-10 рисков и уязвимостей при разработке приложений, основанных на генеративном ИИ, и больших языковых моделей на всех этапах жизненого цикла. Ниже этот список.
ТОП-10:
— Prompt Injections: попытка злоумышленников переопределить изначальный Prompt, что может привести к несанкционированным ответам.
— Insecure Output Handling: неправильная очистка или обработка данных, генерируемых ИИ, что приводит к таким уязвимостям, как cross-site noscripting или утечке информации.
— Training Data Poisoning: подразумевает подделку данных, используемых для обучения моделей, что искажает их поведение.
— Denial of Service: атаки, которые перегружают системы с моделями, делая их недоступными для пользователей, например, путем использования ресурсоемких операций.
— Supply Chain Vulnerabilities: жизненный цикл приложения на базе LLM может быть скомпрометирован уязвимыми компонентами или службами.
— Sensitive Data Leakage or Information Disclosure: непреднамеренное раскрытие конфиденциальной информация системами ИИ из-за недостатков в обработке данных или контроле доступов.
— Insecure Plugin Design: плагины LLM могут иметь небезопасные входы и недостаточный контроль доступа.
— Excessive Agency: возникает из-за чрезмерной функциональности, разрешений или автономии, предоставляемых системам на основе LLM, что приводит к непреднамеренным последствиям.
— Overreliance: чрезмерное доверие к результату работы систем ИИ без адекватного контроля, что приводит к распространению ненадлежащего или вредоносного контента.
— Model Theft: подразумевает несанкционированный доступ к моделям под капотом приложения.
https://genai.owasp.org/llm-top-10/
https://education.securiti.ai/certifications/ai-governance/controlling-data-inputs-and-outputs/attacks-against-generative-ai-systems-owasp-top-10-for-llms/
С ростом популярности решений на базе LLM и генеративного ИИ растет и количество потенциальных уязвимостей. Как первые сайты на php упускали из расчета, что пользователь может ввести логин "; DROP TABLE USERS". Так и сейчас — продукты на основе ИИ растут быстрее, чем исследования в области безопасности таких решений.
Некоммерческая организация OWASP Foundation выпускает "OWASP TOP-10" — это отчет, составленный группой экспертов по безопасности со всего мира, об известных проблемах безопасности приложений с акцентом на 10 самых важных. На них ссылаются создатели основных стандартов кибербезопасности и такие организации, как MITRE, PCI DSS и DISA.
В этом году OWASP выпустили ТОП-10 рисков и уязвимостей при разработке приложений, основанных на генеративном ИИ, и больших языковых моделей на всех этапах жизненого цикла. Ниже этот список.
ТОП-10:
— Prompt Injections: попытка злоумышленников переопределить изначальный Prompt, что может привести к несанкционированным ответам.
— Insecure Output Handling: неправильная очистка или обработка данных, генерируемых ИИ, что приводит к таким уязвимостям, как cross-site noscripting или утечке информации.
— Training Data Poisoning: подразумевает подделку данных, используемых для обучения моделей, что искажает их поведение.
— Denial of Service: атаки, которые перегружают системы с моделями, делая их недоступными для пользователей, например, путем использования ресурсоемких операций.
— Supply Chain Vulnerabilities: жизненный цикл приложения на базе LLM может быть скомпрометирован уязвимыми компонентами или службами.
— Sensitive Data Leakage or Information Disclosure: непреднамеренное раскрытие конфиденциальной информация системами ИИ из-за недостатков в обработке данных или контроле доступов.
— Insecure Plugin Design: плагины LLM могут иметь небезопасные входы и недостаточный контроль доступа.
— Excessive Agency: возникает из-за чрезмерной функциональности, разрешений или автономии, предоставляемых системам на основе LLM, что приводит к непреднамеренным последствиям.
— Overreliance: чрезмерное доверие к результату работы систем ИИ без адекватного контроля, что приводит к распространению ненадлежащего или вредоносного контента.
— Model Theft: подразумевает несанкционированный доступ к моделям под капотом приложения.
https://genai.owasp.org/llm-top-10/
https://education.securiti.ai/certifications/ai-governance/controlling-data-inputs-and-outputs/attacks-against-generative-ai-systems-owasp-top-10-for-llms/
👍9
Привет всем!
Давно не писал. Есть несколько причин.
Первое. Немного охладел к классическому системному дизайну, даже взял отпуск от интервью по этой секции. Почти всё, что хотел сказать, уже сказал и чаще использую канал как референс на паттерны (вот тут, кстати, сборник постов, рекомендую). Есть ощущение, что дальше нужно либо уходить в очень глубокие дебри, либо повторять прописные истины.
Второе. В ТБанке я сильно сфокусировался на построении продуктов и платформ на базе AI (буквально моя зона ответственности). Индустрия развивается очень быстро: если ещё вчера все делали Single Prompt Applications, то сегодня модно строить мультиагентные архитектуры, всё больше приближая нас к AGI.
Теперь про канал и его позиционирование. Хочу открыть новую главу. Он по-прежнему будет про технические вещи, но с акцентом на то, что у меня сейчас в фокусе — AI. В ближайшее время я, скорее всего, переименую его. Давайте начнём с первого поста.
А пока и держите трейнспоттинг с моего рабочего места офиса на Белорусской.
Давно не писал. Есть несколько причин.
Первое. Немного охладел к классическому системному дизайну, даже взял отпуск от интервью по этой секции. Почти всё, что хотел сказать, уже сказал и чаще использую канал как референс на паттерны (вот тут, кстати, сборник постов, рекомендую). Есть ощущение, что дальше нужно либо уходить в очень глубокие дебри, либо повторять прописные истины.
Второе. В ТБанке я сильно сфокусировался на построении продуктов и платформ на базе AI (буквально моя зона ответственности). Индустрия развивается очень быстро: если ещё вчера все делали Single Prompt Applications, то сегодня модно строить мультиагентные архитектуры, всё больше приближая нас к AGI.
Теперь про канал и его позиционирование. Хочу открыть новую главу. Он по-прежнему будет про технические вещи, но с акцентом на то, что у меня сейчас в фокусе — AI. В ближайшее время я, скорее всего, переименую его. Давайте начнём с первого поста.
А пока и держите трейнспоттинг с моего рабочего места офиса на Белорусской.
This media is not supported in your browser
VIEW IN TELEGRAM
👍15🔥3
доклад ВШЭ.Вселенная.pdf
7 MB
Когнитивные архитектуры.
В воскресенье выступал в ВШЭ на мероприятии от Центра непрерывного образования ФКН с обзорным докладом о развитии "когнитивных архитектур" и, в частности, о Вселенной ассистентов ТБанка. Рассказал про рынок AI, историю продуктов и эволюцию генеративных архитектур, топ-10 угроз безопасности и то, как под капотом устроена наша система.
Прикрепляю слайды.
В воскресенье выступал в ВШЭ на мероприятии от Центра непрерывного образования ФКН с обзорным докладом о развитии "когнитивных архитектур" и, в частности, о Вселенной ассистентов ТБанка. Рассказал про рынок AI, историю продуктов и эволюцию генеративных архитектур, топ-10 угроз безопасности и то, как под капотом устроена наша система.
Прикрепляю слайды.
🔥29
Forwarded from [30/100] Витя Тарнавский
Собрал для вас табличку сервисов и фреймворков для создания агентских систем по уровню абстракции - от высокого и простого к низкоуровневым инструментам.
Если хотите посмотреть что такое агенты или сделать простую штуку, начинайте сверху. На уровень 4 спускаться примерно никогда не требуется.
Го в комменты где что забыл и у кого какой опыт
Если хотите посмотреть что такое агенты или сделать простую штуку, начинайте сверху. На уровень 4 спускаться примерно никогда не требуется.
Го в комменты где что забыл и у кого какой опыт
🔥13👎2
Think tank with LLM.
Первый раз увидел упоминания этого метода в прекрасном видео AI as Software Architect и с тех пор пользуюсь.
В классическом мире «think tank» — это исследовательский центр, где работают эксперты разных специальностей, которые совместно анализируют проблему, обсуждают разные точки зрения и формируют рекомендации.
В мире LLM можно моделировать нечто подобное за счёт «разделения» одной или нескольких моделей на несколько ролей или «агентов». Каждый «агент» имеет свою задачу (например, «эксперт по статистике», «консультант по маркетингу», «скептик» и т.д.).
Все «агенты» последовательно обмениваются своими мнениями, и в результате формируется сводное решение или ответ.
Я пользуюсь подходом chain-of-thought, вы даёте модели инструкцию вроде «
Позволяет не столько что-то нагенерировать, сколько посмотреть на проблему с разных сторон и увидеть неочевидные вещи в решении.
Держите несколько примеров:
— Линус Торвальдс, Эрик Эванс и Сэм Альтман решают как должен выгдядеть линукс через 10 лет
— Мобильный и бекенд разработчик выбирают между нативом, bdui и вебвью
— Команда придумывает стартап на 1М в велосипедной индустрии
Первый раз увидел упоминания этого метода в прекрасном видео AI as Software Architect и с тех пор пользуюсь.
В классическом мире «think tank» — это исследовательский центр, где работают эксперты разных специальностей, которые совместно анализируют проблему, обсуждают разные точки зрения и формируют рекомендации.
В мире LLM можно моделировать нечто подобное за счёт «разделения» одной или нескольких моделей на несколько ролей или «агентов». Каждый «агент» имеет свою задачу (например, «эксперт по статистике», «консультант по маркетингу», «скептик» и т.д.).
Все «агенты» последовательно обмениваются своими мнениями, и в результате формируется сводное решение или ответ.
Я пользуюсь подходом chain-of-thought, вы даёте модели инструкцию вроде «
Представь, что у нас есть команда экспертов: Эксперт A, Эксперт B и Эксперт C. Каждый по очереди высказывает своё мнение по задаче, основываясь на своей специализации, а потом они приходят к общему выводу».Позволяет не столько что-то нагенерировать, сколько посмотреть на проблему с разных сторон и увидеть неочевидные вещи в решении.
Держите несколько примеров:
— Линус Торвальдс, Эрик Эванс и Сэм Альтман решают как должен выгдядеть линукс через 10 лет
— Мобильный и бекенд разработчик выбирают между нативом, bdui и вебвью
— Команда придумывает стартап на 1М в велосипедной индустрии
👍13
Forwarded from Denis Sexy IT 🤖
Сделал простой гайд какие модели когда использовать в ChatGPT:
GPT-4o mini – лучше не использовать, самая слабая и придумывает ответы; не способна следовать сложным инструкциям
GPT-4o – быстрая модель, для быстрых ответов не требующих проверки фактов, может их придумывать; перевожу ей картинки в текст если нужно быстро. Ее ответы нужно всегда факт-чекать. Зато эта модель имеет доступ к памяти (где все про вас), с ней можно общаться голосом, через нее можно вызывать генерацию картинок Dalle. Не рекомендую обрабатывать большие файлы с ней
GPT-4o with scheduled tasks (beta) – использую только для To Do: модель пишет мне каждое утро и спрашивает приоритеты, показывает текущий список задач и тп
o3-mini – хорошая модель для кодинга и жизни, хорошо ищет в интернете, неплохо следуют инструкциям и при этом очень быстрая; если вам некогда и нужен быстрый ответ, то берите ее. Для анализа картинок и файлов «быстро» хороший кандидат. Не имеет доступа к памяти. Реже ошибается в фактах, но ошибается. В Plus тире – 150 сообщений в день.
✨o3-mini-high – это просто версия o3-mini, которую просят думать подольше перед тем как дать ответ – работает она медленнее, но еще реже ошибается, и еще качественнее решает задачи. Великолепно следует инструкциям. Хорошо работает с файлами. Я бы советовал сначала тратить 50 запросов этой модели, и дальше переходить к o3-mini или o1.
o1 – модель генератор отчетов, эссе и рефератов. Медленная модель. Хорошо следует инструкциям, может ошибиться в фактах. Не может искать в интернете. Хорошо видит картинки и читает файлы, не теряя деталей. У вас всего 50 запросов в неделю. Требует промптинга с описанием отчета которого вы хотите получить.
o1 pro mode – лучшая модель на рынке: почти никогда не ошибается в фактах, решает самые сложные задачи кодинга, дольше всех думает, лучше всех понимает изображения, но не умеет искать в интернете и не умеет работать с файлами напрямую. С точки зрения фактов – модель всегда сама себя перепроверяет, за ~3 месяца использования я только один раз поймал ее на неточности. Требует детального промптинга с описанием отчета который вы хотите. Доступна только в Pro тире, лимитов нет.
Deep research – несмотря на то, что модель выведена в отдельную кнопку, это версия новой o3 для поиска в интернете, как ей лучше пользоваться я напишу отдельно когда дадут доступ всем. Модель ищет в интернете и сама пишет код (который вам не покажет) для анализа найденных данных, чтобы, например включить в отчет графики. Лучшее, что есть на рынке для поиска данных в интернете. Пока доступна только в Pro. Если активируете эту кнопку - выбор модели в выпадашке – игнорируется, UX который мы заслужили
Tldr:
Для повседневных задач ваш лучший выбор – o3-mini-high, потом o3-mini, когда у первой кончились лимиты
GPT-4o mini – лучше не использовать, самая слабая и придумывает ответы; не способна следовать сложным инструкциям
GPT-4o – быстрая модель, для быстрых ответов не требующих проверки фактов, может их придумывать; перевожу ей картинки в текст если нужно быстро. Ее ответы нужно всегда факт-чекать. Зато эта модель имеет доступ к памяти (где все про вас), с ней можно общаться голосом, через нее можно вызывать генерацию картинок Dalle. Не рекомендую обрабатывать большие файлы с ней
GPT-4o with scheduled tasks (beta) – использую только для To Do: модель пишет мне каждое утро и спрашивает приоритеты, показывает текущий список задач и тп
o3-mini – хорошая модель для кодинга и жизни, хорошо ищет в интернете, неплохо следуют инструкциям и при этом очень быстрая; если вам некогда и нужен быстрый ответ, то берите ее. Для анализа картинок и файлов «быстро» хороший кандидат. Не имеет доступа к памяти. Реже ошибается в фактах, но ошибается. В Plus тире – 150 сообщений в день.
✨o3-mini-high – это просто версия o3-mini, которую просят думать подольше перед тем как дать ответ – работает она медленнее, но еще реже ошибается, и еще качественнее решает задачи. Великолепно следует инструкциям. Хорошо работает с файлами. Я бы советовал сначала тратить 50 запросов этой модели, и дальше переходить к o3-mini или o1.
o1 – модель генератор отчетов, эссе и рефератов. Медленная модель. Хорошо следует инструкциям, может ошибиться в фактах. Не может искать в интернете. Хорошо видит картинки и читает файлы, не теряя деталей. У вас всего 50 запросов в неделю. Требует промптинга с описанием отчета которого вы хотите получить.
o1 pro mode – лучшая модель на рынке: почти никогда не ошибается в фактах, решает самые сложные задачи кодинга, дольше всех думает, лучше всех понимает изображения, но не умеет искать в интернете и не умеет работать с файлами напрямую. С точки зрения фактов – модель всегда сама себя перепроверяет, за ~3 месяца использования я только один раз поймал ее на неточности. Требует детального промптинга с описанием отчета который вы хотите. Доступна только в Pro тире, лимитов нет.
Deep research – несмотря на то, что модель выведена в отдельную кнопку, это версия новой o3 для поиска в интернете, как ей лучше пользоваться я напишу отдельно когда дадут доступ всем. Модель ищет в интернете и сама пишет код (который вам не покажет) для анализа найденных данных, чтобы, например включить в отчет графики. Лучшее, что есть на рынке для поиска данных в интернете. Пока доступна только в Pro. Если активируете эту кнопку - выбор модели в выпадашке – игнорируется, UX который мы заслужили
Tldr:
Для повседневных задач ваш лучший выбор – o3-mini-high, потом o3-mini, когда у первой кончились лимиты
👍10🔥2
Паттерны GenAI приложений от Martin Fowler: Emerging Patterns in Building GenAI Products
Мартин Фаулер, эксперт по программной инженерии, известный многим по ряду статей о паттернах микросервисной архитектуры. Автор, чей сайт я неоднократно перечитывал и часто приводил ссылки на этом канале, опубликовал большую работу по паттернам построения GenAI приложений.
Новых концепций Мартин и его соавтор не вводят, но систематизируют и подают информацию о том, как нужно строить GenAI приложения со стороны программистов-практиков.
Не обходят стороной и такие вещи, которые даже Google в своих whitepappers пропускает - Embeddings и Evaluations.
Паттерны:
— Direct Prompting
— Embeddings
— Evals
— Hybrid Retriever
— Query Rewriting
— Reranker
— Retrieval Augmented Generation (RAG)
Мартин Фаулер, эксперт по программной инженерии, известный многим по ряду статей о паттернах микросервисной архитектуры. Автор, чей сайт я неоднократно перечитывал и часто приводил ссылки на этом канале, опубликовал большую работу по паттернам построения GenAI приложений.
Новых концепций Мартин и его соавтор не вводят, но систематизируют и подают информацию о том, как нужно строить GenAI приложения со стороны программистов-практиков.
Не обходят стороной и такие вещи, которые даже Google в своих whitepappers пропускает - Embeddings и Evaluations.
Паттерны:
— Direct Prompting
— Embeddings
— Evals
— Hybrid Retriever
— Query Rewriting
— Reranker
— Retrieval Augmented Generation (RAG)
martinfowler.com
Emerging Patterns in Building GenAI Products
Patterns from our colleagues' work building with Generative AI
👍22
Lecture 10.03.2025.DB.Indexes.pdf
4.2 MB
Сегодня из отпуска читаю лекцию в Академии Бэкенда - интересный экспириенс =). Тема - “индексы в СУБД”.
Если вдруг хочется вспомнить теорию, где они располагаются, сколько весят, что такое BRIN индексы и как частичные индексы могут облегчить жизнь — прикладываю презентацию. Пересылай в своих коллег.
Если вдруг хочется вспомнить теорию, где они располагаются, сколько весят, что такое BRIN индексы и как частичные индексы могут облегчить жизнь — прикладываю презентацию. Пересылай в своих коллег.
👍30
Я тут не так давно купил квартиру, делаю ремонт и ломаю голову как обустроить свое рабочее место.
Но вот на днях chatgpt выпустил убийцу фотошопа — в режиме gpt-4o научился редактировать изображения. Работает очень медленно, но очень помогает представить как это может выглядеть.
Попробовать тут.
Как варианты?)
Но вот на днях chatgpt выпустил убийцу фотошопа — в режиме gpt-4o научился редактировать изображения. Работает очень медленно, но очень помогает представить как это может выглядеть.
Попробовать тут.
Как варианты?)
🔥12👍9😢2🦄2🤷♂1👎1
MCP — не production-ready.
24 ноября 2024 года Anthropic представили MCP — унифицированный протокол взаимодействия ассистентов/агентов с тулами (API, плагинами, локальными базами и т.д.), расширяющий возможности GenAI-приложений.
Протокол описывает, как формировать запросы, обрабатывать ответы и какие форматы данных использовать, чтобы всё было совместимо и предсказуемо. В духе plug-and-play. Прикрепляю картинку.
И если вначале это воспринималось как мем "ещё один стандарт", то сейчас — сила комьюнити порешала. Уже можно найти MCP-серверы для чего угодно — от управления Raspberry Pi до интеграции с Miro. Смотри, например, вот такую подборку.
Мы уже достаточно долго на него смотрим, и внутри команды мнения сильно разделились.
Напомню, что Anthropic, выпуская этот гайдлайн, делал больший акцент на локальные агенты, даже более конкретно — на Claude Desktop App, а не для распределённых production-систем. Отсюда появляется ряд минусов:
— небезопасный (разбор) — совсем ничего про то, как делать аутентификацию;
— довольно узкая задача протокола (вся сложность перенесена, по сути, на уровень MCP-клиента и хоста);
— сыроват;
— сложный в реализации — минус к adoption;
— мультиагентность обычно не имплементируют, в итоге получается однопромптовый агент.
В итоге, MCP — классная задумка для локальных use-case'ов, особенно при разработке десктопных агентов. Но строить на нём production-продукты пока рискованно — как минимум из-за незрелости и отсутствия базовой безопасности.
Будущее за локальными агентами?
UPD: пока писал этот пост на прошлой неделе, вышел "ответ от Google" — A2A-протокол. Они попытались учесть большинство болячек MCP, вроде безопасности. Интересно, что из этого выйдет. Краткий разбор можно почитать вот тут.
24 ноября 2024 года Anthropic представили MCP — унифицированный протокол взаимодействия ассистентов/агентов с тулами (API, плагинами, локальными базами и т.д.), расширяющий возможности GenAI-приложений.
Протокол описывает, как формировать запросы, обрабатывать ответы и какие форматы данных использовать, чтобы всё было совместимо и предсказуемо. В духе plug-and-play. Прикрепляю картинку.
И если вначале это воспринималось как мем "ещё один стандарт", то сейчас — сила комьюнити порешала. Уже можно найти MCP-серверы для чего угодно — от управления Raspberry Pi до интеграции с Miro. Смотри, например, вот такую подборку.
Мы уже достаточно долго на него смотрим, и внутри команды мнения сильно разделились.
Напомню, что Anthropic, выпуская этот гайдлайн, делал больший акцент на локальные агенты, даже более конкретно — на Claude Desktop App, а не для распределённых production-систем. Отсюда появляется ряд минусов:
— небезопасный (разбор) — совсем ничего про то, как делать аутентификацию;
— довольно узкая задача протокола (вся сложность перенесена, по сути, на уровень MCP-клиента и хоста);
— сыроват;
— сложный в реализации — минус к adoption;
— мультиагентность обычно не имплементируют, в итоге получается однопромптовый агент.
В итоге, MCP — классная задумка для локальных use-case'ов, особенно при разработке десктопных агентов. Но строить на нём production-продукты пока рискованно — как минимум из-за незрелости и отсутствия базовой безопасности.
Будущее за локальными агентами?
UPD: пока писал этот пост на прошлой неделе, вышел "ответ от Google" — A2A-протокол. Они попытались учесть большинство болячек MCP, вроде безопасности. Интересно, что из этого выйдет. Краткий разбор можно почитать вот тут.
👍10
Practical Design Patterns for Modern AI Systems
Интересная картинка из статьи про архитектурные паттерны AI-систем, ориентированных на взаимодействие с LLM через API: Prompting & Context, Responsible AI, User Experience, AI-Ops и Optimization.
Жаль только, что рассмотрели достаточно простую схему вызовов модели вместо агентской архитектуры.
Интересная картинка из статьи про архитектурные паттерны AI-систем, ориентированных на взаимодействие с LLM через API: Prompting & Context, Responsible AI, User Experience, AI-Ops и Optimization.
Жаль только, что рассмотрели достаточно простую схему вызовов модели вместо агентской архитектуры.
👍11
Попробовал за вас Codex от OpenAI.
Под капотом — O3. Агенту можно скормить свой GitHub-репозиторий, и он начнёт выполнять за вас вашу программистскую работу.
Тулзе можно давать задания (вроде «порефач за меня»), и она будет писать код, запускать команды (и даже какой-нибудь Makefile) и отвечать на вопросы по репозиторию.
Натравил его на свой старенький репозиторий с реализацией динамического массива на C.
Codex нашёл пару несуществующих багов, вроде проверки count перед тем как делать memcpy (но мы с вами знаем, как работает memcpy), и проверил либу на актуальность в 2025.
Попросил порефакторить и переписать её так, как пишут C-либы в 2025 году (а пишут?).
Если вдруг пользуетесь и есть реальные рабочие кейсы — поделитесь в комментариях.
Под капотом — O3. Агенту можно скормить свой GitHub-репозиторий, и он начнёт выполнять за вас вашу программистскую работу.
Тулзе можно давать задания (вроде «порефач за меня»), и она будет писать код, запускать команды (и даже какой-нибудь Makefile) и отвечать на вопросы по репозиторию.
Натравил его на свой старенький репозиторий с реализацией динамического массива на C.
Codex нашёл пару несуществующих багов, вроде проверки count перед тем как делать memcpy (но мы с вами знаем, как работает memcpy), и проверил либу на актуальность в 2025.
Попросил порефакторить и переписать её так, как пишут C-либы в 2025 году (а пишут?).
Если вдруг пользуетесь и есть реальные рабочие кейсы — поделитесь в комментариях.
👍4💩1