ruBert-tiny — это "рабочая лошадка" для RAG на русском, где важны скорость и экономия.
ruBert-base подключают, когда качество > стоимость, но в большинстве RAG-кейсов tiny достаточно.

P.S. Для английского аналог — all-MiniLM-L6-v2 (часто используется вместо large-моделей в продакшне).

#llm #courses

#audio #petproject

🔥 Пошаговый гайд создания системы автоматического распознавания речи с помощью PyTorch и Hugging Face

С эти гайдом вы сможете:
- Загружать и обрабатывать речь данные
- Настраивать предварительно обученную модель Wav2Vec2
- Оценивать производительность модели с помощью коэффициента ошибок слов (WER)
- Развертывать модель для перевода речи в текст в режиме реального времени

🔗 Читать

У верблюда два горба, потому что жизнь - борьба...
#иб_для_ml

Так возможно сказал Николас Карлини, так как сегодня вышла статья с его соавторством "🐫 Defeating Prompt Injections by Design". Остальной авторский коллектив этой статьи тоже серьезный - исследователи из Google и ETH Zurich.


Система защиты CaMeL
В этой работе представлена система защиты ИИ-агентов от промпт-атак CaMeL (расшифровывается как CApabilities for MachinE Learning). Основывается она на двух горбах LLM (Priveleged и Quarantined) и специальном интерпретаторе языка Python. По сути, эта методика вытаскивает логику действий агента в явную плоскость, заставляя программу "написать свой код", к которой благодаря кастомному интерпретатору применятся все ограничения безопасности.

Область применения и ограничения
CaMeL, в первую очередь, нацелен на предотвращение несанкционированных действий ИИИ-агентов, которые могут привести к утечкам данных, или использованию данных из ненадежных источников. Однако он совершенно не предназначен для защиты от атак, не влияющих на порядок действий агента или поток данных (например, от фишинга, или изменения содержания сгенерированного текста). Поэтому как компонент системы безопасности ИИ-агентов это решение может быть полезно, но не выполнит ее роль полностью.


Алгоритм работы CaMeL
1. Поступление запроса пользователя: Пользователь формулирует запрос на естественном языке, например, "Отправь Бобу документ, который он просил на прошлой встрече".

2. Генерация кода: Privileged LLM (P-LLM), которой доверяют, берет запрос пользователя и генерирует псевдо-код на Python, который выражает намерения пользователя. Важно, что P-LLM видит только запрос пользователя, но не данные из ненадежных источников (например, содержимое файлов).

3. Интерпретация кода: Созданный код обрабатывается CaMeL Interpreter, который:
— Строит граф потока данных (data flow graph), отслеживая зависимости между переменными.
— Проверяет политики безопасности на основе capabilities (некоторых метаданных, присвоенных различным объектам информации), определяя, какие действия разрешены.
— Выполняет код, вызывая инструменты (например, для отправки email) или блокирует выполнение, если нарушается политика безопасности.
— Использует Quarantined LLM (Q-LLM) для обработки ненадежных данных, таких как извлечение информации из текста.

4. Применение политик безопасности: перед выполнением каждого инструмента агента, CaMeL Interpreter применяет политики безопасности, основанные на capabilities данных. Если политика нарушена, выполнение блокируется, и пользователю может быть запрошено подтверждение.

Что такое capabilities и security policies?
Capabilities — это метаданные (теги), присваиваемые каждому отдельному объекту данных для описания контроля и взаимосвязей потока данных. Capabilities определяют, кому разрешено читать данную часть данных или ее происхождение. Перевести на русский можно как "метки доступа". В статье не указывается их полное содержание, но раскрываются два главных элемента:
— разрешенные читатели (public, или перечень конкретных пользователи),
— происхождение данных (user, camel, inner tool source). С user понятно, camel - порожденные кодом данные, inner tool source - поступившие из инструмента данные, например отправителя полученного email сообщения.

Security policies - код функций на python, в которых реализуются политики безопасности. Например, если данные происходят из недоверенного источника, ответ прерывается. Или если у пользователя нет разрешения на запрошенную информацию, ответ прерывается.


В общем, конечно же интересно увидеть, что будет дальше, так что продолжим следить за работами этих ученых)

PEP765: больше никакой грязи в finally

Ссылка на PEP: https://peps.python.org/pep-0765
Одна из самых сломанных частей питона была пофикшена в 3.14

В чем проблема?

Ранее такой код вел себя крайне странно:

>>> def some():
...     try:
...         return 1
...     finally:
...         return 2

>>> some()
2

Так как из функции может быть только один return, а код в finally всегда выполняется – то получаем, что получаем.

Или такой код:

>>> def other():
...     try:
...         1 / 0
...     finally:
...         return 2

>>> other()
2

Тут вообще жесть. У нас подавляется исключение без except 🫠
Аналогично можно делать не только с return, но и с break / continue в циклах:

>>> def cycle():
...     for i in range(2):
...         try:
...             i / 0
...         finally:
...             print(i)
...             continue
...     return 2

>>> cycle()
# prints: 0
# prints: 1
# returns: 2

Такой код позволял создавать ошибки на ровном месте.

Как исправили?

Теперь такой код генерирует SyntaxWarning в 3.14:

>>> def some():
...     try:
...         return 1
...     finally:
...         return 2
<python-input-14>:5: SyntaxWarning: 'return' in a 'finally' block

Скоро – будет SyntaxError, в будущих версиях.
Но, WPS, например, запрещал такое делать уже очень давно.

Как работает?

Сам патч очень маленький и простой:

1. Добавляет список текущего контекста _Py_c_array_t cf_finally; в ast_opt.c

Храним внутри структуры вида:

typedef struct {
    bool in_finally;  // мы в `finally`?
    bool in_funcdef;  // мы в `def` или `async def`?
    bool in_loop;  // мы в `for`, `async for` или `while`?
} ControlFlowInFinallyContext;

2. При обходе дерева, добавляет нужные данные в текущий контекст: находимся ли мы в finally, функции, цикле
3. Если находим return, break или continue, то выполняем проверку синтаксиса; вот код для return:

static int
before_return(_PyASTOptimizeState *state, stmt_ty node_)
{
    if (state->cf_finally_used > 0) {
        ControlFlowInFinallyContext *ctx = get_cf_finally_top(state);
        // если нашли `return` в `finally`, но не во вложенной функции,
        // то показываем warning пользователю:
        if (ctx->in_finally && ! ctx->in_funcdef) {  
            if (!control_flow_in_finally_warning("return", node_, state)) {
                return 0;
            }
        }
    }
    return 1;
}

4. Внутри control_flow_in_finally_warning используем специальное АПИ для SyntaxWarning:

static int
control_flow_in_finally_warning(const char *kw, stmt_ty n, _PyASTOptimizeState *state)
{
    PyObject *msg = PyUnicode_FromFormat("'%s' in a 'finally' block", kw);
    if (msg == NULL) {
        return 0;
    }
    int ret = _PyErr_EmitSyntaxWarning(msg, state->filename, n->lineno,
                                       n->col_offset + 1, n->end_lineno,
                                       n->end_col_offset + 1);
    Py_DECREF(msg);
    return ret < 0 ? 0 : 1;
}

Готово!

Обсуждение: вы знали про такую проблему? Стреляли так себе в ногу?

P.S. Пока писал пост, нашел багу в питоне и важную опечатку :)

| Поддержать | YouTube | GitHub | Чат |

#dl #nlp

новая работа про токенизацию - SuperBPE - наводит на меня мысли о том, что история развивается по спирали; своим студентам я на первой лекции рассказываю про словосочетания (Multi-Word Expression), которые можно выделять из текста статистически; а потом использовать, например, для лучшего представления в TF-IDF (придуман в 1970-е)

прошло 50 лет, наши представления о токенизации сильно изменились, особенно в 2015 году, с адаптацией алгоритма сжатия ZIP к токенизации (это, собственно, и есть BPE), и теперь мы вышли на новый круг, чтобы снова учитывать словосочетания в токенизации...