#rag #llm

☁️ RAG: концепция [Ч.1]

🚫 Современные LLM обладают впечатляющими навыками решать новые задачи без необходимости обучения. Однако, если в тренировочном датасете были данные или факты, имеющие временную изменчивость, то ответы модели могут приводить к галлюцинациям.

📌 Базовый пример: мы хотим, чтобы LLM отвечала по внутренним документам нашей компании для помощи клиентам.

Очевидно, что любая LLM не имеет точных и актуальных знаний для правильного ответа на любые запросы подобного рода, поэтому и была придумана RAG-концепция.

🔍 RAG (Retrieval Augmented Generation) - метод поиска и извлечения релевантных данных по пользовательскому запросу из внешней или внутренней базы знаний с целью расширить контекст модели актуальной информацией.

🗂 В качестве базы знаний тут могут выступать различные структурированные (базы данных, таблицы) и неструктурированные (книги, журналы, документы) источники информации.

❗️Глобально RAG помогает решать не только проблему актуализации данных, но при этом экономит много ресурсов и времени для продукта, если бы задача обновления знаний решалась через дообучение LLM.

✅ Разберем основные части RAG:

- Retrieval - часть системы, которая отвечает за поиск и извлечение информации, так и называют — ретривер (retriever).
- Retrieval Augmented — дополнение запроса пользователя найденной релевантной информацией.
- Retrieval Augmented Generation — генерация ответа пользователю с учетом дополнительно найденной информацией.

📚 Дополнительное чтиво:
- Простое объяснение RAG на Хабре
- Подробно о генерации с дополненной выборкой на AWS Amazon
- GPT и RAG технологии в Базе знаний InKnowledge

В следующих частях данной серии поговорим про современные подходы к построению RAG, а также от нашей команды вы получите общий справочник по данной теме.
Ставьте ❤️ и 🔥 за интересный пост!
До встречи👋

🦜🔗LangСhain - библиотека, расширяющая возможности LLM

Недавно в нашем канале был опубликован пост Hugging Face Hub и библиотека transformers, а сегодня мы хотим расширить тему наиболее популярных инструментов при работе с LLM и расскажем про ключевые особенности библиотеки и всей экосистемы LangChain.

LangСhain - популярная библиотека, которая упрощает разработку LLM-Driven приложений, предоставляя все необходимые инструменты для создания агентских систем, цепочек вызовов и взаимодействия языковых моделей с внешними API.

Основные особенности LangChain:

1️⃣ RAG (Retrieval Augmented Generation)
В нашем предыдущем посте мы рассказывали про концепцию создания RAG-систем. LangChain оснащен всеми необходимыми инструментами для построения классического RAG.
Например, перед вами поставили задачу построить QnA чат-бота в онлайн-поддержке. С помощью LangChain вы сможете сформировать правильную базу знаний из источников, по которым должен отвечать бот, и на пользовательский запрос находить релевантные части потенциальных ответов для дальнейшей генерации конечного ответа LLM’кой.

2️⃣ Chains (цепочки)
LangСhain запросто позволяет создавать последовательности операций (цепочки) для задач обработки естественного языка, которые могут состоять из различных этапов обращений к LLM, использованию внешних API и составления промптов.
Такой подход может использоваться абсолютно в любой задаче, где процесс обработки пользовательского запроса моделью имеет цепочечный вид: запрос пользователя -> формирование промптов для модели -> получение ответа модели -> преобразование ответа и вывод.
Более детально про цепочки в LangChain читайте из официальной документации.

3️⃣ Агентские системы
Концепция Агентов сейчас набирает большую популярность в задачах, где LLM могут использоваться для решения более сложных задач, нежели просто генерация текста.
Например, дать возможность LLM вызывать API прогноза погоды для предоставления актуальной информации пользователю по данному вопросу. В роли API может выступать более продвинутые инструменты - базы данных, несколько API, пользовательские функции. LangChain расширяет возможности работы LLM в такой роли и упрощает разработку агентских-систем.

4️⃣ LangGraph
Это дополнительная библиотека в экосистеме LangChain, которая позволяет создавать рабочие процессы на основе графов. Сюда может входить, как создание рабочих цепочек, исполняющихся агентом, так и формирование графов знаний, который могут выступать заменой классическим базам знаний в RAG.
🔥Введение в LangGraph смотрите тут и тут

5️⃣ LangSmith
Среда для создания LLM-Driven приложений, которая объединяет все инструменты экосистемы LangChain, а также даёт возможность визуально отслеживать и улучшать разработку таких приложений.
Например, отображает RAG-пайплайн и выводит логи на каждом шаге.
🔥 Изучение LangSmith можете начать тут и тут

📌 Что ещё стоит изучить:
- Серия практикоориентированных постов на Хабре по созданию AI-агентов с помощью LangChain
- Официальный LangChain CookBook с огромным количеством реализаций различных задачек с LLM под капотом
- Как создана концепция экосистемы из официальной страницы
- Дополнительно про агенты читайте здесь

В следующем посте хотим рассказать про особенности AI-Агентов на базе LLM!
Ставьте:
🔥 - если текущий пост был полезен!
❤️ - если ждете следующий!
До встречи👋🏻

🙈 Чистый код? Чистая архитектура? А может лучше когнитивная нагрузка?

Если вы еще не слышали о «Чистой подборке», самое время ознакомиться. Поможет с разных сторон посмотреть на задачу минимизации костов разработки и поддержания кода, инфраструктуры, работы.

Посмотрим на проблему с другой стороны. Что важно? Важно снижать когнитивную нагрузку, это фундаментальное стремление и ограничение человека. Для разработчика — это тратить меньше времени на чтение и понимание кода, чем на его написание.

👀 Типы когнитивной нагрузки

Внутренняя (Intrinsic) — вызвана самой сложностью задачи. Эту нагрузку не уменьшить, она лежит в основе разработки ПО.

Внешняя (Extraneous) — создается тем, как представлена информация. Она возникает из факторов, не связанных напрямую с задачей, например, причудами «умного» автора.

👀 Перейдем к конкретным практическим примерам внешней когнитивной нагрузки

Обозначим уровни когнитивной нагрузки следующим образом:
🧠: свежая рабочая память, нулевая когнитивная нагрузка
🧠++: два факта в рабочей памяти, когнитивная нагрузка увеличена
🤯: переполнение рабочей памяти, более 4 фактов

Сложные условия

if val > some_constant:  # 🧠+
    if condition2 or condition3:  # 🧠+++, предыдущее условие должно быть истинным, одно из c2 или c3 должно быть истинным
        if condition4 and not condition5:  # 🤯, на этом этапе мы уже запутались
            ...

Как написать лучше? Вводим промежуточные переменные с осмысленными именами:

is_valid = val > some_constant
is_allowed = condition2 or condition3
is_secure = condition4 and not condition5  
# 🧠, нам не нужно помнить условия, есть описательные переменные

if is_valid and is_allowed and is_secure:  
    ...

Вложенные if

if is_valid:  # 🧠+, нормально, вложенный код применим только к допустимому вводу
    if is_secure:  # 🧠++, мы делаем что-то только для допустимого и безопасного ввода
        stuff  # 🧠+++

Сравним это с ранними выходами:

if not is_valid:
    return

if not is_secure:
    return

# 🧠, нам не нужно беспокоиться о ранних выходах, если мы здесь, значит все в порядке

stuff  # 🧠+

👀 Кошмар на улице наследований

Допустим, нам нужно изменить пару вещей для администраторов: 🧠

class AdminController(UserController, GuestController, BaseController):

Часть функциональности находится в BaseController: 🧠+
Основные механизмы ролей были введены в GuestController: 🧠++
Что-то частично изменено в UserController: 🧠+++
И вот мы здесь, в AdminController! 🧠++++

Есть еще SuperuserController, который наследует от AdminController. Изменяя AdminController, мы можем поломать что-то в наследуемом классе, поэтому сначала давайте заглянем в SuperuserController: 🤯

Предпочитайте композицию наследованию. На эту тему есть видео.

👀 Слишком много мелких поверхностных методов, классов или модулей, неограниченные варианты реализации, злоупотребление принципом SRP и DRY, желание воткнуть ф р е й м в о р к или б и б л и о т е к у при первой возможности, луковая архитектура может добавить когнитивной нагрузки.

Как этого избежать, читайте в ОЧЕНЬ КРУТОМ ГАЙДЕ, который мы нашли.

Quant Researcher

#cv #llm #gan

Stable Diffusion 3.5 Large

Stability наконец-то выпустили 8B модельку, которую тизерили ещё в феврале. Идёт в двух версиях - обычная и Turbo (которой нужно всего 4 степа). Ещё обещают обновённую Medium завезти, но только 29 октября, через неделю.

По качеству полная моделька, по заявлениям Stability находится между FLUX.1 dev и schnell. Turbo - чуть хуже schnell. До FLUX.1 Pro обоим далеко. Зато хвастаются что SD 3.5 лучше всех в понимании промптов.

Доступны по комьюнити лицензии - то есть если у вас годовая выручка до миллиона долларов, ничего платить не нужно. А вот если больше, то попросят раскошелиться на энтерпрайз лицензию.

После фиаско с Medium 3.0 (которая была ошибкой), к релизу отношусь настороженно.

Не жду, что Stability когда-либо сможет выпустить новую SOTA, т.к. все основные авторы SD ушли.

Веса
Turbo версия
Код
Блогпост

@ai_newz

#code #python

Фабричный метод — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.

from __future__ import annotations
from abc import ABC, abstractmethod


class Creator(ABC):
    """
    Класс Создатель объявляет фабричный метод, который должен возвращать объект
    класса Продукт. Подклассы Создателя обычно предоставляют реализацию этого
    метода.
    """

    @abstractmethod
    def factory_method(self):
        """
        Обратите внимание, что Создатель может также обеспечить реализацию
        фабричного метода по умолчанию.
        """
        pass

    def some_operation(self) -> str:
        """
        Также заметьте, что, несмотря на название, основная обязанность
        Создателя не заключается в создании продуктов. Обычно он содержит
        некоторую базовую бизнес-логику, которая основана на объектах Продуктов,
        возвращаемых фабричным методом. Подклассы могут косвенно изменять эту
        бизнес-логику, переопределяя фабричный метод и возвращая из него другой
        тип продукта.
        """

        # Вызываем фабричный метод, чтобы получить объект-продукт.
        product = self.factory_method()

        # Далее, работаем с этим продуктом.
        result = f"Creator: The same creator's code has just worked with {product.operation()}"

        return result


"""
Конкретные Создатели переопределяют фабричный метод для того, чтобы изменить тип
результирующего продукта.
"""


class ConcreteCreator1(Creator):
    """
    Обратите внимание, что сигнатура метода по-прежнему использует тип
    абстрактного продукта, хотя фактически из метода возвращается конкретный
    продукт. Таким образом, Создатель может оставаться независимым от конкретных
    классов продуктов.
    """

    def factory_method(self) -> Product:
        return ConcreteProduct1()


class ConcreteCreator2(Creator):
    def factory_method(self) -> Product:
        return ConcreteProduct2()


class Product(ABC):
    """
    Интерфейс Продукта объявляет операции, которые должны выполнять все
    конкретные продукты.
    """

    @abstractmethod
    def operation(self) -> str:
        pass


"""
Конкретные Продукты предоставляют различные реализации интерфейса Продукта.
"""


class ConcreteProduct1(Product):
    def operation(self) -> str:
        return "{Result of the ConcreteProduct1}"


class ConcreteProduct2(Product):
    def operation(self) -> str:
        return "{Result of the ConcreteProduct2}"


def client_code(creator: Creator) -> None:
    """
    Клиентский код работает с экземпляром конкретного создателя, хотя и через
    его базовый интерфейс. Пока клиент продолжает работать с создателем через
    базовый интерфейс, вы можете передать ему любой подкласс создателя.
    """

    print(f"Client: I'm not aware of the creator's class, but it still works.\n"
          f"{creator.some_operation()}", end="")


if __name__ == "__main__":
    print("App: Launched with the ConcreteCreator1.")
    client_code(ConcreteCreator1())
    print("\n")

    print("App: Launched with the ConcreteCreator2.")
    client_code(ConcreteCreator2())

#python #code

#паттерны

Введение

Сегодня мы рассмотрим паттерн проектирования "Адаптер".

Классификация

Тип: Структурный

Определение: Адаптер — это структурный паттерн проектирования, который позволяет объектам с несовместимыми интерфейсами работать вместе.
Адаптер выступает прослойкой между объектами превращая вызовы одного в понятные для другого.

Очень удобно понять адаптер на примере из жизни. Представим человеку который говорит только на французском нужно рассказать историю человеку который понимает только немецкий. Сами понять они друг друга не смогут, поэтому им понадобится переводчик, который переведёт французкий на немецкий. В данном случае переводчик выступит адаптером.

Из чего состоит и как работает паттерн адаптер

1. Клиент. Описывает бизнес логику программы. Работает с адаптером и другими объектами.


adapter = Adapter()
result = adapter.do() + "5"


2. Интерфейс с которым может работать клиентский код.


class Test1:
def do(self) -> str:
return "3"


3. Класс, который имеет нужную клиенту логику, однако клиент не может с ним общаться, так как интерфейс данного класса ему не понятен.


class Test2:
def specific_do(self) -> float:
return 3.4


4. Адаптер - класс который помогает клиенту использовать функционал незнакомого ему сервиса в правильном формате. Реализует клиентский интерфейс. Содержит ссылку на незнакомый сервис. Адаптер при получении вызовов от клиента через клиентский интерфейс и переводит их в вызовы незнакомого сервиса в правильном формате.


class Adapter(Test1, Test2):
def do(self) -> str:
return f"Translated: {round(self.specific_do())}"


Уточнение: Приложение должно использовать объект адаптера только через клиентский интерфейс. Это позволит легко создавать и изменять адаптеры в будущем.

Плюсы данного паттерна

1. Скрывает все "низкоуровневые" преобразования интерфейсов от клиента. Реализует принцип абстракция.

Минусы данного паттерна

Таковых я не обнаружил

Пример и задача

В качестве примера возьмём класс с методом do который возвращает небольшой текст. Также есть класс с методом secret_do который возвращает другую строку, зашифрованную шифром Цезаря со сдвигом 5, которая ещё и полностью развёрнута.

В виде клиента выступает функция которая постит текст в ваш блог.(Можете просто создать функцию которая выводит переданный в неё текст). Естественно она должна принимать только расшифрованный текст.

Реализуйте адаптер для второго класса, который спасёт ваш блог от зашифрованных постов.

Пример из реального кода

https://github.com/aiogram/aiogram/blob/b190bbba1915ed3b7f311a780f34723ebd6b5acd/aiogram/contrib/fsm_storage/redis.py#L280

Вот его объяснение какую задачу решает адаптер в данном случае:

Здесь адаптер дает возможность контроллеру хранилища (RedisStorage) работать с первой версией редиса, т.е. адаптирует aioredis-v1, там еще есть адаптер для aioredis-v2, но он в отличие от первой версии адаптирует только создание клиента редиса

Дополнительные материалы

https://habr.com/ru/post/85095/

#llm #cv #gan