Raycast и принцип «сэкономленных секунд»: как мелкие улучшения возвращают часы ⌛️

Знакомый цифровой хаос? Открыть заметки, чтобы скопировать команду, переключиться в браузер на 25-ю вкладку с доками, найти в контактах коллегу, чтобы ему написать... Одна простая задача — несколько приложений и куча переключений контекста.

Оказалось, большую часть этих «микро-пауз» можно убрать. Выпустил новый лонгрид про Raycast — не как про лаунчер, а как про способ борьбы с мелким, но дико раздражающим трением в рабочих процессах.

Что внутри:
• Мой путь от «очередной лаунчер» до «главный рабочий инструмент».
• Конкретные замеры в секундах: как одна команда заменяет минуту рутины.
• Скелет моей системы: Snippets, Quicklinks, AI-команды, которые я использую каждый день.
• Ложка дегтя: где есть порог входа и что мне не нравилось поначалу.

Если тоже чувствуете, что воюете с интерфейсами, а не с задачами — залетайте.

🔗 Читайте подробный гайд на:
Teletype • VC • Dzen • Pikabu

Правильная векторная база для 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 сталкивались вы? Расскажите в комментах.

От «вроде стало лучше» к цифрам. Главное про n8n Evaluation 📰

Главная боль при работе с AI — его вероятностная природа. Поменял одно слово в промпте — где-то в другом месте всё посыпалось. Улучшил ответ для одного кейса — сломал десять других. До сих пор проверка качества AI-воркфлоу напоминала шаманство с бубном.

Так вот, в n8n выкатили фичу, которая наконец-то позволяет опираться хоть на какие-то метрики качества. Называется Evaluation.

Если коротко, это встроенная система для тестирования ваших AI-цепочек. Теперь можно не гадать, стало ли лучше после изменений, а получить конкретные цифры.

Механика простая:
1. Готовишь табличку (куда же без табличек) с тестовыми примерами: входные данные и эталонный, правильный ответ.
2. Настраиваешь в n8n ветку с логикой оценки (например, "сравни ответ модели с эталоном по смыслу"). Стоит отметить, что n8n уже добавили все необхоидмые новые ноды для постройки подобных штук.
3. Запускаешь прогон и смотришь на итоговый score.

И вот тут начинается самое интересное. Я сейчас активно гоняю эту фичу на своих RAG-воркфлоу. Подбираю идеальные параметры для векторной базы, тюню промпты для поиска и генерации ответа, меняю модели. Раньше на это уходили часы/дни ручных проверок. Теперь я вношу изменение, нажимаю кнопку и через 5 минут вижу, стал ли общий результат лучше или хуже.

Самое главное датасет (табличку) хороший собрать. У меня например уже порядка 100 проверочных кейсов, страшно представить сколько я бы руками всё это дело проверял бы каждый раз.

⬆️ Качество AI цепочки, естествено, улучшилось в разы после подобных манипуляций.

Сейчас как раз готовлю небольшой разбор нескольких вариантов реализации RAG в n8n, и там мы будем использовать Evaluation по полной. А пока...

Как вы сейчас проверяете, что ваш новый промпт не сломал всё остальное? Расскажите в комментах.

Продвинутые RAG-паттерны в n8n ⭐️

Почему ваш RAG-бот работает плохо? Во многих кейсах – причина не в LLM, которую вы выбрали. Дело в том, что происходит до того, как запрос пользователя вообще попадает в векторный поиск.

Выпустил новый лонгрид, где на живом workflow в n8n показываю, как научить RAG-систему сначала думать над вопросом, а потом искать ответ. Разбираем продвинутые техники, которые превращают «глупый» поисковик в толкового ассистента.

Если устали от галлюцинаций и нерелевантных ответов – залетайте.

🔗 Читайте подробный гайд на:
Teletype • VC • Dzen • Pikabu

Как измерить «полезность» ответа LLM? Пусть это сделает другая LLM ⚖️

Меня всегда бесила одна проблема при работе с 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? С какими подводными камнями столкнулись? Расскажите в комментах.

Формат vs. Логика: как по-настоящему управлять LLM 🆗

Недавно поймал себя на мысли, что большая часть кода для работы с LLM — это не бизнес-логика, а ритуальные танцы. Сначала вежливо просишь в промпте вернуть JSON, потом пишешь try-except, чтобы поймать ошибку парсинга, добавляешь логику для повторного запроса… Дичь какая-то. И в какой-то момент я понял: проблема не в моделях. Проблема в том, что мы их просим, а не заставляем.

Есть несколько вариантов это исправить.

Первый вариант – это Structured Output. Если по-человечески — принудительная структуризация вывода. Используем, например, библиотеку 💻 instructor:

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 сталкивались? Делитесь в комментах.

Как запретить AI-агенту говорить о кошках? А о конкурентах? А давать медицинские советы? 👀

Стандартные фильтры OpenAI/Google тут бессильны — они не знают про ваши внутренние бизнес-правила. А простая инструкция в системном промпте ломается первым же jailbreak-запросом.

Написал небольшой гайд, где на живом workflow в n8n пошагово строим три уровня кастомной защиты:
• Наивная (через системный промпт)
• Надежная (через Output Guardrails)
• Оптимизированная (через Input Guardrails)

Это особенно критично, когда агент может не только говорить, но и вызывать внешние инструменты.

🔗 Читать гайд:
Teletype • VC • Dzen • Pikabu

{Prompt} – неочевидный способ улучшить ответы вашей LLM 🔄

Мне часто приходится тюнить свой 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: один со старым промптом, другой — с новым.
• Сравните цифры. Часто они приятно удивляют.

Какой самый странный промпт-хак вам помогал? Делитесь в комментах.

Как выбрать 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 из списка рвёт «лидера» именно на твоих данных, а стоит в несколько раз дешевле.

Не ищите «лучшую» модель. Ищите самую эффективную по соотношению цена/качество для вашей задачи. Бенчмарки нужны лишь для того, чтобы составить шорт-лист и не тестировать всё подряд.

Какой самый неожиданный провал у «топовой» модели был у вас? Делитесь в комментах.

Что, если алгоритм любит лучше, чем человек? 💔

На днях прочитал новость, что OpenAI ослабляет цензуру на «пикантный» контент. И в комментах уже понеслось: «Наконец-то GPT снова станет «человечным и любящим».
И знаете, я поймал себя на очень странном и грустном чувстве.

Помните, как мы смотрели всю эту киберпанк-фантастику? «Бегущий по лезвию», «Она»... Cмотрели на эти холодные, бездушные миры, думая, что это просто мрачные сказки, которые нас никогда не коснутся.

Ошиблись. Вот мы здесь. И реальность оказалась как-то... прозаичнее и грустнее. Мы мечтали, что AI поможет нам избавиться от рутины, быстрее найти лечения от болезней, исследовать космос, совершать фундаментальные открытия, тратить 80% жизни на что-то более существенное. А вместо этого мы со всей инженерной мощью создаём... идеальных цифровых партнёров. Которые никогда не спорят, всегда тебя понимают и запрограммированы любить.

Удобный сервис вместо сложных, живых, настоящих отношений.

Я хотел написать об этом злой, обличительный пост, накидать теорий, зачем это делается и в целом рассказать про рынок AI Adult и как он процветает. Разобрать, почему вся эта история – путь в никуда. Но это было бы слишком просто и нечестно. Да и тема слишком личная.

Поэтому я сделал иначе. Собрал четыре фильма, которые исследуют эту проблему гораздо глубже, чем сделал бы это я через призму цифр и собственных мыслей. От нежной драмы до холодного триллера.

Не как нравоучение, а как приглашение к размышлению на этих выходных.

• "Она" (Her, 2013)
• "Blade Runner 2049" (2017)
• "Из машины" (Ex Machina, 2014)
• "Компаньон" (Companion, 2025)

🔗 В лонге, собраны больше подробностей, почему выбрал именно эти фильмы:
Teletype • VC • Dzen • Pikabu

Делаем работу с n8n комфортной. Рекомендации по настройке ⚙️

Я несколько раз поднимал n8n у себя. И каждый раз ловил себя на мысли: почему базовая установка вроде работает, но ощущается… как тестовый стенд? Логов нет, база тормозит, интерфейс отваливается через пару дней.

Потом понял – дело не в самом n8n, а в его настройках по умолчанию. Они сделаны для того, чтобы вы могли запустить его за 5 минут и поиграться. Они не сделаны для реальной работы.

Если вы хотите не просто «запустить», а построить надежную систему, которая не умрет тихо ночью, нужно уделить полчаса конфигурации.

Чтобы вы не тратили недели на сбор граблей, я собрал весь свой опыт в один большой лонгрид. Это не пересказ документации, а практический чеклист.

Внутри разбираю самые частые проблемы:
• Почему ваши воркфлоу срабатывают в 3 ночи, а не в 10 утра?
• Куда через неделю исчезают все логи успешных выполнений?
• Как сделать так, чтобы ваша база не раздулась до 10 ГБ за месяц?

Короче, всё то, что превращает «игрушку» в рабочий инструмент.

🔗 Читать гайд:
VC • Pikabu

Автоматизация, которая зашла слишком далеко. Один поучительный кейс 😵‍💫

Недавно наблюдал историю одного предпринимателя в сети, и она меня зацепила. Заставила задуматься о последствиях того, чем мы тут с вами занимаемся.

Он горел своим делом. Собрал с нуля команду, где многие процессы держались на людях. Счета, отчёты, общение с клиентами – многое делалось руками, и эта ручная рутина была частью их корпоративной ДНК.

А потом он открыл для себя автоматизацию.

В нём проснулся инженер. Он увидел, как можно убрать всё трение, всю рутину, и с горящими глазами начал строить воркфлоу, писать скрипты, оптимизировать всё, до чего мог дотянуться. Счета стали улетать сами, отчёты генерировались по ночам, базы данных синхронизировались без единого клика. Эффективность взлетела до небес. Его компания превратилась в машину.

А потом его команда начала... таять. Бухгалтер, чью работу теперь выполнял скрипт. Менеджер, чьи еженедельные отчёты превратились в дашборд. Специалист поддержки, заменённый умным ботом. В итоге он оставил только зама и тех, кого заменить пока не получилось.

Он – гениальный оптимизатор, герой, который построил эффективный бизнес? Или просто человек, который так увлёкся решением задачи, что забыл о людях, с которыми её начинал?

И вот тут важно понять: проблема не в автоматизации. Инструмент не может быть злым или добрым. Злой или доброй может быть система, в которой его применяют.

Использует ли компания автоматизацию, чтобы усилить своих людей, освободив их от рутины для более сложных задач? Или чтобы от них избавиться, срезав косты?

Да, можно говорить о переквалификации. Это гуманный путь. Но не все готовы или хотят становиться аналитиками после 20 лет работы с бумагами. И это их право. Да и будем честны, сегодня ты переучиваешь бухгалтера в аналитика, а завтра заменяешь аналитика более умной моделью.

И это не просто какая-то гипотетическая страшилка. Это уже происходит. За 2025 год из-за AI и автоматизации работу потеряли более 130 000 технических специалистов. Не кассиров или водителей (там вообще цифры наверное жесть). А таких как мы с вами.

Я веду этот блог с одной мыслью: автоматизация должна усиливать людей, а не заменять их. Позволять им получить то самое время для ещё больших открытий и возможностей.

Мы создаём более эффективный мир. Но становится ли он от этого лучше?