Когда память дороже точности: приближённые структуры данных

Проблема: многие алгоритмы с линейным потреблением памяти не справляются с большим количеством данных. Решение: приближённые структуры!

В новой статье разбираем три популярные структуры данных с константным потреблением памяти, решающие ключевые задачи:
- HyperLogLog — оценка количества уникальных элементов,
- Фильтр Блума — проверка принадлежности ко множеству,
- Count-Min Sketch — подсчёт частот элементов.

Все они работают приближенно, зато позволяют работать с огромными объёмами данных. Читайте, как применять их на практике: https://blog.deepschool.ru/math/kogda-pamyat-dorozhe-tochnosti-priblizhyonnye-struktury-dannyh/

#llm #ml #systemdesign

Рекомендую изучить и в необходимых кейсах применять как методичку

Иллюстрация пайплайна из истории про спасение проекта с LLM под капотом

(проект про извлечение промышленных данных из разных PDF от разных поставщиков с таблицами и графиками)

Ссылки:
(1) Серии: 1, 2, 3, 4, 5, 6+7, Эпилог
(2) Описание первого и второго промпта.

Ваш, @llm_under_hood 🤗

#ml #math

Highly recommend this mathy blog about ML:

https://francisbach.com/

#llm #gan #courses

Microsoft опубликовал большой курс по Generative AI.

https://github.com/microsoft/generative-ai-for-beginners/tree/main

Снизу по ссылке будут дополнительные ссылки на другие курсы.

Самые горячие кейсы по GenAI, с которыми сталкиваюсь:

- Text to Insights (уже несколько проектов по Snowflake + Cortex Analyst и один по BigQuery + TextQL). Такие проекты для больших компаний (enterprise), больше похоже на продажу AI на уровне директора/VP аналитики другим директорам/VP бизнес подразделений, ну типа мы AI driven

- Developer Performance с использование Cursor или Claude Code. GitHub CoPilot пока не дотягивает. Компания покупают лицензии и дают своим инженерам. В репозиториях обязательно файлы с правилами для GenAI.

- PR reviews, часто с Claude Code и Cursor. Опять же можно добавить правила (best practices) для PR review, чтобы фиксить согласно заданным требованиям (правилам)

- RAG - компании строят чат боты по внутренней и внешней документации и базе знаний, чтобы клиенту было проще найти ответ на свой вопрос.

- MCP интеграции, например DataHub (дата каталог) может ходить в Snowflake (хранилище данных), Cursor может писать запросы и на базе них создавать dbt модели.

Это прям, что мои команды используют. Все сходятся на позиции, что prompt (context) engineering очень важен, и нужно знать основы и следовать рекомендациям вендоров.

PS и конечно это все идет в мою любимую рубрику - увлекательные истории для вашего будущего собеседования:)

#llm #petproject

Hybrid: SGR + Tools - закрываем дыры, не ломая протокол

После горячих обсуждений и двух предыдущих постов (пост 1, пост 2) я решил показать рабочий гибридный паттерн и сделать вклад в опенсорс-подход к SGR (линк в конце поста).

TLDR пост1 и пост2: SGR пишет ответ через «поля» и якоря [благодаря чему, приводит к более предсказуемым и верным ответам], но в чистом виде легко размывает семантику tool-calling (если мы ее задействуем): в истории появляются вызовы инструментов, которых не было в объявленном наборе и не передались в чат-темплейт, а если неаккуратно обрабатывать вызовы - нас ждёт еще больше проблем. И всё это расходится с практиками провайдеров и публичными бенчмарками по агентости.

Что я сделал:
Я вынес рассуждение в отдельный инструмент generate_reasoning и заставляю модель вызывать его принудительно сразу после любого пользовательского сообщения с помощью управления tool_choice. Внутри reasoning используется SGR: цель, план, ограничения, проверка предпосылок, сигналы о том, нужно ли звать инструменты и какие именно. Далее "агент", опираясь на получившееся рассуждение, вызывает только те функции, которые явно объявлены в tools, строго через нативный механизм вызовов.

Ключевые свойства подхода:
1. Никакого «динамического tools из воздуха». Всё, чем пользуется модель, заранее объявлено; в истории нет инструментов, которых нет в tools. Контроль с помощью tool_choice.
2. История сообщений валидна и читаема: отдельно видно этап рассуждения и отдельно - действия и финальный ответ.
3. Совместимость с практиками провайдеров и бенчами: снижается риск tool-hallucination, корректнее проходит проверка релевантности функций.
4. Контроль внимания вместо хаоса: сначала гарантированное рассуждение, потом действия. Это делает маршрутизацию детерминированной и устойчивой. Тк много трейновых датасетов, как и в каких ситуациях вызывать тулы, мы используем очень много компьюта в свою пользу: не только будущая корректная оценка цепочек ризонинга (для метрик), но и адаптивный выбор тулов.

Почему это устойчивее, чем «SGR-only»:
- Нативные tool_calls, а не эмуляция вызовов через content (да, можно этого избежать, подкладывая вызов SGRв tool_calls, но не решается следующий пункт:
- Меньше неожиданностей для модели: нет сценария «ответил JSON -> внезапно прилетел tool», когда tools пусты.
- Проще поддерживать качество: reasoning становится обычным шагом workflow. Его вообще можно вынести на значительно более мощные модели или наоборот, более слабые. Позволяет нам давать больше контроля.

Получается стабильный и интерпретируемый паттерн: чат-темплейт согласован с историей, вызовы инструментов не идут «против шерсти», а модель ведёт себя предсказуемо.

Рекомендую попробовать гибрид SGR + Tools на своих задачках

линк на код

поддержите реакциями ❤️

#python #courses #novice

#llm #code #petproject

#llm #petproject