Hacker News Digest

RAG-архитектура, доминировавшая в AI последние три года, уступает место новым подходам. Ранние модели вроде GPT-3.5 ограничивались 4–8 тыс. токенов, что делало невозможной работу с объёмными документами — например, отчёт SEC 10-K содержит ~51 тыс. токенов. RAG решал это через разбиение текста на фрагменты (чанки) и поиск релевантных частей, но даже продвинутые методы чанкинга не спасали от потери контекста: финансовые таблицы, сноски и связи между разделами разрушались.

Современные модели с контекстом в миллионы токенов (например, Gemini 1.5) и агентные архитектуры делают RAG избыточным. Зачем извлекать фрагменты, если можно загрузить весь документ целиком? Это устраняет проблемы чанкинга, эмбеддингов и повторного ранжирования. Ключевой вывод: эра компромиссов между точностью и контекстом заканчивается — будущее за системами, работающими с полными данными без промежуточных шагов.

• Участники критикуют автора за чрезмерное обобщение: утверждение о "смерти RAG" основано на узком примере поиска в коде и не учитывает масштабируемость и другие сложные use-case'ы (например, миллионы документов в распределенных системах).
• Подчеркивается, что RAG — это общий паттерн (извлечение информации + обогащение контекста), а не только векторный поиск; grep, SQL, API-вызовы или использование агента с инструментами — это тоже формы RAG.
• Отмечается, что агентный поиск (с использованием инструментов вроде grep, BM25 и др.) может быть мощнее классического RAG, но он медленнее, дороже и сложнее из-за множественных вызовов функций.
• Указывается, что большие контекстные окна LLM позволяют им читать целые файлы, что меняет workflow и снижает необходимость в сложных пайплайнах чанкинга и эмбеддингов.
• Многие видят иронию в том, что автор называет RAG "кошмаром edge-кейсов", в то время как агентный подход с инструментами вроде grep introduces свои сложности (производительность, безопасность, детерминизм).

Ключевая идея:
Методы ретривала на основе эмбеддингов (EBR) не могут точно воспроизвести полный ранжир по BM25 из-за фундаментальных ограничений геометрии евклидовых пространств.

Проблема:
EBR приближает BM25 через косинусное сходство векторов запроса и документа. Однако BM25 зависит от частоты терминов (TF) и обратной частоты документов (IDF), что нельзя точно закодировать в фиксированном векторе.

Результаты:

1. Нижняя граница ошибки: Для коллекции из n документов минимальная ошибка приближения BM25 через EBR составляет Ω(1/n).
2. Практический эксперимент: На MS MARCO даже идеальные эмбеддинги (обученные для имитации BM25) показывают значительное падение качества (nDCG@10 ↓ на 15–25%).

Вывод:
EBR полезен как компрессия, но не заменяет точные методы. Гибридные системы (EBR + BM25) остаются необходимыми для высокой точности.

• Все сжатия информации (включая эмбеддинги) потерянны, и «обед безплатен» не работает, потому что лучший способ зависит от задачи.
• Теоретические оценки, экстраполирующие полином на тысячи измерений, вызывают сомнение: рост может быть экспоненциальным.
• Плотные векторы ограничены размерностью 4 k, поэтому идеал — «разреженная семантическая» модель вроде SPLADE или гибридные схемы.
• На практике работают многовекторные и late-interaction подходы (ColBERT), но они всё ещё уступают BM25 по ранжированию.
• Реальные системы идут по пути параллельных каналов: плотные, разреженные, BM25 → объединение, дедупликация, переранжирование LLM.

DiffMem — хранилище памяти для диалоговых ИИ-агентов на базе Git.
Использует коммиты как «снимки» контекста: каждое сообщение = отдельный diff, история полностью версионируется.
Поддерживает ветвление диалогов, откат к любой точке и слияние веток без потери данных.
Работает как лёгкая библиотека Python: pip install diffmem, далее diffmem init, diffmem commit, diffmem checkout.
Внутри — обычный репозиторий Git, поэтому можно пушить на GitHub, делать PR и использовать все привычные инструменты.

• Пользователь предложил заменить векторные БД на «агентивный» ретривал: LLM сама выбирает нужные файлы из аннотированного списка; для сотен документов это проще и точнее, чем классический RAG.
• Критика: такой подход не решает задачи семантического поиска в больших пространствах, для которых и создавались векторные БД.
• Поддержка: git-файлы удобны для малого объёма (≈100 МБ), а BM25/Lucene/FAISS-flat можно использовать как быструю альтернативу.
• Предложены улучшения: post-commit-хуки для обновления индекса, гибридные поиски, MCP-сервер, временные knowledge-graph.
• Автор признаёт, что это PoC для «памяти агентов», а не полноценная замена векторных БД; при интересе готов довести до продакшена.