Forwarded from LLM под капотом
Кейс про reasoning, в котором автор признается в использовании векторов и в архитектурной ошибке
Задача кейса - ускорить работу c документами compliance офицеров, час работы которых стоит 160-400 EUR и выше.
Я про это уже писал тут:
- Эпизод I
- Эпизод II
- Эпизод III
- Reasoning кирпичик для Stargate
- Эпизод IV
Архитектура и подходы - не коммерческая тайна. Это просто повторение успешных паттернов, которые я уже видел в других проектах.
Система состоит из трех частей.
Первая часть - data parsing с VLM под капотом. Регуляторные документы обычно распространяются в хитровыверченных PDF разных форматов. Нам нужно не просто их распарсить в текст, но и сохранить семантическую структуру (граф).
Когда я показал один такой документ Илье, он сказал про “криптонит всех парсеров” и “коварно” 😁
На эту часть я потратил в сумме три месяца. Под капотом - PyMuPDF, Paddleocr/PaddleX, Gemini Pro 2.5/OpenAI и пара интерактивных интерфейсов для реализации REPL/Human In The Loop. Конечно же SO CoT.
Вторая часть - анализатор документов c LLM под капотом. Это workflow, который сопоставляет набор регуляторных документов и набор внутренних документов, выделяет список применимых требований и аргументированно выдает список проблем во внутренних документах, которые надо бы проверить.
На эту часть я потратил тоже месяца три в сумме.
(1) загружаем все релевантные графы документов
(2) проходимся по графам, анализируем узлы, проецируем все в мини-графы. Каждый мини-граф - это конкретная статья со всеми подпунктами и релевантным контекстом
(3) анализируем каждый мини-граф - содержит ли он в себе конкретные требования, которые нужно выполнять? А применимы ли эти требования к рассматриваемым документам?
(4) анализируем найденные требования - критичность? какая информация должна быть во внутренних документах, которые будут эти требования выполнять?
Везде тут используются SO CoT. В схемах прописаны checklists, которые содержат промежуточные пункты, чтобы направлять мышление системы, да и просто отлаживать весь процесс.
(5) ищем релевантные мини-графы во внутренней документации. В текущей версии использую embedding openai-text-large + LLM review, который делается просто и из коробки работает хорошо. Если соберется достаточно размеченных данных, которые показывают на ошибки, заменю на поиск по графу и онтологиям.
(6) собираем пакет документации (мини-графы требований и найденный evidence) и прогоняем еще через один SO CoT для финального анализа. Выписываем результаты в audit report, сортируем по срочности.
Третья часть - это интерфейс, который дает экспертам поработать с этим отчетом. Там есть дашборд с метриками и список найденных проблем. Эксперты могут загрузить в workbench каждую проблему, чтобы посмотреть результаты анализа, найденный evidence, пройтись по цепочке размышлений или просто по графу регуляторного документа. Есть возможность сделать review, пометить evidence, чтобы эти правки можно было отправить дальше в работу. Ну и заодно тут мы собираем feedback для калибрации системы в будущем.
Третья часть написана на next.js/React/Tailwind/TS + NixOS/Caddy deployment. Я на нее потратил в сумме часов 18 и пару недель. 100% кода написано AI+Coding.
Концепцию UX помог сформировать Gemini Pro 2.5 (пригодился его инженерный склад ума и активный контекст в 500k). Красивый интерфейс набросал Claude Opus 4
OpenAI Codex встроил этот интерфейс в чистый next.js шаблон и вел разработку дальше (вот тут и была моя архитектурная ошибка - next.js был очень неудачным выбором для AI+Coding - мало документации и слишком часто его меняют).
От меня агентам шел поток задач и отзывов. Они - ваяли. Использовали AICODE- память для посланий друг другу. В сложных случаях использовал implementation plan. Всегда запускал 2-4 версии задач, выбирал самый симпатичный вариант, остальные выкидывал. ~60% задач были отправлены с телефона)
В итоге получился очень интересный опыт. Надо теперь брать отпуск и систематизировать все возможности в голове)
Ваш, @llm_under_hood 🤗
Задача кейса - ускорить работу c документами compliance офицеров, час работы которых стоит 160-400 EUR и выше.
Я про это уже писал тут:
- Эпизод I
- Эпизод II
- Эпизод III
- Reasoning кирпичик для Stargate
- Эпизод IV
Архитектура и подходы - не коммерческая тайна. Это просто повторение успешных паттернов, которые я уже видел в других проектах.
Система состоит из трех частей.
Первая часть - data parsing с VLM под капотом. Регуляторные документы обычно распространяются в хитровыверченных PDF разных форматов. Нам нужно не просто их распарсить в текст, но и сохранить семантическую структуру (граф).
Когда я показал один такой документ Илье, он сказал про “криптонит всех парсеров” и “коварно” 😁
На эту часть я потратил в сумме три месяца. Под капотом - PyMuPDF, Paddleocr/PaddleX, Gemini Pro 2.5/OpenAI и пара интерактивных интерфейсов для реализации REPL/Human In The Loop. Конечно же SO CoT.
Вторая часть - анализатор документов c LLM под капотом. Это workflow, который сопоставляет набор регуляторных документов и набор внутренних документов, выделяет список применимых требований и аргументированно выдает список проблем во внутренних документах, которые надо бы проверить.
На эту часть я потратил тоже месяца три в сумме.
(1) загружаем все релевантные графы документов
(2) проходимся по графам, анализируем узлы, проецируем все в мини-графы. Каждый мини-граф - это конкретная статья со всеми подпунктами и релевантным контекстом
(3) анализируем каждый мини-граф - содержит ли он в себе конкретные требования, которые нужно выполнять? А применимы ли эти требования к рассматриваемым документам?
(4) анализируем найденные требования - критичность? какая информация должна быть во внутренних документах, которые будут эти требования выполнять?
Везде тут используются SO CoT. В схемах прописаны checklists, которые содержат промежуточные пункты, чтобы направлять мышление системы, да и просто отлаживать весь процесс.
(5) ищем релевантные мини-графы во внутренней документации. В текущей версии использую embedding openai-text-large + LLM review, который делается просто и из коробки работает хорошо. Если соберется достаточно размеченных данных, которые показывают на ошибки, заменю на поиск по графу и онтологиям.
(6) собираем пакет документации (мини-графы требований и найденный evidence) и прогоняем еще через один SO CoT для финального анализа. Выписываем результаты в audit report, сортируем по срочности.
Третья часть - это интерфейс, который дает экспертам поработать с этим отчетом. Там есть дашборд с метриками и список найденных проблем. Эксперты могут загрузить в workbench каждую проблему, чтобы посмотреть результаты анализа, найденный evidence, пройтись по цепочке размышлений или просто по графу регуляторного документа. Есть возможность сделать review, пометить evidence, чтобы эти правки можно было отправить дальше в работу. Ну и заодно тут мы собираем feedback для калибрации системы в будущем.
Третья часть написана на next.js/React/Tailwind/TS + NixOS/Caddy deployment. Я на нее потратил в сумме часов 18 и пару недель. 100% кода написано AI+Coding.
Концепцию UX помог сформировать Gemini Pro 2.5 (пригодился его инженерный склад ума и активный контекст в 500k). Красивый интерфейс набросал Claude Opus 4
OpenAI Codex встроил этот интерфейс в чистый next.js шаблон и вел разработку дальше (вот тут и была моя архитектурная ошибка - next.js был очень неудачным выбором для AI+Coding - мало документации и слишком часто его меняют).
От меня агентам шел поток задач и отзывов. Они - ваяли. Использовали AICODE- память для посланий друг другу. В сложных случаях использовал implementation plan. Всегда запускал 2-4 версии задач, выбирал самый симпатичный вариант, остальные выкидывал. ~60% задач были отправлены с телефона)
В итоге получился очень интересный опыт. Надо теперь брать отпуск и систематизировать все возможности в голове)
Ваш, @llm_under_hood 🤗
Forwarded from DeepSchool
Как LLM научились видеть?
Когда-то LLMs работали только с текстом и не обрабатывали входные данные других модальностей: изображения, видео и аудио. Но благодаря прогрессу архитектур и подходов к обучению сегодня они превратились в полноценные мультимодальные системы.
В новой статье рассказываем, какие подходы научили LLM понимать изображения и 3D-сцены.
Читайте новую статью по ссылке!
Когда-то LLMs работали только с текстом и не обрабатывали входные данные других модальностей: изображения, видео и аудио. Но благодаря прогрессу архитектур и подходов к обучению сегодня они превратились в полноценные мультимодальные системы.
В новой статье рассказываем, какие подходы научили LLM понимать изображения и 3D-сцены.
Читайте новую статью по ссылке!
DeepSchool
Как языковые модели научились видеть? - DeepSchool
Какие подходы научили LLM понимать изображения и 3D-сцены
Forwarded from Метаверсище и ИИще (Sergey Tsyptsyn ️️)
Flux Kontext Dev в опенсорсе!
Налетаем, забираем, ставим отсюда:
https://github.com/black-forest-labs/flux
https://huggingface.co/black-forest-labs/FLUX.1-Kontext-dev
Требуха под Комфи тоже уже есть:
https://comfyanonymous.github.io/ComfyUI_examples/flux/#flux-extras
@cgevent
Налетаем, забираем, ставим отсюда:
https://github.com/black-forest-labs/flux
https://huggingface.co/black-forest-labs/FLUX.1-Kontext-dev
Требуха под Комфи тоже уже есть:
https://comfyanonymous.github.io/ComfyUI_examples/flux/#flux-extras
@cgevent
Forwarded from что-то на инженерном
Знакомимся с Apache Iceberg: что такое каталог данных, табличный формат и как устроен Iceberg?
Представьте, что ваша компания - это огромная библиотека, где вместо книг хранятся терабайты и петабайты данных, разбросанных по разным хранилищам: облачным бакетам (S3, GCS), HDFS, базам данных и т.д.
🔘 Каталог данных - это как индексный каталог этой библиотеки. Он не хранит сами "книги" (данные), но содержит всю метаинформацию о них:
— где лежат данные (путь к файлам, подключение к базе данных).
— что в этих данных (схема таблицы: названия колонок, их типы).
— как они организованы (партиции, форматы файлов).
— кто владеет данными, кто может к ним получить доступ.
— когда данные были обновлены, какая у них история изменений.
🔜 Зачем он нужен?
Без каталога Data Lake быстро превращается в «болото данных» (Data Swamp): невозможно найти нужную информацию, обеспечить качество или управлять доступом.
Раньше данные в озерах хранились как обычные файлы (Parquet, ORC), лишённые функциональности БД.
🔘 Табличный формат (Table Format) - это слой абстракции и управления метаданными, который накладывается поверх этих файлов. Он позволяет "видеть" коллекцию разрозненных файлов как единую, полноценную таблицу, давая ей функциональность, присущую базам данных:
— ACID-транзакции - безопасные обновления/удаления;
— Эволюция схемы - изменение структуры без перезаписи данных;
— Time Travel - доступ к прошлым версиям таблиц;
— Оптимизация - ускорение запросов через статистику.
Табличные форматы (Apache Iceberg, Delta Lake, Hudi) добавляют слой абстракции, превращая набор файлов в «умные» таблицы.
➡️ Apache Iceberg - это один из ведущих открытых табличных форматов для Data Lake, который является развитием концепции Hive Metastore.
Ключевые компоненты архитектуры Iceberg
Чтобы понять, как Iceberg достигает всех этих преимуществ, важно знать его основные компоненты:
*️⃣ Каталог (Catalog): Iceberg нуждается во внешнем Каталоге (да-да, том самом "оглавлении"), чтобы хранить указатель на текущий снапшот таблицы. Это может быть Hive Metastore (да, он еще нужен, но уже для другой, упрощенной роли!), Nessie, AWS Glue, или даже специализированный REST-каталог Iceberg.
*️⃣ Таблица (Table): логическое представление данных через метаданные.
*️⃣ Снапшоты (Snapshots): каждое изменение в таблице создает новый снапшот. Снапшот - неизменяемые версии таблицы (реализуют Time Travel).
*️⃣ Манифест-листы (Manifest Lists): Файлы, содержащие список манифест-файлов. Каждый снапшот указывает на свой манифест-лист.
*️⃣ Манифест-файлы (Manifest Files): Содержат записи о файлах данных (Parquet, ORC, Avro), из которых состоит таблица в данном снапшоте. Эти файлы также хранят статистику по каждому файлу (например, min/max значения колонок), что используется для data skipping (ускорения фильтрации).
*️⃣ Файлы данных (Data Files): Сами файлы с данными, расположенные в облачном хранилище (S3, GCS) или HDFS.
Эта многоуровневая структура метаданных позволяет Iceberg эффективно управлять изменениями, обеспечивать ACID-гарантии и работать с огромными объемами данных.
Что рекомендую изучить по этой теме:
⭐️ Apache Iceberg The Definitive Guide | dremio.com
📹 Короткое видео о том, зачем нужен Iceberg и как устроена его архитектура | ENG: YouTube
📹 Доклад с конференции Smart Data: подробное устройство архитектуры, интеграция с Trino | RUS: YouTube
📕 Статья про архитектуру и развертывание Spark+Iceberg в Docker | ENG: Medium
В вашей компании уже используете Iceberg или планируется переход? 👀Делитесь опытом в комментариях!
©️что-то на инженерном
Представьте, что ваша компания - это огромная библиотека, где вместо книг хранятся терабайты и петабайты данных, разбросанных по разным хранилищам: облачным бакетам (S3, GCS), HDFS, базам данных и т.д.
— где лежат данные (путь к файлам, подключение к базе данных).
— что в этих данных (схема таблицы: названия колонок, их типы).
— как они организованы (партиции, форматы файлов).
— кто владеет данными, кто может к ним получить доступ.
— когда данные были обновлены, какая у них история изменений.
Без каталога Data Lake быстро превращается в «болото данных» (Data Swamp): невозможно найти нужную информацию, обеспечить качество или управлять доступом.
Раньше данные в озерах хранились как обычные файлы (Parquet, ORC), лишённые функциональности БД.
— ACID-транзакции - безопасные обновления/удаления;
— Эволюция схемы - изменение структуры без перезаписи данных;
— Time Travel - доступ к прошлым версиям таблиц;
— Оптимизация - ускорение запросов через статистику.
Табличные форматы (Apache Iceberg, Delta Lake, Hudi) добавляют слой абстракции, превращая набор файлов в «умные» таблицы.
Ключевые компоненты архитектуры Iceberg
Чтобы понять, как Iceberg достигает всех этих преимуществ, важно знать его основные компоненты:
Эта многоуровневая структура метаданных позволяет Iceberg эффективно управлять изменениями, обеспечивать ACID-гарантии и работать с огромными объемами данных.
Что рекомендую изучить по этой теме:
В вашей компании уже используете Iceberg или планируется переход? 👀Делитесь опытом в комментариях!
©️что-то на инженерном
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Neural Kovalskii
Валера Ковальский на Conversations 2025.pdf
83.2 MB
Как и обещал в комментариях выкладываю свой доклад, про концепции и подходы
DCD-Domain>>>Collection>>>Document
Про реальные вызовы и опыт про построение workflow llm assistant
DCD-Domain>>>Collection>>>Document
Про реальные вызовы и опыт про построение workflow llm assistant
Forwarded from Valerii Kovalskii
1) Выбрали RAGAS не как готовое решение, а как методологическую основу
Выкинули большую часть компонентов и оставили концепцию "LLM as Judge" для оценки качества генерации
Это дало больше гибкости в настройке метрик под конкретные задачи, чем жесткая структура DeepEval
2) Если под "use case" имеются в виду конкретные пользовательские сценарии и типы запросов
Разметка происходит итеративно через пользовательский фидбек в продакшене, сбор сложных кейсов и edge cases, автоматическую разметку через более сильные модели
Сейчас самый большой размеченный датасет около 5k качественных примеров
3) Метрики качества ретривала
Собрали обширный набор метрик с динамическими порогами: базовые Precision@K, Recall@K, MRR, RAGAS context metrics, кастомные метрики семантической близости
Практика показала, что универсального порога не существует каждый ассистент требует тонкой настройки под свой домен
4) Используем T-Lite (Qwen 2.5 7B) и T-Pro (Qwen 2.5 32B) от Тинькофф
Дообучение на внутренних данных не проводили, используем базовые версии адаптов (за рекламу до сих пор никто не заплатил)
5) Пробовали, но отказались из-за сложности в интеграции и поддержке bottom-up архитектур
Разработали DCD (Domain Collection Document) структуру, где пользователь понимает как сделать top-down структуру чтобы самому потом что-то обновить
Можно легко прикручивать роутеры-маршрутизаторы на базе 7B модели без сложной адаптации
6) Не могу раскрыть детали NDA
Выкинули большую часть компонентов и оставили концепцию "LLM as Judge" для оценки качества генерации
Это дало больше гибкости в настройке метрик под конкретные задачи, чем жесткая структура DeepEval
2) Если под "use case" имеются в виду конкретные пользовательские сценарии и типы запросов
Разметка происходит итеративно через пользовательский фидбек в продакшене, сбор сложных кейсов и edge cases, автоматическую разметку через более сильные модели
Сейчас самый большой размеченный датасет около 5k качественных примеров
3) Метрики качества ретривала
Собрали обширный набор метрик с динамическими порогами: базовые Precision@K, Recall@K, MRR, RAGAS context metrics, кастомные метрики семантической близости
Практика показала, что универсального порога не существует каждый ассистент требует тонкой настройки под свой домен
4) Используем T-Lite (Qwen 2.5 7B) и T-Pro (Qwen 2.5 32B) от Тинькофф
Дообучение на внутренних данных не проводили, используем базовые версии адаптов (за рекламу до сих пор никто не заплатил)
5) Пробовали, но отказались из-за сложности в интеграции и поддержке bottom-up архитектур
Разработали DCD (Domain Collection Document) структуру, где пользователь понимает как сделать top-down структуру чтобы самому потом что-то обновить
Можно легко прикручивать роутеры-маршрутизаторы на базе 7B модели без сложной адаптации
6) Не могу раскрыть детали NDA
Forwarded from Варим МЛ
Сегодня у меня на обзоре книга "Карьера разработчика", которую мне в бумажном виде прислало издательство Питер. Такие коллаборации я очень люблю, пишите побольше с такими предложениями, а не с платной рекламой эвентов и курсов! Книгу я давно хотел прочесть, и в итоге она мне очень понравилась, ну где-то на 8.5 из 10, подробнее читайте по ссылке.
Ещё ребята из CS Space при ПОМИ РАН запустили (возродили) свой клуб и попросили упомянуть в каком-нибудь посте питерский офлайн-митап про LLM для решения математических и алгоритмических задач. Пока я рожал, места на митап закончились... Но ребятам я обещал упоминание, так что просто отрекламирую их сообщество, офлайны с такими спикерами и докладами - это всегда круто.
#Жека #books
Ещё ребята из CS Space при ПОМИ РАН запустили (возродили) свой клуб и попросили упомянуть в каком-нибудь посте питерский офлайн-митап про LLM для решения математических и алгоритмических задач. Пока я рожал, места на митап закончились... Но ребятам я обещал упоминание, так что просто отрекламирую их сообщество, офлайны с такими спикерами и докладами - это всегда круто.
#Жека #books
Telegraph
Книга "Карьера разработчика"
Сегодня у меня на обзорчике книга "Карьера разработчика: стафф - круче, чем senior", в оригинале она называется "The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change". Я точно не являюсь стафф-разработчиком, да и вообще…
Forwarded from Refat Talks: Tech & AI
Media is too big
VIEW IN TELEGRAM
Официальные гайды по промт-инжинирингу от OpenAI, Anthropic и Google в NotebookLM - сделал апдейт и вынес ресурсы в Google Drive
Вам зашла эта подборка в NotebookLM. Помногочисленным просьбам выкладываю все файлы, чтобы вы могли собрать свой ноутбук (как выяснилось, Google не дает копировать публичные ноутбуки).
→ Ссылка на Google Drive
Что в папке:
- Все файлы с официальными гайдами
- Текстовый файл со всеми ссылками для добавления (смотрите в видео как добавлять ссылки)
Плюс добавил пару новых источников, например свежий Prompt Migration Guide от OpenAI.
Забирайте, пользуйтесь🎹
🔥➕🔁
Вам зашла эта подборка в NotebookLM. По
→ Ссылка на Google Drive
Что в папке:
- Все файлы с официальными гайдами
- Текстовый файл со всеми ссылками для добавления (смотрите в видео как добавлять ссылки)
Плюс добавил пару новых источников, например свежий Prompt Migration Guide от OpenAI.
Забирайте, пользуйтесь
🔥➕🔁
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from gonzo-обзоры ML статей
На Google I/O connect не анонсировали, но сделали это сейчас -- полный релиз Gemma 3n, модель на основе матрёшечного трансформера (MatFormer), которая и так маленькая, но можно ещё и практически произвольные размеры из неё "выжимать" (между 2B и 4B). С крутыми аудио и картиночными энкодерами.
https://goo.gle/45EaFch
Результатами на LMArena нынче никого не удивишь, но блин для такого размера это круто.
https://goo.gle/45EaFch
Результатами на LMArena нынче никого не удивишь, но блин для такого размера это круто.
Googleblog
Google for Developers Blog - News about Web, Mobile, AI and Cloud
Learn how to build with Gemma 3n, a mobile-first architecture, MatFormer technology, Per-Layer Embeddings, and new audio and vision encoders.
Forwarded from Базы данных & SQL
DevOps в локальных облаках: как строить высоконагруженные системы с CI/CD, Kubernetes и Grafana
Читать статью
Читать статью
Хабр
DevOps в локальных облаках: как строить высоконагруженные системы с CI/CD, Kubernetes и Grafana
Введение: DevOps в условиях локальных ограничений Когда мы начали разворачивать высоконагруженную fintech-платформу в локальном облаке, задача казалась выполнимой: привычные инструменты, знакомые...