Почему AI-чат - это не поисковик и не ELIZA
Три разные задачи выглядят похоже только снаружи. Классический поисковик ищет и ранжирует уже существующие документы. ELIZA, первый массово известный чат-бот, подставляла фрагменты пользовательской фразы в заготовленный шаблон ответа. AI-чат на языковой модели делает третье: формирует ответ с учётом запроса и всего контекста разговора, а не выбирает готовую страницу (Habr: от готовых реплик к контекстной памяти).
Дальше разберём, как системы пришли к этому: ELIZA и её сценарии, SHRDLU и классический пайплайн NLU / Dialogue Manager / NLG, векторные представления слов и Word2Vec, Seq2Seq с механизмом внимания, Transformer, семейства GPT и BERT, Sentence-BERT, RAG, InstructGPT и RLHF, ChatGPT, длинный контекст, мультимодальность, режимы рассуждения, веб-поиск, память между беседами, Dreaming и голосовые модели.
Для практики это не история ради истории. Понимание того, где именно ломалась каждая архитектура, помогает выбирать модель под задачу, собирать RAG без лишних слоёв и оценивать, какой объём контекста реально нужен вашему сценарию.
ELIZA: как работал первый чат-бот и почему это был сценарий, а не понимание
ELIZA разработал профессор Массачусетского технологического института Джозеф Вейценбаум. В январе 1966 года он опубликовал статью с описанием программы в журнале Communications of the ACM, а общались с ней через печатающий терминал, подключённый к компьютеру IBM 7094.
Поведение ELIZA задавал отдельный сценарий: набор ключевых слов и правил обработки текста. Механика простая и полностью ручная. Программа находила в сообщении ключевые слова, учитывала их приоритеты, выбирала связанные правила и подставляла найденные фрагменты в шаблон ответа. Она умела менять местоимения, переставлять части фразы и сохранять отдельные куски беседы, чтобы вернуться к ним позже. Если подходящего правила не находилось, следовала общая реплика или отсылка к сохранённой ранее фразе.
Сценарий можно было заменить, не переписывая саму ELIZA. Это разделение ядра и сценария перекликается с тем, как сегодня отделяют модель от системного промпта и инструкций.
Сценарий DOCTOR: почему имитация психотерапевта работала
Самый известный сценарий, DOCTOR, имитировал беседу с психотерапевтом. Он не ставил диагнозы и не строил модель ситуации: программа задавала уточняющие вопросы и возвращала собеседнику части его собственных высказываний. Фраза «Я чувствую себя плохо» превращалась в вопрос «Почему вы чувствуете себя плохо?» за счёт смены местоимения и подстановки фрагмента в шаблон. Иллюзия понимания возникала из ожиданий собеседника, а не из модели мира у программы.
Разбор движка, приоритезации ключевых слов и памяти первого чат-бота есть в отдельном материале: архитектура ELIZA.
Главное ограничение: правила не масштабируются
Каждое новое намерение, тему или формулировку приходилось добавлять в сценарий руками: новые ключевые слова, новые правила, новые приоритеты. Число правил растёт, конфликты между ними тоже, а покрытие остаётся фрагментарным. Пользователь формулирует иначе - и сценарий промахивается. Механизма обобщения у ELIZA нет, выйти за пределы написанного сценария она не может. Отсюда и тупик шаблонного подхода: система работает ровно на том наборе запросов, который для неё заранее описали.
SHRDLU и классические NLU/DM/NLG: понимание в пределах микромира
Следующий шаг - системы, которые всё-таки строили внутреннюю модель. SHRDLU работала в мире блоков: понимала команды, отвечала на вопросы о расположении объектов, уточняла задачу, если формулировка допускала варианты. Внутри своего домена это выглядело как понимание языка. За его пределами система замолкала, потому что весь мир был описан заранее и целиком помещался в правила.
NLU, Dialogue Manager, NLG: как был устроен классический пайплайн
Промышленные диалоговые системы собирали из трёх слоёв. NLU разбирал реплику на интент и слоты. Dialogue Manager хранил состояние разговора и решал, какой шаг сценария выполнять дальше. NLG собирал ответ по шаблонам. Контекст в такой схеме - это в основном заполненные слоты и история состояний, а не смысловое представление беседы.
Пример: вместо «забронировать номер на 3 ночи» пользователь пишет «хочу остановиться с пятницы по понедельник». Если NLU не обучен на такой формулировке, интент не распознаётся и диалог рвётся. Каждое новое намерение, сущность и исключение описывали вручную, поддержка росла в цене, а перенос на другой домен начинался почти с нуля.
Вывод, к которому пришла индустрия: язык надёжнее извлекать из данных статистикой, чем описывать правилами. Так начался переход к векторным представлениям.
Word2Vec, Seq2Seq и внимание: как язык превратился в векторы
Word2Vec дал словам координаты в векторном пространстве: близкие по смыслу слова оказываются рядом, а сходство можно посчитать численно. Для моделей это означало переход от строк и правил к математике над векторами. Синонимы и типичные контексты стали выражаться расстоянием, а не списком исключений.
Почему статических эмбеддингов оказалось мало
У Word2Vec одно слово получает один вектор независимо от окружения. Для многозначных слов это проблема: «ключ» в тексте про музыку и «ключ» в тексте про двери выглядят для модели одинаково. Контекстные модели дают разные представления одного и того же слова в зависимости от фразы, и это заметно меняет качество разбора.
Seq2Seq добавил архитектуру «энкодер - декодер»: модель сжимает входную последовательность в представление и разворачивает его в выходную, поэтому длины входа и выхода могут не совпадать. Слабое место нашлось быстро: длинная фраза сжималась в одно фиксированное представление, и детали терялись. Механизм внимания решил это иначе: на каждом шаге генерации декодер смотрит на разные части входа и сам решает, на что опираться. Именно внимание стало мостом к Transformer.
Transformer, GPT и BERT: архитектура, которая сделала диалог возможным
Transformer построен на self-attention: последовательность обрабатывается параллельно, а связи между далёкими словами улавливаются напрямую. Параллельная обработка позволила обучать модели на больших объёмах текста, а рост данных и параметров дал качественный скачок.
GPT-1, GPT-2 и GPT-3 - авторегрессионные модели, которые предсказывают следующий токен. Каждое поколение увеличивало объём данных и число параметров, и вместе с этим росла способность выполнять задачи по описанию в промпте без дообучения. BERT обучался иначе: на маскированных токенах, то есть предсказывал пропущенное слово, видя контекст с обеих сторон. Sentence-BERT адаптировал этот подход к эмбеддингам предложений, что дало осмысленные векторы для поиска и сравнения смысла.
GPT против BERT: генерация и понимание
Роли разные и дополняющие. GPT силён в генерации: диалог, письмо, код, продолжение текста. BERT сильнее в понимании: классификация, извлечение сущностей, ранжирование, поиск. В рабочих системах они часто стоят рядом: Sentence-BERT ищет релевантные фрагменты, генеративная модель пишет ответ. Отсюда прямой путь к RAG.
RAG, InstructGPT и RLHF: как модели научились следовать инструкциям и искать факты
RAG меняет порядок работы: сначала система находит релевантные документы во внешнем источнике, затем формирует ответ с опорой на них. Это снижает число выдуманных фактов и позволяет отвечать по актуальным данным, которых не было в обучающей выборке. Механика привязки генерации к входным данным подробно разобрана в материале про граундинг.
Вторая половина задачи - управляемость. InstructGPT стал одной из ключевых работ по обучению языковых моделей следовать инструкциям человека. Среди её авторов - Диого Алмейда, бывший исследователь OpenAI, основатель TypeSafe AI; его имя есть и в техническом отчёте GPT-4 (Habr).
RLHF без магии: что именно настраивают
Схема в три шага. Люди сравнивают пары ответов и выбирают лучший. На этих сравнениях обучают модель вознаграждения. Затем основную модель оптимизируют так, чтобы она получала более высокую награду.
Что это даёт на практике: ответы лучше следуют формату и тону запроса, реже уходят в сторону, охотнее признают неопределённость. Чего это не даёт: гарантии истинности. Модель вознаграждения учится на мнениях разметчиков, поэтому качество RLHF упирается в качество разметки и может приводить к излишней осторожности или к заученным формулировкам отказа. Факты всё равно нужно проверять, особенно в узких доменах.
ChatGPT: почему диалог стал основным интерфейсом
ChatGPT соединил генеративную модель, обучение на инструкциях и RLHF с интерфейсом из одного текстового поля. Массовой точкой входа стала именно беседа, а не API. Причина практическая: диалог позволяет уточнять задачу по ходу. Пользователь переформулирует, добавляет детали, просит исправить конкретный абзац, и каждый следующий ответ учитывает предыдущие реплики в пределах контекстного окна.
Технически модель не «понимает» беседу в человеческом смысле: она предсказывает следующий токен с учётом всего предыдущего текста. Ощущение осмысленного разговора даёт сам механизм работы с контекстом. Практический вывод: качество ответа зависит от того, насколько полно вы описали задачу, данные и ограничения. Размытый промпт даёт размытый результат, и смена модели это не лечит.
Длинный контекст, мультимодальность и режимы рассуждения
После ChatGPT развитие пошло вширь. Контекстные окна выросли, поэтому за один запрос можно подать документ, часть кодовой базы или длинную переписку. Мультимодальные модели принимают изображения, аудио и видео: это расширяет сценарии на разбор скриншотов интерфейса, работу с голосом и видеоанализ. Анонсы Guided vision и видео - примеры того, как интерфейсы получают новые каналы ввода. Режимы рассуждения заставляют модель тратить больше вычислений на пошаговый разбор задачи. Веб-поиск подключает внешние источники и снижает риск ответов по устаревшим данным.
Где длинный контекст помогает, а где создаёт иллюзию
Помогает там, где нужно удержать много взаимосвязанных деталей: анализ договора, рефакторинг модуля, длинная переписка с историей решений. Иллюзия возникает, когда пользователь считает, что модель «помнит всё одинаково хорошо». Чем длиннее ввод, тем дороже обработка запроса и тем выше шанс, что деталь из середины текста выпадет из ответа.
Практика простая: ключевые факты и требования ставьте ближе к началу или к концу запроса и повторяйте их явно, а не в единственном упоминании где-то в середине. Режимы рассуждения тоже не бесплатны: они увеличивают задержку и стоимость, поэтому для простых задач их лучше не включать. Как отдельные модели управляют блоком рассуждений, разобрано в статье про форсированное мышление в Laguna-S-2.1.
Память между чатами: RAG, Dreaming и персонализация
У контекста три уровня. Контекстное окно живёт в пределах одного разговора и очищается вместе с ним. RAG достаёт факты из внешнего источника в момент запроса. Память между беседами хранит сведения о пользователе и прошлых обсуждениях и подмешивает их в новые диалоги.
Чем память между чатами отличается от RAG
RAG ищет во внешней базе знаний и ничего не знает о человеке. Память отвечает на другой вопрос: не «что известно по теме», а «что известно о вас и о наших прошлых разговорах». Оба механизма работают вместе: модель подтягивает и факты из базы, и ваши предпочтения. Современные AI-чаты умеют учитывать сведения из предыдущих бесед и обращаться к внешним источникам при подготовке ответа.
В контексте персонализации и голосовых моделей 2026 года упоминается система памяти OpenAI на основе Dreaming, а также GPT-Live. Публичных технических деталей по этим механизмам в доступных материалах нет, поэтому относиться к ним стоит как к анонсам: заявлены сохранение и использование сведений между чатами и голосовое взаимодействие, а конкретика по устройству и ограничениям пока не раскрыта (Habr). Пока такие механизмы не описаны технически, проверять их поведение стоит на собственных данных, а не на обещаниях.
Практические последствия для пользователя
Плюсы понятны: меньше повторных объяснений, ответы ближе к вашим задачам, непрерывность между сессиями. Минусы не менее реальны. Память означает, что чувствительные данные могут храниться там, где вы этого не ожидали, а сведения из одной беседы способны всплыть в другой. Управление памятью обычно сводится к просмотру, редактированию и удалению сохранённых фактов, и эти настройки стоит проверить в сервисах, которыми вы пользуетесь. Простое правило: не отправляйте в чат то, что не должно сохраниться, включая токены доступа, персональные данные третьих лиц и внутренние документы без необходимости.
Что это значит для практики: локальные LLM, RAG и выбор модели
История контекста напрямую влияет на выбор инструментов. Для длинных документов решают размер контекстного окна и качество работы с серединой ввода. Для поиска и сравнения смысла критично качество эмбеддингов - здесь наследие Sentence-BERT и его аналогов. Для диалоговых задач важнее способность следовать инструкциям и удерживать нить разговора. Разбор терминов вроде LLM, RAG, MCP и reasoning, без которых сложно читать спецификации моделей, собран в глоссарии AI-терминов 2026.
В локальных сценариях память между чатами почти всегда приходится собирать самому: векторная база плюс RAG плюс сохранение истории и извлечение из неё нужных фрагментов. Принципиально нового по сравнению с облачными сервисами здесь нет, разница в контроле над данными и в ресурсах железа. Реальные кейсы того, как это выглядит у пользователей, собраны в обзоре практических сценариев локальных LLM. AI-агенты и MCP-инструменты опираются на ту же схему: контекст, внешние источники и управление состоянием.
Коротко: главное об эволюции AI-чатов
- ELIZA, 1966: сценарии, ключевые слова и шаблоны ответов. Понимания языка нет, есть манипуляция формой.
- SHRDLU и классические пайплайны NLU / Dialogue Manager / NLG: понимание внутри узкого домена и хрупкость к перефразировкам.
- Word2Vec: слова как векторы, числовая основа для работы с языком.
- Seq2Seq и механизм внимания: генерация последовательностей, где модель учится выбирать, на что смотреть.
- Transformer: параллельная обработка и self-attention, архитектурный фундамент современных LLM.
- GPT, BERT, Sentence-BERT: генерация, понимание и качественные эмбеддинги для поиска.
- RAG: внешние факты в момент запроса.
- InstructGPT и RLHF: следование инструкциям и настройка на предпочтения людей.
- ChatGPT: диалог как основной интерфейс к модели.
- Длинный контекст, мультимодальность, режимы рассуждения, веб-поиск: больше данных на входе и больше вычислений на ответ.
- Память между чатами, Dreaming, GPT-Live, персонализация: анонсированное продолжение работы с контекстом.
Чаты научились работать с контекстом не потому, что «поумнели» в человеческом смысле. Архитектура, объём данных и обучение на предпочтениях позволили удерживать и использовать всё больше контекста, и именно это отличает их от сценарных ботов. Что делать с этим знанием: проверьте, какой размер контекста нужен вашим задачам, оправдан ли RAG в вашем случае и как устроена память в сервисах, которыми вы уже пользуетесь.