Большие языковые модели (Large Language Models, LLM) уже участвуют в вашей работе — от черновиков требований до поиска по корпоративной документации. Чтобы использовать их осознанно, аналитику нужна не «магия нейросетей», а карта терминов, этапов обучения и ограничений. Эта статья отвечает на вопрос: что такое ИИ и LLM в прикладном смысле, и какие свойства модели влияют на качество артефактов анализа.

1. Суть темы

Искусственный интеллект (Artificial Intelligence, AI) — область, где программы выполняют задачи, которые обычно требуют человеческого рассуждения: понимание текста, классификация, генерация ответов, принятие решений в неоднозначных условиях. Для аналитика важно не абстрактное определение, а граница применимости: ИИ аппроксимирует паттерны из данных, а не гарантирует истину.

Машинное обучение (Machine Learning, ML) — подход, при котором модель обучается на примерах, а не программируется явными правилами. Глубокое обучение (Deep Learning) использует многослойные нейросети; LLM — частный случай: модели, обученные предсказывать следующий фрагмент текста (токен) в больших корпусах.

flowchart TB
    AI[Искусственный интеллект] --> ML[Машинное обучение]
    ML --> DL[Глубокое обучение]
    DL --> LLM[Большие языковые модели]
    LLM --> App[Приложения аналитика: черновики, поиск, суммаризация]

LLM не «знает факты» в смысле базы данных. Она строит вероятностное продолжение текста на основе статистики обучения. Паттерны из предобучения (pre-training) — это типичные формулировки и связи из корпуса, а не верифицированные факты вашего проекта. Модель не имеет «живой» базы знаний: у неё есть срез знаний (knowledge cutoff) — дата, на которой остановилось обучение, и всё, что произошло после, она может только догадывать по паттернам. Корпоративный RAG закрывает пробел по вашим документам, но не снимает cutoff по внешнему миру: актуальные версии стандартов, протоколов и фреймворков всё равно нужно подтягивать в контекст или проверять вручную.

Отсюда три практических следствия для системного анализа:

  1. Полезность — быстрый черновик, структурирование, переформулировка, извлечение сущностей из неструктурированных материалов.
  2. Риск — уверенные, но неверные формулировки (галлюцинации), пропуск редких доменных правил, смещение к «типичному» ответу из обучающих данных.
  3. Зависимость от контекста — качество ответа определяется промптом, выбранной моделью и способом подключения внешних данных.

Два режима работы, которые нельзя смешивать:

  • Режим 1 — без подключённых источников — модель опирается только на внутренние паттерны; она не читает ваш Confluence, Jira или Git.
  • Режим 2 — с retrieval (RAG и аналоги) — в контекст попадают фрагменты из индекса документов; ответ опирается на то, что реально нашлось и вошло в окно. Проверка источника и полноты выборки остаётся на аналитике.

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

2. Ключевые понятия

ПонятиеСуть для аналитика
Токен (token)Минимальная единица текста для модели; лимит контекста измеряется в токенах, не в «страницах». Один абзац SRS — десятки–сотни токенов; длинный регламент может не поместиться целиком.
Контекстное окно (context window)Объём текста, который модель «видит» за один запрос. Если SRS на 200 страниц, протокол встречи и шаблон не влезают в одно окно — нужна декомпозиция запроса или RAG по частям. Почему «страницы» не метрика и как устроена токенизация — в 11.02 Теоретические основы обработки естественного языка.
Предобучение (pre-training)Обучение на больших корпусах текста; формирует языковые и «широкие» паттерны, но не актуальную базу фактов проекта.
Дообучение (fine-tuning)Изменение весов модели на доменных данных (стиль, терминология); требует ML-инфраструктуры и контроля качества данных.
Instruction tuningОбучение формату «ассистент отвечает на запрос»; обычно выполняет вендор модели, не команда проекта.
RAG (retrieval-augmented generation)Факты из вашего индекса подаются в контекст при inference; веса модели не меняются, владелец данных и индекса — вы.
RLHF / alignment (выравнивание)Подстройка модели под предпочтения разработчиков (снижение токсичности, «безопасные» ответы). «Выровненная» модель не обязана совпадать с бизнес-контекстом заказчика — промптом это не компенсируется; выбор модели, стресс-тесты и этика — в 11.08 Выбор и настройка моделей для корпоративного использования и 11.06 Этические и правовые аспекты.
Галлюцинация (hallucination)Правдоподобный, но фактически неверный или выдуманный фрагмент ответа.
Inference (инференс)Фаза работы уже обученной модели — генерация ответа на запрос; учитывается в НФТ: латентность, стоимость input/output-токенов, доступность.
Embeddings (векторные представления)Семантический поиск по документам; отдельный компонент от generative LLM — см. 11.04 Архитектуры использования LLM в корпоративном контуре.

Fine-tuning, instruction tuning и RAG решают разные задачи: первые два меняют поведение или «голос» модели на уровне обучения; RAG подставляет актуальные факты без переобучения. На проекте чаще начинают с RAG и промптов; fine-tuning — когда нужен устойчивый доменный стиль или терминология при согласованном контуре данных.

Как устроен типичный жизненный цикл LLM

flowchart LR
    A[Корпус текстов] --> B[Pre-training]
    B --> C[Fine-tuning / инструкции]
    C --> D[RLHF / alignment]
    D --> E[Production inference]
    E --> F[Мониторинг и обратная связь]

Pre-training закладывает языковую компетентность. Этапы дообучения, alignment и мониторинга в production — в 11.08 Выбор и настройка моделей для корпоративного использования и 11.09 Мониторинг и оценка качества LLM-решений.

ИИ, генеративный ИИ и LLM — не синонимы

3. Как применяется в работе аналитика

LLM закрывает задачи, где вход и выход — естественный язык или полуструктурированный текст. Мультимодальные модели применимы к скринам UI, диаграммам и PDF-вложениям — прикладные сценарии в 11.07 Практические кейсы применения LLM в анализе.

Для поиска по корпоративной документации обычно нужна связка embedding + индекс + (опционально) generative LLM — это не один «чат-API»; архитектура — в 11.04 Архитектуры использования LLM в корпоративном контуре. Подключение к Confluence, Jira и другим инструментам аналитика — отдельная задача интеграции, не «встроенная функция» модели: 11.05 Интеграция LLM с инструментами аналитика.

Типовые зоны применения на этапах SDLC:

Этап SDLCПример использования LLMЧто остаётся за аналитиком
Сбор контекстаСуммаризация интервью, протоколов, регламентовПроверка фактов, уточнение у [[02.01.03 Анализ заинтересованных сторон (Stakeholder Map)
Формулировка требованийЧерновики [[04.02 Пользовательские истории (User Stories) и Job Storiesuser story]], критериев приёмки, глоссария
МоделированиеЧерновики элементов [[03.02.01 Диаграмма прецедентов (Use Case Diagram)Use Case]], [[03.04.01 BPMN 2.0 - введение и основы
Ревью артефактовПоиск неоднозначностей, пробелов, противоречийРешение по изменениям, эскалация рисков; инспекция — 08.04 Рецензирование и инспекции (техники Фейгана)

Когда LLM на проекте неуместна или запрещена

Зафиксируйте stop-criteria до пилота:

  • Единоличная юридическая или регуляторная интерпретация без обязательного human gate (договор, compliance, отраслевые нормы) — см. 11.06 Этические и правовые аспекты; при отраслевых требованиях — 08.06 Юридические и регуляторные требования РФ (PCI-DSS).
  • Персональные и чувствительные данные без согласованного контура (on-prem, анонимизация, DLP).
  • Safety-critical решения без независимой верификации (медицина, управление инфраструктурой, финансовые лимиты).
  • Явные запреты заказчика или политики компании на передачу артефактов во внешние API.

Практический протокол работы с LLM на проекте

  1. Определите тип задачи — генерация черновика, классификация, извлечение, Q&A по документам. От типа зависят метрики качества и необходимость RAG (режим 1 или 2).
  2. Зафиксируйте границы доверия — что модель может предлагать, а что требует обязательной проверки (регуляторика, финансы, персональные данные, интеграционные контракты).
  3. Выберите способ адаптации — RAG для фактов из ваших документов; fine-tuning — только при обоснованной потребности в доменном стиле и готовой ML-инфраструктуре (11.08 Выбор и настройка моделей для корпоративного использования).
  4. Документируйте решение и уровень воспроизводимости — в ADR или разделе SRS: версия модели, knowledge cutoff, режим (с RAG / без), ограничения, human-in-the-loop.
    • Полная воспроизводимость (контрактные формулировки, регуляторный пакет, baseline для регрессии промптов) — фиксируйте модель, промпт, temperature и seed.
    • Достаточная трассируемость (разовые черновики, brainstorming) — достаточно версии модели и типа задачи.
  5. Связывайте с НФТ — латентность, стоимость input/output-токенов (длинный контекст и частые запросы бьют по бюджету и SLA), лимиты API, локализация данных — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.

LLM ускоряет рутину, но не заменяет 02.04.01 Верификация и валидация (V&V) и 02.04.03 Управление качеством требований. Выявление требований у заинтересованных сторон остаётся в ветке 02.02 (02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии, 02.02.03 Наблюдение и анализ документов); модель — ассистент первого прохода для черновиков и структурирования, финальное качество — по вашим критериям приёмки.

4. Типовые ошибки и ограничения

Ошибки в понимании и использовании

  • Антропоморфизация — приписывание модели понимания, намерений или «знания регламента компании». В режиме 1 модель не читает Confluence; в режиме 2 опирается только на фрагменты, попавшие в контекст, а не на весь репозиторий.
  • Доверие без верификации — принятие сгенерированных требований или полей API без сверки с контрактом и экспертами.
  • Игнорирование стохастичности — отсутствие фиксации версии модели, промпта и параметров там, где по протоколу нужна полная воспроизводимость.
  • Подмена анализа генерацией — «сначала текст от LLM, потом согласование» вместо elicitation с заинтересованными сторонами (02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии).
  • Иллюзия актуальности через RAG — индекс закрывает внутренние документы, но не заменяет проверку внешних стандартов с учётом knowledge cutoff модели.

Системные ограничения технологии

ОграничениеПроявление в работе аналитикаКритерий смягчения
ГаллюцинацииВыдуманные поля API, несуществующие ссылки на стандартыПроверка по [[10.01.04 Шаблон спецификации REST API
Устаревание знанийНеверные версии протоколов, фреймворковKnowledge cutoff и версия модели в SRS/ADR; актуальные документы в контексте
Культурное и языковое смещениеЗападоцентричные рамки; «уплощение» нюансовВыбор модели — 11.08 Выбор и настройка моделей для корпоративного использования; процедуры и этика — 11.06 Этические и правовые аспекты
«Чёрный ящик»Сложно объяснить выбор формулировкиЛогирование, A/B — 11.09 Мониторинг и оценка качества LLM-решений
КонфиденциальностьУтечка данных через облачный APIOn-prem, DLP — 11.06 Этические и правовые аспекты

Связь с 01.07 Когнитивные искажения и критическое мышление: LLM может усилить confirmation bias, если вы используете её только для подтверждения уже принятой гипотезы. Закладывайте контрпримеры и независимую проверку; LLM-подсказки при ревью не заменяют инспекцию артефактов.

Связи с другими разделами базы

Источники и дополнительные материалы

Обзоры и вводные материалы

Научные статьи и исследования

Книги и обзорные главы

Регуляторика, правовые риски и корпоративные политики по GenAI — 11.06 Этические и правовые аспекты.