#retrieval — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #retrieval, aggregated by home.social.
-
How do you tell whether a fact-checking model got better at numbers or just got luckier with its search results? QuanTemp is a benchmark of 15,514 real numerical claims from 45 fact-checkers, plus a 423,320-snippet evidence corpus, and the best model on it reaches 58.32 macro-F1. But retrieval quality is scored once, as a usefulness rating on 20 claims, so the ranking cannot separate reasoning from retrieval.
-
Which claims are hardest for an automated fact-checker? The 2nd AVeriTeC shared task ran seven systems under open weights, one 23 GB GPU, a minute per claim, and a frozen evidence corpus. Numerical claims came out hardest at 0.16 against 0.36 for position statements, even though the organizers had described the test set's larger numerical share as easier to verify.
-
Честный RAG eval set: как собрать первые 100-300 кейсов и не обмануть себя цифрой
В прошлой статье серии мы сжимали эмбеддинги и замеряли, насколько изменится выдача относительно полного fp32-поиска. Там это был правильный вопрос: ломает ли квантизация уже существующий retrieval . Но у такого замера есть неприятное слепое пятно. Можно аккуратно сохранить 99% выдачи исходного эмбеддера и все равно плохо находить нужные документы на своем домене. Внешний бенчмарк, даже сильный, этого не гарантирует. BEIR как раз был создан, чтобы показать, насколько результаты retrieval меняются между разными задачами и доменами; один усредненный скор там не заменяет проверку на собственных данных. Нужен свой eval set . И тут обычно возникает ложная развилка:
https://habr.com/ru/articles/1070534/
#rag #retrieval #evals #оценка_качества #LLM #эмбеддинги #поиск #MTEB #ragas #BEIR
-
Quizzing Melds Similar Memories, a Nap Holds the Line: EEG Dissects Two Kinds of Consolidation
Follow us and never miss a story.
https://1ban.news/nap-vs-retrieval-training-memory-representations-eeg/
-
Как я ужал русский эмбеддер до 24 млн параметров — и чуть не испортил его одной цифрой
TL;DR. У меня локальный RAG на AMD Strix Halo. Памяти там достаточно, но вычислительно всё упирается в один iGPU: его делят эмбеддер, реранкер и периодическая переиндексация, а в одноузловой конфигурации туда же встаёт генеративная LLM. Поэтому мне понадобился не самый точный retriever вообще, а максимально лёгкий русский retriever, который быстрее завершает первую стадию поиска на том же GPU. Насколько это больно, я в итоге померил на живом узле. На синтетической индексирующей нагрузке полной тяги bge‑m3 снизил generation throughput Qwen3.6-35B-A3B на 92%, STRIZH на 28% при примерно 12,6-кратном темпе индексации (окна замера там неравные, 20,6 против 173,6 секунды, потому что задаются временем пяти генераций; равнооконный прогон RAG‑конвейера ниже даёт по батчам в секунду 9,4-кратный отрыв). В полном RAG‑конвейере с четырьмя пользовательскими потоками и фоновой индексацией STRIZH удержал 14,0 транзакции в минуту против 6,0 у bge‑m3 и индексировал 46 батчей в секунду против 4,9. При фиксированных 200 онлайн‑запросах в секунду генерация проседала на 2% со STRIZH и на 7% с bge‑m3. Оговорка сразу: без фоновой индексации STRIZH преимущества не показал : в этом профиле bge‑m3 оказался немного быстрее, а пропускную способность определяли реранк (0,6–0,7 с на транзакцию), prefill и генерация. Я взял 12-слойный RuModernBERT-small , сначала неудачно попытался повторить пространство большого учителя через MSE, затем обучил retrieval‑донор на контрастивной задаче, выбрал из него четыре слоя [0, 5, 9, 11] и доучил student на русских, английских и смешанных парах с hard negatives от BGE‑M3.
https://habr.com/ru/articles/1064138/
#эмбеддинги #RAG #retrieval #энкодеры #RuModernBERT #STRIZH #llamacpp #GGUF #Vulkan #Strix_Halo
-
От ANN к честному KNN на GPU: как мы пересобрали отбор кандидатов в рекомендациях Ozon
Привет! Мы команда рекомендательной системы Ozon, и сегодня мы хотим рассказать о нашем пути от приближённого поиска соседей (ANN) к точному KNN на GPU. Этот материал для тех, кто работает с рекомендациями, поиском или большими векторными пространствами и задумывается о том, можно ли выжать максимум из железа, не жертвуя качеством. В индустрии уже есть примеры, когда команды рекомендаций уходят от готовых ANN-индексов к более специализированным GPU-решениям скоринга. Мы же опишем, как это выглядит в масштабах российского e-commerce, и расскажем о результатах A/B-тестов. Сразу оговоримся: это не «Hello, world» с парой тысяч векторов, а продакшен на десятки миллионов пользователей и сотни миллионов товаров, где каждый час пайплайна и каждый процент recall имеют цену.
https://habr.com/ru/companies/ozontech/articles/1063304/
#ann #recsys #bigdata #retrieval #knn #spark #pytorch #gpu #рекомендательные_системы #ozon_tech
-
Pruning RAG context down to what the answer actually needs
https://www.kapa.ai/blog/how-we-prune-rag-context
Comments: https://news.ycombinator.com/item?id=48809354
#HackerNews #Pruning #RAG #context #AI #RAG #context #optimization #information #retrieval #machine #learning
-
Сжатие декодерных эмбеддеров: как ужать 8B до продакшена без потери recall
Декодерный эмбеддер 7–8B дает качество, но платит за него памятью, latency и деньгами. Разбираем все оси сжатия - int8, int4, binary + rescoring, PQ, MRL-усечение - на реальных замерах recall@10: где деградация мягкая, а где обрыв. С воспроизводимым кодом и Colab-ноутбуком под Qwen3
https://habr.com/ru/articles/1054930/
#сжатие_эмбеддингов #квантизация #эмбеддинги #embeddings #RAG #Qdrant #Qwen3 #binary_quantization #Matryoshka #retrieval
-
Зачем GenAI-ассистенту platform logic: как управлять источниками, evidence и ответами
GenAI-ассистент может довольно быстро начать отвечать "по теме": находить релевантные фрагменты, собирать уверенный текст и создавать ощущение, что система уже работает. Если подключить LLM к корпоративным документам через RAG, подобрать параметры поиска, немного почистить контекст и добавить хороший prompt, первые результаты часто выглядят обнадеживающе. Пользователи начинают пробовать систему, появляются первые метрики использования, а сама идея быстро кажется готовой к расширению. Но для продуктового контура этого недостаточно. Проблема не только в том, может ли модель сформировать релевантный ответ. Проблема в том, является ли поведение системы ожидаемым, проверяемым и управляемым. Можно получить ассистента, который уверенно отвечает на вопросы, но при этом плохо контролируется в деталях: какие источники он использовал, достаточно ли найденной информации для ответа, можно ли показывать ответ пользователю, где безопаснее остановиться и дать ограниченный ответ (fallback), как проверяется качество, кто управляет ссылками на источники и что происходит при неполных, устаревших или плохо структурированных данных. В этой статье я разбираю не готовый "рецепт правильного GenAI-ассистента", а результаты и выводы из проверки на малом контролируемом прототипе: какие решения появляются вокруг GenAI-системы, когда она должна не просто отвечать, а вести себя управляемо. Фокус будет не на том, как "улучшить prompt" или выбрать модель побольше, а на том, как система управляет ответом после retrieval:
https://habr.com/ru/articles/1050848/
#GenAI #RAG #LLM #AI_Platform #retrieval #evidence #fallback #observability #quality_gates #enterprise_AI
-
Retrieval в 2026: как RAG переехал с энкодеров на LLM (и что с этим делать в своём проекте)
Если вы строили RAG в 2023, ваш стек выглядел плюс-минус одинаково. BERT-семейство (BGE, e5) для семантики, BM25 для буквальных совпадений, cross-encoder для реранкинга, какой-нибудь Qdrant сверху. Этим жили два года, и многие до сих пор так живут. Но если посмотреть, кто реально гоняется в продакшене у команд, которые ушли вперёд, ландшафт другой. Энкодеров там почти нет. Эмбеддит файнтюненная LLM. Реранкер — тоже LLM. Инференс на SGLang, а не на ONNX. И вся обвязка перестроилась под это. Эта статья про то, что поменялось и как переиспользовать этот стек у себя. Особенно если вы работаете в узком домене, где готовых датасетов нет.
https://habr.com/ru/articles/1049872/
#RAG #эмбеддинги #embeddings #retrieval #LLM #Qwen3 #Qdrant #vector_search #hard_negatives #LLM2Vec
-
Evals для чайников. Как тестировать AI-агента, чтобы понимать, где именно он ломается
Большинство команд оценивают производительность AI-агентов через end-to-end метрики: success rate, количество токенов, tool usage, стоимость запроса, долю успешных задач. Это полезно для общего контроля ситуации, но почти бесполезно для реальной диагностики системы. Например, если success rate упал с 85% до 72%, то само по себе число не объясняет причину деградации. Команда вынуждена гадать, какая часть системы вдруг начала допускать ошибки. Сломался retrieval? Модель хуже начала выбирать инструменты? Контекст загрязняется после нескольких ходов? Или система уперлась в возможности base model? При росте проекта и увеличении сложности кодовой базы, сбои начинают расти мультипликативно – ошибки всех систем начинают перемножаться между собой. В конечном итоге, команда теряет реальный контроль. Проблему решает внедрение покомпонентных eval. Они дополняют end-to-end метрики, показывая, какой слой AI-агента работает, какой деградировал – и где именно искать причину. То есть внедрение evals помогает получать метрики производительности каждого компонента вашего агента.
https://habr.com/ru/articles/1042924/
#aiагенты #llm #rag #evals #orchestration #retrieval #tool_calling #context_engineering #production #ai_infrastructure