Нейросети для работы. Книга-тренажёр

Глава 3. Создание личного ИИ-периметра и безопасность данных

Теория

Начнём с концепции периметра, потому что без понимания его границ любое использование нейросетей превращается в игру в русскую рулетку с корпоративными данными. Периметр — это невидимая граница, за пределами которой ваша информация становится доступной третьим лицам и выходит из-под вашего юридического и технического контроля. Почему это важно? Потому что в момент отправки запроса в публичный облачный сервис вы фактически передаёте коммерческую тайну или персональные данные на серверы чужой компании, подчиняясь их пользовательскому соглашению. Как это работает на практике? Существует два базовых состояния инфраструктуры: открытый контур и закрытый контур. Открытый контур — это любые публичные облачные сервисы, где данные обрабатываются на оборудовании провайдера и могут теоретически использоваться для дообучения глобальных моделей. Закрытый контур — это инфраструктура, над которой вы имеете полный физический или юридический контроль, и данные никогда не покидают её пределы. Для читателя это означает простое правило выбора: если данные критичны для бизнеса или личной безопасности, мы работаем исключительно в закрытом контуре.

Далее классифицируем данные, опираясь на требования Федерального закона номер сто пятьдесят два «О персональных данных» и законодательства о коммерческой тайне. Мы уже упоминали три цвета во введении, теперь разберём их механику. Зелёный уровень — это обезличенные тексты, открытые статьи, черновики без реквизитов и общеизвестные факты. Их можно без опасений загружать в любые облачные SaaS-решения, где SaaS расшифровывается как Software as a Service, то есть программное обеспечение как услуга, когда вы просто заходите на сайт и пользуетесь сервисом через браузер. Жёлтый уровень — это внутренние регламенты, деловая переписка без персональных данных клиентов, обезличенная аналитика. Такие данные можно передавать в корпоративные облака по модели IaaS, или Infrastructure as a Service, инфраструктура как услуга, где вы арендуете изолированные серверные мощности у отечественного провайдера, либо обрабатывать в локальных системах. Красный уровень — это персональные данные сотрудников и клиентов, финансовые реквизиты, пароли и проприетарный код. Согласно сто пятьдесят второму закону, обработка таких данных требует письменного согласия субъектов и строгого хранения на территории Российской Федерации, а передача в публичные нейросети является прямым нарушением, влекущим миллионные штрафы. Особое внимание уделяем аудио и видео: голос и изображение лица закон относит к биометрическим данным, если они используются для идентификации личности. Следовательно, запись корпоративного созвона, где обсуждаются зарплаты, или видео с камер наблюдения в офисе — это красный уровень по умолчанию, требующий максимального уровня защиты.

Теперь о моделях развёртывания, то есть о том, где физически находится «мозг» вашего ИИ и как это влияет на безопасность. Первая модель — облачные SaaS, о которых мы сказали выше: это быстро и дёшево, но данные уходят провайдеру. Вторая — IaaS, когда вы арендуете защищённый сервер у российского облачного провайдера и развёртываете там свою модель; это дороже, но даёт юридическую изоляцию и соответствие требованиям регуляторов. Третья — on-premise, или локальное развёртывание на собственных серверах компании в защищённом периметре; это максимальная безопасность, но требует штата инженеров для поддержки железа. Четвёртая — on-device AI, то есть ИИ, работающий непосредственно на вашем ноутбуке или смартфоне без выхода в интернет. Для автономного сотрудника on-device AI через локальные среды является главным и самым надёжным инструментом работы с красными данными, потому что в этой архитектуре утечка физически невозможна.

Реальный кейс

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

Инструкция

Перейдём к тому, как самостоятельно выстроить этот периметр без привлечения дорогих консультантов и потери месяцев на согласования. Вам потребуется установить локальную среду запуска, и я рекомендую два проверенных инструмента: Ollama и LM Studio. Ollama — это легковесная программа, которая работает через командную строку, то есть текстовый интерфейс управления, и идеально подходит для быстрой загрузки и запуска открытых моделей прямо на вашем компьютере. LM Studio — это приложение с графическим интерфейсом, где вы можете визуально выбирать модели, настраивать параметры и общаться с ними в привычном окне чата. Как это работает на практике? Вы скачиваете установочный файл с официального сайта, запускаете его, выбираете в каталоге нужную модель, например Qwen 2.5, и нажимаете кнопку загрузки. После скачивания, которое может занять от десяти минут до пары часов в зависимости от размера модели и скорости интернета, вы отключаете компьютер от сети и продолжаете работать. Это и есть on-device AI в чистом виде: ваши данные физически не могут покинуть жёсткий диск, потому что интернет-соединение разорвано, и никакие хакеры или корпоративные шпионы не смогут перехватить ваш запрос к локальной нейросети.

Чтобы принять решение, какую инфраструктуру выбрать для конкретной задачи, используйте матрицу решений, которую мы проговорим связным текстом. Если задача разовая, данные зелёные и нужен быстрый результат — выбирайте облачный SaaS. Если задача регулярная, данные жёлтые и требуется интеграция с корпоративной базой — арендуйте IaaS у отечественного провайдера и развёртывайте там модель через API. Если данные красные, содержат персональные данные или коммерческую тайну — используйте исключительно on-premise серверы компании или on-device AI на вашем личном рабочем ноутбуке. Для оценки финансовой целесообразности применяется шаблон расчёта TCO, или Total Cost of Ownership, совокупной стоимости владения. При расчёте TCO для локальной модели вы суммируете стоимость железа, то есть видеокарт и оперативной памяти, затраты на электроэнергию, зарплату инженера, который будет её обслуживать, и стоимость платной коммерческой лицензии, если модель не полностью открыта. Сравнивая эту сумму с ежемесячными платежами за облачный API, вы обычно обнаруживаете, что локальное развёртывание окупается примерно через восемь-двенадцать месяцев при условии ежедневного использования, зато после этой точки ваши расходы стремятся к нулю, а безопасность становится абсолютной. Читателю нужно прямо сейчас решить, готов ли он инвестировать время в установку локальной среды, чтобы навсегда закрыть вопрос с утечками.

Практика. Базовый уровень. Лабораторная работа «Полевое развёртывание»

Ваша задача на ближайшие тридцать минут — создать собственный изолированный контур и убедиться в его работоспособности. Скачайте и установите LM Studio или Ollama на свой рабочий компьютер. Найдите в каталоге модель Qwen 2.5 или любую другую доступную модель размером до восьми миллиардов параметров, чтобы она комфортно уместилась в оперативную память обычного ноутбука. Загрузите её. Когда загрузка завершится, физически отключите компьютер от интернета: выдерните кабель Ethernet или выключите Wi-Fi. Откройте локальный чат, загрузите в него любой красный документ, например, черновик личного дневника или фрагмент финансовой таблицы с реальными цифрами, и попросите модель проанализировать данные. Вы воочию убедитесь, что ИИ отлично работает без подключения к сети, и почувствуете то самое спокойствие, которое даёт полный контроль над информацией. Запишите в чек-лист прогресса факт успешного офлайн-развёртывания и размер модели, которую вы смогли запустить на своём железе.

Практика. Экспертный уровень. Задание «Аудит периметра и ТЗ на инфраструктуру»

Если вы руководитель или ИТ-специалист, это задание займёт у вас около часа и потребует системного мышления. Проведите аудит текущего ИИ-периметра вашего отдела: опросите коллег и выясните, какие именно облачные сервисы они используют для работы с текстами, таблицами и презентациями. Определите, попадают ли в эти сервисы жёлтые или красные данные, и оцените масштаб потенциальной уязвимости. На основе этого аудита составьте техническое задание, или ТЗ, для ИТ-департамента на развёртывание локальной модели. В ТЗ обязательно укажите требуемый объём контекстного окна, список открытых моделей, которые необходимо протестировать, требования к изоляции сети и расчёт TCO на первые двенадцать месяцев. Это задание превратит вас из пассивного пользователя в архитектора корпоративной безопасности, и именно такие специалисты, способные bridging the gap между бизнес-задачами и ИТ-инфраструктурой, сейчас ценятся на рынке труда выше всего. Результат аудита и структуру ТЗ зафиксируйте в чек-листе прогресса.

На этом третья глава завершена. Мы выстроили непробиваемый периметр, научились классифицировать данные по цвету и освоили локальное развёртывание моделей. В следующей главе мы перейдём к работе с тяжёлыми артефактами: вы узнаете, как заставить нейросеть читать многостраничные PDF-файлы, анализировать сложные таблицы в Excel и не терять суть в середине огромных документов.

Глава 4. Работа с вложениями, таблицами и документами

Теория

В первой главе мы разобрались, что модель работает с токенами и что контекстное окно ограничивает объём данных, которые она способна удержать в «оперативной памяти» за один запрос. Теперь давайте посмотрим, что происходит, когда вы загружаете в модель не просто текст, а файл: PDF-документ, таблицу Excel, скан договора или фотографию накладной. Для вас как пользователя всё выглядит просто — вы перетаскиваете файл в окно чата и задаёте вопрос. Но внутри системы происходит сложная цепочка преобразований, и понимание этой цепочки критически важно, потому что именно на этапе конвертации файла в токены теряется информация, искажается структура и возникают ошибки, которые потом невозможно исправить никаким промптом.

Когда вы загружаете текстовый документ в форматах DOCX или TXT, система извлекает из него чистый текст, разбивает на токены и помещает в контекстное окно модели. Это самый простой и предсказуемый сценарий. С PDF всё сложнее: PDF — это не текстовый формат, а формат вёрстки, то есть он хранит не последовательность слов, а координаты каждого символа на странице. Если PDF создан из текстового редактора, система может извлечь текст относительно чисто. Но если PDF является сканом бумажного документа, извлечь текст стандартными средствами невозможно — нужно сначала распознать изображение, то есть применить технологию OCR, которая расшифровывается как Optical Character Recognition, оптическое распознавание символов. Таблицы Excel представляют отдельную головную боль: модель не понимает ячейки, строки и столбцы как визуальную сетку, поэтому система либо конвертирует таблицу в текстовое представление, где каждая строка записывается через разделитель, либо вообще теряет структуру, превращая аккуратную матрицу данных в бессвязный поток слов. Понимание этих ограничений — первый шаг к тому, чтобы перестать удивляться, почему модель «не видит» данные на третьей странице вашего пятидесятистраничного отчёта.

Теперь о явлении, которое исследователи назвали эффектом lost in the middle, то есть «потерянный в середине». Суть его в следующем: когда в контекстное окно попадает большой объём текста, модель уверенно обрабатывает начало и конец документа, но информация из центральной части обрабатывается с заметно меньшим вниманием. Это не баг и не ошибка конкретной модели — это следствие архитектуры механизма внимания, о котором мы говорили в первой главе. Когда последовательность токенов достигает десятков тысяч, вычислительные ресурсы распределяются неравномерно, и средние фрагменты получают меньший вес при генерации ответа. Практический вывод прост: если вы загрузите в модель договор на сорок страниц и спросите о пункте, который находится на двадцать третьей странице, с высокой вероятностью модель либо ответит размыто, либо сосшлётся на соседние пункты, либо вообще придумает содержание. Это не значит, что с большими документами работать нельзя — это значит, что нужно использовать правильные стратегии подачи информации.

Первая и самая важная стратегия называется чанкинг, то есть предварительное разбиение большого документа на логические фрагменты. Слово произошло от английского chunk, кусок, и смысл операции в том, что вы не загружаете весь документ целиком, а разрезаете его на осмысленные части: по разделам, по главам, по страницам или по логическим блокам. Каждый чанк обрабатывается моделью отдельно, а результаты потом объединяются. Почему это работает? Потому что каждый отдельный фрагмент полностью помещается в фокус внимания модели, и эффект «потерянного в середине» просто не возникает. Оптимальный размер чанка для большинства задач составляет от пятисот до двух тысяч токенов: меньше пятисот — модель теряет контекст и не понимает, о чём речь; больше двух тысяч — начинает размываться фокус. При чанкинге критически важно сохранять перекрытие, то есть включать последние два-три предложения предыдущего фрагмента в начало следующего, чтобы модель не теряла нить повествования на стыках.

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

Третья стратегия — RAG, что расшифровывается как Retrieval-Augmented Generation, то есть генерация с дополненным поиском. Суть подхода в том, что вместо загрузки всего документа в контекст вы создаёте внешний индекс, где каждый фрагмент текста привязан к своему векторному представлению, то есть к числовому коду, отражающему смысл этого фрагмента. Когда пользователь задаёт вопрос, система сначала ищет в индексе наиболее релевантные фрагменты по смысловому сходству, а затем подаёт только эти фрагменты модели вместе с вопросом. Модель отвечает строго на основе найденных фрагментов, а не на основе своих внутренних знаний, что резко снижает риск галлюцинаций. RAG особенно эффективен для корпоративных баз знаний, где тысячи документов и ни один сотрудник не помнит, в каком именно регламенте записана нужная процедура.

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

Реальный кейс

Чтобы показать, как эти стратегии работают в связке и какой экономический эффект дают, расскажу историю финансового директора группы компаний «Синергия», которого назовём для удобства Андрей Викторович. Задача, которая перед ним стояла, звучала так: за три рабочих дня подготовить сравнительный анализ двенадцати квартальных отчётов конкурентов, каждый объёмом от двадцати пяти до тридцати пяти страниц, с извлечением ключевых финансовых метрик, динамикой выручки, маржинальностью по направлениям и стратегическими приоритетами. Традиционный подход предполагал, что два аналитика вручную читают все двенадцать отчётов, выписывают данные в единую таблицу, сверяют цифры, строят графики и пишут аналитическую записку. На это уходило ровно три рабочих дня, причём к концу третьего дня аналитики уставали, начинали путать колонки и пропускать примечания в сносках.

Андрей Викторович решил применить каскадный промптинг, то есть ту самую стратегию последовательного сжатия, которую мы разобрали выше. На первом этапе он загрузил каждый отчёт по отдельности в модель с контекстным окном на сто двадцать восемь тысяч токенов и промптом, в котором чётко указал: «Извлеки из этого квартального отчёта следующие данные: выручка по сегментам, EBITDA, чистая прибыль, капитальные затраты, ключевые риски, упомянутые в разделе обсуждения руководством, и три стратегических приоритета на следующий квартал. Представь результат в виде структурированного текста с числовыми значениями». Каждый отчёт обрабатывался за три-четыре минуты, включая время на чтение и корректировку промпта. На весь первый этап ушло около сорока минут. На втором этапе он собрал двенадцать саммари, каждое объёмом около одной страницы, и загрузил их одним запросом с инструкцией провести сравнительный анализ, выявить тренды и аномалии. На третьем этапе попросил сформулировать выводы и рекомендации для совета директоров. Общее время: сорок минут вместо трёх дней. Точность извлечения цифр составила девяносто четыре процента, а оставшиеся шесть процентов Андрей Викторович проверил вручную, сверив с оригиналами. С тех пор эта процедура стала еженедельным конвейером, и аналитики освободились для задач, требующих стратегического мышления, а не механического копирования цифр из PDF в Excel.

Инструкция