LLM, которыми вы пользуетесь в работе, — не «чёрный ящик с текстом на входе». Это конкретный конвейер: токенизация, векторные представления, механизмы внимания и архитектура Transformer. Понимание этих слоёв помогает задавать реалистичные НФТ, выбирать между RAG и длинным контекстом, объяснять заказчику, почему модель «не видит» весь BRD целиком, и формулировать требования к корпоративным NLP-сервисам.

1. Суть темы

Обработка естественного языка (Natural Language Processing, NLP) — область, где программы извлекают смысл, структуру и связи из текстов и речи. Современные LLM опираются на нейросетевой NLP-пайплайн: сырой текст превращается в токены, токены — в числовые векторы (эмбеддинги), затем модель через слои самовнимания (self-attention) строит контекстное представление и генерирует ответ.

Корпоративный NLP-сервис — не обязательно чат. Классические задачи — классификация (тип обращения, категория требования), распознавание именованных сущностей (NER), определение намерения (intent) — часто реализуются отдельными моделями или выходным классификатором на представлениях модели (head) без длинной генерации. LLM обобщает эти паттерны в один generative-контур, но на проекте вы всё равно формулируете задачу как «что извлечь / классифицировать / сгенерировать», а не «просто спросить модель».

Сквозной пример. В SRS 180 страниц (~95 000 токенов после токенизации), лимит API — 128k на сумму входа и выхода, а ответ-сводка займёт ещё 2–4k. Модель не «видит» документ целиком: либо усечение хвоста, либо chunking. Следствие для требований: в 10.01.13 Шаблон архитектурного решения (ADR) фиксируете стратегию разбиения и политику трассировки фрагмент → вывод; детали chunking и overlap — в 11.04 Архитектуры использования LLM в корпоративном контуре.

Для системного аналитика граница темы такая: вам не нужно писать модели, но нужно понимать узкие места пайплайна — лимит контекста, стоимость длинных документов, различие encoder и generative-моделей, статических и контекстных эмбеддингов, недетерминизм генерации и отсутствие гарантии привязки к источнику. Это напрямую влияет на архитектуру решений из 11.04 Архитектуры использования LLM в корпоративном контуре и на выбор модели в 11.08 Выбор и настройка моделей для корпоративного использования.

flowchart LR
    T[Сырой текст] --> Tok[Токенизация]
    Tok --> Emb[Эмбеддинги]
    Emb --> Att[Self-attention / Transformer]
    Att --> Out[Классификация / генерация / поиск]

Исторически NLP проходил путь от правил и статистики к глубокому обучению. Ключевой перелом — архитектура Transformer (Vaswani et al., 2017): вместо рекуррентной обработки «слово за словом» модель параллельно учитывает связи между всеми позициями в последовательности через внимание. Именно это лежит в основе GPT, BERT, Claude и большинства корпоративных LLM-сервисов, о которых шла речь в 11.01 Введение в искусственный интеллект и LLM.

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

Encoder, embedding-модели и generative LLM

Не все Transformer-модели — «чаты». Для спецификации контрактов разведите два класса:

КлассАрхитектураТипичные задачиСледствие для контракта
Encoder / embedding-модели (BERT, E5, bge и аналоги)Читает текст, выдаёт вектор или меткуСемантический поиск, классификация, NER, intentОтдельный сервис индексации; низкая latency на коротких входах; нет длинной генерации
Decoder-only LLM (GPT, Claude, Llama)Авторегрессивно предсказывает следующий токенЧат, суммаризация, черновики требованийСтоимость растёт с длиной входа и выхода; нужны параметры decoding и V&V

Критерий выбора без «чата на всё»: высокий объём запросов, жёсткая latency, фиксированная таксономия (20 категорий тикетов, NER по полям из 03.03.03 Словарь данных (описание)) → классический pipeline (encoder + head или маленькая специализированная модель). LLM — когда нужна гибкость формулировок, открытые ответы или работа с неструктурированными протоколами из 02.02.03 Наблюдение и анализ документов. Генеративная модель там, где достаточно embedding + classifier, — лишняя стоимость и риск галлюцинаций.

Токенизация (tokenization)

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

Современные пайплайны используют субсловную токенизацию (WordPiece, BPE — Byte Pair Encoding): редкие и доменные термины разбиваются на частые фрагменты. Различие алгоритмов (WordPiece vs BPE) для аналитика важно в двух местах: оценка лимита и стоимости API (один и тот же текст может дать разное число токенов у разных tokenizer'ов) и смена версии модели — см. ниже про versioning.

АспектПрактическое следствие для аналитика
Токен ≠ символ«Страница» текста в UI ≠ «страница» в лимите API; лимит измеряется в токенах
СубсловаАббревиатуры и неологизмы проекта могут «дороже» занимать контекст
ЯзыкРусский текст часто даёт больше токенов на ту же семантику, чем английский
Версия tokenizerОбновление модели или API может изменить разбиение, подсчёт токенов и качество retrieval — регрессионный прогон при смене версии, см. 11.09 Мониторинг и оценка качества LLM-решений

Эмбеддинги (embeddings)

Эмбеддинги — плотные векторные представления токенов или фрагментов текста в непрерывном пространстве: семантическая близость коррелирует с близостью векторов.

Различайте два поколения подходов:

  • Статические эмбеддинги (Word2Vec, GloVe) — одному слову соответствует один вектор независимо от контекста. «Банк» (финансы) и «банк» (берег) имеют одно представление.
  • Контекстные эмбеддинги (из Transformer-моделей) — значение токена зависит от окружения. Это стандарт для семантического поиска, классификации требований, RAG по корпоративной документации.

Для задач «найти похожий пункт регламента» или «сгруппировать user story по смыслу» контекстные эмбеддинги fine-tuned моделей предпочтительнее статических — особенно при доменной лексике из 03.03.03 Словарь данных (описание) и согласованном 10.01.14 Шаблон глоссария и словаря данных.

Механизмы внимания (attention)

Внимание (attention) — способ взвешивать вклад разных токенов при обработке последовательности: модель «фокусируется» на релевантных частях ввода независимо от их позиции. Это решает проблему дальних зависимостей (long-range dependencies): связь между условием в начале спецификации и исключением в конце.

Базовая формула scaled dot-product attention:

[ \mathrm{Attention}(Q, K, V) = \mathrm{softmax}\left(\frac{QK^\top}{\sqrt{d}}\right) V ]

где (Q) (query), (K) (key), (V) (value) — проекции эмбеддингов; softmax по (QK^\top) задаёт веса «на кого смотреть», а итоговый вектор позиции — взвешенная сумма (V).

Self-attention применяет внимание внутри одной последовательности — ядро Transformer. Cross-attention связывает два потока внутри одной модели (например, декодер «смотрит» на энкодер в seq2seq). В классическом RAG cross-attention внутри одного вызова LLM обычно не заменяет этап retrieval: сначала отдельный поиск по индексу (эмбеддинги, иногда BM25 + embeddings — hybrid retrieval, см. 11.04 Архитектуры использования LLM в корпоративном контуре), затем найденные фрагменты подставляются в промпт. Не путайте «RAG как pipeline retrieve → prompt → generate» с «cross-attention между запросом и документом в одном forward pass».

Архитектура Transformer и сложность O(n²)

Стандартное self-attention вычисляет связи для всех пар позиций длины (n). Вычислительная и памятьная сложность растёт как O(n²) от длины последовательности. На практике это ограничивает контекстное окно (context window) в production: длинный SRS, протокол воркшопа или пакет регламентов не помещается «целиком» без стратегии разбиения.

Чтобы обойти O(n²), используют семейства подходов с общим trade-off «длиннее окно ↔ риск потерять редкую дальнюю связь»: разреженное внимание (sparse attention), линейные аппроксимации, state-space модели (SSM) и гибриды. Это разные архитектурные семейства, не взаимозаменяемые «кнопки»; выбор и бенчмарки на ваших SRS/BRD — в 11.08 Выбор и настройка моделей для корпоративного использования.

flowchart TB
    subgraph dense [Плотное внимание O n²]
        D1[Каждый токен смотрит на все]
        D2[Точнее на дальних связях]
        D3[Дороже по памяти и latency]
    end
    subgraph sparse [Разреженное внимание]
        S1[Смотреть только на выбранные позиции]
        S2[Меньше памяти — длиннее контекст]
        S3[Риск пропустить редкую дальнюю связь]
    end
    dense --> sparse

Генерация, grounding и галлюцинации

После слоёв Transformer decoder-only LLM на каждом шаге предсказывает следующий токен (autoregressive next-token prediction). Декодирование (decoding) — правило выбора: greedy (всегда самый вероятный), temperature, top-p и др. Один и тот же промпт при ненулевой temperature даёт разные формулировки — это не «ошибка API», а свойство стохастической генерации. Для регламентов и воспроизводимых черновиков требований закладывайте параметры генерации и политику фиксации результата — детали в 11.03 Промпт-инжиниринг для аналитика.

Теоретическая связка с рисками: модель оптимизирована на правдоподобное продолжение текста, а не на верификацию факта по источнику. Без явного grounding (RAG, цитирование фрагмента, structured output с полем source_id) сгенерированный абзац может быть связным, но не соответствовать документу — отсюда галлюцинации и усиление confirmation bias при синтезе chunk'ов. Компенсация — не «умнее промпт», а 02.04.01 Верификация и валидация (V&V), трассировка фрагмент → вывод (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки) и human-in-the-loop.

Модель генерирует токены текста, а не SQL, JSON или вызов API «напрямую». Structured output (JSON mode, function calling / tool use) — контракт на уровне API: модель учится выдавать текст в заданной форме, который парсер или оркестратор превращает в структуру. Для интеграций с 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) и 11.05 Интеграция LLM с инструментами аналитика это критично: в спецификации фиксируйте схему выхода и поведение при невалидном JSON, а не предполагайте «модель сама вернёт объект».

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

Принципы Transformer распространились за пределы текста: изображение можно разбить на патчи-токены (Vision Transformer, ViT), мультимодальные модели выравнивают текст и другие модальности через те же эмбеддинги и cross-attention. Для аналитика это та же цепочка «токены → внимание → выход», но с риском доминирования одной модальности. Прикладные сценарии (макеты, OCR, PDF) — в 11.07 Практические кейсы применения LLM в анализе.

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

Теория NLP становится решением, когда вы проектируете или принимаете NLP-компонент в контуре анализа — будь то embedding-сервис для поиска или generative LLM для черновиков.

Лимиты токенов в спецификации и ADR

При интеграции с API зафиксируйте в спецификации или 10.01.13 Шаблон архитектурного решения (ADR) три разных поля — их часто путают:

Поле в контракте / NFRЧто означаетТипичная ошибка
max input / context tokensСколько токенов модель принимает на вход«128k контекст» ≠ «влезет весь BRD + промпт + RAG-фрагменты»
max output / completion tokensСколько токенов модель может сгенерировать за один вызовОжидание 50-страничного отчёта при лимите 4k на completion
Суммарный лимит на запросinput + output ≤ квота провайдераSRS на 120k + ответ 8k не проходит при cap 128k

Дополнительно:

Ограничение пайплайна → что закладывать в NFR/ADR

Одна сводная таблица вместо дублирующих «матриц выбора». Детальные паттерны (chunking, hybrid retrieval, overlap, иерархическая суммаризация) — в 11.04 Архитектуры использования LLM в корпоративном контуре; выбор модели — в 11.08 Выбор и настройка моделей для корпоративного использования.

Ограничение пайплайнаЧто закладывать в NFR / ADRКуда за деталями
Документ длиннее context windowChunking, overlap, трассировка фрагмент → вывод; метрики retrieval (recall@k, MRR)11.04 Архитектуры использования LLM в корпоративном контуре, 11.09 Мониторинг и оценка качества LLM-решений
Нужны перекрёстные ссылки в одном файле (условие ↔ исключение)Валидация на образцах SRS; long-context или sparse/SSM — не «просто больше токенов»11.08 Выбор и настройка моделей для корпоративного использования
Высокий объём, фиксированная таксономия, жёсткая latencyEncoder + head, не generative LLM; SLA на классификацию08.02 Нефункциональные требования (НФТ) — классификация и стандарты
Актуальные факты из Confluence/JiraRAG + контекстные эмбеддинги; fine-tuning не заменяет индекс11.04 Архитектуры использования LLM в корпоративном контуре
Доменный жаргон, стиль, NERГлоссарий (10.01.14 Шаблон глоссария и словаря данных) + RAG; при устойчивом корпусе — fine-tuning11.08 Выбор и настройка моделей для корпоративного использования
Стохастическая генерацияtemperature, seed, max completion tokens; V&V выхода11.03 Промпт-инжиниринг для аналитика, 02.04.01 Верификация и валидация (V&V)
Смена tokenizer / версии моделиВерсионирование в контракте; регрессионный набор запросов и документов11.09 Мониторинг и оценка качества LLM-решений

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

Для корпоративного Q&A и RAG:

  1. Используйте контекстные эмбеддинги encoder-модели, а не устаревшие статические word2vec-подобные векторы.
  2. Согласуйте термины: 03.03.03 Словарь данных (описание) для полей и сущностей, 10.01.14 Шаблон глоссария и словаря данных для единого словаря проекта — синонимы и аббревиатуры влияют на качество retrieval.
  3. Заложите метрики качества поиска (recall@k, MRR) и выборку «сложных запросов аналитика» — методика в 11.09 Мониторинг и оценка качества LLM-решений.

Объяснимость и контроль фокуса модели

Attention weights (распределение весов внимания) иногда используют для explainability: куда модель «смотрела» при классификации или суммаризации. Это не полноценное доказательство рассуждения, но помогает на ревью выявить смещение к boilerplate или к нерелевантному разделу документа.

При автоматической приоритизации требований или извлечении сущностей из 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) и 02.03.03 Спецификация требований (SRS, Use Case, User Story) закладывайте human-in-the-loop и критерии качества артефактов — 02.04.03 Управление качеством требований, 02.04.01 Верификация и валидация (V&V).

Формулировка НФТ к NLP-сервису

Перенесите технические ограничения в 08.02 Нефункциональные требования (НФТ) — классификация и стандарты:

  • Latency — растёт с длиной контекста; отдельные SLA для embedding-сервиса и generative LLM;
  • Throughput — batch vs streaming;
  • max input tokens, max completion tokens, суммарный лимит — в токенах, с указанием tokenizer и версии модели;
  • Детерминизм — допустимая вариативность ответа (temperature, seed) для регламентированных сценариев;
  • Формат выхода — JSON schema, function calling, кодировка;
  • Качество на доменном корпусе — recall@k / MRR для retrieval; accuracy/F1 для классификации — не только «общий» бенчмарк.

Мультимодальные сценарии

Те же примитивы (токены, эмбеддинги, внимание) применимы к макетам, сканам и вложениям — с отдельными критериями качества по модальностям. Детали формулировки запросов — 11.03 Промпт-инжиниринг для аналитика; интеграция и кейсы — 11.05 Интеграция LLM с инструментами аналитика, 11.07 Практические кейсы применения LLM в анализе.

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

Ошибки в понимании и проектировании

  • «Модель прочитала весь документ» — при chunking или усечении контекста модель видит только фрагмент; остальное отсутствует в inference, даже если файл «загружен» в UI.
  • Путаница символов и токенов — завышенные ожидания по объёму текста в одном запросе; неверная оценка стоимости API.
  • Generative LLM вместо encoder + head — чат для классификации 50k тикетов/сутки при SLA 200 ms; лишняя стоимость и недетерминизм.
  • Путаница max context и max completion — «128k окно» не означает «128k символов ответа».
  • Статические эмбеддинги для динамического домена — поиск по Confluence с word2vec-era решением без контекста даёт устаревшие или ложные «похожие» фрагменты.
  • Игнорирование O(n²) — требование «анализировать 500-страничный договор за секунду» на dense Transformer без архитектурных мер нереалистично.
  • RAG = cross-attention в одном вызове — retrieval и генерация — отдельные этапы; качество зависит от индекса и chunking, не только от «умности» LLM.
  • Ожидание grounding «из коробки» — autoregressive generation не проверяет источник; без RAG и V&V модель достраивает правдоподобный, но ложный текст.
  • Ожидание детерминизма без настройки — два прогона с одним BRD дают разный текст при стохастическом decoding; для воспроизводимости нужны параметры и процесс фиксации.
  • Structured output без контракта — модель «почти JSON» ломает интеграции; нужна схема, валидация и fallback.
  • Вера в attention как «объяснение» — heatmap внимания иллюстративен; не заменяет 02.04.01 Верификация и валидация (V&V) и экспертную проверку.

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

ОграничениеПроявлениеКритерий смягчения
O(n²) self-attentionУзкое context window, высокая latency на длинных входахChunking + RAG, long-context/sparse/SSM — 11.08 Выбор и настройка моделей для корпоративного использования
Autoregressive generation без groundingГаллюцинации, уверенный неверный текстRAG, цитирование источника, V&V — 02.04.01 Верификация и валидация (V&V)
Зависимость от обучающих данныхСлабая работа на редкой доменной лексикеFine-tuning, доменный корпус, глоссарий в промпте
Границы context windowПотеря связей при chunkingOverlap, трассировка — 11.04 Архитектуры использования LLM в корпоративном контуре, 02.03.04 Трассировка требований (концепция)
Trade-off sparse / long-context / SSMПропуск дальних зависимостейA/B на реальных SRS/BRD
Смена tokenizer / моделиДругой подсчёт токенов, регрессия retrievalВерсионирование в NFR и ADR; мониторинг — 11.09 Мониторинг и оценка качества LLM-решений
Мультимодальное выравниваниеМодель «слушает» картинку, а не текст требованияРаздельные критерии качества; human review — 11.07 Практические кейсы применения LLM в анализе

Chunking длинных материалов без явной стратегии склейки усиливает confirmation bias при последующем синтезе: модель достраивает связный, но неполный нарратив — см. 01.07 Когнитивные искажения и критическое мышление. Компенсируйте 02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки, указанием источника фрагмента в каждом выводе и 02.04.01 Верификация и валидация (V&V).

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

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

Книги и фундаментальные работы

Обзоры и учебные материалы