Hacker News Digest

За 8 месяцев работы над RAG-системами для обработки 13+ миллионов документов автор выявил ключевые факторы успеха. Начав с типового стека Langchain + Llamaindex по туториалам, команда столкнулась с тем, что прототип на 100 документах показывал отличные результаты, а на полном наборе данных - провальные. Основные улучшения, давшие наибольший эффект: генерация множества семантических и ключевых запросов параллельно с исходным, реранкинг (оптимальное соотношение 50:15 чанков), тщательная настройка чанкинга с сохранением логических единиц, добавление метаданных в контекст LLM и маршрутизация запросов, не требующих поиска по базе.

Технологический эволюция включала переход от Azure к Pinecone, а затем Turbopuffer для векторного хранилища, от Cohere к Zerank для реранкинга, и от GPT-4.1 к GPT-5 и обратно. Автор подчеркивает, что реранкинг - "самые ценные 5 строк кода", а на чанкинг уходит большая часть времени. Весь опыт был упакован в open-source проект agentset под лицензией MIT.

• Обсуждение охватывает широкий спектр тем: от генерации синтетических запросов и проблем с их качеством до самостоятельного хостинга, отсутствия настоящего самостоятельного хостинга и до влияния выбора модели эмбеддинга на качество и стоимость.
• Участники обмениваются практическими советами по оптимизации чанкинга, реранкинга и использованию различных моделей эмбеддинга и ранжирования.
• Обсуждаются сложности с интеграцией и стоимостью при использовании сторонних сервисов, а также вопросы безопасности и контроля при использовании облачных сервисов.
• Рассматриваются вопросы о том, какие факторы действительно важны при выборе инструментов и подходов, и какие из них являются просто маркетинговыми фишками.

Amazon S3 Vectors: убийца или спаситель векторных БД?

AWS запустил S3 Vectors — хранилище эмбеддингов прямо в S3. Цена низкая, интеграция в экосистему AWS очевидна. Кто-то уже похоронил специализированные векторные СУБД вроде Milvus, Pinecone, Qdrant. На деле — не так.

Почему это не конец векторных БД

1. Стоимость поиска может быть выше, чем вызов LLM. У одного AI-стартапа расходы на векторный поиск в 2× превышают счёт за OpenAI.
2. RAG вырос до миллиардов векторов за ночь. С3 не масштабируется до таких размеров без потери скорости и точности.
3. Latency-требования изменились, но не исчезли. Пока LLM генерирует ответ, можно подождать 100 мс, но не 5 с.

Что умеет S3 Vectors

• Простой knn через REST / SQL-подобный язык.
• Хранит векторы рядом с объектами, без отдельного кластера.
• Цена: ≈ 0,32 $/млн запросов + стандартные тарифы S3.

Чего нет

• GPU-ускорения, HNSW, PQ, динамического индексирования.
• Фильтрация по метаданным на лету.
• Горизонтального масштабирования под высокую QPS.
• SLA на latency и точность.

Где пригодится

• Холодный архив, редкие запросы, прототипы.
• Совместная работа с полноценной векторной БД: S3 держит дешёвую «копию всего», а hot-слой (Milvus/Pinecone) — быстрый доступ к топ-N.

Итог
S3 Vectors — ещё один кирпичик в стеке, а не замена. Специализированные СУБД остаются единственным способом получить миллиардные индексы, фильтры и суб-100 мс latency без компромиссов.

• S3 Vectors — это дёшево и сердито: холодное хранилище, top-k ≤ 30, фильтры после поиска, нет гибридного поиска и нормальной документации.
• Подходит лишь для низких QPS и «холодных» данных; для рекомендаций, высокого top-k или сложных фильтров придётся шардировать или выбирать другой продукт.
• Цена растёт ступенчато: одна «квантовая» добавка в фильтре может удвоить счёт; у некоторых компаний поиск стоит дороже, чем вызовы OpenAI.
• Альтернативы: Turbopuffer, LanceDB, Cloudflare Vectorize, pgvector в Postgres — каждый даёт больше контроля, функций и/или дешевле при миллионах векторов.
• AWS не раскрывает внутренности, поэтому сообщество тратит дни на реверс-инжиниринг; при превью-ограничениях производительность может вырасти, но гарантий нет.