tgindex

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

описание

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

← к каналу@proitru
900
подписчиков
Охват к подписчикам
11,6%
ERR
Реакции к просмотрам
2,24%
156 на 48 постов
Пересылки к просмотрам
1,91%
133
Постов в день
0,9
всего 83

Где отзываются чаще

доля реакций к просмотрам
  • 17 авг.Не забывайте классику! Только надо еще про «сделай нейросетью» добавить.10,20%
  • 5 авг.Будет ласковый дождь7,83%
  • 8 авг.Не по теме канала, но закат в Филинской бухте6,61%
  • 31 июл.С праздником, сисадмины! Свитеры под горло, огромные очки, бороды и длинные волосы стали модными и перестали быть отличительной чертой профессии. Но "вы пробовали выключить и снова включить" будет вечным. Всем пива!5,94%
  • 5 авг.«Ядро» ИИ в медиа ICT.Moscow изучил 4,7 тысячи публикаций об ИИ в русскоязычных медиа, чтобы выяснить, из каких составных частей складывается «ядро» темы, и какая связь прослеживается с другими технологиями Что обнаружили: - большинство инфоповодов об ИИ ориентированы на массового читателя и лишены технологических деталей; - более трети публикаций явно затрагивают хотя бы одну тему внутри ИИ. Чаще всего — модели и их типы, а также агентный ИИ; - физический ИИ в русскоязычной медиаповестке пока представлен слабо, как и AGI; - в 14% новостей помимо содержатся упоминания других технологических направлений — робототехники, инфраструктуры и прочих. Подробнее 👈5,32%
  • 14 авг.Пятница, дамы и господа.5,00%
  • 4 авг.Интернет, который мы потеряли4,80%
  • 3 авг.Смотрим на отчёт 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 #ai3,74%
  • 8 авг.Не по теме канала, но лучшее по колобку3,68%
  • 7 авг.Как и обещал, а вы голосовали, скилл 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 #ai3,54%
  • 22 июл.Вернёмся к практике разработки фабрики контента. Как агент находит нужный факт в базе на 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-м → 0.5 — на 3-м → 0.33 — на 5-м → 0.2 Потом усредняю по всем запросам. У меня вышло 0.847 — в среднем нужное стоит между первым и вторым местом. То есть поиск не просто «где-то находит», а выносит правильное почти в самый верх. Это уже хорошо. Метрика 3: precision@5 — «а сколько мусора рядом?» И вот честная, неприятная цифра. Precision спрашивает: из пяти выданных карточек сколько реально по делу? У меня ~0.21. Грубо: из пяти результатов по-настоящему нужный обычно один, а четыре это «рядом лежало, зацепилось по теме». Выдача грязновата. Казалось бы плохо, но тут важно, для кого этот поиск. Если бы результат читал человек и ему пришлось глазами продираться через мусор — да, беда. А у меня получатель агент (LLM). Он получает стопку из пяти карточек и сам отбрасывает нерелевантное: контекста ему хватает. Поэтому я сознательно терплю низкую precision ради высокого hit@5, лучше отдать лишнее, чем упустить нужное. Но и это принципиально — цифру я вижу. Не прячу, не округляю в уме до «нормально». Если однажды агент начнёт захлёбываться в мусоре, я замечу это по метрике заранее, а не по кривым статьям постфактум. Главный вывод: RAG на русском ломается не на эмбеддингах, а на морфологии запроса. Пока агент пишет «базами данных», а ты ищешь по databases — никакая база не поможет. Сначала научи систему понимать, что это одно и то же. А потом обязательно померь, иначе будешь улучшать вслепую. #ai_agents3,20%
  • 2 июл.Про контроль качества контента с помощью скриптов на GitHub Или как контентщику использовать инструменты разрабов. Вводные: агенты у меня сейчас живут в GitHub и запускаются из Code или Codex (в работе их миграция в различные окружения, но пока так). Качество генерируемых текстов я контролировал через промпты и агенты проверки: правила в контексте, отдельный субагент-фактчекер, редакторская вычитка. Я им доверял и, в общем, не зря, они ловят многое. Но у этого доверия есть слепое пятно. Всё это живёт внутри сессии. Проверка случается, если агент про неё "вспомнил", если правило доехало в контекст. А когда что-то из этого не сработало, то ты узнаёшь об осечке уже когда сам садишься вычитывать. Когда я начал работать над качеством, то первым порывом было докрутить сами промпты в агентах — прописать проверки жёстче. Я сделал и поймал проблему раздувания контекстного окна, но про это в другой раз. Однако, такое решение было лишь дополнением в уже существующий слой: заостряешь проверку и надеешься, что все правила доедут. Стало ясно, что нужен контроль снаружи процесса, а не внутри него. Так появился слой на GitHub Actions. Устроено просто: на каждый сгенерированный материал запускается единая команда make check, за ней — цепочка проверок: тесты, валидация структуры, десятки детекторов на отдельных скриптах. Каждый отвечает за свой сюжет: один считает плотность тире и ищет следы машинного текста, другой сверяет цифры в документации, третий ловит устаревшие данные и битые ссылки, ещё один проверяет, что стадии пайплайна реально шли в изоляции, а не слиплись. Часть проверок работает точечно только по тому, что изменилось. Результат не тонет в логах. Робот оставляет один аккуратный комментарий прямо в задаче и обновляет его на месте, а не плодит новые. Почти все проверки я сделал мягкими: они советуют, но не блокируют, финальное слово за мной. Жёстко останавливает только то, что реально ломает сборку. Логика простая: агентам я по-прежнему доверяю, GitHub не заменил их, а стал вторым контуром. В итоге я перестал держать в голове тревогу «а точно ли всё проверилось». Теперь на это отвечает не моя вера в процесс, а сам процесс. #ai_agents #github3,13%