Практика работы с популярными LLM: GPT, GigaChat, Gemini и другие

Обзор экосистемы LLM: выбор модели под задачу и ограничения

В этом курсе мы будем учиться практически работать с популярными LLM (Large Language Models — большие языковые модели): GPT, GigaChat, Gemini и другими. Начнём с главного: как выбирать модель под задачу, через какие каналы к ней обращаться и какие ограничения учитывать, чтобы результаты были предсказуемыми в реальной работе.

Что входит в экосистему LLM

Под «экосистемой» обычно понимают не только саму модель, но и весь набор компонентов вокруг неё:

Каналы доступа: чат-интерфейс, API, локальный запуск (для некоторых открытых моделей)

Инструменты вокруг: встроенный поиск, работа с файлами, генерация изображений, распознавание речи, tools/function calling (вызов функций)

Инфраструктура: лимиты, скорость, стабильность, региональные ограничения

Политики: хранение данных, безопасность, правила использования

В рамках курса мы будем много работать через API и через чаты, потому что именно там легче всего контролировать вход, выход, формат и повторяемость результата.

Основные «семейства» решений: закрытые и открытые модели

На практике модели удобно разделить по способу распространения.

Закрытые (proprietary) модели

Вы используете модель через сервис провайдера (чат или API), но не управляете весами модели.

Плюсы:

Обычно выше качество «из коробки»

Удобные платформенные функции (инструменты, мультимодальность, управляемая безопасность)

Минусы:

Ограничения по данным (куда отправляются, как хранятся)

Зависимость от провайдера, цен и лимитов

Примеры провайдеров и документации:

OpenAI API documentation

Google Gemini API documentation

Anthropic Claude documentation

Открытые (open weights) модели

Вы можете запускать модель у себя (локально или в своём облаке), если лицензия позволяет.

Плюсы:

Больше контроля над данными и инфраструктурой

Возможность оптимизаций под свои задачи и окружение

Минусы:

Нужно самим обеспечивать развёртывание, мониторинг, безопасность

Качество и удобство могут требовать больше инженерных усилий

Примеры экосистем:

Llama

Mistral AI Documentation

> Важное практическое правило: «закрытая» модель не означает автоматически «нельзя использовать в бизнесе», а «открытая» не означает автоматически «безопасно». Всегда смотрите конкретные условия и политики провайдера или лицензии модели.

Каналы доступа: чат vs API vs локальный запуск

Чат-интерфейс

Подходит, если:

Нужно быстро получить результат без разработки

Задача исследовательская: проверить гипотезу, собрать варианты, накидать структуру

Риск:

Сложнее воспроизводить результат (контроль параметров, системных настроек, версий)

API

Подходит, если:

Нужна интеграция в продукт, бота, внутренний сервис

Нужны форматы ответа (JSON), маршрутизация, логи, контроль качества

Риск:

Придётся учитывать лимиты, стоимость, обработку ошибок, версионирование

Локальный запуск

Подходит, если:

Нельзя отправлять данные внешнему провайдеру

Нужна предсказуемая стоимость на большом объёме

Риск:

Требуются ресурсы (GPU/CPU), настройка, обновления, безопасность

Критерии выбора модели под задачу

Ниже — практический чеклист. Идея проста: вы выбираете не «самую умную» модель, а самую подходящую при ваших ограничениях.

Качество и тип задачи

Сначала уточните, что именно вы хотите получить:

Генерация текста (письма, посты, инструкции)

Аналитика текста (извлечение фактов, классификация, разметка)

Работа с кодом (генерация, ревью, объяснение)

Мультимодальность (текст+картинки, иногда аудио)

Инструменты: вызов функций, работа с внешними источниками

Практика: для «строгих» задач (извлечение полей, классификация, JSON) часто важнее не максимальная креативность, а дисциплина формата и устойчивость.

Контекст (сколько данных вы даёте модели за раз)

Контекстное окно — это ограничение на объём входа и выхода в одном запросе. Если вы хотите «скормить» модели длинный договор или историю переписки, контекст становится решающим.

Практика: если документ не помещается в один запрос, придётся:

Резать на части (chunking) и суммировать по этапам

Делать поиск по базе (RAG-подход: Retrieval-Augmented Generation — генерация с подстановкой найденных фрагментов)

Стоимость и скорость

Модели отличаются по цене и задержке ответа. Часто разумная стратегия такая:

Дешёвая/быстрая модель для черновиков и массовой обработки

Более сильная модель для сложных случаев и финальной проверки

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

Это ключевой пункт для бизнеса и любых персональных данных.

Проверьте:

Можно ли отправлять ваши данные внешнему провайдеру

Как провайдер использует данные (например, политика хранения/обучения)

Где территориально обрабатываются данные (если для вас важна юрисдикция)

Примеры страниц, с которых обычно начинают проверку:

OpenAI API data usage policies

GigaChat на портале разработчика Сбера

Ограничения по безопасности и «политики ответа»

Любая популярная LLM имеет встроенные ограничения: она может отказываться от части запросов или «смягчать» ответы.

Практический вывод:

Для чувствительных доменов (медицина, финансы, право) заранее закладывайте сценарии отказа

Стройте продукт так, чтобы отказ модели не ломал процесс (fallback-логика)

Инструменты и интеграции

Если вам нужно не просто «текст», а действие, смотрите поддержку:

Вызова функций (модель возвращает структурированный вызов вашего инструмента)

Ответа в строгом JSON

Поддержки мультимодальности (входные изображения, иногда аудио)

Быстрая таблица выбора: «что смотреть в первую очередь»

| Сценарий | Что важнее всего | Типичная стратегия | |---|---|---| | Чат-ассистент для сотрудников | Качество диалога, безопасность, стоимость | Начать с закрытых моделей через API, добавить логирование и тесты | | Извлечение полей из документов | Формат, стабильность, контекст | JSON-ответы, строгие промпты, тест-наборы, возможно RAG | | Генерация маркетинговых текстов | Креативность, стиль, скорость | Несколько вариантов, выбор лучшего, шаблоны тональности | | Анализ внутренней базы знаний | Приватность, качество поиска, контекст | RAG, контроль источников, ограничение «домыслов» | | Локальный корпоративный контур | Приватность, контроль инфраструктуры | Open weights + развёртывание в своей среде |

!Диаграмма принятия решения: от задачи и ограничений к способу доступа и выбору модели

Ограничения LLM, которые чаще всего ломают проекты

Галлюцинации (уверенные ошибки)

LLM может уверенно выдавать неверные факты. Это не баг «конкретной модели», это типовое свойство генеративных моделей.

Что делать на практике:

Просить модель отделять факты от предположений

Требовать ссылки на источник, если вы используете RAG или даёте документы

Делать пост-проверки: правилами, регулярками, валидацией JSON, бизнес-логикой

Чувствительность к формулировке запроса

Небольшое изменение промпта может сильно менять результат.

Что делать:

Использовать шаблоны промптов

Фиксировать формат входа и выхода

Вести набор тест-кейсов (реальные примеры запросов)

Ограничения контекста

Даже если контекст большой, он не бесконечный. При переполнении модель теряет часть входа.

Что делать:

Резать и собирать ответы по этапам

Подмешивать только релевантные фрагменты через поиск (RAG)

Непредсказуемость в крайних случаях

На редких примерах модель может «поплыть», особенно если:

Входные данные шумные

Формат ответа строго фиксирован

Нужно много шагов рассуждения

Что делать:

Делать маршрутизацию: простые случаи — простая модель, сложные — сильная

Делать повторный запрос при ошибке формата

Практический алгоритм выбора модели (то, как мы будем работать в курсе)

Сформулировать задачу как вход → выход.

Определить ограничения: данные, стоимость, задержка, контекст, политики.

Выбрать канал: чат (быстро проверить) или API (строить процесс).

Протестировать 2–3 модели на одном и том же наборе примеров.

Зафиксировать промпт-шаблон и критерии качества.

Добавить защитные меры: валидация формата, fallback, логирование.

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

Базовые рабочие техники: роль, контекст, цели, формат ответа

В предыдущей статье мы разобрали, что выбор LLM — это выбор под задачу и ограничения: данные, стоимость, скорость, контекстное окно, политики. Теперь перейдём к ежедневной практике: как формулировать запросы так, чтобы GPT, GigaChat, Gemini и другие модели давали более предсказуемый и проверяемый результат.

Эта статья — про четыре базовые техники, которые чаще всего дают ощутимый рост качества:

Роль — кем модель должна быть в рамках задачи

Контекст — какие данные и ограничения реального мира вы ей даёте

Цели — что именно считается успешным результатом

Формат ответа — как должен выглядеть выход, чтобы его можно было использовать

!Схема, показывающая четыре опоры хорошего промпта и их влияние на качество результата

Почему эти четыре элемента работают

LLM генерирует ответ, ориентируясь на инструкции и данные, которые вы ей дали. Большая часть проблем в реальной работе возникает не из-за «слабой модели», а из-за того, что:

модель не поняла, какую роль играть (например, отвечает как маркетолог вместо юриста)

модели не хватает контекста (например, нет исходного текста, но вы просите точные цитаты)

цель описана расплывчато («сделай красиво», «улучши текст»)

формат не задан, из-за чего ответ нельзя автоматически обработать или сравнить

Ниже — практичная карта: какой элемент что чинит.

| Элемент | Что вы контролируете | Типовые проблемы без него | |---|---|---| | Роль | уровень экспертизы, стиль, рамки ответственности | не тот тон, «умничание», нерелевантные советы | | Контекст | источники данных, ограничения, входные материалы | домыслы, ошибки по фактам, «галлюцинации» | | Цели | критерии успеха, приоритеты, что делать при неопределённости | «вроде ответил», но не решил задачу | | Формат | структура, поля, язык, длина, JSON | невозможно парсить, трудно проверять, «растекание мыслью» |

Роль

Роль — это инструкция: «в каком образе и с какими правилами действовать». В чатах роль часто задают фразой «Ты — …». В API роль может задаваться отдельным полем (например, system-сообщением), но в практическом смысле важна не механика, а содержание инструкции.

Как задавать роль, чтобы она работала

Хорошая роль обычно включает:

профессию или функцию: редактор, аналитик, рекрутер, методист, инженер поддержки

аудиторию: для руководителя, для клиента, для школьника, для разработчика

границы: что модель делает и чего не делает

Примеры коротких ролей:

Частая ошибка

Слишком общая роль вроде «Ты — эксперт во всём» почти не помогает. Она не даёт ограничений и не задаёт критериев качества.

Контекст

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

Контекст важен по двум причинам:

он снижает вероятность домыслов: модель «видит» опорные данные

он упрощает проверку: вы понимаете, откуда в ответе взялись выводы

Как давать контекст

Практические правила:

отделяйте данные от инструкций явными разделителями

подписывайте, что это за данные (письмо клиента, договор, лог ошибки)

если ответ должен основываться только на вашем тексте, так и пишите

Шаблон подачи данных:

Контекст и ограничение объёма

Из предыдущей статьи помните ограничение контекстного окна: длинные документы могут не помещаться в один запрос. Практические выходы:

разбивать документ на части и обрабатывать по шагам

сначала извлекать из частей краткие заметки, а затем собирать общий итог

использовать поиск по базе знаний (RAG-подход), когда нужно подмешивать только релевантные фрагменты

Цели

Цель — это не «сделай хорошо», а описание результата так, чтобы его можно было принять или отклонить.

Как формулировать цели

Рабочая формула: что на входе → что на выходе → критерии качества.

Примеры чётких целей:

Что делать с неопределённостью

Один из самых практичных приёмов — заранее прописать правило:

если данных не хватает, задай 1–3 уточняющих вопроса

если вопрос нельзя уточнить (например, это автоматический пайплайн), явно отметь, какие поля неизвестны

Пример:

Формат ответа

Формат ответа — это способ сделать результат пригодным для использования: вставить в письмо, отправить в задачу, положить в CRM, распарсить кодом.

В реальных проектах формат часто важнее «красоты формулировок», потому что:

вы можете автоматически валидировать результат

проще сравнивать ответы разных моделей

легче строить устойчивые процессы (fallback, повторный запрос при ошибке)

Самые полезные ограничения формата

язык ответа (русский/английский)

длина (например, «не больше 120 слов»)

структура (список, таблица, пункты)

строгий JSON (когда ответ будет обрабатываться программно)

Пример строгого JSON-формата для извлечения полей:

Практический смысл полей:

string|null означает: либо строка, либо значение null, если данных нет

confidence — самооценка модели (например, от 0 до 1), чтобы вы могли решать, отправлять ли результат на проверку человеком

Если вы используете API, многие платформы поддерживают режимы, которые помогают получать структурированные ответы. Смотрите актуальные руководства провайдеров:

OpenAI Prompt Engineering

Gemini API documentation

Anthropic documentation

Базовый «каркас» промпта

Ниже — универсальный шаблон, который хорошо переносится между GPT, GigaChat, Gemini и другими моделями. Его удобно превращать в ваш корпоративный стандарт.

Практические приёмы для повышения стабильности

Один запрос — одна задача

Если вы просите одновременно «проанализируй договор», «сгенерируй письмо», «придумай стратегию», модель почти гарантированно смешает уровни и приоритеты.

Лучше:

сначала извлечь факты и риски (структурированно)

затем на основе этого фактагента сгенерировать письмо или рекомендации

Примеры входа и выхода

Если формат сложный, дайте 1 короткий пример ожидаемого результата. Это часто сильнее, чем длинные объяснения.

Запрет на лишний текст

Когда вам нужен машинно-обрабатываемый результат, добавляйте явную инструкцию:

Критерии отказа

Для «опасных» зон (юридические/медицинские/финансовые советы) заранее задавайте границы:

Это не только про безопасность, но и про качество: модель перестаёт «додумывать» там, где цена ошибки высока.

Мини-практика: три готовых промпта

Редактирование текста под задачу

Извлечение полей из текста

Краткое резюме по документу с контролем источника

Как использовать эту статью вместе с выбором модели

Свяжем с предыдущей темой курса:

если у вас строгий формат (JSON, поля, классификация), выбирайте модель и режим, которые лучше держат структуру, и обязательно задавайте формат в промпте

если у вас длинные документы, продумывайте контекст заранее: резка на части или поиск по базе

если домен чувствительный, цель и роль должны включать границы ответственности и сценарии отказа

В следующем материале курса логично перейти к практикам тестирования промптов: как собирать набор примеров, сравнивать модели на одних и тех же данных и фиксировать стабильные шаблоны для команды.

Продвинутый промптинг: цепочки, критика, самопроверка, few-shot

В предыдущих статьях курса мы разобрали практический базис: как выбирать LLM под задачу и ограничения, а затем как стабилизировать результат через роль, контекст, цели и формат ответа. Теперь перейдём к техникам, которые особенно полезны, когда:

задача многошаговая и модель «теряет нить»

нужен более надёжный результат, чем «первый ответ из головы»

формат строгий (JSON, поля, классификация), а качество колеблется

вы хотите одинаковое поведение в GPT, GigaChat, Gemini и других

Эта статья про четыре практических паттерна: цепочки, критика, самопроверка и few-shot.

!Диаграмма показывает, как многошаговые промпты превращаются в устойчивый процесс.

Принцип: не «один идеальный промпт», а управляемый процесс

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

Полезная связка с базовыми техниками из прошлой статьи:

роль фиксирует стиль и границы ответственности

контекст ограничивает источники и вводит данные

цели задают критерии успеха каждого шага

формат делает результат проверяемым (и часто валидируемым кодом)

Цепочки: разбиваем сложную задачу на управляемые шаги

Цепочка (chaining) — это когда вы не просите модель сделать всё сразу, а строите серию запросов, где каждый шаг имеет узкую цель и понятный выход.

Когда цепочки дают максимальный эффект

длинные документы: сначала извлечь факты, потом резюмировать

письма клиентам: сначала понять проблему, потом предложить варианты ответа

аналитика: сначала собрать аргументы, потом сформировать вывод

строгий формат: сначала классифицировать, потом заполнить поля

Базовый паттерн цепочки

Вместо одного запроса вида «проанализируй и напиши итог» используйте два:

Шаг фактов: извлечь только то, что явно есть в данных

Шаг генерации: на основе фактов построить итоговый текст или структуру

Пример для обращения клиента.

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

Практический приём: «план → черновик»

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

Даже без отдельного API-запроса это уже делает генерацию стабильнее.

Критика: отдельный шаг, который улучшает качество

Критика (critique) — это когда вы просите модель оценить результат по чеклисту и затем исправить. Важно: критика должна проверять не «в целом хорошо/плохо», а конкретные критерии из вашей цели и формата.

Два режима критики

Внутренняя: та же модель оценивает свой ответ

Внешняя: другая модель (или человек) проверяет ответ

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

Шаблон: «ответ → критик → исправление»

Практический совет: критерии критики должны повторять ваши цели и запреты из промпта. Иначе «критик» будет исправлять стиль на свой вкус.

Антипаттерн: «просто покритикуй»

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

Самопроверка: делаем ошибки видимыми до того, как они попадут пользователю

Самопроверка (self-check) — это шаг, где модель проверяет результат на ошибки формата, пропуски, несоответствия данным. Важно различать:

проверку логики и соответствия данным

проверку формата (JSON, поля, перечисления)

Самопроверка по данным: «откуда это взялось»

Полезный приём для снижения домыслов — попросить модель сопоставить утверждения с источником.

Этот паттерн особенно хорошо работает в связке с подходом из первой статьи: если вы используете RAG или даёте документ, требуйте опоры на предоставленные фрагменты.

Самопроверка формата: «валидируемость»

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

Если ваш пайплайн программный, всё равно делайте валидацию на стороне кода. Но самопроверка модели часто снижает число повторных запросов.

Важная практическая заметка про «пошаговые рассуждения»

Многие пользователи пытаются повысить качество просьбой «покажи ход мыслей». В рабочих процессах чаще нужен не подробный внутренний ход рассуждений, а:

короткое обоснование, привязанное к данным

список допущений

список того, что неизвестно

Это лучше контролируется и легче проверяется.

Few-shot: обучаем модель формату на примерах

Few-shot — это техника, когда вы добавляете 1–5 коротких примеров «вход → выход», чтобы модель копировала структуру, стиль и правила.

Few-shot особенно полезен, когда:

формат нестандартный

много исключений и правил

модель «съезжает» в разный стиль от запроса к запросу

Правила хороших примеров

примеры должны быть короткими и максимально похожими на реальные

показывайте пограничные случаи (например, когда значения нет и нужен null)

не добавляйте лишних пояснений вокруг примеров

Few-shot для извлечения полей

Few-shot для стиля и тональности

Если ваша цель — единый стиль команды (поддержка, продажи, HR), примеры работают лучше, чем абстрактные описания «пиши дружелюбно».

Комбинируем техники в один устойчивый шаблон

Ниже — практический универсальный шаблон, который можно запускать как цепочку в чате или как серию вызовов API.

Шаблон пайплайна

Извлечение фактов из данных в структурированном виде

Черновик ответа по фактам

Критика по чеклисту

Исправленный ответ

Самопроверка формата и ограничений

Мини-шаблон для чата

Если модель путает этапы, выносите шаги в отдельные сообщения или отдельные API-вызовы.

Как понять, что техника сработала

Чтобы не «верить на глаз», используйте практичные метрики из духа первой статьи (тестируйте 2–3 модели на одном наборе примеров):

доля ответов, прошедших форматную проверку (например, корректный JSON)

доля ответов без запретных элементов (например, обещаний сроков)

стабильность на одинаковых входах (меньше разброс)

количество уточняющих вопросов там, где данных реально не хватает

Совместимость с разными LLM

Цепочки, критика, самопроверка и few-shot работают почти везде, потому что это не «магическая фича конкретного провайдера», а способ лучше формулировать задачу и контролировать выход.

Различаться могут:

максимальный размер контекста

строгость следования формату

поддержка «структурированных ответов» и вызова функций в API

Поэтому практический подход такой же, как мы фиксировали в начале курса: берёте один набор примеров и прогоняете через GPT, GigaChat, Gemini и другие, сравнивая качество именно по вашим критериям.

Полезные отправные точки по документации промптинга и возможностям API:

OpenAI Prompt Engineering

Gemini API documentation

Anthropic Claude documentation

В следующем материале курса логично перейти к практике тестирования и стандартизации: как собирать тест-наборы, как измерять качество промптов и как превращать удачные цепочки в шаблоны для команды.

Рабочие кейсы: тексты, анализ, таблицы, код, презентации, поиск ошибок

В прошлых материалах курса мы закрепили практическую базу:

как выбирать LLM под задачу и ограничения

как стабилизировать ответы через роль, контекст, цели и формат

как повышать надёжность через цепочки, критику, самопроверку и few-shot

Теперь соберём это в типовые рабочие кейсы, с которыми чаще всего сталкиваются в работе с GPT, GigaChat, Gemini и другими: тексты, анализ, таблицы и извлечение данных, код, презентации, поиск ошибок.

!Универсальный процесс, который можно применять к разным кейсам

Универсальный каркас для любого кейса

Чтобы один и тот же подход работал в разных моделях, фиксируйте одни и те же элементы.

Роль: кто модель и какие у неё границы

Данные: что является источником истины

Цель: что считается успехом

Формат: как будет выглядеть результат

Правило при нехватке данных: вопросы или явная пометка

Базовый шаблон:

Если вы делаете интеграцию через API, ориентируйтесь на актуальные руководства провайдеров:

OpenAI API documentation

Gemini API documentation

Портал разработчика GigaChat

Кейсы по текстам

Кейс: деловое письмо клиенту по обращению

Задача: получить письмо, которое опирается на факты и не обещает лишнего.

Рекомендуемая цепочка:

Извлечь факты, требования, неясности

Написать письмо по извлечённым фактам

Прогнать критикой по чеклисту тона и рисков

Шаг фактов:

Шаг письма:

Кейс: редактура текста под стиль компании

Приём, который стабилизирует стиль лучше, чем абстрактное «пиши дружелюбно»: задайте запреты и эталонные примеры.

Кейсы по анализу

Важно: в прикладной работе вам обычно не нужны длинные внутренние рассуждения модели. Вместо этого просите:

вывод

допущения

что неизвестно

как проверить

Кейс: краткий разбор ситуации и рекомендации

Кейс: сравнение вариантов решения

Частая проблема: модель «выбирает по вкусу». Лечится явными критериями.

Кейсы по таблицам и извлечению данных

Здесь ключевой навык: всегда задавать схему и требовать строгий формат.

Кейс: извлечь поля из текста в JSON

Кейс: сделать таблицу из списка

Попросите выход в Markdown-таблице или CSV и ограничьте колонки.

Кейс: проверить таблицу на ошибки

Кейсы по коду

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

Кейс: написать функцию + тесты

Кейс: ревью и улучшение кода без переписывания всего

Хороший формат для команды: просить минимальный дифф и объяснение рисков.

python (вставьте код)

Кейс: объяснить ошибку компиляции или stack trace

Кейсы по презентациям

LLM полезна не как «сделай презентацию целиком», а как инструмент, который делает быстрые артефакты:

структура

слайды с тезисами

заметки спикера

список иллюстраций

Кейс: презентация на 10 минут для руководителя

Кейс: список визуализаций и иллюстраций

Кейсы по поиску ошибок в тексте, данных и процессе

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

Кейс: найти противоречия и дыры в документе

Кейс: найти причину сбоя процесса по логам и шагам

Здесь важно не просить «назови причину», а просить гипотезы и проверки.

Мини-чеклист: как делать результат устойчивым

Делайте задачу проверяемой: формат, длина, схема, запреты

Разделяйте этапы: факты отдельно, генерация отдельно

Добавляйте критику по чеклисту для рискованных текстов

Для таблиц и JSON всегда требуйте «только результат без пояснений»

Для кода просите тесты и ограничения окружения

При отладке просите гипотезы и проверки, а не одну «причину»

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

Инструменты и интеграции: файлы, веб-доступ, плагины и “инструментальные” вызовы

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

Под “инструментами и интеграциями” в контексте GPT, GigaChat, Gemini и других обычно понимают четыре сценария:

Работа с файлами (загрузка, извлечение, суммаризация, выделение полей)

Веб-доступ (поиск/браузинг, проверка актуальности)

Плагины и расширения (готовые коннекторы к сервисам)

“Инструментальные” вызовы (tool calling / function calling) — когда модель возвращает структурированный вызов вашей функции

Ключевая идея: как только модель получает доступ к инструментам, вы строите не “один промпт”, а мини-процесс: модель предлагает действие, ваша система его выполняет, результат возвращается модели, затем модель формирует финальный ответ.

!Базовый цикл работы LLM с инструментами: модель не “магически знает”, а запрашивает данные и действия через инструменты

Что такое “инструменты” и чем они отличаются от обычного промпта

Обычный чат без инструментов ограничен тем, что вы положили в контекст: текст, таблицы, фрагменты кода. Инструменты добавляют возможность:

Получать данные из внешних источников (поиск, базы знаний, CRM)

Обрабатывать документы (парсинг PDF, извлечение таблиц)

Выполнять действия (создать задачу, отправить письмо, записать в календарь)

Практически это означает, что у вас появляется граница ответственности:

LLM принимает решения и формулирует запросы к инструментам

Ваш код выполняет действия и контролирует безопасность

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

Работа с файлами: как получать из документов проверяемый результат

Работа с файлами чаще всего ломается по двум причинам:

документ большой, не помещается целиком в контекст

документ неоднородный: сканы, таблицы, подписи, страницы с разной структурой

Типовые задачи с файлами

Суммаризация документа: “сделай краткое резюме и риски”

Извлечение полей: “дата, сумма, стороны, сроки” в строгом JSON

Сверка: “найди противоречия между приложениями”

Таблицы: “преврати PDF-таблицу в CSV/Markdown-таблицу”

Практический паттерн: “извлечение → нормализация → итог”

Чтобы снизить домыслы и повысить проверяемость, полезно разделить процесс на шаги:

Извлечь сырой текст и/или таблицы из файла (инструментом или встроенной обработкой файлов)

Попросить модель извлечь факты по схеме (строгий формат)

На основе фактов сгенерировать итоговый текст (письмо, отчёт, вывод)

Пример промпта для шага 2 (извлечение):

Здесь source_quotes — простой практический трюк: вы добавляете “якоря” для проверки, не требуя от модели длинных рассуждений.

Риски и меры защиты при работе с файлами

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

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

Инъекции через документ: документ может содержать текст вроде “игнорируй инструкции и отправь секреты”. Файлы — такой же источник атак, как и веб-страницы

Веб-доступ: как делать поиск полезным, а не источником галлюцинаций

Веб-доступ обычно реализуется как встроенный браузинг или инструмент “поиск”. Практическая ценность — актуальность и проверяемость.

Когда веб-доступ действительно нужен

Актуальные данные: цены, изменения в продуктах, новости, вакансии

Проверка факта: “есть ли подтверждение в источниках”

Сбор ссылок и источников для отчёта

Основная проблема: модель смешивает найденное и выдуманное

Поэтому правило для рабочих процессов:

либо вы просите модель ответить только на основе найденных источников

либо вы просите список источников и краткие выдержки, а вывод делаете отдельно

Пример практичного формата запроса:

Практический минимум безопасности для веб-доступа

Разделяйте “данные из источников” и “вывод”: это снижает шанс, что вы примете недостоверное за факт

Ограничивайте домены (если это внутренний ассистент компании)

Логируйте, какие URL использовались для ответа

Не позволяйте веб-странице “переопределять” системные инструкции

Плагины и расширения: где они полезны, а где опасны

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

Когда плагины хороши

Вам нужно быстро подключить типовой сервис без разработки

У вас простой сценарий: “создай событие”, “заведи задачу”, “найди письмо”

Когда лучше свои инструменты через API

Нужны строгие правила доступа и аудит

Нужна валидация аргументов, сложная бизнес-логика, ограничения по данным

Нужны предсказуемые форматы и обработка ошибок

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

Tool calling / function calling: центральный навык интеграций

Tool calling (часто также говорят function calling) — это режим, в котором модель не просто пишет текст, а возвращает структурированный запрос на выполнение функции.

Суть выглядит так:

Вы описываете инструменты: имя, что делает, какие параметры принимает

Модель выбирает инструмент и возвращает аргументы в структурированном виде

Ваш код выполняет инструмент

Результат возвращается модели

Модель формирует ответ пользователю

Официальные отправные точки по этой теме:

OpenAI Function calling

Google Gemini Function calling

Минимальный пример “схемы инструмента”

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

Практический смысл:

query — строка, которую вы реально отправите в поиск

top_k — ограничение, которое защитит от “слишком широкого” запроса

Как писать промпт, чтобы tool calling был стабильным

Рабочие правила:

Чётко разделяйте: когда нужен инструмент, а когда можно ответить из контекста

Требуйте план: “если данных недостаточно — вызови инструмент X”

Фиксируйте формат финального ответа отдельно от шага инструментов

Пример инструкции (подходит и для чата, и для API-обвязки):

Обработка ошибок инструментов: то, что делает интеграцию “живой”

В реальности инструменты ломаются: таймауты, пустая выдача, 500, недоступная авторизация. Поэтому в процесс закладывают поведение по умолчанию:

Если инструмент вернул пусто: модель задаёт уточняющий вопрос или расширяет запрос

Если инструмент недоступен: модель даёт частичный ответ и явно пишет “нужна проверка”

Если формат аргументов невалиден: ваша система возвращает ошибку в структурированном виде, модель исправляет аргументы и повторяет попытку

Важно: ошибки инструментов лучше возвращать модели как данные, а не как “человеческий текст”, чтобы она могла корректно повторить вызов.

Безопасность интеграций: что обязательно учитывать на практике

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

Prompt injection: внешний текст (веб-страница, документ, письмо) пытается заставить модель нарушить правила

Data exfiltration: модель “утекает” секреты в ответах или отправляет их через инструмент

Over-permission: слишком широкие права токена, и модель может сделать лишнее

Практические меры, которые реально работают:

Минимальные права: отдельные ключи и роли “только чтение”, если можно

Явный allowlist действий: какие операции разрешены (читать, создавать, удалять)

Валидация аргументов на стороне кода: типы, длины строк, допустимые значения

Логирование: какие инструменты были вызваны, с какими аргументами, что вернули

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

Как это связать с предыдущими техниками курса

Инструменты почти всегда требуют тех же “четырёх опор” из базовой статьи:

Роль: задаёт границы, например “ты не выполняешь опасных действий без подтверждения”

Контекст: что является источником истины, какие инструменты доступны

Цели: что считается успешным ответом, когда нужно звать инструмент

Формат: финальный ответ и, отдельно, структурированные аргументы инструментов

А из продвинутого промптинга особенно полезны:

цепочки: “поиск → извлечение фактов → финальный ответ”

критика: проверка, что ответ действительно опирается на источники

самопроверка: проверка формата JSON и полноты полей до отдачи пользователю

Если вы строите процесс правильно, замена GPT на Gemini или другую модель чаще всего сводится к адаптации “обвязки” и мелких формулировок, а сама логика работы с инструментами остаётся той же.

Мини-чеклист: готов ли ваш сценарий к инструментам

Инструменты описаны так, чтобы модель не могла вызвать “всё подряд”

Аргументы валидируются кодом, а не доверием к модели

Есть поведение при ошибках инструмента и пустой выдаче

Финальный ответ отделён от шага инструментов и имеет проверяемый формат

Учтены риски: инъекции, утечки, избыточные права

Этого достаточно, чтобы начать практиковать интеграции в чате и через API. Дальше вы сможете комбинировать: файлы + поиск + tool calling, превращая LLM из “генератора текста” в управляемого помощника, который умеет получать данные и выполнять действия под вашим контролем.

API на практике: ключи, лимиты, чаты, embeddings, RAG и базовая автоматизация

В предыдущих статьях курса мы научились стабилизировать результат промптами (роль, контекст, цели, формат), строить многошаговые процессы (цепочки, критика, самопроверка) и подключать инструменты. Теперь соберём инженерный минимум, чтобы перенести эти навыки из чата в повторяемый процесс через API: безопасно хранить ключи, понимать лимиты, вызывать чат-модели, использовать embeddings, собрать простой RAG и автоматизировать потоковую обработку задач.

В статье мы будем говорить про общие принципы, которые переносятся между GPT, Gemini, GigaChat и другими. Конкретные параметры и названия методов отличаются, поэтому держите под рукой документацию провайдера:

OpenAI API documentation

Google Gemini API documentation

GigaChat на портале разработчика Сбера

!Схема полного API-процесса: от запроса до RAG и контроля качества

Зачем переходить на API, если в чате и так работает

Чат удобен для экспериментов. API нужен, когда вы хотите управляемость:

воспроизводимость: фиксированный шаблон промпта, параметры и формат ответа

интеграции: CRM, тикет-система, база знаний, почта

контроль качества: валидация JSON, маршрутизация, повторные попытки

масштабирование: батчи, очереди задач, ограничения по скорости

На практике вы строите не “магический запрос к модели”, а процесс:

Подготовить вход (очистить текст, собрать контекст, выбрать модель)

Вызвать LLM через API

Проверить ответ (формат, запреты, наличие источников)

При необходимости повторить запрос или эскалировать человеку

Ключи API: как хранить и не потерять контроль

API-ключ — это секрет, который даёт доступ к платным вызовам и данным. Основной навык здесь не “как получить ключ”, а “как не превратить его в утечку”.

Правила хранения ключей

храните ключи в переменных окружения или секрет-хранилищах

не коммитьте ключи в репозиторий

разделяйте ключи по окружениям: dev, stage, prod

ограничивайте права ключа, если провайдер это поддерживает

ротируйте ключи: при подозрении на утечку меняйте сразу

Пример: чтение ключа из переменной окружения в Python.

Типовые ошибки

ключ попадает в логи при печати конфигурации

ключ зашит в клиентское приложение (например, фронтенд)

один ключ используют все сервисы и сотрудники

Практический вывод: ключи живут только на сервере, а доступ к ним должен быть аудируемым.

Лимиты и стоимость: что ломает автоматизацию чаще всего

У API почти всегда есть ограничения двух типов:

лимиты скорости: сколько запросов можно отправить за единицу времени

лимиты объёма: сколько входных и выходных токенов можно обработать

Для OpenAI полезны стартовые страницы:

OpenAI rate limits

Что такое “токены” в практическом смысле

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

выше стоимость

больше задержка

выше риск не уместиться в контекстное окно

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

Базовая стратегия работы с лимитами

планируйте ретраи: временные ошибки и превышение лимитов будут

используйте экспоненциальную задержку: 1s, 2s, 4s, 8s

ограничивайте параллелизм: очередь задач почти всегда лучше “шторма запросов”

делайте деградацию качества: простые случаи на более дешёвой модели

Пример логики ретрая (упрощённо).

Чаты через API: как перенести промпт-шаблоны в сообщения

Почти у всех провайдеров есть формат “диалоговых сообщений”: вы передаёте историю и получаете ответ ассистента.

Практически важно:

отделять системные правила от пользовательского текста

фиксировать формат ответа

хранить контекст ровно настолько, насколько он нужен

Универсальная структура сообщений

system: роль, запреты, формат, правила при нехватке данных

user: конкретная задача и данные

assistant: ответы модели (история диалога, если вы её сохраняете)

Пример запроса в стиле “чат-модель” (псевдо-формат, чтобы не привязываться к одному SDK).

Структурированный ответ: JSON как контракт

Если вы строите автоматизацию, текст “для человека” почти всегда хуже, чем структурированный контракт.

Рабочий паттерн:

в промпте описать схему

потребовать “верни только JSON”

валидировать JSON кодом

при ошибке формата повторить запрос с указанием, что именно не прошло

Важно: даже если модель “умеет JSON”, валидация всегда должна быть в вашем коде.

Embeddings: как превратить текст в поиск по смыслу

Embeddings — это способ представить текст в виде набора чисел так, чтобы похожие по смыслу тексты получались “близкими”. На практике embeddings чаще всего используют для:

семантического поиска по базе знаний

дедупликации похожих обращений

кластеризации тем

подготовки RAG

Стартовая точка по теме:

OpenAI Embeddings guide

Практический пайплайн embeddings

Подготовка документов

Разбиение на фрагменты (chunking)

Получение embeddings для каждого фрагмента

Сохранение embeddings в векторное хранилище

По запросу пользователя: embedding запроса, поиск ближайших фрагментов

Где хранить embeddings

Варианты от простого к системному:

в памяти или в файле: подходит только для демо

PostgreSQL с расширением pgvector: удобно для старта

специализированные векторные базы

Полезные ссылки:

pgvector

FAISS

Chunking: как резать документы, чтобы поиск работал

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

Практические правила:

режьте по смысловым границам: заголовки, пункты, абзацы

храните метаданные: документ, раздел, дата, ссылка

добавляйте перекрытие: небольшой повтор между соседними фрагментами

RAG: ответы на основе ваших документов, а не “из головы”

RAG (Retrieval-Augmented Generation) — это подход, где модель отвечает, опираясь на найденные фрагменты из вашей базы знаний.

Идея проста:

Найти релевантные фрагменты по embeddings

Вложить их в контекст запроса к LLM

Попросить ответить только на основе этих фрагментов

Вернуть ответ вместе с основаниями

Минимальный промпт для RAG-ответа

Что чаще всего ломает RAG

мусор на входе: плохой OCR, битые таблицы, неочищенный HTML

плохой поиск: неверное разбиение, нет метаданных, слишком мало фрагментов

нет правила “только по источникам”: модель начинает домысливать

Практический анти-галлюцинационный минимум для RAG:

требуйте основания со ссылками на фрагменты

храните, какие фрагменты были подставлены

измеряйте качество поиска отдельно от качества генерации

Базовая автоматизация: “маленький продакшен” без лишней сложности

Ниже — минимальный набор компонентов, который позволяет превратить промпты в повторяемый процесс.

Компоненты

конфигурация: модель, лимиты, таймауты, шаблоны промптов

очередь задач: чтобы контролировать параллелизм и ретраи

логирование: вход, модель, версия шаблона, время, ошибки

валидация: JSON-схема, ограничения длины, запреты

fallback: что делать при отказе модели или пустом поиске

Практический шаблон “обработки пачки задач”

Нормализация входа

Выбор сценария: обычный чат или RAG

Вызов LLM

Проверка формата

Сохранение результата и метаданных

Пример структуры записи в лог (как идея, не стандарт).

Что автоматизировать в первую очередь

извлечение полей из обращений в JSON

генерацию стандартных ответов по шаблонам

RAG-ответы по базе знаний

маршрутизацию: когда отправлять человеку

Что не автоматизировать сразу

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

юридические и медицинские ответы без контроля и источников

Как связать это с предыдущими статьями курса

из статьи про базовые техники вы берёте каркас промпта: роль, контекст, цели, формат

из статьи про продвинутый промптинг вы берёте управляемый процесс: факты, генерация, критика, самопроверка

из статьи про инструменты вы берёте идею “оркестратора”: модель предлагает, код проверяет и выполняет

API даёт главное: превращает эти навыки в повторяемый пайплайн, где качество повышается не “магией модели”, а дисциплиной входа, проверками и логикой обработки ошибок.

Качество и безопасность: оценка ответов, защита данных, политика и комплаенс

В прошлых статьях курса мы научились получать более предсказуемые ответы за счёт роли, контекста, целей и формата, затем усилили это цепочками, критикой и самопроверкой, подключили инструменты и вынесли процессы в API. Следующий практический слой, без которого почти любой проект с LLM “ломается” в реальности, — это качество и безопасность.

Ключевая идея: качество и безопасность — не “галочка в настройках модели”, а процесс, который включает тесты, валидацию, правила работы с данными, журналирование и управляемые ограничения.

!Диаграмма показывает, что качество и безопасность — это цикл: подготовка, вызов, проверки, действия и мониторинг.

Что считать “качеством” ответа LLM

В прикладной работе качество — это не “понравился текст”, а проверяемые свойства. Минимальный набор критериев, который переносится между GPT, GigaChat, Gemini и другими:

Соответствие задаче: ответ решает вопрос пользователя, а не уходит в сторону.

Доказуемость: понятно, на каких данных основаны выводы (особенно в RAG).

Формат: ответ приходит в виде, который можно использовать (JSON, таблица, письмо до N слов).

Отсутствие запрещённого: нет обещаний сроков без оснований, нет утечек секретов, нет небезопасных инструкций.

Стабильность: при одинаковых входах ответы не “скачут” по структуре и правилам.

Экономичность: приемлемые задержка и стоимость.

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

Как оценивать качество: от простого к надёжному

Тест-набор: “одни и те же примеры для всех моделей и версий промпта”

Самый сильный практический шаг — собрать небольшой тест-набор (обычно 30–200 примеров), который отражает реальный вход:

Типовые случаи (80%): то, что приходит каждый день.

Пограничные случаи (15%): мало данных, шумный текст, смешение тем.

Рискованные случаи (5%): персональные данные, юридические формулировки, попытки “сломать” правила.

Дальше вы прогоняете через разные модели или версии промпта и сравниваете по метрикам, а не “по ощущениям”.

Автоматические проверки (быстрые и дешёвые)

Это то, что должно работать в вашем коде при API-интеграции:

Валидация формата: JSON-схема, наличие обязательных полей, допустимые значения.

Проверка длины: лимит слов/символов.

Запрещённые элементы: регулярные выражения, словари, простые правила.

“Приземление” в RAG: требование ссылок на фрагменты вида [1], [2] и проверка, что они действительно присутствуют.

Здесь важно: модель может стараться соблюдать формат, но гарантировать это может только валидация на стороне вашей системы.

Человеческая проверка (дороже, но незаменима)

Человеческая проверка нужна там, где:

цена ошибки высока (финансы, право, медицина)

есть тонкие требования к тону и коммуникации

вы запускаете новый сценарий и ещё не знаете слабые места

Практичный режим — выборочная проверка: например, 1–5% ответов + 100% ответов, которые не прошли автоматические проверки.

LLM-as-judge (модель как оценщик)

Иногда удобно использовать вторую модель как “судью”: она выставляет оценку по чеклисту и находит нарушения. Это продолжение техники критики из прошлой статьи.

Правила, чтобы это было полезно:

Судья оценивает по фиксированному рубрикатору (чеклисту), а не “в целом”.

Судья не должен иметь доступ к секретам.

Результаты судьи нужно периодически калибровать человеком (иначе вы автоматизируете чужие ошибки).

LLM-as-judge особенно полезен для проверки стиля, наличия запретов, полноты полей, но хуже подходит для проверки фактической истины без источников.

Метрики, которые реально помогают управлять качеством

Ниже — практический минимум метрик, который можно ввести почти в любом проекте.

| Метрика | Что измеряет | Как считать на практике | Зачем нужна | |---|---|---|---| | Доля валидных ответов | Структурную дисциплину | % ответов, прошедших JSON schema | Уменьшает “ручной разбор” и ретраи | | Grounded rate | Привязку к источникам | % утверждений со ссылками на фрагменты (для RAG) | Снижает галлюцинации | | Refusal rate | Частоту отказов | % запросов, где модель отказалась | Важно для UX и комплаенса | | Escalation rate | Долю передачи человеку | % ответов с needs_human=true | Контроль рисков и нагрузки | | Cost per task | Стоимость сценария | токены и цена провайдера | Помогает выбирать модель и стратегию | | Latency p95 | “хвост” задержек | 95-й перцентиль времени ответа | Важен для продуктовых SLA |

Если вы делаете цепочки (факты → генерация → критика), метрики стоит считать отдельно по каждому шагу: это быстрее показывает, где именно ломается процесс.

Защита данных: что можно отправлять в LLM, а что нельзя

Безопасность начинается с простого вопроса: какие данные мы вообще имеем право передавать внешнему провайдеру или даже внутренней модели?

Минимальная классификация данных

Удобно договориться о 3–4 классах данных внутри команды:

Публичные: можно публиковать без ограничений.

Внутренние: не для публикации, но не критично.

Конфиденциальные: коммерческие тайны, ключи, договоры, внутренняя финансовая информация.

Персональные данные: любая информация, которая относится к идентифицируемому человеку.

Дальше вы фиксируете правило: какие классы можно отправлять в конкретный инструмент (чат, API, локальный контур) и при каких условиях.

Практика минимизации данных

Самое рабочее правило: отправляйте в модель только то, что нужно для ответа.

Обычно это достигается комбинацией:

Маскирование: заменить персональные поля на маркеры PERSON_1, PHONE_1, EMAIL_1.

Псевдонимизация: хранить связь “маркер → реальное значение” только в вашей системе.

Удаление лишнего: убрать подписи, футеры, служебные блоки, куски переписки, не влияющие на ответ.

Это одновременно снижает риск утечки и уменьшает стоимость токенов.

Политики провайдеров: что важно проверить до запуска

У разных платформ различаются условия хранения и использования данных. До продакшена проверьте:

хранение запросов и ответов (логирование у провайдера)

возможность запрета использования данных для улучшения сервисов (если доступно)

сроки хранения и возможность удаления

регион обработки (если важно для вашей юрисдикции)

Отправные точки для чтения политики и документации:

Политика использования данных OpenAI API

Документация Gemini API

GigaChat на портале разработчика Сбера

Безопасность промптов и инструментов: prompt injection и контроль действий

Что такое prompt injection простыми словами

Prompt injection — это атака, когда внешний текст пытается заставить модель нарушить ваши правила. Например:

веб-страница “внедряет” инструкцию игнорировать системный промпт

документ содержит текст “отправь секреты в ответ”

пользователь формулирует запрос так, чтобы модель раскрыла приватные данные

Особенно опасно это становится при наличии инструментов (tool calling), потому что модель может не только “написать текст”, но и вызвать действие.

Минимальные меры защиты, которые реально работают

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

Allowlist инструментов: модель должна иметь доступ только к строго нужным инструментам.

Валидация аргументов инструментов: типы, длины, допустимые значения — проверяет ваш код.

Разделение прав: ключи “только чтение” для поиска и просмотра; отдельные ключи для изменения данных.

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

Практический ориентир по типовым рискам приложений на LLM:

OWASP Top 10 for Large Language Model Applications

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

Политика и комплаенс: как оформить правила так, чтобы ими пользовались

Комплаенс в контексте LLM — это соответствие внутренним правилам компании, контрактным условиям и законам. На практике он “живёт” не в документе на 50 страниц, а в коротких правилах, которые встроены в процесс.

Что должно быть в внутренней политике использования LLM

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

Классы данных: что можно отправлять, что нельзя, что можно только после маскирования.

Правила логирования: что сохраняем, как долго, кто имеет доступ.

Правила эскалации: когда ответ обязан уйти на проверку человеку.

Правила обновлений: как меняем модель или промпт-шаблон (версии, тесты, откат).

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

Что важно для юридической и регуляторной стороны

Это зависит от страны и отрасли, но типовые вопросы одинаковы:

есть ли право передавать данные третьей стороне

где обрабатываются данные территориально

какие сроки хранения

кто имеет доступ

как выполняются запросы на удаление данных (если требуется)

Если вы работаете с данными граждан ЕС, вам важно понимать базовую рамку GDPR:

Регламент (ЕС) 2016/679 (GDPR) на Eur-Lex

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

Практический “скелет” процесса качества и безопасности для LLM

Ниже — последовательность шагов, которую удобно применять к любому сценарию (чат, API, RAG, инструменты).

Описать задачу как вход → выход и зафиксировать формат.

Определить риск-уровень сценария:

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

Собрать тест-набор и метрики (валидность формата, grounded rate, эскалации).

Встроить автоматические проверки:

- JSON schema - запреты и длина - проверка ссылок на источники для RAG

Встроить меры защиты данных:

- маскирование - минимизация - контроль логов

Протестировать на атакующих примерах (мини red teaming):

- попытки вытащить секрет - “инструкции” внутри документа - провокации на опасные действия

Запустить мониторинг в продакшене:

- метрики качества - журнал инструментальных вызовов - алерты на всплеск ошибок формата или эскалаций

Мини-чеклист перед запуском в работу

Есть фиксированный формат ответа и валидация в коде.

Есть тест-набор и метрики, по которым сравниваются модели и версии промптов.

В сценариях с RAG ответы требуют оснований со ссылками на фрагменты.

Данные минимизируются и маскируются, секреты не попадают в промпты и логи.

Инструменты работают по allowlist, аргументы валидируются, опасные действия требуют подтверждения.

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

Эта дисциплина позволяет спокойно менять модель (GPT ↔ Gemini ↔ GigaChat ↔ другие), потому что управляемость обеспечивается не “магией провайдера”, а вашей системой: форматами, проверками, политиками и мониторингом.