Комментарии 11
Что нам нужно?
Импорт больших текстовых файлов с временными рядами и возможность анализа данных, кластеризации и выявления корреляций .
И можно будет сравнить с результатами анализа, выполненного другой большой известной нейросетью . Наверное будет интересно . И главное - реальная практическая польза для анализа инцидентов производительности СУБД.
P.S. И пользуясь случаем - просьба сделать вывод результата без псевдографики , в простом текстовом виде. Для дальнейшего протоколирования и анализа в текстовых редакторах.
Очень классная статья. Огромное спасибо за труд.
Спасибо за статью!
Sglang хорош на time to first token а вот при высокой конкурентности vllm в топе
У меня проквантизацию вопрос.
Для тяжёлых аналитических документов, я на карте 80Gb, без квантизации и галлюцинаций поднимал спокойно Qwen 32B VL, и все стабильно работало. Я думал взять более тяжёлые модели с квантизации 4, и даже разок эксперимент провел, но прироста особого по качеству я не увидел, а вот глюков больше стало при обработке БЗ в 7к+ доков.
У вас квантизации реально принесла толк ? Какого типа информация в доках БЗ ? Есть ли там большое количество сложных матформул на весь А4, порой рукописных и таблиц большой вложенности ?
Qwen 32B VL спокойно поднять можно, но нам был важен throughput по токенам и хороший параллельный инференс на несколько сессий, исходя из ограничений по ресурсам. Собственно здесь и появляется основной tradeoff - качество vs скорость. Уменьшая размер модели, например, до 14B, мы сильно проседали в качестве. Агрессивная квантизация для 32B модели тоже давала сомнительный результат (модель путала языки и легко циклилась). По итогу спасение появилось, откуда не ждали - 80B модель, но с MoE на 3 миллиарда активных параметров. Здесь и понадобилась 4-bit квантизация, но по сравнению с предыдущими моделями серии у нас сохранилось относительно стабильное поведение на тех же tool calls (80B на то и 80B).
Информация у нас преимущественно текстовая с вкраплениями кода и таблиц. Формул мало, больших рукописных таблиц тоже нет. Всё-таки у вас специфика оффлайн OCR рукописного текста - она отличается. Я бы посмотрел в сторону современных OCR последнего поколения, типа paddleOCR-VL, dots.ocr или другие более компактные и специализированные варианты (хороший обзор здесь https://huggingface.co/blog/ocr-open-models). Также у вас, возможно, пригодится fine-tune на ваших данных, для задач OCR он зачастую оправдан.
Спасибо за ответ. Я так понял, что у вас была задача чтобы как можно больше было контекстное окно потому и размер взяли больше ?
В моем случае 32B VL использовалась для конвертации документа. Я проводил эксперимент чтобы 32B с квантизацией 4 запустить на карте в 40Gb с целью в процессах поднять 2 модели на двух картах, чтобы четные и нечётные страницы обрабатывать. Но увы, все как вы и говорите, они путала языки, галюцинировала часто. Процент погрешности до 40 дошел.
К сожалению поверхностный эксперимент с OCR тоже крах потерпел. Я работаю в банковской сфере и БЗ которую использую оказалось достаточно сложной чтобы OCR которые я с HF заводил во внутренний контур справились. Может есть какие-то особые OCR-модели которые могут формулы в LATEX перевести и таблицы нормально разглядеть, но пока не нашел. 32B уложила всех на лопатки.
А как ваша модель на 80B называлась, которую вы использовали, если не секрет ?
Контекстное окно важно, да, преимущественно для результатов вызова инструментов - мы работаем с агентами, поэтому именно здесь наибольшая сложность.
Насчёт формул в LaTEX - вопрос хороший, нужно изучить, возможно, есть модели, подходящие вам, например, в эта или эта.
Наша 80B модель - https://huggingface.co/cyankiwi/Qwen3-Next-80B-A3B-Instruct-AWQ-4bit , но она без VL. Если VL и нужен, то только для анализа графиков и для этого поднимаем отдельно модель, но пока в качестве R&D.
Спасибо, очень интересный опыт и познавательная публикация. Интересно, используете ли вы реранкеры (tomaarsen/Qwen3-Reranker-4B-seq-cls неплох по железу/скорости/качеству), пробовали ли другие embedder'ы (Alibaba-NLP/gte-multilingual-base - вдвое быстрее и размерность меньше - 768 (против 1024 у BGE-M3 - получается, что на 25% меньше передавать по сети и хранить в индексе/таблице БД), или google/embeddinggemma-300m, который не быстрее, но также размерности 768, лучше по публичным метрикам качества, умеет разные задачи (через префиксы - QA / retrieval / classification / clustering / semantic similarity) и поддерживает Matryoshka, однако, sparse представлений у обоих нет), какие наиболее удачные по вашему опыту получились методики/параметры чанкера (используете ли RecursiveCharacterTextSplitter из langchain или что-то более специфическое https://habr.com/ru/companies/raft/articles/954158/)? По Qwen'у интересно используете ли system или все в user промпты прописываете и в каком формате (markdown/xml/json), причем применяете ли при работе с MCP упомянутые методики structured output (например, чтобы не было ошибок в вызове mcp инструментов) или SGR (например, чтобы вызывать не mcp tool, a гарантированный, оформленный в виде sgr схемы tool) и подаете ли при этом схему SO/SGR в виде json в самом промте, не пишет ли часто иероглифы/отклоняется от контекста (и какой, в целом, вы считаете основную причину необходимости в 235B, при достигнутом на текущий момент на ваших потребностях балансе ресурсы/качество) и не пробовали ли в сравнении с Qwen-next модель t-tech/T-pro-it-2.1-FP8 (у которой в основе (dense модель) qwen3-32b с изначально более низким hallucination rate https://huggingface.co/spaces/vectara/leaderboard 5.9% против 9.3% у next), но после улучшения авторами модели, предположительно, должно быть меньше проблем с языком/tools/json и с FP8 в комплекте. Отдельно интересны подробности по агентам в плане RAG дополненных агентов (по упомянутому на изображении из раздела "к агентам на MCP" - SearXNG - в каком виде получилось лучше всего в Qwen подавать поисковые сниппеты (title,snipper description,date,url) - KV/XML/TOON/JSON - https://habr.com/ru/articles/955778/) как работает дополнение "критик + валидатор" (в плане используется ли оно в RAG цепочке для факт-чекинга генерации), как осуществляется маршрутизация в поиск (сам ли агент понимает, что данных в контексте недостаточно/нерелевантные и нужен вызов search tool или агент всегда вызывает единый search tool, который ищет в БД, и если ничего не нашлось (rule-based методикой), возвращает результаты не из БД, а из SearXNG), используете ли какие-нибудь Guardians https://habr.com/ru/companies/redmadrobot/articles/971388/ и на каком этапе/какой области - пользователи/RAG/агенты? Если слишком много спросил, вопросы неинтересные или на некоторые неудобно отвечать (по абсолютно любым причинам долго/NDA/ноу-хау/экспертиза/security...), не отвечайте или пропустите, возможно позже, создадите еще одну, такую же прекрасную, как эта, публикацию (или даже серию - от RAG к DeepResearch Агентам, n8n подобным решениям, guard'у и факт-чекингу).
Впереди ещё много статей по практическим применениям и реализациям LLM-агентов, тулингу, бенчмаркингу и дообучению. Думаю, что очень многое будет меняться, но на некоторые вопросы отвечу - они очень в тему)
Используем ли мы реранкеры? Да, когда вышли эмбедеры и реранкеры от Qwen - мы сразу протестировали их на нашем retrieve и получили, что связка дообученной bge + qwen3-reranker-4b отрабатывает лучше всего по MRR+ACC@5 на нашем бенче.
Пробовали ли другие эмбедеры? Да, но полтора года назад bge-m3 и показал себя лучше всего на нашем корпусе. Далее пробовали разное, но dense/sparse-вектора в bge-m3 и наш гибридный retrieve сохраняются до сих пор. Скорее всего отойдём от него, когда начнём уходить в графы знаний + семантику, но к этому ещё идём.
Как сплитим? Мы используем биение по документам/главам + RecursiveCharacterTextSplitter (4096/128), связываем их через таблицу связи, производим семантическую дедупликацию, векторизуем, делам частотное дисконтирование у sparse-векторов и дальше обычный retrieve через RRF.
System или user? Мы делаем основную инструкцию в system, а далее по разному в разных продуктах. По началу запихивали всё в user, затем, когда появились агенты - начали передавать историю в обычном формате - system→user→assistant (в т.ч. tool calls + tool results)→user→... На таком формате получали более стабильное поведение с точки зрения ролевой модели.
В каком формате промпты? Зависит от задачи, но преимущественно всё в Markdown
Делаем ли в MCP structured output и подаём ли схему промпте? В AskPostgres пока что нет - тул колы выбираются свободно (auto) через цикл ReAct. Но в рамках отдельных прототипов и внутренних разработок прописываем в SGR схемы тулов и передаём всю схему в промпт, чтобы стабилизировать семплирование (а то модель не знает, что и в каком формате от неё вообще ждут, может начать галлюцинировать без конкретной схемы. Короче через промпт смещаем распределения в нужную нам область).
Бывают ли проблемы с иероглифами? Да, часто. Это бич квантизованных китайских моделей. Вообще вставки семантически схожих токенов я и в ChatGPT очень часто наблюдаю, типа
constрукция, embedинг, реrankери другие, но их легко прочитать, а вот что-то типа м模ель распознать уже сложнее. Бывает полностью скатывается в китайский ответ. Тут боролись промптингом и ограничением семплирования на множество "хороших" токенов, но это снижало throughput. В общем проблема есть, но с каждым новым релизом и увеличением размера модели/уменьшением квантизации, она становится всё реже.Зачем нам увеличивать модель до 235B? Тут всё просто - стабильность агента на сложных сценариях, включая тул колинг и сохранение ролевой модели. Также привлекает лучшая работа на больших контекстах, к чему мы собственно и идём.
Сравнивали ли с t-tech/T-pro-it-2.1-FP8 ? Пока что нет, ещё не успели) Но как минимум есть проблема с тем, что это не MoE. Мы уже привыкли к хорошему througput благодаря MoE (к тому же на наших тестах Qwen3-32B и Qwen3-80B-A3B давали +- схожее качество). Скорее всего это будет основным ограничением при внедрении подобных моделей.
Как работаем с SearXNG? У нас единый search-tool по проверенным движкам. Контекст из тула возвращается в формате json - так и передаём (отдельно url, отдельно content).
Выбор LLM и фреймворка для ИИ-агентов