Да, спасибо за разъяснения, я понимаю, как вы пришли к выводу о кликбейтности. Тем не менее, в заголовке не написано про «только gigachat», и статья описывает ровно то что в заголовке. Тесты не принижают Opus, а даже наоборот. Основная мысль про память, а не про сравнение моделей, и мы не делаем выводы кто лучше или хуже, а смотрим, кто насколько поднимается в конкретном применении.
Цену считал отдельно, на боевом инстансе, привожу.
Объём контекста. Бюджет фиксирован заранее: top_n=16, depth=2, в промпт уходит 12 узлов. Медиана инъекции: 6590 байт (1,5-2 тыс. токенов) на промпт, за период накопилось 1.2 МБ. Граф расходует ровно те же слоты, что и BM25: при одном размере выдачи меняется её состав. Поэтому +37 пунктов находимости (с 44% до 81%) достаются при том же объёме промпта.
Время. Латентность извлечения: медиана 1585 мс, p90 = 7,7 с против 16 мс в контрольной группе с выключенной памятью. Условия честные и неидеальные: общая машина с соседними сервисами, Postgres без pgvector, brute-force по 5967 узлам. Это верхняя граница, а не предел возможного — ANN-индекс (76 тыс. рёбер, сборка 101 с) даёт скорость, качество при этом остаётся тем же. Сам обход графа на depth=2 занимает малую долю; основное время съедают эмбеддинг запроса и косинус по корпусу.
Вклад в время ответа модели. Лишние ~2 тыс. токенов на prefill — десятки миллисекунд, на фоне полутора секунд ретрива и самой генерации это теряется. Прогон 100 вопросов через боевой garland занял 52 секунды на весь набор.
Пользователь, который сегодня мигрирует «на модель посильнее», на этом классе задач получил бы от памяти больше, чем от смены модели — дешевле и внутри своего контура.
Отдельно мне вот эта мысль понравилась:
Отдельно про деньги, раз уж они в таблице. Самая выгодная из семи — младшая gigachat-2: 0.21 ₽ за верный ответ против 1.85 ₽ у старшей и 1.66 ₽ у Opus. По точности она отстаёт от gigachat-2-max на шесть пунктов (51% против 57%), и эти шесть пунктов обходятся почти в девять раз дороже. Для потоковых задач, где ошибку ловит следующий шаг, выбор далеко не очевиден.
Если у вас, например, техподдержка или консалтинг, то вы можете заметно повысить качество обслуживания клиента, в рамках примерно того же бюджета и не прибегая к мощнейшим решениям, которые вам особо не нужны своей мощью. Не кодом единым.
Статья про то, как быть в отсутствие Claude. Замеры все есть, и когда я их показывал первым рецензентам, меня просили о сравнении. Вот оно, честное, проверяемое.
Предложите ваш вариант сравнения, и я с радостью сделаю. Спасибо.
Статья показывает ориентир для пользователей, кто не имеет возможности работать с продвинутыми моделями в своём контуре, как можно улучшить пользовательский опыт с тем что есть. Не «мы побили беззащитный Клод», а «вот вам рычаг — чуть подняться, примерно до уровня Клода». Отдельно хотелось бы услышать мнение разработчиков отечественных моделей — эти люди работают под натиском критики и сарказма, и им бы интересно было улучшить пользовательский опыт, а мне — заглянуть в будущее наших проектов. Вопросы в конце статьи.
А в каких конкретно "в корпоративных внедрениях" только векторный поиск реализован? Неужели такие корпоративы сегодня есть?
Про внедрения — тут поймали, статистики у меня нет. Это впечатление, а не данные: дефолт ходовых фреймворков — top-k по эмбеддингам, и то, что я вижу у заказчиков, тоже он. Назвать конкретные компании не могу. Точнее было бы написать «самый распространённый вариант из тех, что мне попадались», и как контрольная точка в замере он всё равно нужен — от чего-то надо отсчитывать.
Про динамическое — значит, я вас неправильно прочитал, простите. Тогда встречный вопрос: даже если веса подстраиваются под семантику запроса, факт «эту жалобу закрыл вот этот PR, вчера вечером» должен откуда-то взяться. Подстройка меняет то, как модель читает вход, а сам вход всё равно надо собрать. Плюс нужен доступ к весам, а корпоративный пользователь GigaChat или YandexGPT сидит на API, где такого рычага нет вообще. Если есть работающий пример на корпоративных данных с цифрами — киньте ссылку, я посмотрю и готов прогнать на нём свой набор вопросов.
Не манипуляция, а ориентир: Гига подтягивается к лидерам, и это лучше, чем если ничего не делать, и даже лучше в сравнении с тем, кто использует лидера как есть. Не всем доступен Клод, поэтому для них и написана эта статья, как ещё один способ достичь того, что уже есть у тех, у кого "всё хорошо".
Возражение принимаю, спасибо. Правило висит на одной строке — gigachat-2, 42% в mc против 51% в vecmory, и при ±10 пунктах такая строка тянет только как наблюдение.
Кривой по числу кандидатов у меня нет: mc гонялся только с 12. Предложение правильное, прогоню mc с 3, 6 и 12 на тех же 100 вопросах и семи моделях. По моим ценам это 1400 новых вызовов и около 900 ₽ — деньги небольшие, результат выложу сюда же и в репозиторий, там и код, и сырые ответы.
Долю выдуманных как функцию k не считал. Одно косвенное наблюдение из того, что есть: у младшей gigachat-2 в mc доля отказов 1% при 42% верных. Она почти никогда не говорит «не нашёл», а уверенно называет что-то — это ближе к вашему второму варианту, что модель перестаёт опираться на список. Порог там или плавный сдвиг, покажет только кривая.
Согласен, RAG — это зонтик. В статье под ним я имел в виду самый ходовой вариант: эмбеддер + top-k, потому что в корпоративных внедрениях чаще всего стоит именно он, и он мне нужен был как контрольная точка. С сегодняшними решениями сравнение тоже есть — раздел про публичные наборы (musique, 2wiki, hotpotqa в раздаче HippoRAG): там RAPTOR, GritLM-7B, NV-Embed-v2 на 7B и HippoRAG 2, цифры в таблице. Дообучение решает другую задачу: знание в веса, а мне нужен факт из тикета, закрытого вчера, и чтобы он появился в контексте через секунду после закрытия, без прогона и без денег на него.
Уточню немного. Сам навык — нет, память ему ума не добавит. Она уточняет контекст и убирает класс промахов «не знал». Что в проекте так не принято, что этот баг уже чинили вот тут, что функция рядом делает то же самое. На повторных граблях помогает заметно. А если модель задачу не тянет — с памятью не потянет тоже, просто ошибётся аккуратнее. По коду цифр у меня нет, это из наблюдений.
Вот это я бы хотел проверить с командой Гигачата, им это вроде ничего не стоит, но они сильно заняты внедрением своих собственных вундервафель и им пока некогда. А так — да, в длительных проектах это поможет сделать более рабочий инструмент для программирования. Особенно с учетом того, что у их разработчиков альтернативы НЕТ, в отличие от нас.
В целом умеет, скрипты всякие, что-то несложное. Он и на сложное замахнется без зазрения, но там уже надо стоять над ним и бдить. Пока смысла нет с ним связываться для таких целей, лучше выбрать что-то другое.
Из-за порога основная масса клиентов не лезет в Python и VBA, хотя достигает высокого профессионализма в Excel — это происходит действительно годами, функция за функцией, начиная от открытия Alt+Enter для переноса строки внутри ячейки (пожалуйста!) и до МДСЧ().
Стащить людей с таким массивным и тяжело добытым пластом знаний куда-то ещё возможно только если у них совсем нет иного выхода.
Да, спасибо за разъяснения, я понимаю, как вы пришли к выводу о кликбейтности. Тем не менее, в заголовке не написано про «только gigachat», и статья описывает ровно то что в заголовке.
Тесты не принижают Opus, а даже наоборот. Основная мысль про память, а не про сравнение моделей, и мы не делаем выводы кто лучше или хуже, а смотрим, кто насколько поднимается в конкретном применении.
Добавил в статью Udate: сколько стоит контекст от связей
Цену считал отдельно, на боевом инстансе, привожу.
Объём контекста. Бюджет фиксирован заранее: top_n=16, depth=2, в промпт уходит 12 узлов. Медиана инъекции: 6590 байт (1,5-2 тыс. токенов) на промпт, за период накопилось 1.2 МБ. Граф расходует ровно те же слоты, что и BM25: при одном размере выдачи меняется её состав. Поэтому +37 пунктов находимости (с 44% до 81%) достаются при том же объёме промпта.
Время. Латентность извлечения: медиана 1585 мс, p90 = 7,7 с против 16 мс в контрольной группе с выключенной памятью. Условия честные и неидеальные: общая машина с соседними сервисами, Postgres без pgvector, brute-force по 5967 узлам. Это верхняя граница, а не предел возможного — ANN-индекс (76 тыс. рёбер, сборка 101 с) даёт скорость, качество при этом остаётся тем же. Сам обход графа на depth=2 занимает малую долю; основное время съедают эмбеддинг запроса и косинус по корпусу.
Вклад в время ответа модели. Лишние ~2 тыс. токенов на prefill — десятки миллисекунд, на фоне полутора секунд ретрива и самой генерации это теряется. Прогон 100 вопросов через боевой garland занял 52 секунды на весь набор.
статья как раз про наоборот:
Отдельно мне вот эта мысль понравилась:
Если у вас, например, техподдержка или консалтинг, то вы можете заметно повысить качество обслуживания клиента, в рамках примерно того же бюджета и не прибегая к мощнейшим решениям, которые вам особо не нужны своей мощью.
Не кодом единым.
Не уточнял про русский язык. Хотелось проверить на публичных бенчмарках, там не про русский язык, а про повторяемость и независимость.
Статья про то, как быть в отсутствие Claude. Замеры все есть, и когда я их показывал первым рецензентам, меня просили о сравнении. Вот оно, честное, проверяемое.
Предложите ваш вариант сравнения, и я с радостью сделаю. Спасибо.
Мы так и сравниваем, жига с наддувом дает больше скорости. Кому это актуально (феррари в госах нельзя) могут ездить быстрее таким образом.
Статья показывает ориентир для пользователей, кто не имеет возможности работать с продвинутыми моделями в своём контуре, как можно улучшить пользовательский опыт с тем что есть. Не «мы побили беззащитный Клод», а «вот вам рычаг — чуть подняться, примерно до уровня Клода».
Отдельно хотелось бы услышать мнение разработчиков отечественных моделей — эти люди работают под натиском критики и сарказма, и им бы интересно было улучшить пользовательский опыт, а мне — заглянуть в будущее наших проектов. Вопросы в конце статьи.
Про внедрения — тут поймали, статистики у меня нет. Это впечатление, а не данные: дефолт ходовых фреймворков — top-k по эмбеддингам, и то, что я вижу у заказчиков, тоже он. Назвать конкретные компании не могу. Точнее было бы написать «самый распространённый вариант из тех, что мне попадались», и как контрольная точка в замере он всё равно нужен — от чего-то надо отсчитывать.
Про динамическое — значит, я вас неправильно прочитал, простите. Тогда встречный вопрос: даже если веса подстраиваются под семантику запроса, факт «эту жалобу закрыл вот этот PR, вчера вечером» должен откуда-то взяться. Подстройка меняет то, как модель читает вход, а сам вход всё равно надо собрать. Плюс нужен доступ к весам, а корпоративный пользователь GigaChat или YandexGPT сидит на API, где такого рычага нет вообще. Если есть работающий пример на корпоративных данных с цифрами — киньте ссылку, я посмотрю и готов прогнать на нём свой набор вопросов.
Не манипуляция, а ориентир: Гига подтягивается к лидерам, и это лучше, чем если ничего не делать, и даже лучше в сравнении с тем, кто использует лидера как есть. Не всем доступен Клод, поэтому для них и написана эта статья, как ещё один способ достичь того, что уже есть у тех, у кого "всё хорошо".
В статье есть оба сравнения: с памятью и без для всех моделей, плюс вот эта оговорка. Возможно, я не совсем понял вопрос.
Возражение принимаю, спасибо. Правило висит на одной строке — gigachat-2, 42% в mc против 51% в vecmory, и при ±10 пунктах такая строка тянет только как наблюдение.
Кривой по числу кандидатов у меня нет: mc гонялся только с 12. Предложение правильное, прогоню mc с 3, 6 и 12 на тех же 100 вопросах и семи моделях. По моим ценам это 1400 новых вызовов и около 900 ₽ — деньги небольшие, результат выложу сюда же и в репозиторий, там и код, и сырые ответы.
Долю выдуманных как функцию k не считал. Одно косвенное наблюдение из того, что есть: у младшей gigachat-2 в mc доля отказов 1% при 42% верных. Она почти никогда не говорит «не нашёл», а уверенно называет что-то — это ближе к вашему второму варианту, что модель перестаёт опираться на список. Порог там или плавный сдвиг, покажет только кривая.
Согласен, RAG — это зонтик. В статье под ним я имел в виду самый ходовой вариант: эмбеддер + top-k, потому что в корпоративных внедрениях чаще всего стоит именно он, и он мне нужен был как контрольная точка.
С сегодняшними решениями сравнение тоже есть — раздел про публичные наборы (musique, 2wiki, hotpotqa в раздаче HippoRAG): там RAPTOR, GritLM-7B, NV-Embed-v2 на 7B и HippoRAG 2, цифры в таблице.
Дообучение решает другую задачу: знание в веса, а мне нужен факт из тикета, закрытого вчера, и чтобы он появился в контексте через секунду после закрытия, без прогона и без денег на него.
Ха, не совсем :)
Ок, с той же памятью Opus 68%, GigaChat 57% — тут никакой интриги.
Это не тот случай, парни честно стараются.
Уточню немного. Сам навык — нет, память ему ума не добавит. Она уточняет контекст и убирает класс промахов «не знал». Что в проекте так не принято, что этот баг уже чинили вот тут, что функция рядом делает то же самое. На повторных граблях помогает заметно. А если модель задачу не тянет — с памятью не потянет тоже, просто ошибётся аккуратнее.
По коду цифр у меня нет, это из наблюдений.
Вот это я бы хотел проверить с командой Гигачата, им это вроде ничего не стоит, но они сильно заняты внедрением своих собственных вундервафель и им пока некогда.
А так — да, в длительных проектах это поможет сделать более рабочий инструмент для программирования. Особенно с учетом того, что у их разработчиков альтернативы НЕТ, в отличие от нас.
В целом умеет, скрипты всякие, что-то несложное. Он и на сложное замахнется без зазрения, но там уже надо стоять над ним и бдить. Пока смысла нет с ним связываться для таких целей, лучше выбрать что-то другое.
Из-за порога основная масса клиентов не лезет в Python и VBA, хотя достигает высокого профессионализма в Excel — это происходит действительно годами, функция за функцией, начиная от открытия Alt+Enter для переноса строки внутри ячейки (пожалуйста!) и до МДСЧ().
Стащить людей с таким массивным и тяжело добытым пластом знаний куда-то ещё возможно только если у них совсем нет иного выхода.
Откуда инфа? Мы пробовали замерять на одном публичном репо, 70% в серой зоне, 0,2% имеют четкий след ИИ.
https://habr.com/ru/articles/1065112/