Да, про абляции: они есть — и половина наших решений их не пережила: важность в ранге проиграла (0.41 против 0.81 у чистого косинуса) всеми четырьмя способами подмешивания, RRF оказался худшим (0.06), так что важность мы из ранга выкинули, а PPR оставили опцией.
Как делать выбор — никак, это про наш корпус. Прогнали, получили своё число. На чужом репозитории ydb-platform/ydb, 293 пары: 32.1% против 94.5% — то есть мы проверяем не значение, а разрыв.
Мы не соревнуемся — это A/B одного компонента (тот же корпус, энкодер, запросы, top-k; меняется только «ходим по рёбрам Closes #N или нет»).
Прямо сейчас провели исследование на открытом репозитории YDB (Yandex Database) — ydb-platform/ydb — результаты публикуем без ретуши как обновление к этой заметке, также потом сделаем отдельную статью, потому что тема очень интересная.
Да, один корпус, и универсальной теоремы мы не заявляем. Переносится не число, а процедура: "не гадать порог абсолютного косинуса, ранжировать top-k, мерить на своих данных". Именно потому, что число поехало — между синтетикой и реальностью, и поедет между корпусами. Механизм не экзотичен: мультиязычные энкодеры (MiniLM-семейство) держат косинус в узком высоком диапазоне, из-за чего облака "соседи" и "случайные" перекрываются. Мы не прогоняли десяток моделей — это субъективная граница замера. Но безопасный вывод "ранжируй, а не ставь пороги" от модели не зависит.
Ключевой момент, и фичу мы выкинули не потому, что важность бесполезна. Провалился не один линейный бленд — проиграли чистому косинусу все четыре способа смешать сигнал (сумма, гейт, RRF, PPR) на реальных парах "запрос - ответ". Причина глубже калибровки: знак пользы важности зависит от интента запроса — на хабовых запросах важность помогает (на синтетическом графе вытаскивает MRR с 0.033 до 1.0), на запросах про конкретный редкий факт — топит его (0.81 -> 0.41). Любой статический вес поэтому неверен по форме. Правильное лекарство — вес, зависящий от запроса/обратной связи; это осознанный план действий, а не тупик. PPR оставлен опцией, из дефолтного ранга важность убрана.
Точность рёбер отдельно не считали - тут пока пробел; но +49 п.п. меряется на held-out gold-парах, а ложное ребро уводит обход и recall занижает, а не раздувает, то есть выход на 87% скорее пол для чистого набора рёбер. Точность рёбер добавим отдельной цифрой.
Дорого не хранение — диск копеечный, мы ничего не удаляем.
Дорого извлечение: в контекст уходит фиксированный top-k, и каждый лишний почти-дубликат занимает слот, который стоил бы нужному факту. Отсюда третий закон статьи: частый плотный сигнал топит редкий, но ценный (популярный узел топит точный факт, хабы зарывают specific, плотные similar_to глушат редкие caused_by). Поэтому «освобождать» — это не про забыть, а про то, что попадает в горячий индекс: decay/вытеснение мы применяем к частому классу и никогда — к редко-ценному. Он живёт отдельным механизмом: изолированный причинный обход + повторные грабли (revert 39 раз, xsrf 60) подмешиваются первым блоком в каждый recall.
То есть, не «из крайности в крайность», а две разные политики для двух классов памяти. Крайность как раз «сложить всё в один индекс и надеяться, что редкое само всплывёт» — именно это даёт 38% вместо 87%.
Бенчмарк в статье есть, он под спойлером «Как мы намерили 87%». Чего в первой статье нет — замеров latency и сравнения с pgvector: это будет третья статья, про HNSW руками.
Мусор можно отфильтровать, с этим проблем нет, а вот проплаченную выдачу не получится. Выдача Яндекса делает всё более незаметной выдачу по контекстной рекламе, и от этого рекламного мусора не избавиться никак: он выходит первым, выпукло выставляет преимущества рекламодателя и провоцирует кликнуть именно его. Окно ИИ-агента небольшое, и пока непонятно, насколько сложно будет бороться с рекламным мусором там, и вот промптом его вряд ли устранить. Во всяком случае, это будет не для масс, как, например, ad-блокеры.
Поймал себя на мысли спросить в чате с ИИ, удержался. Пока не могу представить, какие испытания пройдет такой прекрасный инструмент поиска. Вроде он должен оставаться беспристрастным, просто будет обвешан контекстной мишурой и спонсорскими предложениями.
3) Точность прогноза на массиве 50 000 SKU какая? Там где запрос или токенизация настроены под конкретный продукт - получается 6-8 верных кандидатов из 10, первый (верхний по весу) как правило походит точно.
2) Может ли обычный менеджер по закупкам повторить эту процедуру без sql-запросов и какую информацию подготовить? Тот менеджер, на ком мы пробовали, смог повторить. У него каталоги нескольких типов товаров и он получает приемлемый результат даже не пользуясь конструктором запросов - работает как дали, без оптимизаций. Но он совмещает - сопоставляет шорт-лист через ВПР() в экселе. Сейчас мы его обучаем как самостоятельно делать тонкую настройку, это примерно уровень формул экселя, непривычно, но вполне постижимо.
Приветствую! 1) Сколько на эту операцию у вас потребуется токенов/затрат? Токены все были бесплатные, потому что регулярку написать и простое рабочее место - это бесплатный Дипсик может или Клод в рамках бесплатного лимита. Затраты только на инфраструктуру - хостинг с БД, для описанного здесь примера мы обошлись только одним конструктором.
Меряем своё решение против плоского baseline на одном корпусе: 38 -> 87%. С mem0/Zep пока не мерялись, но всё впереди, спасибо
Спасибо! Тут ещё продолжение будет, не переключайтесь
Да, про абляции: они есть — и половина наших решений их не пережила: важность в ранге проиграла (0.41 против 0.81 у чистого косинуса) всеми четырьмя способами подмешивания, RRF оказался худшим (0.06), так что важность мы из ранга выкинули, а PPR оставили опцией.
Как делать выбор — никак, это про наш корпус. Прогнали, получили своё число. На чужом репозитории ydb-platform/ydb, 293 пары: 32.1% против 94.5% — то есть мы проверяем не значение, а разрыв.
Мы не соревнуемся — это A/B одного компонента (тот же корпус, энкодер, запросы, top-k; меняется только «ходим по рёбрам Closes #N или нет»).
Прямо сейчас провели исследование на открытом репозитории YDB (Yandex Database) — ydb-platform/ydb — результаты публикуем без ретуши как обновление к этой заметке, также потом сделаем отдельную статью, потому что тема очень интересная.
Да, один корпус, и универсальной теоремы мы не заявляем. Переносится не число, а процедура: "не гадать порог абсолютного косинуса, ранжировать top-k, мерить на своих данных". Именно потому, что число поехало — между синтетикой и реальностью, и поедет между корпусами. Механизм не экзотичен: мультиязычные энкодеры (MiniLM-семейство) держат косинус в узком высоком диапазоне, из-за чего облака "соседи" и "случайные" перекрываются.
Мы не прогоняли десяток моделей — это субъективная граница замера. Но безопасный вывод "ранжируй, а не ставь пороги" от модели не зависит.
Ключевой момент, и фичу мы выкинули не потому, что важность бесполезна. Провалился не один линейный бленд — проиграли чистому косинусу все четыре способа смешать сигнал (сумма, гейт, RRF, PPR) на реальных парах "запрос - ответ".
Причина глубже калибровки: знак пользы важности зависит от интента запроса — на хабовых запросах важность помогает (на синтетическом графе вытаскивает MRR с 0.033 до 1.0), на запросах про конкретный редкий факт — топит его (0.81 -> 0.41). Любой статический вес поэтому неверен по форме.
Правильное лекарство — вес, зависящий от запроса/обратной связи; это осознанный план действий, а не тупик. PPR оставлен опцией, из дефолтного ранга важность убрана.
Точность рёбер отдельно не считали - тут пока пробел; но +49 п.п. меряется на held-out gold-парах, а ложное ребро уводит обход и recall занижает, а не раздувает, то есть выход на 87% скорее пол для чистого набора рёбер. Точность рёбер добавим отдельной цифрой.
Знакомо, да, боль - опозориться перед клиентом хуже любого бага. Мы начинали так же, с md и правил. Спасибо, отличный кейс.
Дорого не хранение — диск копеечный, мы ничего не удаляем.
Дорого извлечение: в контекст уходит фиксированный top-k, и каждый лишний почти-дубликат занимает слот, который стоил бы нужному факту. Отсюда третий закон статьи: частый плотный сигнал топит редкий, но ценный (популярный узел топит точный факт, хабы зарывают specific, плотные similar_to глушат редкие caused_by). Поэтому «освобождать» — это не про забыть, а про то, что попадает в горячий индекс: decay/вытеснение мы применяем к частому классу и никогда — к редко-ценному. Он живёт отдельным механизмом: изолированный причинный обход + повторные грабли (revert 39 раз, xsrf 60) подмешиваются первым блоком в каждый recall.
То есть, не «из крайности в крайность», а две разные политики для двух классов памяти. Крайность как раз «сложить всё в один индекс и надеяться, что редкое само всплывёт» — именно это даёт 38% вместо 87%.
Бенчмарк в статье есть, он под спойлером «Как мы намерили 87%».
Чего в первой статье нет — замеров latency и сравнения с pgvector: это будет третья статья, про HNSW руками.
Точно. А горизонт настоящего включается только когда recall-пинок принудительный и попадает в момент решения
Потом появятся GEO-директологи и прочие «профессионалы», наверное. В общем, заметку написал про это — наслаждаемся чистыми ответами, это ненадолго :-)
Мусор можно отфильтровать, с этим проблем нет, а вот проплаченную выдачу не получится. Выдача Яндекса делает всё более незаметной выдачу по контекстной рекламе, и от этого рекламного мусора не избавиться никак: он выходит первым, выпукло выставляет преимущества рекламодателя и провоцирует кликнуть именно его. Окно ИИ-агента небольшое, и пока непонятно, насколько сложно будет бороться с рекламным мусором там, и вот промптом его вряд ли устранить. Во всяком случае, это будет не для масс, как, например, ad-блокеры.
Поймал себя на мысли спросить в чате с ИИ, удержался.
Пока не могу представить, какие испытания пройдет такой прекрасный инструмент поиска. Вроде он должен оставаться беспристрастным, просто будет обвешан контекстной мишурой и спонсорскими предложениями.
Кстати, у этой статьи есть видео-версия https://rutube.ru/video/52f8842c8ffb60af77ed89c2776c36c4/
3) Точность прогноза на массиве 50 000 SKU какая?
Там где запрос или токенизация настроены под конкретный продукт - получается 6-8 верных кандидатов из 10, первый (верхний по весу) как правило походит точно.
2) Может ли обычный менеджер по закупкам повторить эту процедуру без sql-запросов и какую информацию подготовить?
Тот менеджер, на ком мы пробовали, смог повторить. У него каталоги нескольких типов товаров и он получает приемлемый результат даже не пользуясь конструктором запросов - работает как дали, без оптимизаций. Но он совмещает - сопоставляет шорт-лист через ВПР() в экселе.
Сейчас мы его обучаем как самостоятельно делать тонкую настройку, это примерно уровень формул экселя, непривычно, но вполне постижимо.
Приветствую!
1) Сколько на эту операцию у вас потребуется токенов/затрат?
Токены все были бесплатные, потому что регулярку написать и простое рабочее место - это бесплатный Дипсик может или Клод в рамках бесплатного лимита.
Затраты только на инфраструктуру - хостинг с БД, для описанного здесь примера мы обошлись только одним конструктором.
Кстати, вот есть на эту тему заметка, решается задача сопоставления каталогов:
https://habr.com/ru/articles/1055368/