<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Tech Selection on kenji.blog</title><link>http://kenji.blog/ru/tags/tech-selection/</link><description>Recent content in Tech Selection on kenji.blog</description><generator>Hugo -- gohugo.io</generator><language>ru</language><copyright>kenjinote</copyright><lastBuildDate>Sat, 12 Sep 2026 12:00:00 +0900</lastBuildDate><atom:link href="http://kenji.blog/ru/tags/tech-selection/index.xml" rel="self" type="application/rss+xml"/><item><title>Влияние алгоритмов социальных сетей на наше мышление и выбор технологий</title><link>http://kenji.blog/ru/p/sns-algorithm-tech-selection/</link><pubDate>Sat, 12 Sep 2026 12:00:00 +0900</pubDate><guid>http://kenji.blog/ru/p/sns-algorithm-tech-selection/</guid><description>&lt;img src="http://kenji.blog/p/sns-algorithm-tech-selection/img/eyecatch.jpg" alt="Featured image of post Влияние алгоритмов социальных сетей на наше мышление и выбор технологий" />&lt;h2 id="1-введение-демократизация-технической-информации-и-господство-алгоритмов">1. Введение: Демократизация технической информации и господство алгоритмов
&lt;/h2>&lt;p>В современной программной инженерии большая часть технической информации, которую мы потребляем ежедневно, проходит через социальные сети (SNS), такие как X (бывший Twitter), Hacker News, Reddit и LinkedIn, а также новостные агрегаторы. Когда-то мы собирали информацию автономно и в хронологическом порядке через списки рассылки, блоги, управляемые конкретными экспертами, или RSS-ридеры. Однако со взрывным ростом числа новых фреймворков и инструментов, появляющихся каждый день, стало обычной практикой полагаться на «алгоритмы рекомендаций (Recommendation Algorithms)», предоставляемые платформами, чтобы оптимизировать наши ограниченные когнитивные ресурсы (свободное время и внимание).&lt;/p>
&lt;p>Этот сдвиг парадигмы принес огромные преимущества, позволив нам эффективно находить полезные технические статьи и новаторские проекты с открытым исходным кодом. Однако это также вызвало очень серьезный побочный эффект. Факт заключается в том, что &lt;strong>«технологические тренды и передовые методы, которые мы видим, искажаются не объективной оценкой или чисто техническим превосходством, а алгоритмической «функцией оптимизации вовлеченности»»&lt;/strong>.&lt;/p>
&lt;p>В этой статье мы с математической и структурной точек зрения разберем, как продвинутые алгоритмы машинного обучения, работающие за кулисами социальных сетей, формируют наше восприятие и влияют на процесс принятия решений при выборе технологий. Кроме того, мы глубоко рассмотрим опасности «Hype Driven Development (HDD: разработки, управляемой хайпом)», когда люди поддаются энтузиазму, порожденному алгоритмами, и конкретные подходы к отходу от этого в сторону объективного и надежного выбора технологий.&lt;/p>
&lt;hr>
&lt;h2 id="2-эволюция-и-механизмы-алгоритмов-рекомендаций">2. Эволюция и механизмы алгоритмов рекомендаций
&lt;/h2>&lt;p>Когда мы открываем социальную сеть, контент, отображаемый на нашей временной шкале (в ленте), не случаен. За этим стоят модели машинного обучения, тщательно настроенные для максимизации времени пребывания пользователя и увеличения доходов от рекламы. Давайте сначала посмотрим на технологии, лежащие в их основе.&lt;/p>
&lt;h3 id="21-коллаборативная-фильтрация-collaborative-filtering-и-матричное-разложение">2.1 Коллаборативная фильтрация (Collaborative Filtering) и матричное разложение
&lt;/h3>&lt;p>«Коллаборативная фильтрация» служила мощным базовым подходом с первых дней существования рекомендательных систем до настоящего времени. В частности, широко используется «матричное разложение (Matrix Factorization)», которое представляет взаимодействие между пользователями и элементами (постами или статьями) в виде матрицы и отображает их в скрытом пространстве признаков.&lt;/p>
&lt;p>Если мы обозначим матрицу оценок для $M$ пользователей и $N$ элементов как $R \in \mathbb{R}^{M \times N}$, матричное разложение аппроксимирует эту огромную и разреженную (sparse) матрицу произведением матриц скрытых признаков низкой размерности $U \in \mathbb{R}^{M \times K}$ (признаки пользователей) и $V \in \mathbb{R}^{N \times K}$ (признаки элементов) ($K \ll M, N$).&lt;/p>
$$
R \approx U \times V^T
$$&lt;p>Прогнозируемая оценка (вероятность вовлеченности) $\hat{r}_{ij}$ элемента $j$ для конкретного пользователя $i$ вычисляется как скалярное произведение их соответствующих векторов скрытых признаков.&lt;/p>
$$
\hat{r}_{ij} = \mathbf{u}_i \cdot \mathbf{v}_j
$$&lt;p>Эта модель обучается так, чтобы минимизировать следующую функцию потерь ($\lambda$ — член регуляризации для предотвращения переобучения).&lt;/p>
$$
\mathcal{L} = \sum_{(i,j) \in \Omega} (r_{ij} - \mathbf{u}_i \cdot \mathbf{v}_j)^2 + \lambda (\|\mathbf{u}_i\|^2 + \|\mathbf{v}_j\|^2)
$$&lt;p>&lt;strong>Влияние на выбор технологий:&lt;/strong>
Этот алгоритм сближает в скрытом пространстве «Человека А, интересующегося Rust» и «Человека Б, интересующегося Rust». Если А поставит лайк посту о новом веб-фреймворке, существует высокая вероятность того, что этот пост появится и в ленте Б. В результате возникает феномен, когда определенные технологии локально становятся очень популярными среди групп инженеров, предпочитающих конкретные технологические стеки.&lt;/p>
&lt;h3 id="22-рекомендательные-модели-на-основе-глубокого-обучения-dlrm">2.2 Рекомендательные модели на основе глубокого обучения (DLRM)
&lt;/h3>&lt;p>В последние годы получили распространение архитектуры на основе глубокого обучения, такие как Deep Learning Recommendation Model (DLRM), в первую очередь популяризированные Meta (бывший Facebook). DLRM принимает на вход широкий спектр признаков (Features), таких как история прошлых действий пользователя и метаданные элементов, и прогнозирует рейтинг кликов (CTR: Click-Through Rate) и другие показатели.&lt;/p>
&lt;p>Особенностью DLRM является то, что он преобразует разреженные категориальные признаки (например, идентификаторы пользователей, хештеги, на которые они подписаны) в плотные векторы (Dense Vector) через «таблицы встраивания (Embedding Table)» и комбинирует их с непрерывными плотными признаками (например, количество дней с момента создания учетной записи, среднее время пребывания в прошлом).&lt;/p>
$$
\mathbf{e}_{\text{sparse}} = \text{EmbeddingLookup}(\mathbf{x}_{\text{sparse}})
$$$$
\mathbf{h}_{\text{dense}} = \text{BottomMLP}(\mathbf{x}_{\text{dense}})
$$&lt;p>После того как они объединяются (Concatenate) или взаимодействуют (Feature Interaction) посредством скалярного произведения, они подаются в верхний многослойный перцептрон (Top MLP), и окончательная вероятность (например, CTR) выводится с помощью сигмоидной функции $\sigma$.&lt;/p>
$$
\hat{y} = \sigma(\text{TopMLP}(\text{Interact}(\mathbf{e}_{\text{sparse}}, \mathbf{h}_{\text{dense}})))
$$&lt;p>&lt;strong>Влияние на выбор технологий:&lt;/strong>
Огромные модели вроде DLRM способны улавливать даже самые незначительные сигналы (например, небольшое увеличение времени пребывания на «посте с видео» или «посте, содержащем определенное модное слово») и отражать их в прогнозируемом балле. В результате техническая информация, содержащая «провокационные заголовки (например, &amp;ldquo;React уже устарел&amp;rdquo;, &amp;ldquo;Конец микросервисов&amp;rdquo;)» или «визуально яркие демонстрации», с большей вероятностью будет алгоритмически предпочтительной.&lt;/p>
&lt;h3 id="23-обучение-с-подкреплением-и-задача-о-многоруком-бандите-multi-armed-bandits">2.3 Обучение с подкреплением и задача о многоруком бандите (Multi-Armed Bandits)
&lt;/h3>&lt;p>Рекомендательные системы всегда должны исследовать последние предпочтения пользователей. Здесь вступает в игру «задача о многоруком бандите». Она оптимизирует компромисс между «использованием (Exploitation)», то есть показом надежного контента на основе существующих предпочтений, и «исследованием (Exploration)» для обнаружения новых тенденций.&lt;/p>
&lt;p>В типичном алгоритме UCB (Upper Confidence Bound) оценка для выбора ручки (группы контента) $a$ в момент времени $t$ вычисляется следующим образом:&lt;/p>
$$
a_t = \arg\max_{a} \left( \hat{\mu}_a + c \sqrt{\frac{\ln t}{N_a(t)}} \right)
$$&lt;p>Здесь $\hat{\mu}_a$ — среднее вознаграждение (уровень вовлеченности) ручки $a$ к настоящему времени, $N_a(t)$ — количество раз, когда она была выбрана, а $c$ — параметр, регулирующий степень исследования.&lt;/p>
&lt;p>&lt;strong>Влияние на выбор технологий:&lt;/strong>
Алгоритм временно предоставляет бонус к исследованию для постов о недавно появившихся фреймворках или библиотеках (с малым количеством попыток $N_a(t)$) и показывает их случайной группе пользователей. Если в течение этой начальной «фазы исследования» реакция влиятельных лиц (инфлюенсеров) положительна, $\hat{\mu}_a$ резко возрастает и быстро превращается в вирусный шум (базз). Это и есть механизм, из-за которого «внезапно все начинают говорить об этой технологии».&lt;/p>
&lt;hr>
&lt;h2 id="3-математика-эхо-камер-и-пузырей-фильтров">3. Математика эхо-камер и пузырей фильтров
&lt;/h2>&lt;p>По мере продвижения алгоритмической оптимизации пользователи начинают окружать себя «информацией, которая им приятна или которая подкрепляет их существующие убеждения». Это и есть &lt;strong>феномен эхо-камеры (Echo Chamber)&lt;/strong> и &lt;strong>пузырь фильтров (Filter Bubble)&lt;/strong>.&lt;/p>
&lt;p>В теории сетей тенденция схожих людей объединяться называется «гомофилией (Homophily)». В графе $G=(V, E)$ ребра (отношения подписки или распространение информации) между узлами (пользователями) с большей вероятностью образуются при высокой степени сходства атрибутов.&lt;/p>
&lt;p>Алгоритмы рекомендаций в социальных сетях искусственно ускоряют эту гомофилию. Например, представьте, что есть сообщество инженеров, продвигающих «бессерверную архитектуру (Serverless)», и сообщество, поддерживающее «локальное размещение на голом железе (Bare Metal)». Алгоритм учится снижать вес ребер между различными сообществами (Cross-cutting ties) и усиливать ребра внутри одного сообщества (поскольку конфликтующие мнения часто вызывают уход с платформы и рискуют снизить вовлеченность. С другой стороны, иногда крайний гнев может повышать вовлеченность, но в технологической среде преобладает первая тенденция).&lt;/p>
&lt;p>В результате на вашей временной шкале может показаться, что «компании по всему миру переходят на бессерверные технологии», в то время как на временной шкале кого-то другого будет казаться, что «уход из облака (Cloud Repatriation) — это глобальный тренд». Так создаются совершенно изолированные технологические реальности.&lt;/p>
&lt;hr>
&lt;h2 id="4-разработка-управляемая-хайпом-hdd-порожденная-алгоритмами">4. Разработка, управляемая хайпом (HDD), порожденная алгоритмами
&lt;/h2>&lt;p>Сочетание эхо-камер и мощных рекомендательных моделей приводит к одному из крупнейших антипаттернов в инженерной индустрии — &lt;strong>Hype Driven Development (разработке, управляемой хайпом)&lt;/strong>. HDD — это феномен внедрения новых технологий просто потому, что они «обсуждаются в социальных сетях» или «являются последним трендом», без глубокого рассмотрения их реальных преимуществ, компромиссов или соответствия бизнес-требованиям компании.&lt;/p>
&lt;p>Следующая диаграмма Mermaid показывает, как алгоритмы социальных сетей запускают цикл обратной связи HDD.&lt;/p>
&lt;pre class="mermaid">
graph TD
A[&amp;#34;Инженер публикует &amp;#39;огромные преимущества&amp;#39; новой технологии&amp;#34;] --&amp;gt; B[&amp;#34;Алгоритм измеряет начальный CTR и время пребывания (Исследование)&amp;#34;]
B --&amp;gt; C[&amp;#34;Определяется высокая вовлеченность, расширяется показ в лентах похожих пользователей&amp;#34;]
C --&amp;gt; D[&amp;#34;Пользователи, стимулируемые FOMO (страхом упущенной выгоды), распространяют дальше&amp;#34;]
D --&amp;gt; E[&amp;#34;Возникновение иллюзии частотности (ошибочного восприятия), что это &amp;#39;становится отраслевым стандартом&amp;#39;&amp;#34;]
E --&amp;gt; F[&amp;#34;Внедрение в реальные проекты без достаточной проверки (HDD)&amp;#34;]
F --&amp;gt; A
&lt;/pre>
&lt;p>Что пугает в этом цикле, так это то, что алгоритм намеренно вызывает &lt;strong>«Иллюзию частотности (Феномен Баадера — Майнхоф)»&lt;/strong>. Если вы однажды увидите название новой библиотеки управления состоянием, алгоритм воспримет это как сигнал и со следующего дня наполнит вашу ленту разговорами об этой библиотеке. Человеческий мозг ошибочно принимает это за «глобальную эпидемию».&lt;/p>
&lt;p>На графике ниже показана разница в жизненных циклах технологий, которые чрезмерно расхайплены (преувеличены) в социальных сетях, и простых, скучных, но надежных технологий (Boring Technology).&lt;/p>
&lt;pre class="mermaid">
xychart-beta
title Жизненный цикл технологий и динамика их оценки
x-axis [&amp;#34;0 мес.&amp;#34;, &amp;#34;6 мес.&amp;#34;, &amp;#34;12 мес.&amp;#34;, &amp;#34;18 мес.&amp;#34;, &amp;#34;24 мес.&amp;#34;, &amp;#34;30 мес.&amp;#34;, &amp;#34;36 мес.&amp;#34;]
y-axis &amp;#34;Количество упоминаний / Уровень энтузиазма в соцсетях&amp;#34; 0 --&amp;gt; 100
line [10, 85, 95, 45, 20, 10, 5]
line [15, 20, 25, 35, 50, 65, 80]
&lt;/pre>
&lt;p>&lt;em>(Примечание: на графике выше линия, которая резко возрастает и резко падает, представляет «Технологию на хайпе», а медленно и неуклонно растущая линия представляет «Скучную технологию»)&lt;/em>&lt;/p>
&lt;p>Расхайпленные технологии сталкиваются с такими реальными проблемами, как «нехватка документации», «серьезные ошибки в крайних случаях» и «выгорание мейнтейнеров» через 6–12 месяцев после внедрения, и быстро исчезают из социальных сетей. Однако устранение технического долга, однажды встроенного в систему, требует огромных затрат.&lt;/p>
&lt;hr>
&lt;h2 id="5-стратегии-отхода-от-алгоритмов-при-выборе-технологий">5. Стратегии «отхода от алгоритмов» при выборе технологий
&lt;/h2>&lt;p>Итак, как мы можем принимать объективные и взвешенные решения о выборе технологий, находясь под контролем этих алгоритмов? Вот несколько конкретных стратегий не для взлома алгоритмов, а для «выхода» из-под их влияния.&lt;/p>
&lt;h3 id="51-возврат-к-первоисточникам-исходный-код-и-rfc">5.1 Возврат к первоисточникам: исходный код и RFC
&lt;/h3>&lt;p>Самая надежная защита — это перенос источников информации с агрегаторов социальных сетей на &lt;strong>первоисточники (Primary Sources)&lt;/strong>.&lt;/p>
&lt;ol>
&lt;li>&lt;strong>Читайте исходный код:&lt;/strong> Вместо того чтобы верить постам в социальных сетях о том, что «эта библиотека работает молниеносно», откройте GitHub и проверьте вычислительную сложность базовой логики и механизм выделения памяти.&lt;/li>
&lt;li>&lt;strong>Следите за RFC (Request for Comments):&lt;/strong> Многие зрелые проекты с открытым исходным кодом (React, Rust, Python и т. д.) используют процесс RFC при внедрении новых функций. В RFC логично и беспристрастно описаны вопросы «зачем нужна эта функция», «каковы архитектурные компромиссы» и «каковы альтернативы», без оглядки на алгоритмическую вовлеченность. Именно здесь кроется истинная техническая ценность.&lt;/li>
&lt;/ol>
&lt;h3 id="52-внимательное-чтение-научных-статей-academic-papers-и-технических-документов-whitepapers">5.2 Внимательное чтение научных статей (Academic Papers) и технических документов (Whitepapers)
&lt;/h3>&lt;p>Когда дело доходит до фундаментального выбора технологий, таких как распределенные системы, базы данных и архитектуры моделей машинного обучения, вам следует читать напрямую научные статьи, опубликованные ACM, IEEE или arXiv, а также подробные технические документы, опубликованные компаниями (например, статья Google о Spanner, статья Amazon о Dynamo), а не резюме в несколько строк в социальных сетях.&lt;/p>
&lt;p>Посты в социальных сетях оптимизированы на «захват внимания читателя», тогда как рецензируемые статьи оптимизированы на «фактическую точность и воспроизводимость». Функции оценки совершенно разные.&lt;/p>
&lt;h3 id="53-построение-фреймворка-для-принятия-решений-в-организации">5.3 Построение фреймворка для принятия решений в организации
&lt;/h3>&lt;p>Чтобы предотвратить HDD на уровне команды или организации, необходим процесс, исключающий субъективную интуицию или причины вроде «потому что я видел это в Twitter». Типичным примером является внедрение &lt;strong>ADR (Architecture Decision Records)&lt;/strong>.&lt;/p>
&lt;p>При внедрении новой технологии следующие пункты всегда должны быть задокументированы и рецензированы:&lt;/p>
&lt;ul>
&lt;li>&lt;strong>Context (Контекст):&lt;/strong> Зачем нужна новая технология? Какова текущая проблема?&lt;/li>
&lt;li>&lt;strong>Decision (Решение):&lt;/strong> Что будет принято?&lt;/li>
&lt;li>&lt;strong>Consequences (Последствия):&lt;/strong> Каковы компромиссы? (Чем мы жертвуем и что получаем?)&lt;/li>
&lt;/ul>
&lt;p>Сделав этот процесс обязательным, можно превратить «Хайп (Hype)» в «Инженерию (Engineering)».&lt;/p>
&lt;h3 id="54-философия-boring-technology-club">5.4 Философия Boring Technology Club
&lt;/h3>&lt;p>В технологическом мире есть известная мантра: &lt;strong>&amp;ldquo;Choose Boring Technology&amp;rdquo; (Выбирайте скучные технологии)&lt;/strong>. Она учит нас не тратить токены инноваций (ограниченные ресурсы, которые организация может потратить на новые неизвестные технологии) на выбор инфраструктуры или фреймворков, не связанных напрямую с основными бизнес-ценностями.&lt;/p>
&lt;p>Алгоритмы социальных сетей любят «новизну». Однако для создания надежной системы, способной выдержать реальную эксплуатацию, вам нужны «скучные» технологии с более чем 10-летней историей использования, процедуры восстановления после сбоев для которых дают миллионы результатов в поиске Google (PostgreSQL, Redis, стандартные REST API и т. д.).&lt;/p>
&lt;hr>
&lt;h2 id="6-заключение-как-нам-следует-относиться-к-технологиям">6. Заключение: Как нам следует относиться к технологиям
&lt;/h2>&lt;p>Алгоритмы рекомендаций социальных сетей — это мощные инструменты, которые расширяют наш технологический кругозор и позволяют знакомиться с замечательными сообществами. Однако, поскольку их внутренняя структура (матричное разложение, DLRM, многорукие бандиты) имеет своей главной целью «максимизацию вовлеченности», выдаваемая информация неизбежно будет предвзятой.&lt;/p>
&lt;p>Нам необходимо развить грамотность, чтобы относиться к информации, поступающей в наши ленты, как к одному из «сигналов», а не как к «фактам» или «абсолютным трендам».&lt;/p>
&lt;p>Нужно выйти за пределы эхо-камер, читать исходный код своими глазами, следить за обсуждениями в RFC, расшифровывать математические формулы в научных статьях и смотреть в лицо истинным проблемам нашего бизнес-домена. Это единственный способ практиковать настоящую программную инженерию, не будучи поглощенным волной алгоритмов.&lt;/p></description></item></channel></rss>