0: Всем привет. Меня зовут Толя. Я в т отвечаю за фундаментальные технологии ллм. Год назад со сцены турбо Эмеля. Я рассказывал, как мы готовим свои фундаментальные модели. Во
1: Сильного опенсорса. Сегодня я расскажу про очередную нашу опенсорс модель в этот раз другого, немножко другого рода. Я расскажу про тесеч. Наш открытый агент ретривер для многошагового поиска.
2: На самом деле это уже 5 наш открытый релиз. Мы выходим с релизом примерно каждые полгода, и каждый наш релиз обычно посвящён решению актуальных на тот момент проблем, как докру.
3: Mie для того, чтобы можно было делать классные продукты, так, на нашем 1 релизе мы обкатали наш рецепт и вообще до обучения.
4: Для того чтобы решать проблемы с русским языком. Дальше мы сфокусировались на приросте в качество, в проминг, задачах и способности решать разнообразные задачи. После этого был наш релист про 2 0 где мы
5: Работали с гибридным ризонингом и ускорили генерацию с помощью спекулятивного декодинга. И дальше в декабре 25 года мы зарелизили нашу линейку 2 1 с улучшенным следованием инструкциям и улучшенным.
6: Кино и агентностью. А что же актуально сейчас, на момент лета 26 года? На самом деле открытые модели стали настолько хорошими, что имея достаточно
7: Совершенный контекст, они могут решать очень сложные агентские бизнесовые задачи, но проблема начинает смещаться в сторону того, как этот контекст собрать. Давайте посмотрим на вопрос на слайде.
8: Такого типа вопросы, в принципе, нельзя решать обычными рак системами, потому что их невозможно решить в 1 ход. Никакая рак система вам на этот вопрос сразу в 1 заход ответить не сможет. Просто потому, что для того, чтобы
9: Найти ответ на этот вопрос. Нужно сначала понять, что речь шла о горьковском автозаводе, потом связать его с тем, что, ну, наверное, это было в городе горький, и отдельно отдельным хопом понять, что этот город на самом деле.
10: Девяностые был переименован назад в Нижний Новгород, и только таким образом прийти к ответу. На самом деле все больше и больше вопросов нерешённых остались как раз те, которые требуют мультихоп, где нужно много.
11: А что-то загуглить, порезание в промежутках и только так прийти к финальному ответу и на самом деле не мы это придумали индустрия последовательно шла к этому дизайну мы начали с roxy.
12: Тем, которые, как я раньше сказал, на самом деле такие сложные вопросы не решают и дальше для того, чтобы как-то их научиться решать, нам пришлось перейти к react, лупам, которые позволят.
13: Погуглить, подумать между и делать это в несколько итераций. И в пределе эта идея превращается в свой, в депрессе подобные системы, но поисковые траектории они на самом деле расходуют довольно много то,
14: И на больших языковых моделях это становится долго и тяжело, и затратно по ресурсам, и дальше возникает довольно очевидная идея сбор контекста, на самом деле концептуально довольно похожий в разных
15: Совых задачах. Давайте разделим наш процесс дип ресерча на отдельный агент ретривер, который собирает контекст. И давайте сделаем его поэффективнее. Давайте обучим какую-то маленькую модель, которая реша
16: Эту задачу быстрее и эффективнее, но на самом деле также хорошо, и генерацию тогда можно отдать любой какой-то другой модели, и при этом существенно сэкономить в эффективности. Мы взяли эту идею, и так родился наша модель тесеч.
17: Агент ретривер, задача которого это в таком дип ресерче, или агентик рак, подобном контексте собирать контекст для вашей задачи это дообученный
18: Основе квен 3, 6, 35, a3 б модель, обученная в специальном нашем scaffold и by design, её задача это вернуть ссылки на набор исходных Чанков, и поэтому она не может by design галлюцинировать.
19: После этого эти чанки можно передать в любую другую модель и сынтегрироваться с какой-то вашей последующей бизнесовой задачей. Это работает, так что тесеч может переиспользоваться в разных задачах, а индекс вы можете
20: Принести свой любой индекс документов, векторный бм 25 и все такого рода. И в итоге на выходе мы получаем список Чанков, который можно дальше передать в любую другую.
21: Агентскую модель и использовать их для ваших агентских юзкейсов. Делая эту модель, нам пришлось решать 4 типа вот больших проблем, про которые я как раз и буду рассказывать. 1, это поисковые траектории ли
22: Как не словить context рот и не терять найденное по дороге. 2 для того, чтобы такую модель обучать, нужен конвейер разнообразных и честно сложных поисковых задач и уметь это смасштабировать на относительно небольшой
23: Модели надо придумать, как это эффективно обучать, чтобы выжать максимум из sft стадии и чтобы рель докидывала поверх. Ну и, как всегда, задача, как вообще измерять качество таких задач об этом?
24: Обо всем сейчас дальше расскажу. Начнём с харнесса, с обвязки моделей, и, как показывает практика, на самом деле от харнесса довольно сильно зависит качество агентских
25: Решение агентских задач, поэтому это какая-то важная часть сейчас любого решения в 26 году и 1 из важных проблем тут что поисковые траектории длинные. Возникает проблема контекст трота мы проанали
26: Анализировали, как вообще эту проблему решали разные игроки, и все в принципе сводится к 4 разным иде, к 4 различным идеям суммаризировать периодически контекст, как-то сохранять его в отдельной.
27: Базе знаний, дать модельке самой возможность редактировать свой контекст и также периодически удалять часть или историю целиком. При этом
28: Суммаризировать, ять какой-то ключевой факт. Например, отрицание. И тогда вся цепочка рассуждений сломается, а удаление истории часто приводит к бесполезной потере токенов и потере эффективности на
29: Основе этого мы спроектировали свой харнесс. Он устроен следующим образом. У модельки есть всего 3 инструмента, который она может использовать, поискать по корпусу, сохранить чанки, перейти в новый раунд и
30: И закончить, и отдать отранжированный список финальных Чанков. При этом у нас есть несколько раундов, где внутри раунда у нас обычный реакт луп, а между раундами есть явный перенос не всей истории вызова.
31: А явной структурированной памяти, которая содержит в себе чанки вопроса и цели на следующий раунд. Таким образом, мы одновременно решаем проблему контекс трота за счёт относительно небольшой длины раунда и при этом имеем возможность де
32: Длинную, серч траекторию, выполняя там по пути десятки запросов. Поиск, что интересно, харнесс это штука, которая может помогать модели, но также направлять и дисциплинировать её. Мы
33: В частности, это подсмотрели в клод коде и других похожих харнесса. В частности, у нас харнесс может выдавать сообщения для модели. Ты не можешь, например, или заблокировать какое-то действие, например, или не делай.
34: Так, делай по другому. И моделька на самом деле часто это позволяет модельке часто исправиться и в конечном итоге закончить траекторию успешно. Как мы дисциплинируем модельку. Мы, например, не даём ей
35: Делать слишком мало поисков и сразу сохранять не даём делать, например, одинаковые запросы, явно запрещая ходить в поиск с одинаковыми кверями. Или, например, запрещаем переходить в следующий раунд.
36: Финализировать, когда вопрос был недостаточно покрыт. Это на самом деле довольно сильно позволяет поднять качество и стабильность решения на таких поисковых траекторий. Переходим к следующей части, что
37: Чтобы такую модель обучать, нам нужна фабрика по производству верифицируемых синтетических данных, и тут возникает класс проблем, что не всегда сложно выглядящий вопрос.
38: Вопрос на самом деле является сложным для модели, и наоборот, нам нужно научиться генерировать какие-то честно сложные для модели запросы, которые решаются, но при этом не решаются в 1 round при.
39: Этом нам таких вопросов нужно много, чтобы собрать обучающие данные. И мы делаем это итеративно, что требует относительно небольшой модели, потому что на большой это станет неподъёмно. Ну, в частности,
40: Сложный на вид вопрос может быть на самом деле отвечаем моделью из весов или отвечаем там в 1 hob или содержать там подсказки все в 1 документе, поэтому нужно честно научиться генерировать вопросы, которые решаются в n Шагов.
41: Как мы собираем такие сложные вопросы? На самом деле не только на уровне, просто дать модельке промт сгенерировать. Мы готовим для неё подграф Чанков, которые связаны
42: Какими-то нишевыми сущностями, что позволяет не ходить по всему индексу, а сразу из небольшого количества контекста генерировать правильный вопрос. Мы перефразируем факты до того, как подавать в генератор, чтобы это тоже сразу не
43: Готовым поисковым запросом. И также мы итеративно, пошагово усложняем каждый раз свой запрос и на каждом этапе проверяем их решаемость. Как это выглядит? Это выглядит как такая сущность композитор.
44: Разнообразность которого обеспечивается таксономией вопросов. Также ему на вход подаются вот эти как раз подграфы для генерации сложных запросов и дальше происходит итеративный состязательный цикл проверок. Зачем нужны проверки.
45: Проверки нужны, чтобы отсекать какие-то на самом деле неправильные вопросы, то есть
46: Что, например, этот вопрос не решается каким-то достаточно совершенным агентом слишком легко или что он действительно решается по опорным чанкам, что
47: Чанков неизбыточное количество, при этом проверки итеративно, с нарастающей сложностью. И если вопрос не проходит проверку, он возвращается назад композитору на доработку и таким образом, вот в состязатель
48: Интерактивном цикле улучшений в итоге получаются какие-то готовые поисковые синтетические вопросы, которые дальше уходят в базу для того, чтобы их там дальше ребалансировать для обучения. Что в итоге
49: У нас получилось, у нас получилась фабрика синтетических верифицируемых поисковых задач, которая позволяет генерировать данные для сфт и для эрэль стадии. При этом мы используем одинаковое распре.
50: Деление, но разные затравки для сфт и для эрль стадии. У нас 2 независимых процесса генерации русских и английских вопросов. То есть мы не используем их переводы, а генерируем н.
51: Зависимо русскую, английскую часть нашего датасета. Дальше переходим к обучению. Обучение у нас состоит из 2 стадий сфти эрэль.
52: На sft стадии в итоге, итеративно обучая модели, смотря что у нас получается, мы пришли к 5 ключевым идеям, которые нам позволили делать sft хорошо единица.
53: Обучение это у нас 1 раунд, мы маскируем под пинки от харнесса и не считаем по ним лос.
54: Мы убираем из обучения холостые раунды, которые не добавили ни 1 нового чанка. Мы ребалансирует траектории, чтобы они были не слишком простые, не слишком сложные, потому что это как раз то самое, на чем моделька хорошо учится, и мы
55: Ратифицируем наш сфти микс по нескольким осям, по числу раундов, по способам завершения, по полноте чанка, механике вопросов и так далее. Вот таким образом мы получаем в итоге сеттинг нашего sft обучения.
56: Переходим дальше к релю и вот тут как раз
57: Почему? Мне очень нравится эта стадия? Потому что как раз вот эта фабрика синтетических поисковых кверей производит честно верифицируемые примеры, на которых можно заводить верифай. Эрель у нас есть
58: Набор минимально необходимых золотых Чанков, которые нужно найти на запросы. Дальше мы можем, поэтому честно считать награду. Мы в итоге остановились на реколле.
59: Поскольку для нас приоритетно реально решать сложные задачи, а когда мы пробовали использовать пресижен или ф. 1, моделька в итоге была склонна слишком рано финализировать и отвечала хорошо только на более простые вопросы, и также мы сравнивали
60: Разные методы. И в итоге гспо у нас заработал лучше, чем грпо. Оказалось, что для мешек действительно лучше получается.
61: Перейдём к бэнчмаркам, когда мы думали, как вообще валидировать такие задачи, как сделать это устойчивым и как проверить, что наша моделька действительно будет генерализироваться и
62: Работать в каком-то широком диапазоне. Мы посмотрели, какие банчмарки вообще существуют, и нам было важно, чтобы
63: Чтобы замеры были детерминированными, на самом деле большинство бенчей типа брауз комп, они ходят в настоящий интернет, а интернет меняется во времени, поэтому нам нужны были бэнчмарки с фиксированным поисковым индексом, и таких оказалось недостаточно.
64: Довольно мало, но мы взяли их и попробовали их аккуратно перевести на русский, при этом сохраняя связку фактов, валидируя и все остальное, но мы выяснили, что на таких переведённых бэнчмарках модели
65: На самом деле продолжают формировать 60 80% запросов на английском, а не на русском, хотя и benchmark, и индекс переведён, мы все перепроверили, все работает хорошо. В итоге мы пришли к выводу, что в рунете необходимы
66: Нативные русскоязычные поисковые банчмарки и переводы у нас обойтись нам не получится вот. И в итоге так мы собрали траст наш 1 бенчмарк агентского поиска на русском.
67: В нём 324 вопроса, мы собирали их с нуля пятнадцатью аи тренерами валидировали агентом на gpt 5 точка 4 в разных режимах.
68: Майнили хард негативы методология очень похожа на browse ком плюс с фиксированным индексом, при этом на распределение тематик и типов задач можете посмотреть на картинке вот как раз пример с городом горьким и с заводом.
69: Это хороший пример, как раз темпорал трекинга и
70: И мультихоп. Вопросы. Как раз вот хороший пример вопроса. Из такого бенчмарка. Также мы собрали 2 бэнчмарк, назвали его синт комп, он синтетический, то есть его произвела вот как раз та самая фабри.
71: Которая производила данные для обучения, мы дедуплицировать довольно хорошо мин хэшем со всеми обучающими данными. Тут 2 версии. Русская, английская на 395 вопросов. Он самый на самом деле, вы
72: Длительно затратный в среднем. Для того, чтобы решить вопрос, из него нужно порядка 100 поисковых Хопов там против 40, там в brows комп подобных бэнчмарках, то есть там реально сложные синтетические запросы, они не
73: Структурировано. Сейчас вот на слайде пример вопроса из такого бенчмарка и как оно в целом работает, двигаемся дальше. Что у нас в итоге получилось? Мы замерили.
74: Большое количество опенсорс моделей и также нашу модель, те. Серч в 2 версиях en равно 1. Это когда мы запускаем 1 поисковую траекторию, и н 3 с 3 параллельными субагентами, где мы дальше
75: Агрегируем их выдачу через ррф. Что мы видим? Мы видим, что в среднем базовая модель имеет на таком индексе 41 с половиной процентных пунктов.
76: Наша модель 55 и 61 в режиме 3 параллельных субагентов. И мы на этой задаче. Понятно, это не general модель, это специализированная модель. Агентик для агентик рага. Мы обходим
77: Существенно больше их по размеру опенсорсных конкурентов. Дальше, если посмотреть на эту эффективность в разрезе эффективности. Вот тут есть график, где по горизонтальной оси у нас
78: Время работы, оно же летенси, а по вертикальной оси у нас агрегированное качество по индексу бенчмарков. Вот здесь видно, что мы существенно эффективнее, чем базовая модель.
79: И что вот этот параллелизм, где можно запустить 3 параллельных субагента, оно в принципе даёт очень понятный размен эффективности на качество работы, когда мы замерили этот график,
80: Сразу возникла интересная, интересный вопрос, а почему бы нам не замерить тут какие-нибудь проприетарные модельки? Потому что, ну, мы довольно сильно выше, чем тот же глм.
81: 5 1. Но потом мы посчитали, сколько это будет стоить. И, в общем, нарисовать 1 фронтир на этом графике будет стоить примерно 30, 40 000 $. И мы решили, как бы это в итоге не делать. Хотя есть ощущение, что в
82: В целом на узкой задаче тоже будет неплохо выглядеть даже по сравнению с проприетарными модельками.
83: Да, устойчивость к ретриверам. В принципе, мы добавляли в наш сфти микс какое-то количество траекторий с разными ретриверами. Обучались мы в основном на queen 3, эмбеддинг 8 б, но мы проверили, что
84: В целом моделька хорошо работает и с другими эмбедерам, включая энграммы, так что, в принципе её можно использовать с разными эмбедерам в продакшене, и метрики действительно оказываются устойчивыми. Ну и
85: Если подытожить, вчера мы выложили это все в опенсорс. Мы выложили нашу модель. Те серч, мы выложили харнесс для неё, и мы выложили те банчмарки, которые мы собирали с нуля траст синт комп.
86: И так далее. Вот в этот раз мы решили не делать дженерал релиз и сделали специализированную модель для агентик рага. Ну, приглашаем вас попробовать. Кстати, харнесс можно использовать и просто с опенсорсными моделями.
87: Не только с нашей моделью, те. Серч. Попробуйте. Вполне возможно, у вас есть агентские кейсы, где вы можете сэкономить на футпринте или на времени работы, а также, может быть, банчмарки вам помогут в ваших каких-то внутренних Валах.
88: Спасибо. Ну а теперь вопросы. Самое главное, мы дарим подарки за самые лучшие вопросы, и Толя сможет выбрать, что ему понравилось больше.
89: Всего из того, что вы спросите, поэтому не стесняйтесь, давайте общаться. У нас есть ещё достаточно большое количество времени, чтобы поболтать с Толей.
90: Да. О, привет. Ты упомянул, что вы не даёте модели. Ну, вы запрещаете модели слишком рано отвечать на вопрос, когда запрос ещё не слишком хорошо покрыт. Как вы определяете, что вот уже достаточно и можно finale.
91: А там было как раз история, что она, мы требуем базово, чтобы она не меньше 5 этих сделала.
92: А если то, ну, у модельки есть внутренняя калибровка, она, в принципе, может сама решить, когда ей остановиться. У неё есть возможность финализировать. Мы не даём финализировать совсем рано.
93: Мы считаем, что есть какое-то минимальное количество поисков, которое нужно для реального мультихоп вопроса, типа, если больше, то дальше это её там внутренняя калибровка, она сама решает, когда уже можно остановиться в целом.
94: Сейчас у меня вопрос, как она работает на простых вопросах. То есть вы её готовили для сложных вопросов, а что с самыми простыми вопросами? Ну, наверное, это
95: Модель действительно для ситуаций, когда вам в продукте реально нужен мультихоп и реально нужен какой-то какая то сложная история. Если у вас часть вопросов в вашем распределении, это какие-то вопросы, для которых достаточно рага, там, наверное, нужна какая-то маршрутизация и какая
96: Рак система, которая будет там на 1 линии работать условно. Вот у этой модельки, наверное, минимально осмысленный диапазон работы, это там, в районе, там, 1 раунда, то есть там, в районе, там, не знаю, 5, 10, там поход.
97: В поиск. Угу. Ну, то есть обычный рак она не улучшит, условно, да? Ну, то есть я исхожу из того, что по рагу уже придумано. Плюс минус все, в принципе, уже во всех компаниях люди знают, как готовить хороший
98: Систему под свою задачу. Это модель для юзкейсов, которые рак системы не решают бай дизайн. Ну то есть типа просто мы исходим из того, что рак это решённая задача. Уже хорошо. Спасибо.
99: Привет. Спасибо за доклад. Скажи, а есть примеры реального применения уже вот этой модели? Ну, в реальных бизнес кейсах или пока только в теории? У нас есть планы по внедрению в н. Внутренних систем. В частности, мы смотрим на агент
100: В саппорте на нашего оператора Афанасия, который там на 2 линии саппорта, работает также на нашу внутреннюю там rock платформу и всякие поисковые сценарии, на самом деле мы довольно часто релизим.
101: Опенсорс, модельки с колёс. Ну, в частности, мы закончили её учить, наверное, 2 недели назад, поэтому, ну, просто прогресс движется настолько быстро, что если её ещё придерживать пару месяцев на внедрение, это станет совсем неактуально. Спасибо.
102: Привет. Классный доклад позабавил вопрос по поводу горький Нижний Новгород. Имеет ли задача решать какие-то сложные математические задачи? 1 вопрос. И 2 ты говорил про то, что интернет, в общем, сложно. Ну, вашей, нашей поисковой системе.
103: Классные делать, классные ответы, сложные. Вот я был на митапе клауд ру, не говорю про cpp, что это вот нужно оптимизировать, в общем, сайты, и вот что ты думаешь про это, про оптимизацию интернета под для агента.
104: То есть сайт больше для агентов, чем для людей. Спасибо. Я думаю, что это хорошее направление, и в целом все будет в эту сторону двигаться. Если говорить про нашу модель, то мы в 1 очередь рассматривали сценарий агентик рак, где индекс так или иначе локальный.
105: Развёртывание модельки так или иначе локальное, но в принципе можно пробовать её, наверное, и с поисковым индексом использовать. Хотя мы её для этого не делали. Мы не знаем, как оно будет работать.
106: Да, привет. Вопрос следующий. А насколько ваше решение устойчиво к неоднозначным или не имеющим ответа вопросам? Потому что в целом депрессе агенты имеют привычку циклиться до бесконечности в таких ситуациях? Да, смотри, ну
107: У нас есть максимальное количество раундов, то есть есть как бы максимальное число раундов 5. То есть есть максимальная длина траектории моделька остановится в любом случае, и она выдаст какой-то в конечном итоге набор Чанков, да, какой
108: То или никакой, поскольку сеттинг этого агента в том, что она выдаёт ссылки на исходные чанки из индекса, не искажая их, то, в принципе, вот эту задачу калибровки. А имеет ли задача ответ на самом деле может решать
109: Более верхнего уровня. Агентская модель, которая эти чанки от неё получит. Ну, то есть, в принципе, эту задачу можно делегировать самому агенту. Да, спасибо.
110: В общем, вопрос касаемо бичмарк. В общем, как я поняла, что датасет, на котором тренировал, обучалась модели и benchmark синтетический, использовалось 1 решение, и как бы нет там вероятности какого-нибудь. Дата ликида.
111: Трус бэнч, мы собирали с нуля асессорами, там 100% не может быть никаких пересечений. Если мы говорим про синтом бэнч, то мы тщательно дедуплицированном числе мин хэшем. Ну то есть, типа, мы сделали все возможное, что там
112: Не было никаких ликов. Ну, как бы это понятно, что сделали все возможное, как-то проверялось. Это кто это гарантия? Да, мы замеряем перформанс нашей модельки по довольно широкому индексу. У нас там суммарно в районе 6 бенчмарков. И мы видим, что с коры
113: На всех бэнчмарках в целом скоррелированы, поэтому, ну, в крайнем случае, у нас есть куча других бэнчмарков, на которых можно убедиться в том же ранжировании в целом. Поняла. Спасибо.
114: Спасибо за доклад. У меня такой вопрос. Вот вы говорили, что вы в реле учили на реколл, то есть на то, чтобы модель искала как можно глубже, как можно дольше не было идеи, например, учить её на Индии, джи или на что-то подобное, чтобы
115: Она останавливалась как можно раньше, когда покрыла уже полностью план вопроса. Мне кажется, это классная идея. У нас сейчас есть идея, например, во внутреннем R&D пойти в сторону эффективности модели, то есть
116: Сейчас мы показываем там, типа, типичное время работы, там в районе минуты или чуть больше, да, а есть, например, какие-то практические сеттинги, где надо получить максимум качества, там за 5, 10, 15 секунд. То есть, типа там с балансом разменивания, типа качества на
117: Скорость работы. Вот мы думаем в это пойти. Сейчас нам было важно показать, что мы умеем там на самые сложные запросы находить ответы, поэтому мы максимизировали рекол. В принципе, если бизнесово задача какая-то другая, в частности, или какой-то временной бюджет какой-то
118: Другой то вполне Разумная идея попробовать. Спасибо большое.
119: Оля, спасибо за доклад. Меня зовут синк. Алексей, расскажи, пожалуйста, подробнее про ту часть, когда вы харнесса блокировали. Ответ как-то, что он недостаточно покрыт.
120: Как вы это определяли? Там сам сама модель в процессе работы выда генерирует это покрытие. То есть харнесс это просто простая бизнес логика, которая это валидирует. То есть на самом деле
121: Эта моделька генерирует бай продактом в процессе работы. В этом харнесс бай дизайн. Я правильно понимаю, что модель должна сгенерировать покрытие ответа, на какую долю ответа она нашла чанки верхнеуровнево? Да, чуть более
122: Низкоуровневая. Сейчас можно будет с командой пообщаться. Спасибо.
123: Привет. Мне вот стало интересно, как работает модель, когда её можно попытаться максимально сильно запутать изначально. То есть цель стоит сделать так, чтобы она ошибилась, то есть использовать какие-то
124: 2 реальных, но совершенно несвязанных факта, какие-то амонимы, какое-то двусмыслие. То есть если прям вот максимально попытаться запутать модель запросом, справится ли она с этим и как
125: Ох, честно, мы не исследовали это поведение. Я точно могу сказать, что мы ограничиваем минимальные ризонинг эффорт и максимальный ризонинг эффорт, да, то есть она в какой-то момент в любом случае остановится, она будет честно пытаться
126: В условиях той квери, которая у неё есть, найти ответ, но её робастность. Ну, в общем, мы не предполагаем, что она работает в каком-то незащищённом сеттинге типа бай дизайн для нас это под агент, который
127: Может вызывать основная модель агент, который дешевле решает задачу сложных поисков. Ну то есть мы не предполагаем, что на неё кто-то будет делат.