Как стать экспертом по нейросетям в 2026 году: фундаментальные знания для технического писателя

Дата публикации: 14 мая 2026 года.

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

Ниже — ключевые области знаний, которые превращают технического писателя в специалиста, работающего с ИИ осознанно. В эксперта, который не просто запускает чат-бота, а проектирует систему генерации и проверки контента. Все перечисленные блоки универсальны: они применимы к GPT, Claude, Gemini, Llama и десяткам других моделей, а главное — не устареют после очередного апдейта.

• Фундаментальные механизмы больших языковых моделей
• Промпт-инжиниринг
• RAG: базовая техника генерации на основе поиска
• Оценка качества (эвалюация) сгенерированного контента
• Интеграция нейросетей в процессы разработки документации

Разберём каждый из этих блоков по порядку, от базовых принципов работы LLM до их интеграции в реальные процессы разработки пользовательской документации. Начнём с самого фундаментального — устройства больших языковых моделей. Понимание того, как модель обрабатывает текст и где у неё "слепые зоны", — основа, на которой строится всё остальное.

1. Фундаментальные механизмы больших языковых моделей

Большие языковые модели (LLM) не "понимают" текст в человеческом смысле. Они предсказывают следующее слово на основе вероятностных закономерностей, извлечённых из огромного массива обучающих данных. Если вы знаете, как именно модель обрабатывает информацию, вы перестаёте ожидать невозможного и начинаете закладывать в промпты компенсацию её недостатков. Это означает проектировать инструкции так, чтобы обходить известные ограничения языковой модели. Проще говоря, вы не надеетесь, что модель "справится сама", а заранее подстраховываете её на самых уязвимых участках.

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

Никогда не рассчитывайте, что модель "прочтёт и поймёт" ваш условно 50-страничный документ так же, как человек. Разбивайте контент на смысловые куски (чанки), дублируйте действительно важные указания и управляйте температурой в зависимости от того, ждёте ли вы точности или вариативности.

Недостатки LLM и как их компенсировать

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

Проблема: модель теряет середину длинного текста (контекстное окно велико, внимание рассеивается).

Решение: разбивайте документацию на смысловые блоки, а в промптах самые важные требования дублируйте в начале и в конце. Например:

В начале инструкции обязательно укажи версию продукта. В самом конце ещё раз проверь, что версия указана.

Проблема: модель придумывает несуществующую функциональность или искажает процедуры.

Решение: используйте RAG (поиск по реальной документации, описан далее) и принуждайте модель ссылаться на источник. В промпт включайте правило:

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

Проблема: нестабильность при высокой температуре (о температуре речь пойдёт далее).

Решение: для критически важных проверок (орфография, соответствие стандартам, предупреждения о безопасности) ставьте температуру 0–0.2. Творческие варианты запрашивайте отдельным прогоном с температурой 0.8.

Проблема: ограниченность обучающих данных (модель не знает ваш продукт).

Решение: добавляйте в промпт глоссарий терминов, фрагменты реальных диалогов поддержки, примеры удачных инструкций. Так вы дообучаете модель "на лету" через контекст.

Проблема: неумение соблюдать tone-of-voice без образцов.

Решение: превратите tone-of-voice в набор жёстких правил внутри промпта:

Используй повелительное наклонение. Не начинай предложения с "Пожалуйста". Избегай страдательного залога.

И обязательно дайте несколько примеров "плохо – хорошо".

Слабость: склонность к общим фразам.

Решение: требуйте конкретики:

Опиши каждый шаг так, чтобы самый неопытный пользователь мог выполнить его. Замени все общие слова типа "соответствующий" на точные названия кнопок и полей.

Другими словами, зная фундаментальные механизмы моделей, вы не полагаетесь на удачу, а сознательно строите промпты и пайплайны, которые учитывают слабые места и минимизируют их влияние на итоговый результат. Вы осознанно регулируете параметры генерации, добиваясь либо строгой повторяемости, либо творческого разнообразия. Кроме того, вы понимаете, почему модель "забывает" инструкцию в середине длинного документа, и учитесь правильно структурировать входные данные.

2. Промпт-инжиниринг

Что это такое и почему критически важно для пользовательской документации?

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

Ключевые приёмы, которыми стоит овладеть, и примеры их применения к пользовательской документации:

• Цепочка рассуждений (Chain-of-Thought). Вы требуете от модели рассуждать по шагам. Например, при оценке инструкции к банковскому приложению модель сначала анализирует целевую аудиторию (к примеру, пожилые пользователи), затем проверяет, объяснены ли все термины, а потом делает вывод о понятности. Так вы получаете не просто вердикт "неясно", а конкретный разбор.
• Few-shot prompting. Допустим, нужно получить текст, написанный в определенном стиле. Вы даете модели несколько готовых примеров (образцов стиля, структуры, тона), а она генерирует новый текст, подражая этим шаблонам. Например, если вы дадите модели две текста по сбросу пароля в кратком повелительном стиле, а затем попросите написать инструкцию по изменению пароля, она выдаст текст, похожий по форме, длине и тону на показанные образцы.
• Структурированный вывод. Вы принуждаете модель выдавать JSON, Markdown-таблицы или YAML. Допустим, вы хотите автоматически собирать глоссарий из документации. Промпт предписывает возвратить массив объектов вида { "термин": "интерфейс", "определение": "..." }. Скрипт затем вставляет эти определения прямо в справочный портал без ручной обработки.
• Управление тоном и стилем. Вы описываете tone-of-voice как константную часть промпта: "Пиши нейтрально, обращайся на вы, не используй страдательный залог, давай инструкции в повелительном наклонении". Модель применяет эти правила последовательно, благодаря чему все статьи звучат одинаково, даже если их готовили разные люди.

Как это применяется в документации?

Температура — это один из параметров инференса, который управляет "смелостью" модели при выборе следующего слова.

Инференс (от англ. inference — "вывод", "умозаключение") — это этап работы нейросети, когда она уже полностью обучена и применяет свои знания для ответа на ваш запрос. Другими словами, это момент, когда вы задаёте вопрос, а модель выдаёт ответ.

Чтобы было понятнее, представьте разницу между учёбой в школе и экзаменом:

• Обучение (тренировка): модель "учит материал" на огромном количестве текстов, книг, сайтов. Этот процесс занимает недели или месяцы, требует мощных серверов и стоит миллионы долларов.
• Инференс: модель уже всё выучила и теперь просто "отвечает на билеты". Вы посылаете запрос (промпт), модель за доли секунды обрабатывает его и выдаёт результат. Именно этот этап вы оплачиваете, когда используете API OpenAI или запускаете локальную модель.

Почему это важно для технического писателя? Потому что параметры инференса — это рычаги, которыми вы управляете во время получения ответа, не меняя саму модель. Вы не можете переучить модель (это слишком дорого и сложно), но вы можете повлиять на то, как она будет применять свои знания: строго и предсказуемо или творчески и вариативно. Упомянутые ранее параметры — температура, top‑p, top‑k — относятся именно к инференсу. Настраивая их, вы не меняете знания модели, а лишь корректируете её поведение на "экзамене".

Простой пример: если вы попросите модель перефразировать одно и то же предложение 10 раз при температуре 0 — вы получите 10 абсолютно одинаковых ответов. При температуре 0.8 — каждый раз будут разные варианты, хотя смысл сохранится. Инференс — это как раз тот самый момент, когда вы выбираете, насколько "свободной" должна быть модель.

При низкой температуре (0–0.2) модель почти всегда выбирает самое вероятное слово, и текст получается строгим и повторяемым. Это подходит для проверки грамматики, соответствия стандарту или генерации критически важных инструкций, где нельзя ошибаться. При высокой температуре (0.7–0.9) модель чаще выбирает менее вероятные слова, что делает текст разнообразнее. Такой режим полезен, когда нужно предложить несколько альтернативных формулировок для одного и того же шага или придумать примеры.

Техписатель, владеющий промпт-инжинирингом, выстраивает конвейер, в котором каждый этап запускается со своей температурой. Например, сначала модель проверяет орфографию и пунктуацию (строгий промпт, температура 0). Затем оценивает логику и полноту (промпт с цепочкой рассуждений, сравнивающий текст с шаблоном). Далее проверяется стиль и тон (few-shot промпт с примерами удачных и неудачных фраз). В конце, если нужны альтернативные варианты, запускается творческий промпт с температурой 0.8. Каждый этап повторяем, каждый можно измерить.

Типичные антипаттерны: чего стоит избегать

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

Антипаттерн 1: слишком общий, размытый промпт

Пример:

"Напиши инструкцию для пользователя, как настроить уведомления. Сделай её понятной и подробной."

Почему это плохо:

• Языковая модель не знает, для какого продукта — она может взять пример из обучающей выборки, который не имеет отношения к вашему интерфейсу.
• "Понятная и подробная" — субъективные критерии. Одна модель понимает под этим три абзаца, другая — десять страниц.
• Нет контроля над форматом: результат может оказаться в виде маркированного списка, сплошного текста или даже таблицы, что нарушит единый стиль документации.

Как правильно: конкретизируйте продукт, приведите пример желаемой структуры, задайте ограничения по объёму и тону.

Антипаттерн 2: забыли про "отрицательные инструкции"

Пример:

"Объясни пользователю, как сбросить пароль. Используй дружелюбный тон."

Почему это плохо:

• Модель может начать фразу с "Пожалуйста, попробуйте…" или добавить эмодзи, если в её данных дружелюбный тон ассоциируется с этим.
• Вы не запретили использовать пассивный залог или сложные технические термины без объяснения.
• Модель может "переусердствовать" с шутками или неуместными метафорами — для документации по безопасности это недопустимо.

Как правильно: явно перечисляйте, чего делать нельзя. Например: "Не используй слово «пожалуйста», не ставь смайлики, избегай страдательного залога, не пиши фразы длиннее 20 слов".

Антипаттерн 3: неправильная температура для задачи

Пример:

"Проверь орфографию и пунктуацию в этом предупреждении о безопасности. Температура = 0.9."

Почему это плохо:

• Высокая температура (0.7–0.9) делает генерацию разнообразной и креативной — она начнёт переформулировать предупреждение, а не просто исправлять ошибки. В итоге может исчезнуть важное слово "внимание" или изменится смысл.
• Для детерминированных задач (проверка, извлечение, классификация) температура должна быть 0–0.2.

Как правильно: для каждого этапа конвейера подбирайте свою температуру. Орфография и факты — 0. Генерация альтернативных формулировок примеров — 0.8.

Антипаттерн 4: плохая сегментация документации для RAG

Пример: разбить руководство на фрагменты строго по 500 токенов (пример онлайн сервиса для подсчета токенов), игнорируя логические заголовки и смысловые границы. К примеру, обрезать описание процедуры "Настройка двухфакторной аутентификации" прямо посередине четвёртого шага.

Почему это плохо:

• Фрагмент, который обрывается на полуслове, не может быть правильно интерпретирован ни эмбеддингом (рассмотрен далее), ни генеративной моделью. Поиск по нему скорее всего вернёт бессмыслицу.
• Модель при генерации ответа получит неполную инструкцию и либо дополнит её своими фантазиями, либо откажется отвечать.

Как правильно: фрагменты (чанки) должны совпадать со смысловыми блоками: целый раздел, законченная процедура, полное предупреждение. Используйте перекрытие (overlap) в 10–20% между соседними чанками, чтобы не терять контекст на границах.

Антипаттерн 5: игнорирование необходимости контекстных ссылок

Пример: сгенерировать ответ от RAG-бота, выдавая его от лица эксперта, но не указать, из какого именно раздела документации взята информация.

Почему это плохо:

• Пользователь не может проверить правдивость ответа — доверие падает.
• При возникновении спорной ситуации поддержка не сможет быстро найти исходный материал и воспроизвести ответ.
• Юридические риски: вы не можете доказать, что инструкция была опубликована именно в таком виде.

Как правильно: в каждом ответе RAG-бота добавлять ссылку на исходный фрагмент документации (например, "Источник: раздел 3.2, стр. 15"). Это повышает доверие и упрощает аудит.

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

3. RAG: базовая техника генерации на основе поиска

RAG (Retrieval-augmented generation) — это механизм, при котором нейросеть не выдумывает ответ, а сначала ищет его в вашей пользовательской документации. Обычная LLM (например, ChatGPT без доступа к интернету) отвечает только на основе того, что запомнила во время обучения. Спросите её: "Как настроить двухфакторную аутентификацию в нашем продукте?" — и она начнёт фантазировать, потому что не знает ваш продукт. Это называется галлюцинацией.

RAG эта проблема решается в четыре шага:

1. Вы задаёте вопрос.
2. Система идёт в вашу базу знаний и находит самые похожие по смыслу фрагменты.
3. Эти фрагменты вместе с вашим вопросом отправляются в нейросеть.
4. Нейросеть отвечает, опираясь только на эти фрагменты, а не на свою память.

Результат: ответ точный, основан на вашей документации, к нему можно прикрепить ссылку на источник.

RAG объединяет два компонента: поисковый механизм, который извлекает нужные фрагменты из вашей базы знаний, и генеративную модель, которая на основе этих фрагментов синтезирует ответ. Вместо того чтобы хранить все знания внутри параметров модели (дорого и негибко), вы даёте актуальный контекст в момент запроса. Пользователь спрашивает: "Как настроить автоответ в выходные?" — система находит соответствующий раздел справки и передаёт его в модель вместе с вопросом. Модель строит ответ, опираясь на предоставленный текст, а не на свою память.

Ценность для создателей пользовательской документации

• Ответы на основе реальных документов. Чат-бот, работающий по RAG, не выдумывает процедуру, а пересказывает фрагмент вашей инструкции, давая ссылку на оригинал. Это резко снижает риск галлюцинаций и повышает доверие пользователей.
• Автоматическая генерация документации. Разработчик коммитит описание API, система находит этот фрагмент и предлагает техписателю адаптированный текст для руководства пользователя. Черновик появляется без участия человека.
• Упрощённая локализация. Исходная документация существует на одном языке, но пользователь задаёт вопрос на другом. RAG-система находит нужный фрагмент в исходном корпусе, а модель генерирует ответ на языке пользователя, не требуя полного предварительного перевода всех материалов.

Ключевые понятия с примерами

Чтобы RAG работал надёжно, нужно понимать его основные строительные блоки. Вот как они связаны с вашей работой.

Рассмотрим ситуацию, когда пользователь пишет чат-боту: "Как настроить двухфакторную аутентификацию?".

• Без RAG: модель выдаёт общие слова из интернета (про Google Authenticator, про банк — пользователю непонятно).
• С RAG:
  1. Система ищет в вашей документации чанки про "двухфакторную аутентификацию", "2FA", "вход с подтверждением".
  2. Находит ваш раздел "Настройка 2FA в личном кабинете" (шаг 1, шаг 2, шаг 3).
  3. Передаёт этот чанк в нейросеть.
  4. Ответ: "Чтобы включить двухфакторную аутентификацию, перейдите в Личный кабинет → Безопасность и нажмите Включить 2FA. Затем отсканируйте QR-код приложением-аутентификатором. Подробнее: ссылка на ваш раздел".

Пользователь получает точный ответ, а не галлюцинацию.

Здесь мы возвращаемся к вопросу важности чёткой логичной структуры. Именно от неё зависит качество RAG.

• Чанки: разбивайте документацию на небольшие, законченные блоки. Одна инструкция — один чанк. Не режьте посреди шага.
• Заголовки: пишите чёткие, описательные заголовки. "Настройка двухфакторной аутентификации" лучше, чем "Шаг 2".
• Ключевые слова: добавляйте синонимы: "экспорт" и "выгрузка", "пароль" и "PIN-код". Эмбеддинги их поймут.
• Ссылки: в каждом чанке указывайте ссылку на оригинал (страница, раздел). Это позволит RAG-боту давать источники.

Что говорят исследования?

Эффект от правильной настройки RAG, в частности реранкинга, можно измерить. Например, в контролируемом исследовании 2026 года сравнивали пять стратегий поиска в RAG-пайплайне. Cross-Encoder Reranking показал наивысшую контекстную точность — 0.852 и composite score 0.827, тогда как стратегия Multi-Query Expansion дала лишь 0.671. Benchmarking Retrieval Strategies for Biomedical RAG (2026).

Другая группа исследователей изучила Cross-Encoder реранкинг и его файн-тюнинг специально для задач Retrieval-Augmented Generation. Оказалось, что переход с Bi-Encoder на Cross-Encoder повышает точность поиска на 7.9%, а дополнительный файн-тюнинг прибавляет ещё 10.4%.

Промышленные кейсы подтверждают лабораторные выводы. В одном из них оценивали опыт сотрудников средней компании при использовании RAG-чатбота для поиска по внутренней документации. Анализ отзывов показал, что пользователи высоко оценили удобство и приняли такую систему. Evaluation of User Experience with RAG-based Chatbots for Searching Documentation (2025).

RAG — это способ заставить нейросеть давать ответы строго по вашей документации, а не выдумывать их. Сначала ищем подходящий кусок текста в вашей базе знаний, затем отдаем его модели. Где это применяется: чат-боты поддержки, автоматические помощники по документации, генерация ответов на вопросы пользователей, проверка полноты инструкций. Чем лучше вы структурируете контент, тем точнее будет работать RAG и тем выше доверие пользователей к вашему продукту.

4. Оценка качества (эвалюация) сгенерированного контента

Почему оценить "на глаз" недостаточно?

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

Основные метрики и подходы

• Метрики, основанные на эталонных ответах. BERTScore, ROUGE, METEOR сравнивают сгенерированный текст с "золотым стандартом", написанным человеком. Подходят для задач, где есть чёткий ожидаемый ответ, например, описание полей API или предупреждений безопасности.
• Метрики без эталона. Оценка по шкале Лайкерта (1–5) группой экспертов или автоматическая оценка с помощью более сильной модели (LLM‑as‑a‑Judge). Используют для творческих задач — генерация рекомендаций, FAQ.
• Обнаружение галлюцинаций. Фреймворки типа Ragas проверяют, насколько сгенерированный текст опирается на предоставленный контекст и не противоречит ему.

Как внедрить это в практику?

1. Соберите тестовый набор из 20–30 характерных вопросов и идеальных ответов (или эталонных фрагментов документации).
2. Перед запуском нового промпта или модели прогоните эти вопросы и вычислите метрики (например, BERTScore).
3. Задайте порог: если качество ниже 0.85 — промпт дорабатывают, модель отвергают.
4. Повторяйте тест при каждом значительном изменении. Это QA для вашей ИИ-системы.

Только так можно гарантировать, что нейросеть действительно помогает, а не создаёт иллюзию качества.

Какую нейросеть выбрать техписателю?

Не существует "лучшей модели для разработки документации". Всё зависит от задачи, бюджета, требований к конфиденциальности и языка. Эксперт не привязан к одному инструменту, а комбинирует несколько решений под разные этапы работы.

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

5. Интеграция нейросетей в процессы разработки документации

От разовых экспериментов к инженерному подходу

Разовые запросы в чат-интерфейсе не масштабируются и не воспроизводятся. Экспертность заключается в том, чтобы встроить нейросети в существующие пайплайны документации так же органично, как средства проверки орфографии и анализаторы кода (линтеры). Речь идёт об автоматизации рутины, а не о замене человека.

Ключевые точки интеграции

Приём, который стоит рассмотреть отдельно, — работа с семантической разметкой (DITA, XML).

Если Markdown — это стандарт для простых веб-справок, то работа с DITA (Darwin Information Typing Architecture) или кастомными XML-схемами — это "высшая лига" технического писательства. Современные LLM отлично справляются с семантической разметкой, если понимать специфику их взаимодействия с древовидными структурами.

• Генерация типизированного контента: модель можно обучить (через few-shot промпты) строго разделять контент на task, concept и reference. Она не просто пишет текст, а сразу оборачивает его в нужные теги, например, выделяя шаги процедуры в steps и step, а контекст — в context.
• Валидация против схемы: ИИ может выступать в роли "умного линтера", проверяя не только синтаксис, но и семантическую логику. Например, корректно ли заполнены атрибуты id или conref, и не нарушена ли иерархия элементов, специфичная для вашего DITA-OT плагина.
• Интеллектуальный reuse (повторное использование): при подготовке новых разделов модель может анализировать существующую библиотеку компонентов и предлагать использовать уже готовые conref или keyref вместо написания нового текста. Это помогает избегать дублирования и упрощает поддержку документации.

Таким образом, работа с семантической разметкой расширяет классическое написание текстов до уровня проектирования и структурирования данных.

Необходимые навыки

• Работа с Git и CI/CD (GitHub Actions, GitLab CI).
• Базовое знание Python или JavaScript для написания скриптов-обёрток.
• Понимание REST API для взаимодействия с облачными моделями.
• Умение проектировать промпты, которые стабильно работают в автоматическом режиме и не требуют ручной подстройки.

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

Правовые и этические нормы

Когда вы встраиваете нейросети в создание пользовательской документации, вы берёте на себя ответственность за результат. Незнание правовых нюансов может привести к репутационным и финансовым потерям.

• Авторское право. Сгенерированный текст может содержать фрагменты, близкие к защищённым материалам. Политики разных провайдеров различаются: одни передают права пользователю, другие оставляют за собой. Изучайте условия использования каждой модели.
• Конфиденциальность. Отправляя документацию в облачный API, вы раскрываете внутренние данные. Для закрытых продуктов используйте локальные модели или убедитесь, что провайдер не использует ваши запросы для обучения.
• Предвзятость и инклюзивность. Модели могут воспроизводить стереотипы из обучающих данных. Проверяйте, не дискриминирует ли текст пользователей по полу, возрасту, национальности. Следуйте стандартам доступности (WCAG) и принципам инклюзивного языка.

Заключение

Перечисленные блоки знаний — не абстрактная теория. Это практический инструментарий, который позволяет техническому писателю перейти от роли пассивного пользователя готовых нейросетей к позиции проектировщика интеллектуальных систем документирования. Понимание того, как модель разбивает текст на токены, как правильно сегментировать документацию для RAG, как измерять качество ответов метриками и как встроить промпты в CI/CD-пайплайн, — всё это делает вас ценным специалистом, а не просто исполнителем. Именно такие знания выделяют на рынке тех, кто действительно понимает, как работают нейросети, и кто может построить надёжный конвейер создания пользовательской документации.

Дополнительные материалы

• Токенизатор OpenAI — наглядный инструмент для понимания разбиения текста на токены.
• Короткие курсы DeepLearning.AI — множество бесплатных введений в промпт-инжиниринг и RAG.
• Документация Ragas — фреймворк для оценки качества генеративных моделей с учётом контекста.
• Ollama — простой способ запускать локальные модели без облачных зависимостей.
• State of Docs Report 2026 — отраслевой обзор профессии технического писателя, включая влияние ИИ.