Transcription
У нас следующий спикер — это Виталий Трикеншу с её Beats.do, Dataanomic Pro, эксперт в области аналитики данных и AI для госзакупок. Свою первую нейронную сеть Виталий написал ещё в 2003 году, а сегодня его проекты получают международные награды и помогают находить риски в закупках с экономическим эффектом более 600 млн долларов.
>> Спасибо большое. У меня в подписи две компании: это Dataanomic Pro и Bits.do. Datanomic Pro — основная моя компания, которая занимается внедрением аналитического софта. Мы делаем аналитические системы, в том числе для госзакупок. Госзакупки вообще моя любимая предметная область. Я ей где-то лет 15 занимаюсь. Руководил проектами, компаниями, командами. А и мы помогали заказчикам закупать дешевле, экономить бюджет. Мы помогали контролирующим органам, а, выявлять экономические коррупционные риски и устранять их в закупках. Но объективно мы делали мало для поставщиков, тех, кто участвует в тендерах, находятся с другой стороны портала госзакупок. И вот это мы решили исправить.
И с моим партнёром Александром Полоротовым, он сегодня в зале, а мы решили запустить новый проект для поставщиков. Это ещё один тендерный агрегатор Bits.do. И решили сделать в нестандартном формате. То есть мы с Сашей выделили бюджет и отпачковали меня как соло-пренёра. То есть я полностью вышел из операционки в Dutanomics. Благо, у меня сильная техническая производственная команда и очень крутой партнёр, который позволит это сделать. И вот с января уже 5 месяцев я разрабатываю в одного проект а Bits. Сегодня вам расскажу, а чему я за это время научился.
Для начала надо немножко рассказать, что такое тендерные агрегаторы и как поставщики сейчас участвуют в тендерах. То есть вот представьте, вы поставщик, а хотите участвовать в тендере, выигрывать, поставлять го на госзакупках товары, зарабатывать деньги, вам сначала нужен какой-то тендерный агрегатор. То есть это площадка, которая, а, подключена к разным площадкам госзакупок, которых много, на них есть тендеры, площадка собирает эти тендеры, потому что вы вручную просто не можете на каждую площадку заходить и искать релевантные тендеры. Их слишком много.
И вот вы регистрируетесь в таком тендерном агрегаторе, дальше настраиваете ключевые слова. Предположим, я продаю ноутбуки, соответственно, я настраиваю ключевой слот на ноутбуке, мне начинает сыпаться уведомления и, а, я на эти уведомления реагирую, разгребаю этот inbox, э, смотрю, что там за тендер, читаю техническую спецификацию, принимаю решение участвовать, не участвовать. Вот так выглядит моя day-рутина.
И это всё работает, э, только для ограниченного масштаба. Вот представьте, у вас каталог товаров на 1.000 позиций или 10.000 позиций, например. А теперь попробуйте настроить ключевые слова для 1.000 позиций. Это та ещё задачка. А, а если у вас CEO пришёл и подписал контракт с новым дистрибьютором, вам скинули номенклатуру его прайс на 17.000 позиций, и теперь вот для них обновите ключевые слова, там проще застрелиться. Это первая проблема.
Вторая проблема: вы настроили ключевые слова, и вам теперь тысячи уведомлений приходят, тысячи тендеров. Аа и вам нужно в каждый тендер на ноутбук зайти, скачать техническое задание, техническую спецификацию, а там мелким шрифтом на две страницы технические характеристики, которые хочет заказчик. И вот теперь, а, прочитайте это всё и найдите в Прайсе подходящие под всем техническим характеристикам ноутбуки. Вот. И вы тратите на это час, чтобы понять, что ничего из прайса моего не подходит. И тендер идёт в мусорку. И таких 99%. Это очень большая проблема. То есть всё, вы тратите очень много времени. Оно масштабируется только наймом таких же специалистов. То есть без иишки это сделать очень сложно.
Соответственно, появилась идея: "А почему бы не доверить ЛМке вычитывать техническую спецификацию, подбирать тендера для меня?" Собственно говоря, вот эту проблему мы и начали решать, собственно говоря. А вот что мне удалось сделать. Э, пример конкретный на экране. Департамент полиции хочет купить пару ноутбуков. У них есть 49 требований, а, технических характеристик этих ноутбуков. И у меня в прайсе, на скрине это не видно, но можете поверить на слово, 17.000 позиций. Там ноутбуки, не ноутбуки, всё подряд. А что сделала система?
Система нашла подходящих 31 товар в моём прайсе. Дальше из этих подходящих она нашла четыре штуки, а, которые маржинальные и которые более-менее подходят по требованиям. Вот мы видим, что там 30, а 34 там требованиям мы соответствуем из 49. И система дала пояснение здесь, то есть вычитала техническую спецификацию. А и более того, она для вас эту техническую спецификацию разложила, сделала таблицу требований и по каждому требованию вынесла свой вердикт. Вот этот ноутбук соответствует или не соответствует. Соответственно, всё, она за меня сделала всю работу. И вот сегодня я расскажу про кишки этой системы, как она устроена под капотом и как это всё происходит.
Ну, давайте на конкретном примере. Этот тендер на ноутбуки, 49 требований, идёт у нас на вход. А также на вход у нас идёт прайс поставщика, 17.000 позиций. А и что мы делаем в пайплайне? В первую очередь запускается ретривер. То есть задача ретривера — сузить эти 17.000 позиций, потому что мы не можем все 17.000 товаров кинуть в ЛМку и сказать: "Ну, найди там". Нет, это не поместится в контекст, не будет работать. Соответственно, мы ретривером сужаем гибридным поиском до наиболее релевантных товаров, которые могут нам подойти. Здесь мы фокусируемся на широте охвата, на метрике Recall, то есть там большинство этих товаров не подходит, этот мусор, но ничего страшного. Главное, чтобы нужный ноутбук хотя бы один там был. А это задача ретривера, то есть он быстрый, дешёвый, аа и генерирует нам вот 30 кандидатов.
А дальше уже вступает в силу реранкер. То есть как реранкер я использую ЛМ. Я просто подаю эти 31 товар вместе с требованием тендера ЛМке и говорю: "А вот теперь детально оцени, что подходит, что не подходит". И ЛМка даёт свои вердикты: подходит, не подходит, частично подходит, нужно проверить. А и на выходе у меня есть три конкретные рекомендации. Вот есть три товара, которые подходят. Пожалуйста, а рассмотри их для подачи на тендер. Так работает пайплайн end-to-end.
И как теперь это устроено технически? Давайте мы начнём с а ретривера. Ретривер используется классика — это гибридный поиск. Гибридный поиск — это полнотекстовый поиск плюс семантика. Ну, начнём с полнотекстового. Это алгоритм BM25. То есть, что такое BM25? Это вариация алгоритма TF-IDF. Ну, на максималках, кто знает, она используется в поисковиках. А, то есть её алгоритм очень простой. Она смотрит по ключевым словам, есть ли совпадение. Поэтому, если вот у вас есть два примера, в одном есть совпадение, пересечения ключевых слов, она отработает хорошо. А если там будут синонимы, абстрактное описание, парафразы, аббревиатуры, то оно будет работать плохо.
А, соответственно, BM25 у нас идеален для того, чтобы находить артикулы, модели, бренды, но он плохо работает с синонимами. Например, экран или монитор. Для него это разные вещи. А, и вот вот эту слабую сторону BM25 закрывает векторный поиск. Тоже классика. Что делает векторный поиск? Он понимает семантику. То есть он, во-первых, каждый текстовый документ превращает в число. Это число он, а, размечает в каком-то семантическом пространстве многомерном. Так что близкие по смыслу товары группируются вместе. Ну, вот, например, зелёный кластер, но всякие экраны, мониторы, дисплеи у нас находятся вместе. И что это нам даёт? Мы, значит, просто простым поиском ближайших соседей можем находить релевантные соседние товары. Таким образом, а у нас вот этот вот векторный поиск а не использует ключевые слова, но понимает смысл и понимает экраны, мониторы, дисплеи и так далее. Ну вот ключевые слова он наоборот плохо находит, соответственно, это его слабая сторона.
А комбинируя эти два подхода, мы получаем сильные стороны обоих подходов и слабые стороны нивелируются. Всё просто, классика. Там деталей не буду расписывать. GPT вам а про это всё расскажет, если кто не знал. Ну, в целом так устроены все RAG. Ничего нового. А единственный вопрос — это как это теперь вот два результата вот этих поиска объединять.
Ну, здесь тоже классика — это RRF. Что такое RRF? RRF — это аэ функция слияния рангов. Что она делает? Очень просто. Вот у нас есть два списка, а, который нам BM25 дал, и список, который нам векторный поиск дал. Соответственно, она эти два списка объединяет вместе. То есть, если товар, а, находится высоко в первом списке и высоко во втором списке, он будет в топе у нас итогового списка. Эта формула поощряет консенсус, её не нужно обучать. Простая, лёгкая, а, собственно говоря, опять GPT вам расскажет лучше.
Но в чём проблема здесь, с которой я столкнулся? А на первой когорте тестовых пользователей, 10 штук, у меня расходы выросли на токены до 1.000 долларов в день. Почему? Потому что вот у меня есть 3 млн лотов госзакупок, которые публикуются в год. И я хочу, чтобы у меня было 1.000 поставщиков и и больше. И ретривером я отбираю там в среднем, предположим, 25 товаров на каждого поставщика в прайсе. Это даёт мне уже 75 млрд пар, которые нужно оценить. И если я всё это буду делать по парным сравнениям, то я потрачу 19 млн долларов на токены в год. То есть абсолютно неприемлемо. Соответственно, надо с этим что-то делать.
Что я сделал? Ну, возникла простая идея. А если у меня поставщик поставляет металлопрокат, то зачем я показываю ему этот тендер с ноутбуками? То есть я для тендера ноутбуки лезу в прайс поставщика ретривер и находит на 25 наиболее подходящих арматур. Вот это можно, конечно, сделать, но к чему это приведёт? Я потом кину это в реранкер, мне ЛМка скажет, что я сошёл с ума, и я просто потрачу зря вот эти токены. А, соответственно, появилась идея: а давайте мы перед тем, как запускать вот этот ретривер, проверим, а есть вообще в прайсе у поставщика ноутбуки или нет. Если нет, то мы просто, ну, будем этот лот игнорировать.
Вот, соответственно, добавился ещё один этап — это пересечение по категориям, и это позволило в 100 раз сократить расходы. И теперь расходы у нас стали, а, там, 190.000 долларов в год. О'кей, дорого всё ещё, но жить с этим как-то можно. А что я сделал ещё? Я перешёл, а, заменил кросс-энкодер, который у меня был, который я пытался обучать. Работало это, кстати, плохо. А, на ЛМку с listwise-ранкером. То есть я просто все запросы объединил в один. Все 25 товаров начал подавать и ЛМке в один контекст. И это в шесть раз ещё сократило расходы. Примерно вот расчётные до 30.000 долларов в год на 1.000 пользователей. Это уже, это уже норм. Вот. То есть в 160 раз получилось таким механизмом, категориальная фильтрация и аливангом LM, сократить расходы.
А, соответственно, в пайплайне ретривера у меня добавился ещё один этап. Это фильтр струru. Казалось бы, ну, всё просто. А, но тут возникла другая проблема. А вот у вас есть задачка: у вас есть прайс поставщика на входе, 17.000 товаров, и вам для каждого нужно проставить код из справочника. Поставщика я не могу этим грузить, потому что это застрелиться опять с 17.000 позиций искать вручную коды. Нужен какой-то классификатор. Казалось бы, классификатор — стандартная задача, а все это решают. Вот надо просто обучить модель. Но не тут-то было.
А сюрприз первый в том, что на масштабе 35.000 классов классические ML-алгоритмы не работают. Всё, у вас просто вы не можете дообучить никакой XG Boost, CatBoost или прочие там Random Forests. Вот они просто созданы для малого количества классов. Дальше у них пропорционально квадрату растут требования к ресурсам. Всё, обучение никогда не закончится. А что делают, рекомендуют GPT и что рекомендуют, э, в литературе, в паперах по Extreme classification, это прямо отдельная отрасль, а, обучать всякие трансформеры, берты, обучать специализированные модели, типа Parabel. Я всё это пробовал, работает. У меня сработало это плохо. И я пришёл, а к другой парадигме. Это опять retrieve-and-rank подход, а, который у меня сработал хорошо. Вот им я хочу поделиться, потому что всё, что я говорил до этого, вам GPT расскажут точно так же, а вот вот это почему-то нет ни в литературе, ни в Ютубе, а ни в GPT.
А что сработало? То есть идея простая. А давайте мы возьмём вот этот справочник, а и по нему будем гибридным поиском искать кандидаты. Ну, топ, а, 30 подходящих кодов, а затем, а, реранкером выбирать, э, наиболее подходящие. Ну, простая идея. А, ну, если кто-то подумал, что можно в ЛМку весь справочник закинуть, нет, нельзя. Он в контекст просто, ну, не поместится. ЛМки здесь тоже не работают. Они вам просто галлюцинируют коды и всё. А я начал обогащать справочник струru для того, чтобы ретривер и реранкер у меня хорошо работали. И вот вот это а идеи, которые сработали.
Что такое обогащение? Давайте расскажу на примере. Вот у вас есть какой-то ноутбук. Для него нужно, а, подобрать код. Вот есть код "ноутбук среднего класса". И первое, а что я начал, я а запустил реранкер и посмотрел, с чем этот класс в основном путается. И это я назвал семантические соседи. То есть вот ноутбук среднего класса. Часто путаю с ноутбуком бюджетным, с мультимедийным, с бизнес-ноутбуком и так далее. Это всё разные коды, и надо выбрать правильные. Тут человек-то не сможет выбрать. Вот чем отличается бизнес-ноутбук от мультимедийного, я, например, не знаю. А, соответственно, человек не знает, а ЛМка откуда знает? Или ранкер. А, о'кей, я сделал вот этот саматические соседи. У меня получилось confusion set.
Как я это использую? Дальше я закинул этот confusion set в ЛМку и сказал: "А сделай мне, пожалуйста, описание для, сгенерируй описание для каждого, а кода и настрой всего 35.000, то есть 35.000 описаний с учётом семантических соседей". То есть что это за товар и чем он отличается от его соседей? Всё, ЛМка сгенерировала это описание. Это позволило а улучшить гибридный поиск по этим кодам. А что я дальше сделал? А теперь сгенерируй, пожалуйста, 30 ключевых слов опять. А с учётом семантических соседей, это тоже позволило улучшить рекол, улучшить поиск. А это всё с ЛМкой вообще без данных.
Но у меня ведь есть ещё и датасет очень большой по госзакупкам, а, и товарам. Что я сделал? Аэ, я закинул, обработал примерно миллион текспек и вытащил оттуда ключевые атрибуты, их значения. А, то есть, например, что чаще всего встречается, а, в требованиях техспек заказчиков на ноутбук, бюджетный или мультимедийный или бизнес-ноутбук, и вытащил эти атрибуты и их значения. Дальше, а, ну, у меня ведь есть теперь атрибуты и значения. Я ведь могу, а, разработать позитивные дискриминаторы. Что это такое? Это какие-то ключевые слова или фразы, которые встречаются в этом коде, в "ноутбук мультимедиа", но не встречаются в других, в его соседях. Например, в "ноутбук Мультимедиа", скорее всего, будет видеокарта, да, а какая-нибудь игровая, а в других она встречается, это требование редко. Соответственно, получились позитивные дискриминаторы. Ну и таким же макаром получились негативные дискриминаторы. А какие ключевые слова, если встречаются, то это точное указание, что это не этот код. Например, если встретилась а у нас видеокарта, значит, скорее всего, это точно не бюджетный ноутбук.
Вот таким образом у меня получился вот такой датасет, который я, а, закинул в векторную базу и в VODB, а, и по нему сделал гибридный поиск. Что из этого сработало на метриках? Отлично показали себя атрибуты, значения, синонимы из текспек. Там дали очень хороший прирост метрик, хорошо показали себя. А ЛМкой сгенерированное описание тоже дали хороший прирост метрик. Семантические соседи — классная идея была. Ну и позитивные, негативные дискриминаторы и другие, э, разные идеи дали какой-то буст, но не супер, а, ну, но но хоть что-то. О'кей. И в общем, это позволило добиться вот таких метрик классификации. То есть 85 на микро, 72 на макро.
А, и это неплохо. Почему? Потому что, когда я обучал модели, тот же Берт или а другие модели, у меня был, а, микро-метрика хорошая, 80%, а макро-метрика 41. И поднять я её не мог. Почему я не мог её поднять? Потому что просто нет данных для обучения. У вас выборка несбалансированная. Ну, то есть бумагу А4 закупают чуть больше, чем все, а бумагу Брайля, например, закупает чуть меньше, чем никто. Соответственно, у вас просто нет данных для обучения вот этих редких классов. Поэтому макро-метрика никак не поднималась. И преимущество вот этого подхода, обогащённый классификатор и retrieve-and-rank по нему — это то, что эта штука работает и без обучающих данных, а, и хорошо работает с редкими классами. Это вот то, что можно, а, можно вытащить себе. И она тиражируется на другие классификаторы. То есть за эту неделю я добавил классификатор абсолютно тем же алгоритмом. То есть я написал скилл для агента. Агент по этому скилу а сделал у меня классификатор ОКТру. Метрики стали ещё выше даже по нему, потому что сам классификатор лучше. Вот так. Это вот было про решение автоматической классификации.
А всё, мы закончили с ретривером. Так выглядит у меня ретривер. Дальше мы выбрали кандидатов, отправляем на реранкер. А, ну и реранкер, у меня один слайд. Говорить особо здесь не о чем. Я просто отправляю, э, все требования и всех кандидатов в ЛМку и говорю: "Вынеси свой вердикт по каждому". То есть вот она говорит: "Этот ноутбук подходит, этот ноутбук не подходит". И что важно, она даёт опис, а, обоснование, почему он подходит или не подходит. А для поставщиков это оказалось суперважно, потому что они не доверяют чёрным ящикам и моделям, и каким-то абстрактным скорам. Вот. Ну, плюсы, соответственно, то, что опять listwise у меня LM видит сразу всех кандидатов, и это очень удобно получается. А вам не нужно ничего обучать, переобучать кросс-энкодеры. А вы можете тюнить для категории прямо in-prompt learning использовать. А и оказалось, самый большой для меня сюрприз, что ЛМка дешевле кросс-энкодера. Почему? Потому что ЛМка один вызов на 25 товаров, а кросс-энкодер хоть моделей меньше в 10 раз, да? А, но 25 попарных вызовов а мне ЛМка обходится дешевле, чем кросс-энкодер свой. Ну, минусы: опять много товаров в контекст я подать не могу, поэтому плюс-минус 30-40 штук.
А, всё, так выглядит пайплайн end-to-end. И над чем я работаю сейчас. Я хочу вообще выключить ЛМку из процесса отсюда. Почему? Потому что это всё ещё дорого. А, и я хочу перейти от сравнения текстов к сравнению данных. Для этого я делаю нормализацию номенклатуры. То есть я тексспеки превращаю в джейсоны и прайсы поставщика тоже превращаю в джейсоны. Для этого я разработал нормализатор. Чтобы его разработать, я вот как раз вот этот 1 млн техпек, который я через ЛМку отработал и вытащил ключевые атрибуты. Это 274.000 свойств для 25.000 категорий товаров. Вот обогатил этот товарными классификаторами, различными товарами, каталогами на 13 млн позиций. И, собственно говоря, теперь у меня ЛМка делает нормализацию, а сравнение уже идёт простыми бизнес-правилами. Это то, к чему я сейчас иду, что я сейчас тестирую. А вот всё у нас состояние на сегодня. Спасибо большое тем, кто выжил.
>> Спасибо большое, Виталий, за такой интересный доклад. А, и я хочу напомнить, что вопрос вы можете задать в Telegram-боте. А у нас уже есть несколько вопросов, поэтому предлагаю сразу перейти туда к ним. И первый вопрос — это у нас: "Какой процент погрешности у системы?"
А процент погрешности у системы классификации я показывал. То есть 85% точность микро, 72% точность макро. Это если говорить классификации. А если говорить погрешность в целом по а тендерам, я её не меряю. Просто почему? Потому что нет датасета, на котором мы можем помериять. И померить это очень сложно, потому что а ключевая для меня метрика — это участие. То есть поставщик подал документы или не подал. Вот, соответственно, если система решила, что этот тендер подходит, и у нас есть релевантный прайс, мы проходим поже, но поставщик не подал, то, ну, как бы стоит это считать за матч или не стоит это считать за матч. Поэтому я фокусирую здесь на бизнес-метрике и метрики меряю то, что я могу помериять, это классификация, но и бизнес-метрику это процент участия и всё.
>> Хорошо, спасибо. Следующий вопрос: "И всё ещё несовершенный. Как вы боретесь с галлюцинациями ЛМк?"
А, супер вопрос. А, двумя, наверное, даже тремя вещами. Первое, а, я не давлю в промте. То есть, знаете, вот это типа "если ты не дашь правильный ответ, котёнок умрёт" там бла-бла-бла. Вот. А если вы начинаете давить, ЛМка галлюционирует. То есть первое, что я прошу, а я прошу ЛМку честно сказать, если нет данных, то я не могу, а то есть отказаться от классификации или отказаться от принятия решения. Это раз. То есть есть вердикт "нет данных" — это первое. Второе. Я прошу ЛМку явным образом оценить свой confidence, свою уверенность по трёхбалльной шкале. Ну, э, сложной шкалой смысла нет делать. Просто уверен, не уверен, вот high, medium, low и всё. А, и вот вот это очень сильно снижает галлюцинации. Ну и дальше это сам контекст, как вы его готовите. А это это очень важно. То есть, если у вас а-а в контексте нет нужных данных, есть вероятность, что его эти данные выдумает. Поэтому в контексте должны быть аа должны быть нужные данные. То есть всё.
>> Спасибо. Очень валидные советы. А и переходим к следующему вопросу. Это у нас: "Вы создали свой агент или подключили модель существующего гиганта через API? И как вы ещё оптимизируете свои процессы помимо рекомендаций возможных товаров?"
А так, давайте несколько вопросов. Первое, а я использую API. У меня там целый ворох моделей для разных задач, разные модельки используются. А свои видеокарты я не использую, просто потому что это очень сложно масштабировать. Вот у меня, а, чтобы обработать миллион техпек, это надо несколько миллиардов токенов запроцессить, соответственно, параллельно. А, и это работает только, если я подключаю API. Никаких там секретных данных нет, поэтому я могу это делать. Это первое. Это тоже было принципиальное решение — использовать фронтир-модели по API. Это, кстати, дешевле выходит, чем свои видеокарты.
А второе, как я свои процессы оптимизирую. Ну, всё у меня делают агенты, деплоят, разрабатывают агенты. А CRM-система, встроенная в э в мой же софт, написанноя агентами. Соответственно, агенты анализируют каталог товаров, которые даёт поставщик, переваривают его в наш формат, загружают, а, анализируют самих поставщиков, которые заявку на сайте оставляют, гуглят данные по ним и так далее. Это то, как я оптимизирую процессы у нас, то есть я как, ну, это для нас эксперимент, то есть я соло-пренёр, поэтому хоть и на фултайм, а как далеко я смогу зайти в одного? На самом деле уже не справляюсь. Уже есть, уже есть потребность как минимум второго человека брать, чтобы один смотрел на вне, другой внутрь компании. Но в целом ставка в оптимизации на ИИ-агентов.
>> Отлично.
>> Хорошо. У следующего участника два вопроса. Виталий, подскажите, пожалуйста, какие бизнес-метрики для оценивания использовали в вашем решении? И второй: "Как вы боролись с дрифтом RAG?"
>> Как? Как я боролся с чем?
>> Дрифт.
>> С дрифтом RAG? А такой глубокий вопрос. А, о'кей. А как я борюсь с дрифтом RAG? У меня настроен то, что называется data flywheel. То есть чем больше поставщиков загружают свои прайсы, чем больше я их классифицирую, обогащаю данных через ЛМку, тем больше у меня появляется данных. Чем больше у меня, а, ошибается система, тем больше у меня данных для обучения появляется. Соответственно, вот эти данные я использую опять для обогащения вот этих классификатов. То, что я показал вот эти идеи, это не один раз я сделал и всё. То есть в каких-то категориях у меня метрики хорошие, в каких-то категориях метрики плохие, но как только поставщик у меня даёт множество товаров, а с категории, где у меня система справляется, например, с классификацией плохо, а что я делаю? Я обогащаю вот этот справочник, ноже новый confusion set, новые атрибуты, э, соответственно, вот то, что я показывал с обогащением, оно заново работает. И теперь у меня эта категория начинает классифицироваться хорошо. Вот. А, и таким образом у меня, а, регулярно идут агенты, меряют, а, вот эти метрики, а, прирост, аа, деградацию я пока не видел, поэтому, ну, вот с дрифтом RAG я, наверное, пока не смогу ответить, как я борюсь, наверное, просто у меня пока ещё я с этой проблемой не столкнулся, но в целом вот так. Да.
И ещё один вопрос — это у нас: "Читает ли модель требования по договорам, так как по цене продукт может проходить, а, но в требованиях может быть 110 дней отстро ой, 180 дней отсрочки, 2 дня на доставку, хотя товар 30 дней производится?" Супер вопрос, да, обязательно читается. То есть там был скриншот с требованиями. У меня, когда модель анализирую к, она требования делит на категории. То есть есть требования к товару, есть требования к доставке, есть требования к гарантии, есть требования к поставщику, есть требования к потенциальному поставщику. Соответственно, а требования к товару мы закрываем из прайсов, а иногда не совсем закрываем. То есть приходится загружать даташиты, гуглить и так далее. Это всё ИИ-агенты делают. А, но требования к поставщику, требования к доставке, вот эти бизнес-система этого ничего не знает, поэтому она просто пишет вопросик: "Прими решение сам". И всё. Ну и, соответственно, есть возможность у человека прямо в прайсе указать, что этот товар производится 30 дней. И тогда модель, да, тогда модель это понимает и говорит, что здесь мы не проходим по срокам.
>> Всё отлично. Спасибо большое за ваши ответы.