Vnc решения или классические подходы автоматизации chrome через cdp (пупитер, вебдрайвы И так далее) не решают главной проблемы - получить максимальную плотность и полный контроль над процессом веб рендеринга и композитинга (да css , html )поступая на вход движку браузера проходят процесс расстеризации преобразования в векторное представление (по сути набор линий и прямоугольников) chrome использует skia и по моему сейчас уже paint который в последствии обрабатывается или видео драйвером и визуализируется . Так вот не один из доступных подходов не позволяет добиться полного управления процессом генерации кадров что открывает путь контролю потребляемых ресурсов, стабильной модели масштабирования и управления всем процессом. Используя vnc подход по сути потребовалось бы оборудование аналогичной мощности равной rdp кластеру - вы просто перенесли нагрузку в полном обьеме . Плюс доступные решения что перечислил - в основе своей строятся вокруг chromium - а он не поддается вменяемой оптимизации и управлению - и построение на базе таких решений серьезного масштабируемого кластера удаленного рендеринга - превращается в не контролируемый ад. Что то простое автоматизировать - парсить данные управляя сотней инстансов еще можно , но построенние полноценного браузерного взаимодействия- я подобных решений не нашел. Я же добился полного удовлетворения, контролем памяти, контролем количества генерируемых кадров для каждого из событий что позволило снизить нагрузку в 5 раз. К пиимеру mail.ru 1 процесс ~ 350 мб нагрузка цп минимальна в момент навигации дальше -0
какое же коллективное сопротивление прогрессу😉 А если по факту - стала задача снять с rdp фермы нагрузку генерирую Chrome. Почесал репку, и с помощью Claude pro за месяц решение полностью кастомный browser headless решение на базе WebKit C++ реализует весь функционал управления процессором рендера, обработкой, коддированием SHM буферов в jpeg , в роли session-manager слоя IPC бинарный протокол взаимодействия с инстансами + websocket на Rust - клиент js , canvas. Проект на 15000 строк кода . Месяц - полностью функциональное решение - полный контроль за процессом рендеринга, генерации фреймов - то что генерит 90% нагрузки браузера - все крутится на кластере виртуалок в docker. Результаты - даже мечтать о током было нереально - вся нагрузка вынесена с rdp все довольны ! Бонус - настоящая изоляция браузера - юзвери в rdp ничего принести не могут так как в их браузере jpeg изображения. Буфер обмена, прокси, политики ограничения контента (трекеры, всякие красивости ) регулируются в касание. Скрол плавный, в общем не искушенный не поймет что перед ним не настоящий веб контент а изображение. И замечу это не а-ля VNC и прочие решения - чистый контролируемый jpeg по websocket. Да для примера only CPU севере supermicro старенький VM 10 ядер 40 Gb оперативки - комфортно работает 70 юзеров 3-5 табов на инстанс. И да, все прелести persistent cookie все реализовано. Так вот к чему это я - я Hello world на python без Google не смогу наверное накидать. А теперь вопрос - есть среди вас спец кто бы без LLM что то подобное смог хотя бы за год, да что там вообще осилить!? Или тут команда - сто мильонов бюджет!?))) Поэтому господа, прогресс отрицать- себя обманывать - нужно трансформироваться. Всем бобра!
Последнее время окунулся в изучение данного вопроса (как раз имеющего узкий специализированный домен) и все больше склоняюсь с мысли, что без объемного и развенутого( множеством примеров) файн тюнинга не родится аленький цветочек)) (причем это справедливо как для имбеддинг так и для модели суммирования). Ну а в случае систем выставляющих требования контекстной зависимости, можно улучшить результат добавив в цепочку компонент для работы с графовым представлением данных , что при правильно организованной логики пеплайна даст хороший результат. С уважением.
Приветствую. Лет 15 читаю habr (без регистрации), но эта статья мотивировала пройти регистрацию. В первую очередь хочу выразить благодарность автору, хороший слог, основные моменты вопроса изложены последовательно, понятным языком! Но тема векторных представлений данных в контексте системы RAG лишь на первый взгляд выглядит «чудным» , «экспертным» решением и в начале может показаться бюджетной альтернативой моделям обученным на конкретном домене данных. В статье также следовало сделать акцент на том, что очень важным моментом является правильный выбор имбеддинг модели, а также подчеркнуть, что в процессе работы поменять ее на другую не выйдет, прийдется выполнять векторизацию данных сначала. Но все это по сути «цветочки» , ягодки начинаются когда подходим к вопросу «чанкинга» и приходит осознание, что в кейсах использующих обьемные контекстно не зависимые массивы для узко специализированных доменов, данный подход не принесет желаемого результата. (В специфичных доменах (например, техническая документация СТО) слово «машина» может значить не только «автомобиль», но и, например, станок или агрегат. Если модель не обучена именно на таких данных, она может неправильно интерпретировать смысл. Поэтому в узких областях важно дообучать модель или использовать доменно-специфичные данные для векторизации.) Так же вы упомянули что в случае использования мощных (DeepSeek, ChatGPT) в качестве модели суммирования позволяет получить ответ на нужном языке пользователю. Это верно лишь отчасти, действительно крупная модель с легкостью вернет результат выполнив осмысленный перевод, НО важным моментом является то, что в случае если запрос пользователя выполняется на языке отличного от того в который использовался при создании векторов, ничего у нас не сработает, так как логично что векторное представление «машина» и «car» будут бесконечно далеки. Этот нюанс так же необходимо учитывать. Подводя итог, не все так гладко , прекрасно и легко на текущем уровне развития систем RAG, и пока использование их в сферах с высокими требованиями к достоверности данных вызывают больше вопросов чем ответов. Ведь сама суть таких систем - «модель суммирования» не должна фантазировать, и работать с нулевой температурой. Еще раз спасибо автору, статья действительно хорошая!
Vnc решения или классические подходы автоматизации chrome через cdp (пупитер, вебдрайвы И так далее) не решают главной проблемы - получить максимальную плотность и полный контроль над процессом веб рендеринга и композитинга (да css , html )поступая на вход движку браузера проходят процесс расстеризации преобразования в векторное представление (по сути набор линий и прямоугольников) chrome использует skia и по моему сейчас уже paint который в последствии обрабатывается или видео драйвером и визуализируется . Так вот не один из доступных подходов не позволяет добиться полного управления процессом генерации кадров что открывает путь контролю потребляемых ресурсов, стабильной модели масштабирования и управления всем процессом. Используя vnc подход по сути потребовалось бы оборудование аналогичной мощности равной rdp кластеру - вы просто перенесли нагрузку в полном обьеме . Плюс доступные решения что перечислил - в основе своей строятся вокруг chromium - а он не поддается вменяемой оптимизации и управлению - и построение на базе таких решений серьезного масштабируемого кластера удаленного рендеринга - превращается в не контролируемый ад. Что то простое автоматизировать - парсить данные управляя сотней инстансов еще можно , но построенние полноценного браузерного взаимодействия- я подобных решений не нашел. Я же добился полного удовлетворения, контролем памяти, контролем количества генерируемых кадров для каждого из событий что позволило снизить нагрузку в 5 раз. К пиимеру mail.ru 1 процесс ~ 350 мб нагрузка цп минимальна в момент навигации дальше -0
какое же коллективное сопротивление прогрессу😉 А если по факту - стала задача снять с rdp фермы нагрузку генерирую Chrome. Почесал репку, и с помощью Claude pro за месяц решение полностью кастомный browser headless решение на базе WebKit C++ реализует весь функционал управления процессором рендера, обработкой, коддированием SHM буферов в jpeg , в роли session-manager слоя IPC бинарный протокол взаимодействия с инстансами + websocket на Rust - клиент js , canvas. Проект на 15000 строк кода . Месяц - полностью функциональное решение - полный контроль за процессом рендеринга, генерации фреймов - то что генерит 90% нагрузки браузера - все крутится на кластере виртуалок в docker. Результаты - даже мечтать о током было нереально - вся нагрузка вынесена с rdp все довольны ! Бонус - настоящая изоляция браузера - юзвери в rdp ничего принести не могут так как в их браузере jpeg изображения. Буфер обмена, прокси, политики ограничения контента (трекеры, всякие красивости ) регулируются в касание. Скрол плавный, в общем не искушенный не поймет что перед ним не настоящий веб контент а изображение. И замечу это не а-ля VNC и прочие решения - чистый контролируемый jpeg по websocket. Да для примера only CPU севере supermicro старенький VM 10 ядер 40 Gb оперативки - комфортно работает 70 юзеров 3-5 табов на инстанс. И да, все прелести persistent cookie все реализовано. Так вот к чему это я - я Hello world на python без Google не смогу наверное накидать. А теперь вопрос - есть среди вас спец кто бы без LLM что то подобное смог хотя бы за год, да что там вообще осилить!? Или тут команда - сто мильонов бюджет!?))) Поэтому господа, прогресс отрицать- себя обманывать - нужно трансформироваться. Всем бобра!
Спасибо большое за подробную информацию 👍🏻
Спасибо за труд! Очень круто!
Большое спасибо!
Последнее время окунулся в изучение данного вопроса (как раз имеющего узкий специализированный домен) и все больше склоняюсь с мысли, что без объемного и развенутого( множеством примеров) файн тюнинга не родится аленький цветочек)) (причем это справедливо как для имбеддинг так и для модели суммирования). Ну а в случае систем выставляющих требования контекстной зависимости, можно улучшить результат добавив в цепочку компонент для работы с графовым представлением данных , что при правильно организованной логики пеплайна даст хороший результат. С уважением.
Приветствую. Лет 15 читаю habr (без регистрации), но эта статья мотивировала пройти регистрацию. В первую очередь хочу выразить благодарность автору, хороший слог, основные моменты вопроса изложены последовательно, понятным языком! Но тема векторных представлений данных в контексте системы RAG лишь на первый взгляд выглядит «чудным» , «экспертным» решением и в начале может показаться бюджетной альтернативой моделям обученным на конкретном домене данных. В статье также следовало сделать акцент на том, что очень важным моментом является правильный выбор имбеддинг модели, а также подчеркнуть, что в процессе работы поменять ее на другую не выйдет, прийдется выполнять векторизацию данных сначала. Но все это по сути «цветочки» , ягодки начинаются когда подходим к вопросу «чанкинга» и приходит осознание, что в кейсах использующих обьемные контекстно не зависимые массивы для узко специализированных доменов, данный подход не принесет желаемого результата. (В специфичных доменах (например, техническая документация СТО) слово «машина» может значить не только «автомобиль», но и, например, станок или агрегат. Если модель не обучена именно на таких данных, она может неправильно интерпретировать смысл. Поэтому в узких областях важно дообучать модель или использовать доменно-специфичные данные для векторизации.) Так же вы упомянули что в случае использования мощных (DeepSeek, ChatGPT) в качестве модели суммирования позволяет получить ответ на нужном языке пользователю. Это верно лишь отчасти, действительно крупная модель с легкостью вернет результат выполнив осмысленный перевод, НО важным моментом является то, что в случае если запрос пользователя выполняется на языке отличного от того в который использовался при создании векторов, ничего у нас не сработает, так как логично что векторное представление «машина» и «car» будут бесконечно далеки. Этот нюанс так же необходимо учитывать. Подводя итог, не все так гладко , прекрасно и легко на текущем уровне развития систем RAG, и пока использование их в сферах с высокими требованиями к достоверности данных вызывают больше вопросов чем ответов. Ведь сама суть таких систем - «модель суммирования» не должна фантазировать, и работать с нулевой температурой. Еще раз спасибо автору, статья действительно хорошая!