Спасибо! Очень хорошее замечание - реальность, разумеется, сложнее, чем приведенная в статье иллюстрация: в жизни действительно необходимо будет дополнительно вводить поправочные коэффициенты, зависящий от имплементируемого решения, инженерной обвязки, системы развертывания для апроксимации приближенной к реальности картины.
Тут простой формулы, к сожалению, не существует и общее число запросов зависит от ряда факторов – от того, какой “плотности” бизнес-процесс или его часть вы автоматизируете, с помощью каких решений это делаете (например, RAG, агенты), того, как эти решения реализованы и т.д.
Если какие-то краткие рекомендации тут давать, то:
- предварительную оценку кол-ва запросов можно сделать, исходя из статистики существующего неавтоматизированного процесса – это можно будет взять, как некий бейзлайн
- в зависимости от имплементируемого решения нужно будет накинуть на бейзлайн поправочный коэффициент – например, для RAG системы ~х1.3, для агентной системы ~х3
- в формате пилота запуститься на этих предварительно рассчитанных цифрах и собрать статистику по фактичесскому кол-ву запросов и объему токенов, затрачиваемому в среднем на запрос, по латенси и т.д.
- отталкиваясь от фактической статистики можно будет уже более уверенно прогнозировать и итоговые цифры по потреблению в рамках полномасштабной эксплуатации и использовать полученную статистику для более точного расчета сайзинга на продакшене
Все верно - если посмотрите исходную на статью автора подхода( ссылка есть в публикации), то он открыто указывает на то, что предложенная методика "списана" с используемой в ТЭК LCOE (levelized cost of electricity) и адаптирована под специфику ML решений.
Спасибо за оценку! И да, предложенный подход, разумеется, не претендует на то, чтобы заменить классический CRISP - это больше попытка альтернативного взгляда на возможность проверки гипотез с максимальным использованием инструментария сегодняшнего дня :)
Буду рад, если удастся применить на своих задачах. Возвращайтесь - делитесь результатами ;)
Для русского языка довольно много уже готовых моделей, хорошо решающих эту задачу, но сама идея с точки зрения демонстрации подхода хорошая - постараемся выпустить follow-up статью, где проделаем то же упражнение на русском :)
Да, интересная идея! Тут правда важно, какие цели преследуются создателями решения - если evoluation для внутреннего использования производится, то креатив в угоду снижению стоимости всячески приветствуется, тогда как, если метрики нужны для того, чтобы хвастаться ими наружу, то тут придется все же идти с общепринятыми подходами и привлекать SME и нейтивов и считать тот же MOS.
Да, вы правы, при том, что основные трудности здесь они не технического характера и сделать негалюцинирующую модель, с удовлетворительным уровнем качества генерирующей скрипты, задача выполнимая.
Основные трудности, которые я вижу, они лежат в продуктовой плоскости. Начать хотя бы даже с целевой аудитории - в сегодняшней сложной геополитической ситуации нельзя просто так взять и выпустить универсальное решение, которое бы работало и в РФ, и за пределами. Если говорить про РФ, то нет смысла вести речь об облачной версии или OpenAI моделях под капотом - тут предложение вероятнее всего должно базироваться на серверной версии и локальных моделях, а это с большой долей вероятности отрезает не-энтерпрайзную часть аудитории и переводит нас в русло заказной разработки.
В общем, вопросов в истории создания полномасштабного продукта здесь действительно больше, чем ответов, поэтому пока только прототип :)
Пока это на уровне PoC и до промышленной эксплуатации не доведено - тут, как говорится, скоро сказка сказывается, да не скоро дело делается :) разрывы между экспериментами в внедрением их результатов в производство пока на месте и анализ того, кто виноват и что делать, будет достойно отдельного лонг-рида :))
Ну, все относительно :) На заднем фоне там Blue Sky Tower - не Бурдж-Халифа, конечно, но свои 105 метров имеет :)) Относительно свеженькие при том - в 2006 году построен и, что интересно, ровно 100 лет разницы с храмовым комплексом Чойжин-ламы рядом
Всегда! :) т. к. золото - это 'не только ценный мех, но и 3-4 килограмма' надёжных инвестиций, помогающих в защите капитала в наше турбулентное время :))
В статье я опирался на свой профессиональный опыт, который 'размазан' по нескольким сферам, поэтому возникли и ритейл, и производство - это еще спасибо, что рука удержалась и не упомянул здравоохранени, финтех, EDI и много чего еще :) А так цель была не всеобъемлющий анализ дать существующим моделям, а на одном конкретном живом примере проиллюстрировать эволюцию подходов и показать, что эксперименты, проверки гипотез и построение PoC в современном мире это не блажь бигтехов по цене крыла самолета, а необходимость, диктуемая суровой реальностью :))
Спасибо! Очень хорошее замечание - реальность, разумеется, сложнее, чем приведенная в статье иллюстрация: в жизни действительно необходимо будет дополнительно вводить поправочные коэффициенты, зависящий от имплементируемого решения, инженерной обвязки, системы развертывания для апроксимации приближенной к реальности картины.
Тут простой формулы, к сожалению, не существует и общее число запросов зависит от ряда факторов – от того, какой “плотности” бизнес-процесс или его часть вы автоматизируете, с помощью каких решений это делаете (например, RAG, агенты), того, как эти решения реализованы и т.д.
Если какие-то краткие рекомендации тут давать, то:
- предварительную оценку кол-ва запросов можно сделать, исходя из статистики существующего неавтоматизированного процесса – это можно будет взять, как некий бейзлайн
- в зависимости от имплементируемого решения нужно будет накинуть на бейзлайн поправочный коэффициент – например, для RAG системы ~х1.3, для агентной системы ~х3
- в формате пилота запуститься на этих предварительно рассчитанных цифрах и собрать статистику по фактичесскому кол-ву запросов и объему токенов, затрачиваемому в среднем на запрос, по латенси и т.д.
- отталкиваясь от фактической статистики можно будет уже более уверенно прогнозировать и итоговые цифры по потреблению в рамках полномасштабной эксплуатации и использовать полученную статистику для более точного расчета сайзинга на продакшене
Все верно - если посмотрите исходную на статью автора подхода( ссылка есть в публикации), то он открыто указывает на то, что предложенная методика "списана" с используемой в ТЭК LCOE (levelized cost of electricity) и адаптирована под специфику ML решений.
Привет! Спасибо за высокую оценку и за то, что помог сделать статью лучше! Привел форму в соответствие с содержанием - "очепятки" поправил! ;)
Спасибо за оценку! И да, предложенный подход, разумеется, не претендует на то, чтобы заменить классический CRISP - это больше попытка альтернативного взгляда на возможность проверки гипотез с максимальным использованием инструментария сегодняшнего дня :)
Буду рад, если удастся применить на своих задачах. Возвращайтесь - делитесь результатами ;)
А как обстоят дела в части отладки knowledge graph-ов в сравнении с векторной базой в случае, если, например, модель галлюцинирует?
Для русского языка довольно много уже готовых моделей, хорошо решающих эту задачу, но сама идея с точки зрения демонстрации подхода хорошая - постараемся выпустить follow-up статью, где проделаем то же упражнение на русском :)
... и увлекательно! :)
Да, интересная идея! Тут правда важно, какие цели преследуются создателями решения - если evoluation для внутреннего использования производится, то креатив в угоду снижению стоимости всячески приветствуется, тогда как, если метрики нужны для того, чтобы хвастаться ими наружу, то тут придется все же идти с общепринятыми подходами и привлекать SME и нейтивов и считать тот же MOS.
Theranos, наверное :) хотя вопрос, конечно, кто из них больший злодей :))
Application based approach, что поделать :)
Всё относительно :) если взять, к примеру, соседний Хьюстон, где и в апреле днём на улице хаммам, то Остин, наверное, можно назвать сухим :))
Ждем отделения ковбоев от остальных Штатов или рано еще? :)
Да, вы правы, при том, что основные трудности здесь они не технического характера и сделать негалюцинирующую модель, с удовлетворительным уровнем качества генерирующей скрипты, задача выполнимая.
Основные трудности, которые я вижу, они лежат в продуктовой плоскости. Начать хотя бы даже с целевой аудитории - в сегодняшней сложной геополитической ситуации нельзя просто так взять и выпустить универсальное решение, которое бы работало и в РФ, и за пределами. Если говорить про РФ, то нет смысла вести речь об облачной версии или OpenAI моделях под капотом - тут предложение вероятнее всего должно базироваться на серверной версии и локальных моделях, а это с большой долей вероятности отрезает не-энтерпрайзную часть аудитории и переводит нас в русло заказной разработки.
В общем, вопросов в истории создания полномасштабного продукта здесь действительно больше, чем ответов, поэтому пока только прототип :)
..и не забывать есть кактус, запивая текилой, иначе какой он тогда амиго ;)
Пока это на уровне PoC и до промышленной эксплуатации не доведено - тут, как говорится, скоро сказка сказывается, да не скоро дело делается :) разрывы между экспериментами в внедрением их результатов в производство пока на месте и анализ того, кто виноват и что делать, будет достойно отдельного лонг-рида :))
Ну, все относительно :) На заднем фоне там Blue Sky Tower - не Бурдж-Халифа, конечно, но свои 105 метров имеет :)) Относительно свеженькие при том - в 2006 году построен и, что интересно, ровно 100 лет разницы с храмовым комплексом Чойжин-ламы рядом
Всегда! :) т. к. золото - это 'не только ценный мех, но и 3-4 килограмма' надёжных инвестиций, помогающих в защите капитала в наше турбулентное время :))
В статье я опирался на свой профессиональный опыт, который 'размазан' по нескольким сферам, поэтому возникли и ритейл, и производство - это еще спасибо, что рука удержалась и не упомянул здравоохранени, финтех, EDI и много чего еще :) А так цель была не всеобъемлющий анализ дать существующим моделям, а на одном конкретном живом примере проиллюстрировать эволюцию подходов и показать, что эксперименты, проверки гипотез и построение PoC в современном мире это не блажь бигтехов по цене крыла самолета, а необходимость, диктуемая суровой реальностью :))