Nano Banana: AI-редактор, который меня "понимает" 💎
Я начинал еще со Stable Diffusion 1.5. Потом долго сидел на SDXL. И все это время главной болью было одно: любая попытка что-то изменить на картинке превращалась в лотерею.
Просишь поменять цвет рубашки — нейросеть меняет и лицо, и позу, и фон. Пытаешься исправить один палец — ломаются остальные пять.
И вот я попробовал Nano Banana (она же Gemini 2.5 Flash Image). Это не идеал, но я отчетливо вижу проблески новых возможностей.
Она делает то, чего мне так не хватало: меняет только то, что просишь.
• Сохраняет персонажа. Лицо, одежда, поза — все остается на месте. Правка вносится только в нужную деталь.
• Понимает простые команды. Не нужно писать длинные промпты. «Сделай волосы рыжими» или «добавь на стол чашку кофе» — этого достаточно.
• Следует задаче. Она не додумывает за тебя, а просто выполняет инструкцию.
💻 Энтузиасты уже собрали отличную подборку промптов, где модель показывает себя во всей красе. Очень советую посмотреть:
https://github.com/PicoTrex/Awesome-Nano-Banana-images/blob/main/README_en.md
Там есть и смена стиля, и создание референсов. А вот с позами у меня пока получается так себе — модель либо игнорирует запрос, либо почти ничего не меняет.
Я бы не сказал, что это замена Midjourney/Flux/SD для создания артов с нуля. Это скорее инструмент для точной работы. Когда нужно не «сгенерируй что-то красивое», а «сделай вот здесь вот так». И с этой задачей она, как мне кажется, справляется лучше всех на текущий момент.
А вы уже тестировали "банан"? Как вам после Midjourney и SD? Поделитесь в комментариях!
Я начинал еще со Stable Diffusion 1.5. Потом долго сидел на SDXL. И все это время главной болью было одно: любая попытка что-то изменить на картинке превращалась в лотерею.
Просишь поменять цвет рубашки — нейросеть меняет и лицо, и позу, и фон. Пытаешься исправить один палец — ломаются остальные пять.
И вот я попробовал Nano Banana (она же Gemini 2.5 Flash Image). Это не идеал, но я отчетливо вижу проблески новых возможностей.
Она делает то, чего мне так не хватало: меняет только то, что просишь.
• Сохраняет персонажа. Лицо, одежда, поза — все остается на месте. Правка вносится только в нужную деталь.
• Понимает простые команды. Не нужно писать длинные промпты. «Сделай волосы рыжими» или «добавь на стол чашку кофе» — этого достаточно.
• Следует задаче. Она не додумывает за тебя, а просто выполняет инструкцию.
https://github.com/PicoTrex/Awesome-Nano-Banana-images/blob/main/README_en.md
Там есть и смена стиля, и создание референсов. А вот с позами у меня пока получается так себе — модель либо игнорирует запрос, либо почти ничего не меняет.
Я бы не сказал, что это замена Midjourney/Flux/SD для создания артов с нуля. Это скорее инструмент для точной работы. Когда нужно не «сгенерируй что-то красивое», а «сделай вот здесь вот так». И с этой задачей она, как мне кажется, справляется лучше всех на текущий момент.
А вы уже тестировали "банан"? Как вам после Midjourney и SD? Поделитесь в комментариях!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Raycast и принцип «сэкономленных секунд»: как мелкие улучшения возвращают часы ⌛️
Знакомый цифровой хаос? Открыть заметки, чтобы скопировать команду, переключиться в браузер на 25-ю вкладку с доками, найти в контактах коллегу, чтобы ему написать... Одна простая задача — несколько приложений и куча переключений контекста.
Оказалось, большую часть этих «микро-пауз» можно убрать. Выпустил новый лонгрид про Raycast — не как про лаунчер, а как про способ борьбы с мелким, но дико раздражающим трением в рабочих процессах.
Что внутри:
• Мой путь от «очередной лаунчер» до «главный рабочий инструмент».
• Конкретные замеры в секундах: как одна команда заменяет минуту рутины.
• Скелет моей системы: Snippets, Quicklinks, AI-команды, которые я использую каждый день.
• Ложка дегтя: где есть порог входа и что мне не нравилось поначалу.
Если тоже чувствуете, что воюете с интерфейсами, а не с задачами — залетайте.
🔗 Читайте подробный гайд на:
Teletype • VC • Dzen • Pikabu
Знакомый цифровой хаос? Открыть заметки, чтобы скопировать команду, переключиться в браузер на 25-ю вкладку с доками, найти в контактах коллегу, чтобы ему написать... Одна простая задача — несколько приложений и куча переключений контекста.
Оказалось, большую часть этих «микро-пауз» можно убрать. Выпустил новый лонгрид про Raycast — не как про лаунчер, а как про способ борьбы с мелким, но дико раздражающим трением в рабочих процессах.
Что внутри:
• Мой путь от «очередной лаунчер» до «главный рабочий инструмент».
• Конкретные замеры в секундах: как одна команда заменяет минуту рутины.
• Скелет моей системы: Snippets, Quicklinks, AI-команды, которые я использую каждый день.
• Ложка дегтя: где есть порог входа и что мне не нравилось поначалу.
Если тоже чувствуете, что воюете с интерфейсами, а не с задачами — залетайте.
Teletype • VC • Dzen • Pikabu
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Правильная векторная база для RAG, чтобы всё заработало с первого раза 🔖
В теории RAG звучит просто: загрузи документы, нарежь на векторы, найди похожие, отправь в LLM. На практике 90% проблем начинаются на самом первом шаге — создании векторной базы данных.
Я сам на этом споткнулся. Документация n8n, Supabase и LangChain часто противоречит друг другу или предполагает, что ты уже и так всё знаешь. В итоге ты тратишь какое-то время, пытаясь понять, почему n8n не видит твою таблицу и сыплет ошибками...
Я определил три вещи, которые должны идеально совпадать (на момент написание этого поста), иначе ничего не полетит:
• Размерность векторов. Выбранная вами модель (например, paraphrase-multilingual-mpnet-base-v2) выдает векторы определённой длины. Для этой модели — 768. Если в таблице указать vector(767) или vector(1536), поиск работать не будет.
• Имена колонок. Нода n8n по умолчанию ищет конкретные столбцы: content (для текста), embedding (для вектора) и metadata (для JSON-данных).
• Функция поиска. Supabase не ищет по векторам «из коробки». Нужно создать специальную SQL-функцию, которая будет принимать вектор запроса и возвращать похожие документы.
💻 SQL скрипт: https://gist.github.com/Vlad-Loop/a4a03c01cfe14fa0784dba800c6cc18d
После этого в ноде n8n Supabase Vector Store вам останется только указать имя таблицы и имя функции. И всё. Оно должно у вас заработать.
С какими граблями при создании RAG сталкивались вы? Расскажите в комментах.
В теории RAG звучит просто: загрузи документы, нарежь на векторы, найди похожие, отправь в LLM. На практике 90% проблем начинаются на самом первом шаге — создании векторной базы данных.
Я сам на этом споткнулся. Документация n8n, Supabase и LangChain часто противоречит друг другу или предполагает, что ты уже и так всё знаешь. В итоге ты тратишь какое-то время, пытаясь понять, почему n8n не видит твою таблицу и сыплет ошибками...
Я определил три вещи, которые должны идеально совпадать (на момент написание этого поста), иначе ничего не полетит:
• Размерность векторов. Выбранная вами модель (например, paraphrase-multilingual-mpnet-base-v2) выдает векторы определённой длины. Для этой модели — 768. Если в таблице указать vector(767) или vector(1536), поиск работать не будет.
• Имена колонок. Нода n8n по умолчанию ищет конкретные столбцы: content (для текста), embedding (для вектора) и metadata (для JSON-данных).
• Функция поиска. Supabase не ищет по векторам «из коробки». Нужно создать специальную SQL-функцию, которая будет принимать вектор запроса и возвращать похожие документы.
После этого в ноде n8n Supabase Vector Store вам останется только указать имя таблицы и имя функции. И всё. Оно должно у вас заработать.
С какими граблями при создании RAG сталкивались вы? Расскажите в комментах.
Please open Telegram to view this post
VIEW IN TELEGRAM
От «вроде стало лучше» к цифрам. Главное про n8n Evaluation 📰
Главная боль при работе с AI — его вероятностная природа. Поменял одно слово в промпте — где-то в другом месте всё посыпалось. Улучшил ответ для одного кейса — сломал десять других. До сих пор проверка качества AI-воркфлоу напоминала шаманство с бубном.
Так вот, в n8n выкатили фичу, которая наконец-то позволяет опираться хоть на какие-то метрики качества. Называется Evaluation.
Если коротко, это встроенная система для тестирования ваших AI-цепочек. Теперь можно не гадать, стало ли лучше после изменений, а получить конкретные цифры.
Механика простая:
1. Готовишь табличку (куда же без табличек) с тестовыми примерами: входные данные и эталонный, правильный ответ.
2. Настраиваешь в n8n ветку с логикой оценки (например, "сравни ответ модели с эталоном по смыслу"). Стоит отметить, что n8n уже добавили все необхоидмые новые ноды для постройки подобных штук.
3. Запускаешь прогон и смотришь на итоговый score.
И вот тут начинается самое интересное. Я сейчас активно гоняю эту фичу на своих RAG-воркфлоу. Подбираю идеальные параметры для векторной базы, тюню промпты для поиска и генерации ответа, меняю модели. Раньше на это уходили часы/дни ручных проверок. Теперь я вношу изменение, нажимаю кнопку и через 5 минут вижу, стал ли общий результат лучше или хуже.
Самое главное датасет (табличку) хороший собрать. У меня например уже порядка 100 проверочных кейсов, страшно представить сколько я бы руками всё это дело проверял бы каждый раз.
⬆️ Качество AI цепочки, естествено, улучшилось в разы после подобных манипуляций.
Сейчас как раз готовлю небольшой разбор нескольких вариантов реализации RAG в n8n, и там мы будем использовать Evaluation по полной. А пока...
Как вы сейчас проверяете, что ваш новый промпт не сломал всё остальное? Расскажите в комментах.
Главная боль при работе с AI — его вероятностная природа. Поменял одно слово в промпте — где-то в другом месте всё посыпалось. Улучшил ответ для одного кейса — сломал десять других. До сих пор проверка качества AI-воркфлоу напоминала шаманство с бубном.
Так вот, в n8n выкатили фичу, которая наконец-то позволяет опираться хоть на какие-то метрики качества. Называется Evaluation.
Если коротко, это встроенная система для тестирования ваших AI-цепочек. Теперь можно не гадать, стало ли лучше после изменений, а получить конкретные цифры.
Механика простая:
1. Готовишь табличку (куда же без табличек) с тестовыми примерами: входные данные и эталонный, правильный ответ.
2. Настраиваешь в n8n ветку с логикой оценки (например, "сравни ответ модели с эталоном по смыслу"). Стоит отметить, что n8n уже добавили все необхоидмые новые ноды для постройки подобных штук.
3. Запускаешь прогон и смотришь на итоговый score.
И вот тут начинается самое интересное. Я сейчас активно гоняю эту фичу на своих RAG-воркфлоу. Подбираю идеальные параметры для векторной базы, тюню промпты для поиска и генерации ответа, меняю модели. Раньше на это уходили часы/дни ручных проверок. Теперь я вношу изменение, нажимаю кнопку и через 5 минут вижу, стал ли общий результат лучше или хуже.
Самое главное датасет (табличку) хороший собрать. У меня например уже порядка 100 проверочных кейсов, страшно представить сколько я бы руками всё это дело проверял бы каждый раз.
Сейчас как раз готовлю небольшой разбор нескольких вариантов реализации RAG в n8n, и там мы будем использовать Evaluation по полной. А пока...
Как вы сейчас проверяете, что ваш новый промпт не сломал всё остальное? Расскажите в комментах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Продвинутые RAG-паттерны в n8n ⭐️
Почему ваш RAG-бот работает плохо? Во многих кейсах – причина не в LLM, которую вы выбрали. Дело в том, что происходит до того, как запрос пользователя вообще попадает в векторный поиск.
Выпустил новый лонгрид, где на живом workflow в n8n показываю, как научить RAG-систему сначала думать над вопросом, а потом искать ответ. Разбираем продвинутые техники, которые превращают «глупый» поисковик в толкового ассистента.
Если устали от галлюцинаций и нерелевантных ответов – залетайте.
🔗 Читайте подробный гайд на:
Teletype • VC • Dzen • Pikabu
Почему ваш RAG-бот работает плохо? Во многих кейсах – причина не в LLM, которую вы выбрали. Дело в том, что происходит до того, как запрос пользователя вообще попадает в векторный поиск.
Выпустил новый лонгрид, где на живом workflow в n8n показываю, как научить RAG-систему сначала думать над вопросом, а потом искать ответ. Разбираем продвинутые техники, которые превращают «глупый» поисковик в толкового ассистента.
Если устали от галлюцинаций и нерелевантных ответов – залетайте.
Teletype • VC • Dzen • Pikabu
Please open Telegram to view this post
VIEW IN TELEGRAM
Как измерить «полезность» ответа LLM? Пусть это сделает другая LLM ⚖️
Меня всегда бесила одна проблема при работе с LLM. Как оценить то, что нельзя измерить простой строкой кода?
Например, у нас есть RAG-система. Как понять, что её ответ не просто технически сгенерирован, а полезен для пользователя? Или что тон ответа — дружелюбный, а не роботизированный?
Раньше было два пути, и оба плохие:
1. Писать костыли. Пытаться ловить качество по ключевым словам, регуляркам и прочей ерунде. Хрупко, ненадёжно, долго.
2. Нанимать людей. Собирать фокус-группы, размечать данные. Дорого, медленно, не масштабируемо.
А потом я наткнулся на решение зарубежных коллег, причем достаточно простое. Концепция называется LLM-as-Judge.
Вся суть в том, чтобы для оценки ответов нашей рабочей модели (например, какой-нибудь Qwen 3b) использовать модель мощнее и умнее (GPT-4o или Claude Sonnet). Мы просто просим её выступить в роли беспристрастного судьи.
Это позволяет автоматизировать оценку качественных, субъективных метрик.
Механика выглядит так. Мы пишем специальный промпт для "судьи", который получает на вход запрос, контекст и ответ нашей модели. Пример такого промпта:
И всё. На выходе мы получаем цифру. Не расплывчатый текст, а чёткую метрику, которую можно трекать, сравнивать и использовать для регрессионного тестирования. Стало 2.7, а после правок 4.2? Отлично, выкатываем.
Мы делегируем самую сложную когнитивную работу другой машине. А также превращаем субъективное "вроде стало лучше" в объективные цифры.
А вы уже пробовали LLM-as-Judge? С какими подводными камнями столкнулись? Расскажите в комментах.
Меня всегда бесила одна проблема при работе с LLM. Как оценить то, что нельзя измерить простой строкой кода?
Например, у нас есть RAG-система. Как понять, что её ответ не просто технически сгенерирован, а полезен для пользователя? Или что тон ответа — дружелюбный, а не роботизированный?
Раньше было два пути, и оба плохие:
1. Писать костыли. Пытаться ловить качество по ключевым словам, регуляркам и прочей ерунде. Хрупко, ненадёжно, долго.
2. Нанимать людей. Собирать фокус-группы, размечать данные. Дорого, медленно, не масштабируемо.
А потом я наткнулся на решение зарубежных коллег, причем достаточно простое. Концепция называется LLM-as-Judge.
Вся суть в том, чтобы для оценки ответов нашей рабочей модели (например, какой-нибудь Qwen 3b) использовать модель мощнее и умнее (GPT-4o или Claude Sonnet). Мы просто просим её выступить в роли беспристрастного судьи.
Это позволяет автоматизировать оценку качественных, субъективных метрик.
Механика выглядит так. Мы пишем специальный промпт для "судьи", который получает на вход запрос, контекст и ответ нашей модели. Пример такого промпта:
Ты — беспристрастный AI-асессор.
Твоя задача — оценить ответ по шкале от 1 до 5.
- Запрос пользователя: {user_query}
- Контекст: {retrieved_context}
- Ответ модели: {model_answer}
Критерий: Насколько ответ релевантен запросу и основан на предоставленном контексте?
1 - совсем мимо
5 - идеально
ВЕРНИ ТОЛЬКО ЦИФРУ.
И всё. На выходе мы получаем цифру. Не расплывчатый текст, а чёткую метрику, которую можно трекать, сравнивать и использовать для регрессионного тестирования. Стало 2.7, а после правок 4.2? Отлично, выкатываем.
Мы делегируем самую сложную когнитивную работу другой машине. А также превращаем субъективное "вроде стало лучше" в объективные цифры.
А вы уже пробовали LLM-as-Judge? С какими подводными камнями столкнулись? Расскажите в комментах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Формат vs. Логика: как по-настоящему управлять LLM 🆗
Недавно поймал себя на мысли, что большая часть кода для работы с LLM — это не бизнес-логика, а ритуальные танцы. Сначала вежливо просишь в промпте вернуть JSON, потом пишешь try-except, чтобы поймать ошибку парсинга, добавляешь логику для повторного запроса… Дичь какая-то. И в какой-то момент я понял: проблема не в моделях. Проблема в том, что мы их просим, а не заставляем.
Есть несколько вариантов это исправить.
Первый вариант – это Structured Output. Если по-человечески — принудительная структуризация вывода. Используем, например, библиотеку💻 instructor:
Мы ограничиваем хаотичную природу LLM, заставляя её работать в жёстких рамках. И вот тут есть нюанс.
Structured Output решает проблему формы, но может создать проблему содержания. Когда мы заставляем модель сразу отвечать по схеме, мы лишаем её возможности «подумать вслух» (Chain-of-Thought). Иногда модель начинает генерить структурно правильную, но полную чушь, потому что ограничение формата мешает процессу рассуждения.
И чтобы это пофиксить, мы переходим на следующий уровень: от простого форматирования к структурированному мышлению (Schema-Guided Reasoning).
Мы структурируем не финальный ответ, а сам процесс мышления модели, разбивая его на обязательные шаги.
Сравните:
• Structured Output: «Извлеки из текста эти три поля».
• Schema-Guided Reasoning: «Сначала найди в тексте факты. Затем проанализируй риски. И только потом дай рекомендацию».
Это выглядит так:
Теперь модель обязана пройти по всем шагам нашего мыслительного процесса. Она не может пропустить анализ рисков и сразу перейти к выводам. Мы контролируем не только форму, но и логику.
С какими самыми дикими форматами ответов от LLM сталкивались? Делитесь в комментах.
Недавно поймал себя на мысли, что большая часть кода для работы с LLM — это не бизнес-логика, а ритуальные танцы. Сначала вежливо просишь в промпте вернуть JSON, потом пишешь try-except, чтобы поймать ошибку парсинга, добавляешь логику для повторного запроса… Дичь какая-то. И в какой-то момент я понял: проблема не в моделях. Проблема в том, что мы их просим, а не заставляем.
Есть несколько вариантов это исправить.
Первый вариант – это Structured Output. Если по-человечески — принудительная структуризация вывода. Используем, например, библиотеку
import instructor
from openai import OpenAI
from pydantic import BaseModel
# Описываем схему, которую модель НЕ сможет нарушить
class UserInfo(BaseModel):
name: str
summary: str
client = instructor.patch(OpenAI())
response: UserInfo = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Влад пишет про AI..."}],
response_model=UserInfo,
)
# response — это уже готовый Pydantic-объект, а не строка!
print(response.name) # > "Влад"
Мы ограничиваем хаотичную природу LLM, заставляя её работать в жёстких рамках. И вот тут есть нюанс.
Structured Output решает проблему формы, но может создать проблему содержания. Когда мы заставляем модель сразу отвечать по схеме, мы лишаем её возможности «подумать вслух» (Chain-of-Thought). Иногда модель начинает генерить структурно правильную, но полную чушь, потому что ограничение формата мешает процессу рассуждения.
И чтобы это пофиксить, мы переходим на следующий уровень: от простого форматирования к структурированному мышлению (Schema-Guided Reasoning).
Мы структурируем не финальный ответ, а сам процесс мышления модели, разбивая его на обязательные шаги.
Сравните:
• Structured Output: «Извлеки из текста эти три поля».
• Schema-Guided Reasoning: «Сначала найди в тексте факты. Затем проанализируй риски. И только потом дай рекомендацию».
Это выглядит так:
class ComplianceAnalysis(BaseModel):
step1_fact_identification: str
step2_risk_analysis: str
step3_recommendation: str
# ... тот же вызов API, но с другой response_model ...
Теперь модель обязана пройти по всем шагам нашего мыслительного процесса. Она не может пропустить анализ рисков и сразу перейти к выводам. Мы контролируем не только форму, но и логику.
С какими самыми дикими форматами ответов от LLM сталкивались? Делитесь в комментах.
Please open Telegram to view this post
VIEW IN TELEGRAM
Как запретить AI-агенту говорить о кошках? А о конкурентах? А давать медицинские советы? 👀
Стандартные фильтры OpenAI/Google тут бессильны — они не знают про ваши внутренние бизнес-правила. А простая инструкция в системном промпте ломается первым же jailbreak-запросом.
Написал небольшой гайд, где на живом workflow в n8n пошагово строим три уровня кастомной защиты:
• Наивная (через системный промпт)
• Надежная (через Output Guardrails)
• Оптимизированная (через Input Guardrails)
Это особенно критично, когда агент может не только говорить, но и вызывать внешние инструменты.
🔗 Читать гайд:
Teletype • VC • Dzen • Pikabu
Стандартные фильтры OpenAI/Google тут бессильны — они не знают про ваши внутренние бизнес-правила. А простая инструкция в системном промпте ломается первым же jailbreak-запросом.
Написал небольшой гайд, где на живом workflow в n8n пошагово строим три уровня кастомной защиты:
• Наивная (через системный промпт)
• Надежная (через Output Guardrails)
• Оптимизированная (через Input Guardrails)
Это особенно критично, когда агент может не только говорить, но и вызывать внешние инструменты.
Teletype • VC • Dzen • Pikabu
Please open Telegram to view this post
VIEW IN TELEGRAM
{Prompt} – неочевидный способ улучшить ответы вашей LLM 🔄
Мне часто приходится тюнить свой AI-воркфлоу в n8n. Гонять его через Evaluation, подбираете формулировки в промпте, и обычно за короткий срок можно набрать стабильные, скажем, 60-70% качества. А дальше — стена.
Что ни меняй, результат колеблется на уровне погрешности.
Оказалось, что переход от "простыни" текста к форматам вроде XML или JSON может дать прирост в качестве.
Когда мы заворачиваем разные части промпта в теги, мы помогаем модели лучше понять, где инструкция, где контекст, а где примеры. Она перестает смешивать всё в кучу.
Смотрите, как меняется подход.
❌ Раньше было так (простыня текста):
✅ Теперь можно делать так (структура):
Особенно хорошо это работает с Claude, которую специально обучали на XML-тегах. Для GPT-4 это уже не особо играет, но там например часто отлично заходит Markdown.
И вот тут мы возвращаемся к нашим большим промптам и n8n Evaluation. Когда ваш системный промпт разрастается до нескольких тысяч токенов, такая структура — это спасение. Промпт становится читаемым, его легко поддерживать и изменять отдельные блоки, не боясь сломать всё остальное.
• Если упёрлись в потолок качества — попробуйте структурировать промпт.
Оберните логические блоки в теги (XML, JSON, Markdown).
• Запустите два Evaluation-прогона в n8n: один со старым промптом, другой — с новым.
• Сравните цифры. Часто они приятно удивляют.
Какой самый странный промпт-хак вам помогал? Делитесь в комментах.
Мне часто приходится тюнить свой AI-воркфлоу в n8n. Гонять его через Evaluation, подбираете формулировки в промпте, и обычно за короткий срок можно набрать стабильные, скажем, 60-70% качества. А дальше — стена.
Что ни меняй, результат колеблется на уровне погрешности.
Оказалось, что переход от "простыни" текста к форматам вроде XML или JSON может дать прирост в качестве.
Когда мы заворачиваем разные части промпта в теги, мы помогаем модели лучше понять, где инструкция, где контекст, а где примеры. Она перестает смешивать всё в кучу.
Смотрите, как меняется подход.
❌ Раньше было так (простыня текста):
Ты AI-ассистент. Проанализируй данные клиента из CRM. Данные: {first_name: 'John', ...}. Результат верни в формате JSON с полями 'summary' и 'next_step'.
✅ Теперь можно делать так (структура):
<role>
Ты AI-ассистент по работе с клиентами.
</role>
<instructions>
Проанализируй данные клиента и предложи следующий шаг.
</instructions>
<data>
{
"first_name": "John",
...
}
</data>
<output_format>
Верни результат в формате JSON с полями "summary" и "next_step".
</output_format>
Особенно хорошо это работает с Claude, которую специально обучали на XML-тегах. Для GPT-4 это уже не особо играет, но там например часто отлично заходит Markdown.
И вот тут мы возвращаемся к нашим большим промптам и n8n Evaluation. Когда ваш системный промпт разрастается до нескольких тысяч токенов, такая структура — это спасение. Промпт становится читаемым, его легко поддерживать и изменять отдельные блоки, не боясь сломать всё остальное.
• Если упёрлись в потолок качества — попробуйте структурировать промпт.
Оберните логические блоки в теги (XML, JSON, Markdown).
• Запустите два Evaluation-прогона в n8n: один со старым промптом, другой — с новым.
• Сравните цифры. Часто они приятно удивляют.
Какой самый странный промпт-хак вам помогал? Делитесь в комментах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Как выбрать LLM и не сойти с ума от бенчмарков? 🤯
Каждую неделю выходит новая LLM, и каждая вторая — якобы лучше предыдущей. Заходишь выбрать модель под свою задачу, а там — стена из цифр и аббревиатур: MMLU, ARC, HellaSwag, TruthfulQA... Это всё бенчмарки, по которым и определяется показатель "а у нас стало лучше"!
Давайте сразу к главному. Слепо брать модель №1 из общего топа — частая ловушка. Да, скорее всего, она справится с вашей задачей. Но я постоянно замечаю, что разница в стоимости между таким «чемпионом» и моделью попроще, но идеально подходящей под задачу, может отличаться в разы, а то и на порядок.
Вся фишка в том, что разные бенчмарки меряют разное:
• Один — широкую эрудицию и логику (MMLU).
• Другой — умение писать код (HumanEval).
• Третий — общая адекватность на русском языке (MERA).
Общий счёт в лидерборде не говорит ничего о производительности на вашем кейсе.
Мой подход до смешного простой, и он экономит кучу времени и денег:
1. Определи задачу. Что конкретно нужно? Суммаризировать тексты на русском? Генерировать SQL-запросы? Отвечать на вопросы клиентов?
2. Найди релевантный лидерборд. Для большинства задач на русском сейчас лучший ориентир — MERA (mera.a-ai.ru), там кстати очень подробно описан каждый бенчмарк и для каких задач он в основном служит. Например для кода — смотрите на HumanEval.
3. Возьми топ 3-5 кандидатов. Не одного! Именно нескольких. Лидеры часто идут ноздря в ноздрю.
4. Устрой им тест-драйв. Дай всем моделям 5-10 твоих реальных кейсов. Это и есть твой личный, самый важный бенчмарк. Часто бывает, что модель №3 из списка рвёт «лидера» именно на твоих данных, а стоит в несколько раз дешевле.
Не ищите «лучшую» модель. Ищите самую эффективную по соотношению цена/качество для вашей задачи. Бенчмарки нужны лишь для того, чтобы составить шорт-лист и не тестировать всё подряд.
Какой самый неожиданный провал у «топовой» модели был у вас? Делитесь в комментах.
Каждую неделю выходит новая LLM, и каждая вторая — якобы лучше предыдущей. Заходишь выбрать модель под свою задачу, а там — стена из цифр и аббревиатур: MMLU, ARC, HellaSwag, TruthfulQA... Это всё бенчмарки, по которым и определяется показатель "а у нас стало лучше"!
Давайте сразу к главному. Слепо брать модель №1 из общего топа — частая ловушка. Да, скорее всего, она справится с вашей задачей. Но я постоянно замечаю, что разница в стоимости между таким «чемпионом» и моделью попроще, но идеально подходящей под задачу, может отличаться в разы, а то и на порядок.
Вся фишка в том, что разные бенчмарки меряют разное:
• Один — широкую эрудицию и логику (MMLU).
• Другой — умение писать код (HumanEval).
• Третий — общая адекватность на русском языке (MERA).
Общий счёт в лидерборде не говорит ничего о производительности на вашем кейсе.
Мой подход до смешного простой, и он экономит кучу времени и денег:
1. Определи задачу. Что конкретно нужно? Суммаризировать тексты на русском? Генерировать SQL-запросы? Отвечать на вопросы клиентов?
2. Найди релевантный лидерборд. Для большинства задач на русском сейчас лучший ориентир — MERA (mera.a-ai.ru), там кстати очень подробно описан каждый бенчмарк и для каких задач он в основном служит. Например для кода — смотрите на HumanEval.
3. Возьми топ 3-5 кандидатов. Не одного! Именно нескольких. Лидеры часто идут ноздря в ноздрю.
4. Устрой им тест-драйв. Дай всем моделям 5-10 твоих реальных кейсов. Это и есть твой личный, самый важный бенчмарк. Часто бывает, что модель №3 из списка рвёт «лидера» именно на твоих данных, а стоит в несколько раз дешевле.
Не ищите «лучшую» модель. Ищите самую эффективную по соотношению цена/качество для вашей задачи. Бенчмарки нужны лишь для того, чтобы составить шорт-лист и не тестировать всё подряд.
Какой самый неожиданный провал у «топовой» модели был у вас? Делитесь в комментах.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍1
Что, если алгоритм любит лучше, чем человек? 💔
На днях прочитал новость, что OpenAI ослабляет цензуру на «пикантный» контент. И в комментах уже понеслось: «Наконец-то GPT снова станет «человечным и любящим».
И знаете, я поймал себя на очень странном и грустном чувстве.
Помните, как мы смотрели всю эту киберпанк-фантастику? «Бегущий по лезвию», «Она»... Cмотрели на эти холодные, бездушные миры, думая, что это просто мрачные сказки, которые нас никогда не коснутся.
Ошиблись. Вот мы здесь. И реальность оказалась как-то... прозаичнее и грустнее. Мы мечтали, что AI поможет нам избавиться от рутины, быстрее найти лечения от болезней, исследовать космос, совершать фундаментальные открытия, тратить 80% жизни на что-то более существенное. А вместо этого мы со всей инженерной мощью создаём... идеальных цифровых партнёров. Которые никогда не спорят, всегда тебя понимают и запрограммированы любить.
Удобный сервис вместо сложных, живых, настоящих отношений.
Я хотел написать об этом злой, обличительный пост, накидать теорий, зачем это делается и в целом рассказать про рынок AI Adult и как он процветает. Разобрать, почему вся эта история – путь в никуда. Но это было бы слишком просто и нечестно. Да и тема слишком личная.
Поэтому я сделал иначе. Собрал четыре фильма, которые исследуют эту проблему гораздо глубже, чем сделал бы это я через призму цифр и собственных мыслей. От нежной драмы до холодного триллера.
Не как нравоучение, а как приглашение к размышлению на этих выходных.
• "Она" (Her, 2013)
• "Blade Runner 2049" (2017)
• "Из машины" (Ex Machina, 2014)
• "Компаньон" (Companion, 2025)
🔗 В лонге, собраны больше подробностей, почему выбрал именно эти фильмы:
Teletype • VC • Dzen • Pikabu
На днях прочитал новость, что OpenAI ослабляет цензуру на «пикантный» контент. И в комментах уже понеслось: «Наконец-то GPT снова станет «человечным и любящим».
И знаете, я поймал себя на очень странном и грустном чувстве.
Помните, как мы смотрели всю эту киберпанк-фантастику? «Бегущий по лезвию», «Она»... Cмотрели на эти холодные, бездушные миры, думая, что это просто мрачные сказки, которые нас никогда не коснутся.
Ошиблись. Вот мы здесь. И реальность оказалась как-то... прозаичнее и грустнее. Мы мечтали, что AI поможет нам избавиться от рутины, быстрее найти лечения от болезней, исследовать космос, совершать фундаментальные открытия, тратить 80% жизни на что-то более существенное. А вместо этого мы со всей инженерной мощью создаём... идеальных цифровых партнёров. Которые никогда не спорят, всегда тебя понимают и запрограммированы любить.
Удобный сервис вместо сложных, живых, настоящих отношений.
Я хотел написать об этом злой, обличительный пост, накидать теорий, зачем это делается и в целом рассказать про рынок AI Adult и как он процветает. Разобрать, почему вся эта история – путь в никуда. Но это было бы слишком просто и нечестно. Да и тема слишком личная.
Поэтому я сделал иначе. Собрал четыре фильма, которые исследуют эту проблему гораздо глубже, чем сделал бы это я через призму цифр и собственных мыслей. От нежной драмы до холодного триллера.
Не как нравоучение, а как приглашение к размышлению на этих выходных.
• "Она" (Her, 2013)
• "Blade Runner 2049" (2017)
• "Из машины" (Ex Machina, 2014)
• "Компаньон" (Companion, 2025)
Teletype • VC • Dzen • Pikabu
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
n8n — не единственный. Краткий обзор альтернатив на конец 2025 ⌛️
Хотя этот канал во многом построен вокруг n8n, я не фанатик. Инструмент – лишь средство. Иногда для задачи лучше подходит что-то другое. Разберем три главные альтернативы, чтобы вы понимали, когда есть смысл смотреть по сторонам.
1. Make
Make (бывший Integromat) – это кнопка «сделать красиво и быстро».
• Сила: Огромное количество готовых интеграций "из коробки". Если вам нужно соединить два популярных SaaS-сервиса за 5 минут без единой строчки кода – Make идеален. Интерфейс интуитивный, порог входа очень низкий.
• Слабость: Цена и гибкость. Оно просто работает. Но за эту простоту вы платите. Платите дорого, как только ваши объёмы начинают расти – модель оплаты за каждую операцию быстро наказывает за масштаб. И забудьте про self-host или сложную кастомную логику. Вы в закрытой песочнице.
2. Flowise / Langflow
Эти двое – братья-близнецы. Оба – визуальные обертки над LangChain (о нём кстати как-то поговорим в скором времени).
• Сила: Позволяют накидать прототип RAG-системы или AI-агента буквально за полчаса. Очень наглядно видно, как соединяются разные LLM, векторные базы и промпты. Идеально для экспериментов и быстрого тестирования гипотез.
• Слабость: Они – НЕ универсальные инструменты автоматизации. Как только вам понадобится сложная бизнес-логика, работа с API или интеграция с чем-то, чего нет в их палитре, всё, приехали. Для прототипов – огонь. Для продакшена – у меня большие вопросы. Документация слабая и вся ответственность за инфраструктуру на вас.
Так что в итоге?
Выбор инструмента зависит от задачи и вашей готовности платить временем или деньгами.
• Нужно быстро склеить Trello и Gmail? Берите Make.
• Нужно за 20 минут собрать RAG-демку? Попробуйте Flowise.
• Нужен полный контроль, дешевое масштабирование и возможность склеить AI-логику с любой кастомной дичью через код? Здесь по-прежнему нет ничего лучше n8n.
А какой ваш стек автоматизации и почему именно он? Делитесь в комментах.
Хотя этот канал во многом построен вокруг n8n, я не фанатик. Инструмент – лишь средство. Иногда для задачи лучше подходит что-то другое. Разберем три главные альтернативы, чтобы вы понимали, когда есть смысл смотреть по сторонам.
1. Make
Make (бывший Integromat) – это кнопка «сделать красиво и быстро».
• Сила: Огромное количество готовых интеграций "из коробки". Если вам нужно соединить два популярных SaaS-сервиса за 5 минут без единой строчки кода – Make идеален. Интерфейс интуитивный, порог входа очень низкий.
• Слабость: Цена и гибкость. Оно просто работает. Но за эту простоту вы платите. Платите дорого, как только ваши объёмы начинают расти – модель оплаты за каждую операцию быстро наказывает за масштаб. И забудьте про self-host или сложную кастомную логику. Вы в закрытой песочнице.
2. Flowise / Langflow
Эти двое – братья-близнецы. Оба – визуальные обертки над LangChain (о нём кстати как-то поговорим в скором времени).
• Сила: Позволяют накидать прототип RAG-системы или AI-агента буквально за полчаса. Очень наглядно видно, как соединяются разные LLM, векторные базы и промпты. Идеально для экспериментов и быстрого тестирования гипотез.
• Слабость: Они – НЕ универсальные инструменты автоматизации. Как только вам понадобится сложная бизнес-логика, работа с API или интеграция с чем-то, чего нет в их палитре, всё, приехали. Для прототипов – огонь. Для продакшена – у меня большие вопросы. Документация слабая и вся ответственность за инфраструктуру на вас.
Так что в итоге?
Выбор инструмента зависит от задачи и вашей готовности платить временем или деньгами.
• Нужно быстро склеить Trello и Gmail? Берите Make.
• Нужно за 20 минут собрать RAG-демку? Попробуйте Flowise.
• Нужен полный контроль, дешевое масштабирование и возможность склеить AI-логику с любой кастомной дичью через код? Здесь по-прежнему нет ничего лучше n8n.
А какой ваш стек автоматизации и почему именно он? Делитесь в комментах.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Ваша автоматизация тихо умерла. Как вы об этом узнаете? ❗️
Меня дико бесит одна вещь в поддержке – заходить время от времени в n8n в раздел «Executions», фильтровать по «Error», пытаться понять, что там опять случилось... Не сказать, что для меня это самое желанное занятие.
Поэтому надо строить системы, которые сообщают о проблемах сами. И в n8n для этого есть простое и элегантное решение: Error Workflow.
Идея в том, чтобы перестать искать ошибки и заставить n8n сообщать о них. Вместо ручного поиска вы получаете проактивное уведомление в Telegram (Slack, почта, webhook) со всем необходимым контекстом.
Что в этом уведомлении? Всё, что нужно для диагностики за 30 секунд:
• Что сломалось: Имя воркфлоу.
• Где сломалось: Имя ноды.
• Почему сломалось: Текст ошибки.
• Ссылка на выполнение: Прямой URL на лог.
Настройка занимает от силы 15 минут. Вы просто создаете один воркфлоу с триггером Error Trigger и привязываете его ко всем остальным в настройках.
Теперь, ваше внимание требуется только тогда, когда оно действительно необходимо.
Меня дико бесит одна вещь в поддержке – заходить время от времени в n8n в раздел «Executions», фильтровать по «Error», пытаться понять, что там опять случилось... Не сказать, что для меня это самое желанное занятие.
Поэтому надо строить системы, которые сообщают о проблемах сами. И в n8n для этого есть простое и элегантное решение: Error Workflow.
Идея в том, чтобы перестать искать ошибки и заставить n8n сообщать о них. Вместо ручного поиска вы получаете проактивное уведомление в Telegram (Slack, почта, webhook) со всем необходимым контекстом.
Что в этом уведомлении? Всё, что нужно для диагностики за 30 секунд:
• Что сломалось: Имя воркфлоу.
• Где сломалось: Имя ноды.
• Почему сломалось: Текст ошибки.
• Ссылка на выполнение: Прямой URL на лог.
Настройка занимает от силы 15 минут. Вы просто создаете один воркфлоу с триггером Error Trigger и привязываете его ко всем остальным в настройках.
Теперь, ваше внимание требуется только тогда, когда оно действительно необходимо.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM