От векторов 70-х к современным AI-агентам 🧩

Я, как всегда, со своим скрупулезным подходом — решил залезть под капот и разобраться, как это всё работает на самом деле. А там... старый добрый pipeline.

Идеи сходства (similarity) и поиска ближайших соседей (nearest neighbors) — это вообще не ново. Эти концепции десятилетиями использовались в поиске, computer vision, распознавании образов и исследовательских системах еще задолго до публичного AI-бума.

Новое здесь — только обертка:

• Vector DB: Назвали их «новым» типом баз для массового рынка (Pinecone и другие), хотя по сути это просто эффективные индексы для векторов.
• API и Cloud services: Удобный способ доставки и масштабирования.
• RAG-пайплайны и LLM: Просто интерфейс для конечного пользователя.

Векторные представления (Embeddings) были стандартом еще в 70x! «Новизна» лишь в том, что теперь мы можем ворочать огромными объемами данных через API.

---

2. Что под капотом? (The Pipeline) ⚙️

Когда мы пишем запрос (prompt), запускается тот самый pipeline:

Tokenizer

Текст режется на куски (токены). Слово или символ превращается в ID. По сути, это простая структура данных (Map) и алгоритм нарезки.

• В open-source: это файлы tokenizer.json, vocab.json, merges.txt.
• В managed API: это спрятано внутри runtime провайдера.

const userQuestion = "How does Vector DB work?"

// Процесс токенизации (упрощенно):
// input  -> ["How", " does", " Vector", " DB", " work", "?"]
// output -> [2437, 857, 12944, 6212, 990, 30]

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

Embedding Layer

Токены попадают в модель и заменяются на векторы (координаты в многомерном пространстве):
2437 -> [0.12, -0.03, 0.88, ...]

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

Здесь модель вычисляет, какие токены в контексте связаны друг с другом. В вопросе "How does Vector DB work?" токен "work" должен «внимательно» смотреть на "Vector DB", чтобы понять смысл. Это почти как поиск по ключевым словам (Keywords) для определения интента вопроса.

Matrix Multiplication

Основная математика. Векторы умножаются на веса (weights) уже обученной модели.
Weights — это как взвешенное среднее. Входные данные с бóльшим весом сильнее влияют на итоговый результат.

Важно понимать: в момент запроса модель не учится. Она просто прогоняет данные через готовую функцию:
$$weights \times vectors$$

Next Token Prediction

На выходе мы получаем вероятности для следующего токена. Выбираем один, добавляем в контекст и уходим на новый круг (Loop):
Context -> Trained Function -> Prediction.
И так токен за токеном, пока не соберется ответ.

"Это мне как раз напомнило курс Andrew Ng. Там параметры шли через функцию, мы считали ошибку (cost) и двигались к минимуму (loss). Только тут prediction — не class label, а следующий токен из словаря."

Кстати, курс Эндрю Ына вышел уже 12 лет назад!

И тут я задумался: если эти идеи публично преподавались так давно, сколько закрытых систем использовали их раньше?

Системы ПВО, спутниковая разведка, медицинские экспертные системы (вроде MYCIN из 70-х).
Всё это живет на этих принципах десятилетиями!

---

3. Проблема «памяти» и RAG 🧠

Context window — это жесткий limit на количество токенов за один request.
Модель не «забыла» информацию — просто если данных слишком много, приложение отрезает старое по принципу FIFO.

while (countTokens(messages) > contextLimit) {
  messages.shift() // Старый контекст просто не отправляется в новый запрос
}

Чтобы использовать модель эффективно, нужно «подкармливать» её свежими данными через метод RAG (Retrieval-Augmented Generation).

Как это работает: Вопрос пользователя ⮕ Поиск по документам ⮕ Найденные фрагменты + Вопрос ⮕ Языковая модель ⮕ Ответ.

Зачем это нужно:

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

---

4. Кто рулит этим процессом? (Оркестрация) 🎮

Это не делает сама модель. Она не решает, какую историю чата взять и какие инструменты вызвать. Этим занимается orchestration layer.

Когда нам стало мало обычного чат-бота, то появились такие штуки как LangGraph (State Machine), которая работает вокруг модели. Оркестратор создает макро-flow:

1. Запрос пользователя ⮕ Слой оркестрации.
2. Проверка состояния / памяти.
3. Определение маршрута (Route).
4. Поиск в Vector DB.
5. Вызов инструментов (Tools).
6. Формирование финального контекста ⮕ Вызов LLM.
7. Валидация ответа ⮕ Конец или новый цикл.

Если LLM — это вероятностный движок, то LangGraph — это императивный контроль. Он говорит: "Сначала сходи в SQL за фактами, если мало — загляни в Vector DB, проверь результат, если хрень — иди на повторный цикл".

---

Архитектура вместо магии 🏗️

Современный AI-агент — это архитектура. Называть её «интеллектом» в полном смысле слова странно, но то, что мы сейчас все живем в статистической матрице — это факт!

---