Новое Распределяем каналы MAX по категориям и территориям. Читать новость
Открытый канал ID 70926720041177

Инженер Контекста

Евгений Левашов, контент-лид в VK Tech, отвечаю за VK Cloud, VK Data Platform, Tarantool и другой технохардкор. Редактирую ИТ-компании, консультирую, учу. Здесь всё про Ai в контенте, дату, облака и остальной ИТ.

CC BY-NC-SA 4.0

Открыть в MAX

Публикации за период

По реакциям

Поиск и вся лента — после бесплатной регистрации. Свои даты — по подписке; владелец канала видит их бесплатно. Сортировка по реакциям — по подписке. Зарегистрироваться

Загрузка…

Выложил в опенсорс скилл aeo-trust-blocks для аудита и переработки текста под AI-выдачу. Проверяет, насколько безопасно ИИ-поисковикам (ChatGPT, Perplexity, Google AI Overviews, Яндекс Нейро) цитировать ваш контент, и переписывает слабые места в самодостаточные блоки доверия — Extractable Trust Blocks.

Что внутри:

➡️ Аудит cite-safety — каждый блок текста оценивается по шкале 0–10 (извлекаемость, прямой ответ, фактологичность, структура, объём, имплицитные ссылки, нейтральность);
➡️ чек-лист самодостаточности и каталог «слепых зон контекста»;
➡️ формула Trust Block: [Утверждение] → [Объяснение] → [Граница применимости] → [Пример/Источник] и 6 типов блоков под разные интенты (answer capsule, fact block, comparison, how-to, definition, key takeaway);
➡️ замены «размыто → конкретно» («быстрое внедрение» → «внедрение за 2–4 часа»);
➡️ безопасная JSON-LD-разметка (Article, FAQPage, Organization) без нарушения structured data policies;
➡️ контракт с голосом канала: что переводить в ETB, а что оставить живым;
➡️ защита фактуры: цифры, цитаты и атрибуции при переработке не меняются.

Результат — таблица аудита (фрагмент → проблемы → переработанный блок → как повышен cite-safety) и итоговый Cite-Safety Score до/после.

📌 GitHub📌

Следующий скилл на тысяче подписчиков, что на моём скучном контенте выглядит не очень реальным. 😂

#ai_skills #ai
Просмотры: 25
Перейти в пост Открыть в MAX Сообщить о неточности
0.5
— на 3-м → 0.33
— на 5-м → 0.2
Потом усредняю по всем запросам. У меня вышло 0.847 — в среднем нужное стоит между первым и вторым местом. То есть поиск не просто «где-то находит», а выносит правильное почти в самый верх. Это уже хорошо.

Метрика 3: precision@5 — «а сколько мусора рядом?»
И вот честная, неприятная цифра. Precision спрашивает: из пяти выданных карточек сколько реально по делу? У меня ~0.21. Грубо: из пяти результатов по-настоящему нужный обычно один, а четыре это «рядом лежало, зацепилось по теме». Выдача грязновата. Казалось бы плохо, но тут важно, для кого этот поиск. Если бы результат читал человек и ему пришлось глазами продираться через мусор — да, беда. А у меня получатель агент (LLM). Он получает стопку из пяти карточек и сам отбрасывает нерелевантное: контекста ему хватает. Поэтому я сознательно терплю низкую precision ради высокого hit@5, лучше отдать лишнее, чем упустить нужное. Но и это принципиально — цифру я вижу. Не прячу, не округляю в уме до «нормально». Если однажды агент начнёт захлёбываться в мусоре, я замечу это по метрике заранее, а не по кривым статьям постфактум.

Главный вывод: RAG на русском ломается не на эмбеддингах, а на морфологии запроса. Пока агент пишет «базами данных», а ты ищешь по databases — никакая база не поможет. Сначала научи систему понимать, что это одно и то же. А потом обязательно померь, иначе будешь улучшать вслепую.
Просмотры: 20
Перейти в пост Открыть в MAX Сообщить о неточности
Вернёмся к практике разработки фабрики контента. Как агент находит нужный факт в базе на 200+ карточек

Я вроде рассказал, как собрал агентам базу знаний-граф? Если не рассказывал, то там я пришёл к той же идее, что Карпатый описывал как LLM Wiki, — связный самоподдерживающийся граф концептов, где всё ссылается друг на друга в обе стороны. Могу отдельно рассказать про карточки и базу отдельно, если интересно.

Но база бесполезна, если агент не может достать из неё нужное. И вот тут началось самое весёлое. Наивный план был такой: агент формулирует запрос → ищем по тегам → отдаём карточки. Запустил. Агент спрашивает про «работу с базами данных» — находит ноль. Хотя в базе лежит жирный синтез с тегом databases.

Проблема — русский язык. Морфология, будь она неладна

Агент пишет запрос живым языком: «базами данных», «облака в России», «искусственного интеллекта». А теги в базе канонические: databases, cloud, ai. Точного совпадения нет. Падежи, порядок слов, синонимы — всё это ломает простой поиск.

Пришлось строить query expansion — разворачивать запрос перед поиском:

➡️ Синонимы и алиасы. «ИИ» и «субд» — это ai и databases. Ведётся словарь синонимических групп поверх таксономии: каждый канонический тег знает все свои народные варианты.
➡️ Лёгкий RU-стеммер. Отрезаю частое окончание, чтобы «облако», «облака», «облаком» сводились к одному стему. Намеренно тупой стеммер на ~10 правил, но его достаточно и он не тянет зависимостей.
➡️ Фразовый индекс по стемам. Многословный алиас «базы-данных» распознаётся во фразе «работа с базами данных» — по множеству стемов частей, несмотря на падеж и порядок слов. Внутри это frozenset стемов: пересеклись — попадание.

Синоним матчится не только против тегов файла, но и против его домена — это ловит карточки, где тема зашита в домен, а теги пустые.

fact-cards — отдельным потоком

Обычные синтезы ранжируются в общий шортлист. А вот проверяемые факты поднимаются отдельно с уровнем доверия (confidence) и допуском к публикации (allowed_use). Просроченные по expires из выдачи вырезаются молча, чтобы автор физически не смог процитировать протухшую цифру. Ретривер тут работает как фильтр доверия, а не просто поиск.

Playbook на каждый сценарий

Не «агент, посмотри базу». А конкретная карта: для этого типа материала подавай сначала fact-cards и позиционирование, конкурентов по релевантности, а вот эти слои вообще запрещены без явной проверки. Один сценарий — один playbook.

И самое важное — я это померил

Тут очень легко себя обмануть. Погонял поиск руками, пару раз он выдал что нужно и ты такой: «работает». А на деле ты проверил три запроса из тысячи возможных, и на четвёртом всё разваливается. «Вроде находит» — это не факт, это ощущение.

Чтобы перестать врать себе, я сделал скучную, но честную вещь: завёл метрики для поиска. Это просто список запросов, где я заранее, руками, отметил правильный ответ. Типа:

Запрос: «тренды систем управления базами данных»
Правильный ответ: вот эта карточка и вот эта

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

Метрика 1: hit@5 — «нашёл ли вообще?»
Самый простой вопрос: в первых пяти результатах есть нужная карточка — да или нет? Считаю по всем запросам долю, где ответ «да». Сейчас это 1.0 — то есть по каждому из 15 запросов нужное лежит где-то в топ-5. Пока что промахов нет вообще. Почему именно топ-5, а не топ-1? Потому что агенту я и так отдаю несколько карточек — ему есть из чего выбрать. Мне важно, чтобы нужное попало в стопку, которую он получит.

Метрика 2: MRR — «а насколько высоко?»
Попасть в топ-5 мало. Одно дело — нужная карточка на 1-м месте, другое — на 5-м, за четырьмя лишними. MRR смотрит, на какой строчке стоит нужный ответ, и переводит это в оценку:
— ответ на 1-м месте → 1.0 (идеал)
— на 2-м →
Просмотры: 17
Перейти в пост Открыть в MAX Сообщить о неточности
Ваши скиллы возможно написаны под модель, которой уже нет

Anthropic удалила больше 80% системного промпта из Claude Code, и качество на их тестах не упало. Пересказывать статью не буду, интереснее, что из этого следует, если вы сами пишете агентов и скиллы.

1. Половина ваших правил — заплатки на провалы прошлых версий. «Не начинай с общих фраз», «не используй конструкцию X» — вы это добавляли, потому что модель так делала. Перестала делать, и правило работает вхолостую, а иногда против вас: запрет отнимает у сильной модели право решать по ситуации. Что сделать: пройти по скиллам и рядом с каждым правилом поставить дату и ошибку, из-за которой оно появилось. Где ошибку не вспомнить или ей больше полугода — кандидат на удаление.

2. Резать вслепую нельзя, а мерить нечем. У Anthropic были свои прогоны: удалили кусок промпта, прогнали набор задач, сравнили результат. Поэтому они и могли уверенно сказать «сняли 80%, качество то же». У нас так не выходит. Меняем скилл, смотрим на два поста и решаем, что стало лучше. А на третьем оказывается, что модель перестала расставлять ссылки, просто в первых двух ссылок и не было.

3. Конфликтуют не правила, а источники правил. Редстандарт, скилл канала, CLAUDE.md, бриф — четыре места, где написано про тон. Модель разгребает противоречие вместо работы. Решение не в сокращении, а в иерархии: тон и позиция живут только в скилле канала, фактура и грабли — только в CLAUDE.md, задача выпуска — только в брифе. Правило встретилось дважды — одно вхождение удаляется, а не уточняется.

4. Эталонные тексты в скиллах, скорее всего, вредят. Приложил три идеальных поста — получил четвёртый такой же по каркасу. Меняем образцы на структуру: рубрикатор, обязательные элементы, признаки плохого лида. Образец оставляем там, где нужен формат — вёрстка, разметка, шаблон ответа.

5. Архитектура скиллов важнее их содержания. Один SKILL.md на девятьсот строк грузится целиком: пишете пост в телеграм — модель попутно читает правила для лендингов. Лишнее разбавляет нужное, а трогать такой файл страшно, поэтому его проще дополнить, чем разобрать. Разложите по уровням: верхний решает, что за задача и куда идти дальше; профиль канала держит тон и рубрикатор только для себя; редкие рубрики подгружаются по надобности. Тогда правки перестают быть страшными: меняете один канал и точно знаете, что остальные не задели.

Что переносится на другие модели

Не переносится цифра. 80% — результат конкретной связки: их обвязка, их модели, их тесты на коде. Для GPT, Gemini или локальных моделей такого замера у вас нет.

Переносится наполовину принцип «меньше правил — лучше». Это функция силы модели, а не тренд индустрии: чем модель слабее, тем нужнее ей явные правила и примеры. Если вы гоняете тяжёлое на топовой, а рутину на дешёвой, один облегчённый скилл на всех не сработает. Либо два профиля инструкций, либо пишете под самую слабую в связке и теряете на сильной.

Не переносятся архитектурные приёмы. Прогрессивное раскрытие, отложенная загрузка инструментов, автопамять — это свойства обвязки, а не модели. В чужом фреймворке эквивалента может не быть, и тогда «вынесите редкое в отдельный скилл» превращается в «вынесите в файл, который никто не подгрузит».

И главное

Спор о длине промптов маскирует настоящую проблему: у нас нет способа отличить улучшение от ухудшения. Пока его нет, любое решение — резать или не резать — принимается на ощущениях. Вопрос не в том, сколько правил у вас в скиллах, а в том, знаете ли вы, какие из них хоть на что-то влияют. А это уже content ops. 😎

Тг: https://t.me/proitru/2948
Просмотры: 16
Перейти в пост Открыть в MAX Сообщить о неточности
Смотрим на отчёт Similarweb «2026 Generative AI Landscape». Сначала общие выводы:

1️⃣ Первое, что стоит заметить, — это разрыв между двумя метриками роста. Визиты выросли на 70% до 9,5 млрд, а уникальные посетители — только на 57%, до 655 млн. Аудитория расширяется медленнее, чем растёт частота обращений: приходят не столько новые люди, сколько одни и те же, но чаще. ИИ перешёл из режима «попробовать» в режим привычки, и окно первого впечатления для брендов закрывается — вас теперь встречают внутри уже сложившегося сценария.

2️⃣ Второе — дробление идёт не туда, куда кажется по заголовкам. Доля ChatGPT в веб-визитах упала с примерно 76% в июне 2025 до около 53% к маю 2026, и главный бенефициар здесь Gemini: с менее 9% до 27–28%. По вебу перераспределение идёт в пользу Google. Это меняет практический вывод: «оптимизировать под ИИ» и «оптимизировать под Google» — уже не два проекта, а один.

3️⃣ Третье — замещения нет, есть наслоение. 461 млн из 494 млн пользователей ChatGPT в марте-мае 2026 продолжали пользоваться и Google, а поиск в целом держит 3,3 млрд уникальных посетителей в месяц против 655 млн у чатботов. Разрыв впятеро. Старый канал никуда не делся, новый добавился сверху — бюджет делится, а работы становится вдвое больше.

4️⃣ И, четвёртое, последнее, самое неудобное для отчётности. К рекомендованному ИИ бренду пользователи заходят в два-четыре раза чаще, чем к нерекомендованному конкуренту — при том что ссылку на источник содержат всего 6,8% ответов. Влияние на выбор идёт мимо реферального трафика, и в вашей аналитике его просто не будет видно.

➡️ Теперь #контентменеджерское :

1️⃣ Обновлять, а не только производить. Частота обращений растёт быстрее охвата, а значит один и тот же материал перечитывают и переспрашивают. Ставим регулярный пересмотр ключевых страниц: дата обновления, актуальные цифры, вычищенные устаревшие формулировки.

2️⃣ Держать фактуру в извлекаемом виде. ИИ берёт как доказательство то, что легко вынуть: определения абзацем, цифры с датой и источником, таблицы сравнения, прямые ответы под подзаголовком-вопросом. Длинное подводящее вступление перед сутью — проигрыш.

3️⃣ Разделить роли страниц. ИИ цитирует материалы на два-три уровня вглубь, а приходят люди почти всегда на главную и верхнеуровневые. Значит, страницу «из глубин сайта» нельзя оценивать по трафику — её задача быть доказательной базой, и мерить её надо упоминаниями. А верхнеуровневая должна встречать человека, который уже что-то о вас знает из ответа ИИ, а не начинать разговор с нуля.

4️⃣ Писать под длинный запрос, а не под ключ. Средняя длина запросов растёт: привычка формулировать промпты переехала в поисковую строку. Это меняет требование к материалу — он должен отвечать на конкретный вопрос с условиями («для команды из пяти человек», «если данные в другом формате»), а не покрывать тему в целом. Ключ теперь не в заголовке, а в том, насколько узкий случай вы разобрали внутри.

5️⃣ Проставить авторство и подтверждаемость. Фамилия автора, его роль, ссылка на первоисточник у каждой цифры. Это то, что отличает материал-донор от материала-сырья.

6️⃣ Завести реестр упоминаний. Раз в месяц прогонять 20–30 профильных запросов по ChatGPT, Gemini, Perplexity и фиксировать: упомянули или нет, какая формулировка, кто рядом, какая страница процитирована. Без этих логов обсуждать «видимость в ИИ» не с чем.

#geo #ai
Просмотры: 16
Перейти в пост Открыть в MAX Сообщить о неточности
ВКонтакте Телеграм Одноклассники
Избранное в datool.ru

Следите за каналом в личном кабинете

Зарегистрируйтесь в datool.ru, чтобы добавить канал «Инженер Контекста» в избранное и отслеживать его показатели.

Зарегистрироваться
Для владельцев каналов

Подтвердите свой канал

Войдите или зарегистрируйтесь в datool.ru, затем добавьте нашего бота в канал по инструкции в личном кабинете. После проверки владения замок исчезнет и вам станет доступно управление каналом.

Войти или зарегистрироваться

Сообщить о неточности

Опишите, что нужно исправить. Если есть источник, добавьте ссылку.

Вы покидаете datool.ru

Ссылка ведёт на внешний сайт. datool.ru не отвечает за его содержимое — проверьте адрес, прежде чем вводить пароли или платёжные данные.

Переход через 10 с

Перейти