На самом деле, в продакшн-решении пришел именно к этому. Здесь Hybrid Search описан как комбинация Graph + Vector для простоты понимания базового баланса. Однако Graph Search внутри гибрида может быть реализован именно через Graph-Native Chunking.
Причина, по которой разделил их в анализе - латенси. Graph-Native Chunking требует предварительной подготовки эго-сетей и верификации доказательной базы. Если пустить этот тяжелый процесс параллельно с векторным поиском в RRF, итоговая задержка системы всегда будет ограничена самым медленным компонентом (в нашем случае — графовым чанкингом, который достигает 5 секунд). Для моих бизнес-сценариев это неприемлемо, поэтому Hybrid Search оставил на облегченном графовом поиске.
Не совсем про чанкинг)), но смотри, если нужно просто добавить новый договор или клиническую рекомендацию, Weaviate отлично справляется с CRUD-операциями на лету. Мы просто загружаем новые объекты. Благодаря тому, что Weaviate (в отличие от, например, FAISS) — это полноценная БД, она сама управляет блокировками и консистентностью. Индекс HNSW обновляется динамически.
А вот Blue-Green - это, наверно, в контексте версионирования - очень на это похоже, здесь мы по классике делаем: часто меняются не просто документы, а логика их интерпретации (или мы меняем модель эмбеддинга) - тогда логично создаем новую коллекцию (Class) в Weaviate с суффиксом версии, заливаем туда данные в фоновом режиме, прогоняем наши CI/CD автометрики (DeepEval) на новой коллекции, если метрики не просели - мы переключаем алиас на уровне API-шлюза или внутри кода приложения на новую коллекцию, старая коллекция живет еще некоторое время как бэкап, затем удаляется. Это гарантирует Zero Downtime и защищает от выкатки битого индекса.
Да, очевидно, так и есть и мы не отвергаем такого подхода, а наоборот активно его внедряем. Кстати, не так давно было неплохое интервью по этому вопросу https://www.youtube.com/watch?v=6TJDriX1CAo&t=2140s
На самом деле, в продакшн-решении пришел именно к этому. Здесь Hybrid Search описан как комбинация Graph + Vector для простоты понимания базового баланса. Однако Graph Search внутри гибрида может быть реализован именно через Graph-Native Chunking.
Причина, по которой разделил их в анализе - латенси. Graph-Native Chunking требует предварительной подготовки эго-сетей и верификации доказательной базы. Если пустить этот тяжелый процесс параллельно с векторным поиском в RRF, итоговая задержка системы всегда будет ограничена самым медленным компонентом (в нашем случае — графовым чанкингом, который достигает 5 секунд). Для моих бизнес-сценариев это неприемлемо, поэтому Hybrid Search оставил на облегченном графовом поиске.
Не совсем про чанкинг)), но смотри, если нужно просто добавить новый договор или клиническую рекомендацию, Weaviate отлично справляется с CRUD-операциями на лету. Мы просто загружаем новые объекты. Благодаря тому, что Weaviate (в отличие от, например, FAISS) — это полноценная БД, она сама управляет блокировками и консистентностью. Индекс HNSW обновляется динамически.
А вот Blue-Green - это, наверно, в контексте версионирования - очень на это похоже, здесь мы по классике делаем: часто меняются не просто документы, а логика их интерпретации (или мы меняем модель эмбеддинга) - тогда логично создаем новую коллекцию (Class) в Weaviate с суффиксом версии, заливаем туда данные в фоновом режиме, прогоняем наши CI/CD автометрики (DeepEval) на новой коллекции, если метрики не просели - мы переключаем алиас на уровне API-шлюза или внутри кода приложения на новую коллекцию, старая коллекция живет еще некоторое время как бэкап, затем удаляется. Это гарантирует Zero Downtime и защищает от выкатки битого индекса.
Да, очевидно, так и есть и мы не отвергаем такого подхода, а наоборот активно его внедряем. Кстати, не так давно было неплохое интервью по этому вопросу https://www.youtube.com/watch?v=6TJDriX1CAo&t=2140s