Привет, на связи Алексей Дубинец, Павел Беспалов и Глеб Гладков — BI-аналитики Авито. В тексте делимся идеями и промптами для использования локальной LLM в своих повседневных задачах, а ещё расскажем, как настроить инхаус модель в LM-Studio.

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

Содержание:

• Почему публичные LLM подходят не всегда

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

• Настраиваем LM Studio для работы

• Кейс 1: категоризируем обращения с помощью локальной LLM и автоматизируем работу поддержки

• Кейс 2: создаём базу знаний с помощью локальной LLM

• Вместо выводов: практические советы, как внедрять локальные LLM и писать рабочие промпты

Почему публичные LLM подходят не всегда 

У всех нас есть задачи, которые мы спихиваем на стажёра вынуждены выполнять, даже если они нам не нравятся. При этом рутина — одно из главных препятствий для повышения продуктивности. Например, по данным из исследования Всемирного экономического форума, около 40% рабочего времени сотрудников можно автоматизировать с помощью больших языковых моделей — Large Language Models (LLM). LLM эффективны в выполнении повторяющихся задач, таких как: классификация текстов, составление отчётов, суммаризация, чистка данных. 

Но внедрить их в большой компании может быть проблематично. Вот основные сложности: 

1. Политика безопасности и защита данных. Авито и другие крупные компании обрабатывают миллионы записей персональных данных пользователей: ФИО, телефоны, адреса, платёжные данные. По закону, передача таких данных за рубеж строго запрещена без соблюдения исключительных условий, поэтому использование иностранных ИИ для обработки такой информации — нарушение законодательства РФ.

2. Коммерческая тайна. Данные о спросе, поисковых запросах, сезонности и географии сделок — это важные бизнес-активы. Анализ этих данных иностранными ИИ может раскрыть уязвимости на рынке.

3. Риски утечек. Зарубежные провайдеры ИИ обязаны передавать данные властям своих стран, например, по закону FISA в США. Даже если данные «анонимны», существует риск, что пользователей можно идентифицировать по косвенной информации — истории покупок или геолокации.

4. Санкционные ограничения. Прямые санкции против РФ запрещают компаниям вроде OpenAI предоставлять услуги российским юрлицам, поэтому мы никак не смогли бы заключить легальный контракт. 

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

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

Возможно, их больше, но мы видим такие:

Российские платформы, например: YandexGPT, GigaChat, модели от MWS AI. Хотя использование таких сервисов позволяет соответствовать законодательству, Авито всё равно не может работать с поставщиками напрямую и сотрудничать с конкурентами. Это создаёт разные риски: может произойти утечка стратегических инсайтов или чувствительных датасетов. Так что такое решение нам не подходит.

Гибридный подход. Мы рекомендуем использовать российские или иностранные ИИ только для задач:

• с публичными, нечувствительными данными. Например: просить модель проанализировать открытые новости или тренды; 

• где риск утечки не наносит ущерба. Например, сгенерировать с помощью нейросети шаблонный текст для справки;

• со строгой анонимизацией и очисткой данных перед отправкой. Хотя это как раз и снижает полезность моделей.

Локальные LLM и инхаус разработка. Для нас и других компаний в высококонкурентных нишах полный контроль над данными и моделью — не просто предпочтение, а стратегическая необходимость. У инхаус разработок есть разные преимущества:

• данные и инсайты остаются внутри компании;

• модель кастомизируется именно под вашу специфику;

• инхаус решения независимы от вендоров и их политики и будут устойчивы в долгосрочной перспективе.

При этом стоит помнить, что, несмотря на все плюсы, такие решения требуют от компаний определённых мощностей. Например, нужно инвестировать в собственные GPU-кластеры и MLOps-инфраструктуру, развивать внутреннюю экспертизу в области машинного обучения и NLP, создавать или адаптировать открытые модели и обучать их только на внутренних данных в изолированном контуре. 

Мы выбираем последний подход. Расскажем, как с относительно небольшими затратами внедрить LLM-модель в рабочие задачи.

Настраиваем LM Studio для работы

Если уже знаете, как пользоваться приложением, — переходите в разделы с кейсами:

• категоризируем обращения с помощью локальной LLM и автоматизируем работу поддержки;

• создаём базу знаний с помощью локальной LLM.

LM Studio — это open source программа для поиска, загрузки и запуска сотен открытых моделей, например, Mistral, Llama или Phi без написания кода. Она же позволяет одним кликом поднять локальный API-сервер для интеграции ИИ в ваши скрипты и приложения. 

Расскажем, как найти, скачать и настроить модель в LM Studio на своём компьютере. 

1. Устанавливаем на компьютер приложение с официального сайта.

2. Скачиваем модель. В LM Studio интегрирована платформа Hugging Face Hub, так что прямо в приложении можно загружать открытые модели, в том числе основанные на трансформерах. Для этого:

• открываем вкладку «Обзор моделей»:

• дальше находим модель через поиск, выбираем её квантование и скачиваем. 

Подробнее про квантование можно почитать в статье: «Разбираемся с суффиксами квантования LLM: что на самом деле значат Q4_K_M, Q6_K и Q8_0»

Всё, что скачаете, будет отображаться во вкладке «Мои модели» — их можно удалять, сохранять настройки и открывать на Hugging Face.

Как выбрать модель. Тут всё зависит от ваших требований и задач. Оставим список популярных и эффективных вариантов, которые хорошо работают на потребительском «железе»:

3. Загружаем модель. После того как мы скачали модель, её нужно ещё и загрузить. Для этого переходим во вкладку «Разработка», выбираем нужный вариант из списка и параметры для установки, нажимаем: «Загрузить модель».

4. Опционально: проверяем модель. На вкладке «Чат» можно протестировать загруженную модель в режиме реального времени и оценить её возможности из коробки. Для этого попросите её решить тестовую задачу, похожую на то, с чем планируете работать. Например, мы попросили оценить тональность отзыва на салон красоты, так как в дальнейшем планировали давать модели задачи, связанными с сообщениями из чата поддержки. 

Из интересного

Локальная LLM умеет больше, чем облачная. Например, в ней можно редактировать не только свои сообщения, но и ответы модели — это меняет контекст переписки и влияет на следующие ответы. Можно также создавать ветки чата после любого сообщения, возвращаться и задавать новые вопросы, чтобы развивать диалог по-другому. В облачных версиях таких возможностей часто не хватает.

5. Запускаем локальный HTTP API-сервер. В LM Studio это можно сделать одним кликом. У сервера будет стандартный, аналогичный OpenAI API, интерфейс для взаимодействия с выбранной LLM. Благодаря этому можно будет интегрировать модель в сторонние приложения, скрипты и бизнес-процессы. 

Делается всё это на той же вкладке «Разработка». Настройка сервера сводится к нажатию кнопки «Status: Running». 

Ограничения и особенности работы с локальными LLM:

• для современных моделей нужен достаточно мощный компьютер с хорошей видеокартой. На обычном процессоре (CPU) тоже будет работать, но медленнее и плохо масштабируется;

• локально будет сложно запустить самые продвинутые модели вроде GPT-4 или Gemini Ultra. Скорее вы будете работать с более лёгкими моделями Mistral, Llama 3 или Phi-2/3 на 7B–30B параметров;

• нужно вкладываться в prompt engineering и настраивать параметры генерации — такие как temperature, top_p, max_tokens. Если промпты будут некачественными или неточными, это будет сильно влиять на стабильность результатов;

• в целом, локальные модели работают медленнее, особенно без GPU, и подходят не для всех задач. Например, они не очень подходят для творческих задач или тех, где нужно глубокое понимание контекста.

Если интересно изучить тему запуска локальных моделей подробнее, вот несколько статей:

• Running LLM Locally vs. Cloud GitHub: A Complete Guide;

• How to Run Mistral 7B on Your Machine: Hardware & Software Specs.

Кейс 1: категоризируем обращения с помощью локальной LLM и автоматизируем работу поддержки

Расскажем про использование LLM на реальном примере.

Наша команда — это BI-подразделение в Коммерческом департаменте Авито. Мы отвечаем за разработку, поддержку и развитие аналитической отчётности компании: отчёты, дашборды и витрины данных, которыми постоянно пользуются сотрудники из разных подразделений, чтобы принимать решения и заниматься операционным контролем.

Основной канал поддержки пользователей BI-экосистемы — чат в Mattermost. Туда пишут тимлиды, аналитики и другие специалисты, когда у них возникают вопросы или проблемы с BI-инструментами. Вот с какими проблемами пользователи обычно приходят в чат:

• отображение данных в витринах: некорректные или неактуальные цифры, отсутствие ожидаемой информации; 

• функциональность дашбордов: неработающие фильтры, кнопки, визуализации; 

• доступ: не удаётся открыть нужный отчёт или раздел;

• интерпретация: не понимают, как рассчитываются показатели или как читать отчёты; 

• «не наши» проблемы: вопросы, которые относятся к другим отчётам или требуют вмешательства других подразделений, например, смежных BI-команд;

• прочие вопросы: настройки, документация, предложения. 

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

В день приходит от трёх до семи обращений, а в месяц получается где-то 85. На обработку одного такого запроса уходит 1–2 часа. Раньше мы никак не категоризировали запросы, а сразу решали возникающие у пользователей проблемы. 

Это помогало закрывать ситуативные вопросы, но без категоризации мы не могли понять, какие типы проблем возникают чаще всего и на какие отчёты или типы данных приходится основной объём обращений.

Категоризация запросов была нужна не только чтобы находить «проблемные» отчёты или отлавливать часто встречающиеся сложности. Ещё это нужно, чтобы планировать ресурсы поддержки, создавать шаблоны и базу знаний с ответами на самые частые вопросы. Например: «Как считается метрика X в отчёте?», «Что делать, если отчёт Y не открылся?». 

Да и в целом, данные о часто встречающихся запросах помогают улучшать отчёты, делать их более «дружелюбными» и обучать пользователей самостоятельно настраивать нужные фильтры и использовать данные с бóльшей пользой.

Без категоризации все обращения — неструктурированная масса, из которой трудно извлекать количественные инсайты для улучшения и развития сервиса. 

Первое решение — категоризировать текущие обращения c помощью эмодзи. Мы решили, что дежурный аналитик в чате поддержки будет ставить эмодзи под каждым сообщением от пользователя. Каждое эмодзи соответствует определённому типу проблемы — так обращения автоматически кодируются по категориям.

Это помогло с текущими сообщениями. Но возник вопрос: что делать с историческими данными? Вникать в переписки за прошлый год и проставлять нужные категории было очень долго и муторно, а использовать облачную LLM-модель мы не могли из-за персональных данных и наличия коммерческой тайны в переписках. 

Тогда мы решили освободить людей от муторного труда и категоризировать прошлые обращения с помощью локальной LLM. 

Следующий шаг — категоризировали исторические данные с помощью LLM. Расскажем, как мы запускали и настраивали локальную модель, чтобы она помогла нам автоматически категоризировать сообщения за прошедший период.

1. Выгрузили предварительно обработанные обращения в Excel, а потом загрузили всё в dataframe.

import pandas as pd
import requests
from tqdm import tqdm
import numpy as np
# Загрузка данных из Excel файла
excel_file = '/Users/пользователь/Desktop/my_file_name.xlsx'
df = pd.read_excel(excel_file)

2. Создали функцию с параметрами для работы с API локальной LLM. На этом этапе важно написать качественный системный промпт. Вот наш пример:

# URL вашего локального сервера LM Studio
api_url = 'http://localhost:9999/v1/chat/completions'
# Параметры запроса
model = "qwen3-30b-a3b"
temperature = 0.5
max_tokens = -1
# Функция для отправки сообщения и получения ответа
def send_message(message):
    headers = {'Content-Type': 'application/json'}
    data = {
        "model": model,
        "messages": [
            {"role": "system", "content": ("Ты решаешь задачу классификации. Тебе надо классифицировать сообщения пользователей в чат поддержки по группам."
                                            " Я буду высылать тебе текст сообщений, а тебе нужно его проанализировать и присвоить одну из групп."
                                            " Для каждого отдельного сообщения верни одну группу. Возможные группы: 1. 'Проблемы с обновлением' — запаздывает обновление, не обновились данные, отсутствуют данные в отчете за период"
                                            " 2. 'Некорректные привязки' — изменение менеджера, изменение структуры, внесли какие-то правки, но они не отображаются в отчете. Изменения, которые внесли, но они не отобразились."
                                            " 3. 'Проблема в отчете'— не работает визуал, поломались параметры в отчете, баг в визуализации, что-то исправить в отчете"
                                            " 4. 'Проблема в данных' — не сходятся цифры с тем, что ожидал увидеть пользователь. Данные не корректны. Проблема в витрине данных."
                                            " 5. 'Доступы к отчету' — проблема с доступом к отчету, row level security, RLS, нет прав доступа и тд"
                                            " 6.'Остальное' — все остальные проблемы, проблема не относится ни к одной из группы выше. Возвращай только название группы без комментариев")},
            {"role": "user", "content": message}
        ],
        "temperature": temperature,
        "max_tokens": max_tokens,
        "stream": False
    }
    response = requests.post(api_url, json=data, headers=headers)
    return response.json()

Несколько статей о том, как писать промпты:

• «Как написать эффективный промт для нейросети»;

• Effective Prompts for AI: The Essentials.

3. Далее протестировали, как это работает. Написали модели вопрос:

response = send_message("{Коллеги, привет! Ко мне пришел менеджер ****, говорит, что у него по поступлениям на сегодня и общему результату не хватает порядка 350к. У нас все данные доезжали? Не было сбоя?}")
response

И посмотрели, что она ответит: 

И забрали ответ: 

response['choices'][0]['message']['content']

4. Потом написали цикл для обработки каждого обращения в чате: 

for index, row in tqdm(filtered_df.iterrows(), total=filtered_df.shape[0]):
    message = row['Message_for_llm']         
    if pd.isna(message):
        assistant_response = "No message available"
    else:
        response = send_message(message)
        assistant_response = response['choices'][0]['message']['content']
    filtered_df.at[index, 'response'] = assistant_response  

5. Сохранили результат в Excel.

filtered_df.to_excel('/Users/пользователь/Desktop/my_result.xlsx', index=False)

После категоризации мы загрузили полученные данные — ID обращений и их категории — в базу данных и объединили их с основной информацией из чата.

Всего было около 1 300 обращений, и разметка заняла 3–3,5 часа. Время зависит от выбранной модели, например, рассуждающие модели работают медленнее, но дают более точные результаты.

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

Кейс 2: создаём базу знаний с помощью локальной LLM

У нас накопилась история обращений в поддержку за последние 2 года. Мы решили выделить из неё полезные сообщения и на их основе создать базу знаний — с ответами, конкретными примерами и типовыми ситуациями. Вот что для этого сделали. 

Сначала мы прогнали историю обращений в цикле для определения полезных, с точки зрения поддержки, сообщений. Например, отсеяли всё, что содержало слова «починил», «поправил», «это не наша ошибка», «давайте обсудим на встрече». Так мы удалили все чаты, где не было каких-то конкретных шагов решения проблемы.

Пример промпта, который использовали для такого отбора:

SYSTEM_PROMPT = """Вы - классификатор технических переписок. Анализируйте каждую переписку с точки зрения полезности для службы поддержки и определите его статус:

УДАЛИТЬ, если сообщение:

1. Системное уведомление (примеры: «Оператор подключился», «Диалог завершён», «Файл загружен», «Скриншот прикреплён»).

2. Не содержит информации о бизнес логики для будущих пользователей. 

3. Содержит только подтверждение решения без объяснений (примеры: «Сделано», «Исправлено», «Готово», «Спасибо», «Хорошо, жду», «Завел задачу»).

4. Состоит из перенаправления к другому специалисту. Или предложения встретиться и обсудить. Или что этот вопрос вне зоны ответственности.

5. Нет информации про тот как конкретно он решил проблему. 

6. Если переписка не содержит информацию, которую может использовать другой специалист для решения похожей проблемы. 

7. Содержит единоразовый баг, который был исправлен и больше не будет появляться.

Пример: 

@user_1: Добрый день. Подскажите, пожалуйста, когда будут подтягиваться данные по пользователям за Декабрь в папке Авто мес. Ранее это было в начале след.месяца.

@user_2: Привет! Закончили работу над исправлением отчета, можно идти проверять и пользоваться.

@user_1: Коллеги, безмерно благодарен! 

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

@user_1: Коллеги, привет! Клиент с id … в отчете Report_1 попадает со статусом started_as_SS (ну и соответственно не тянет, как новые деньги), а когда его по отчету Report_2 проверяешь — там он ... В чем может быть проблема, помогите, пожалуйста, разобраться?

@user_2: Привет! Отчет в зоне ответственности аналитиков, обратись плиз к ним. 

Нет понимания, как была решена проблема.

ОСТАВИТЬ, если сообщение:

1. Содержит описание проблемы и далее описание того, как её решили или из-за чего была проблема.

2. Включает конкретные шаги/инструкции для воспроизведения решения.

3. Содержит примеры корректных конфигураций или настроек.

4. Если переписка содержит информацию, которую может использовать другой специалист для решения похожей проблемы. 

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

6. Включает причинно-следственные объяснения технических процессов.

Пример: 

@user_1: Коллеги, привет. В двух отчетах по мотивации видим разные значения в планах. Почему есть разница? Какому отчету верить?

@user_2: В первом скрине отфильтрованы категории. План ставится на клиентскую базу, у небольшой части ID клиентов могут быть размечены категории не из … — из-за этого расхождение. То есть, вы смотрите план и факт в одном случае по полной базе, во втором случае — по ее части.

Есть четкий вопрос и четкий ответ, в чем проблема и как ее решить. Главная часть: план ставится на клиентскую базу, у небольшой части ID клиентов могут быть размечены категории не из недвижимости — из-за этого расхождение. То есть вы смотрите план и факт в одном случае по полной базе закрепленных клиентов, во втором случае — по ее части.

ПРАВИЛА:

• анализируйте ТОЛЬКО текстовое содержание без ссылок на отчеты;

• не учитывайте орфографические/грамматические ошибки;

• при сомнениях выбирайте «Оставить»;

• отвечайте ОДНИМ словом: Удалить/Оставить.

Остальной скрипт остался без изменений, его легко можно адаптировать под ваши задачи.

После прогона 2 002 чатов мы отобрали примерно 1 000 полезных. Если бы человек вручную читал и размечал каждый чат, это заняло бы в среднем по 3 минуты на чат — около 100 часов или 13 рабочих дней.

Наша модель справилась с этим за 8 часов 20 минут. Такое решение помогло нам сэкономить 100 часов или 13 дней рабочего времени, а ещё позаботиться о моральном состоянии сотрудников, избавив их от скучной и монотонной работы. 

Дальше мы убрали всю лишнюю информацию из сообщений. Не всегда удобно возвращаться к чужой переписке и вчитываться в неё в поисках ответа. Поэтому для оставшейся тысячи чатов мы запустили ещё один цикл проверки через LLM, чтобы выделить из текста только вопрос и ответ и убрать всю лишнюю информацию. 

Использовали вот такой промпт:

# Разделение системного и пользовательского промптов

SYSTEM_PROMPT = Вы — ассистент для структурирования переписок технической поддержки. Ваша задача:

1. ОБРАБОТКА ДИАЛОГА:

• определи основной вопрос пользователя (даже если он сформулирован в нескольких сообщениях);

• выдели конечный ответ поддержки, решивший вопрос;

• если ответ распределен в нескольких сообщениях - объедини их логически;

• сохраняй исходную терминологию;

• убирай маловажную информацию: «Коллеги, привет...», «Все зависит от задачи, но в целом можно...»;

• удали все имена; 

• вопрос и ответ должны быть четкими.

2. ФОРМАТИРОВАНИЕ:

• для каждого решение инцидента выводи в формате:

question: «[основная суть вопроса пользователя]»

answer: «[ответ на вопрос, без привязки к конкретному примеру]»

• если вопрос не был решен — укажи answer: "NO SOLUTION PROVIDED"

3. ОСОБЫЕ СЛУЧАИ:

• множественные вопросы в одном диалоге: разделяй на отдельные пары question-answer;

• уточняющие вопросы оператора: не считай их основным вопросом;

• сохраняй нумерацию сообщений из оригинального диалога в комментариях.

Пример: 

@user_1: Привет! Подскажите, хочу к новым раскладкам притянуть менеджера К dds... и dds... Но почему-то ничего не джойнится с dds... Это ожидаемое поведение или что-то не так? 

@user_2: Привет! а как вы джойните? 

@user_1: Итоговая связка (https…) 

@user_2: Посмотрел ваш [загрузчик](https…), джойниться напрямую и не будет. Только через 2 хаба.

@user_2: https:… точно верная логика? Мне кажется, там должно быть — «…» вместо «…», но это, конечно, зависит от задачи, которую вы решаете.

Пример:

@user_1: Тут задача притянуть к сделке менеджера MSD, которого проставили в Битриксе. Мы сегодня с @user еще обсуждали процесс взаимодействия с данными битрикса, нам бы хотелось как раз провалидировать то, что мы сделали и выстроить дальнейший процесс с данными. 

@user_2: Давайте запланируем встречу и обсудим — какие данные вам нужны.

@user_1: Мне кажется текущие вопросы можно офлайн решить, сейчас нам нужно: к сделке притянуть менеджера и агентского менеджера (… и …). Вот тут нужна ваша помощь, как это сделать корректно. А дальше обсудили с @user, что в будущем мы будем просто заранее к вам приходить с тем, что нам нужно. 

Если еще нужно обсудить — можем, конечно, встретиться. 

[«Ответ»: question: почему такая разница в отчетах по выполнению? Квартальный план (больше) vs Месячный план (меньше). 

answer: в факт за месяц признаются только траты вертикали услуг»].

Пример:

@user_1: Привет, сориентируйте плиз, где во вкладке квартальный план смотреть тотал? 

@user_2: Привет! Тоталы не выведены в этом дашборде, как вариант — скачать в эксель и просуммировать. 

@user_1: Чет неудобно, а можно вывести?

@user_2: Можно, но не сегодня точно).

@user_1: Ну давайте не сегодня, но выведем плиз). 

[«Ответ»: question:где во вкладке квартальный план смотреть тотал? 

answer: Тоталы не выведены в этом дашборде, как вариант — скачать в эксель и просуммировать].

USER_PROMPT_TEMPLATE = """

Обработай диалог: {chat_history}

Требования:

• максимальная близость к оригинальным формулировкам;

• е добавляй интерпретаций/дополнений/примечаний/комментариев;

• для длинных URL используй сокращения [...].

В среднем, на преобразование переписки в формат FAQ может уходить до 10 мин, а LLM сделала это за 7 часов 10 минут — так что мы сэкономили ещё 166 часов или 21 рабочий день.

На текущем этапе мы ещё не создали базу знаний, но вот какие шаги планируем сделать дальше: 

1. Проанализируем все диалоги с помощью LLM и разделим их на 2 группы: диалоги, в которых есть техническая ценность, бизнес-знания или неявные нюансы и переписки, которые не содержат ценности. 

2. Сделаем рефакторинг «полезной» переписки в формат FAQ, а также обезличим данные. Формат будет представлять из себя вопрос и ответ на него. 

Это позволит упростить работу дежурных в чате поддержки и сократить время решения проблем. В дальнейшем можно будет интегрировать в чат Retrieval Augmented Generation (RAG) систему. 

Про RAG читайте в статье на Хабре: «RAG (Retrieval Augmented Generation) — простое и понятное объяснение».

Вместо выводов: практические советы, как внедрять локальные LLM и писать рабочие промпты 

Задачи, которые мы описали в тексте, это лишь небольшая часть того, что можно сделать с помощью локальной LLM. Если решите внедрять такие решения у себя, вот вам наши рекомендации:

1. Начните с малого. Выберите одну чётко очерченную, повторяющуюся задачу. Например, классифицировать клиентов по всем их отзывам, нормализировать адреса клиентов или сделать их дедупликацию. Проверьте, возможно ли решить поставленную задачу с помощью локальной LLM и только потом масштабируйте. Успех на небольшом участке даст понимание, мотивацию и аргументы для масштабирования.

2. Инвестируйте в Prompt Engineering. Качество результатов на 80% зависит от качества промпта. Пробуйте разные формулировки, добавляйте контекст, просите конкретный формат, например, JSON.

3. Задавайте модели конкретную роль в промпте. Например, «Ты — опытный аналитик, классифицирующий карточку товара на продающие и не продающие». 

4. Давайте качественные примеры решений. Включайте в промпт 2-5 примеров входных и идеальных выходных данных. Это самый надёжный способ объяснить задачу модели. Например, мы часто используем DeepSeek — правим и тестируем промпты прямо в интерфейсе.

5. Тщательно выбирайте модель. Универсальной модели не существует, например, модели, которые хорошо справляются с кодингом, часто плохо категоризируют текст. Тестируйте варианты на своих данных

Ещё важно учитывать баланс размера и качества модели. Для простых задач классификации, извлечения по шаблону подойдут маленькие модели. Например:

• Phi-3 3.8B, TinyLlama — обычно они достаточно точны и работают очень быстро даже на CPU; 

• Mistral 7B — отличный выбор для баланса производительности, качества и требований к ресурсам;

• Llama 3 8B/70B или Qween 3 30B/70B — топ для сложных задач, но требуют мощного железа. 

Также уделите внимание выбору квантования модели — использование облегчённых версий, например, int8 или int4 снижает требования к ресурсам без сильной потери качества.

6. Настраивайте параметры генерации чётко под задачи. Для разных задач разный набор параметров.

• Temperature — определяет, насколько «творческой» будет модель. Чем она выше — тем более творческие задачи можно будет решать;

• Max_tokens контекстное окно — максимальное количество токенов, которые принимает модель. Чем больше, тем больше памяти будет занято;

• Keep_in_memory = false — параметр, который определяет, будет ли модель загружаться в оперативную память или нет. Если не загружать — это будет замедлять скорость работы, но позволит работать с более объёмными моделями;

• Number_of_experts — количество экспертов внутри модели. Чем их больше, тем точнее результат, но тем сложнее им договорится между собой. При большом количестве модель может не выйти из режима размышления. 

7. Проверяйте результаты! Не доверяйте модели вслепую, особенно на старте. Внедрите простые правила валидации, например: «JSON парсится корректно?», «Значения соответствуют нужному списку?», «Дата в правильном формате?».

Что в итоге. Локальная LLM не заменяет человека, а снимает рутинную нагрузку, ускоряет обработку информации и улучшает её структурированность. Также это не замена облачным гигантам, а мощный дополнительный инструмент для специфических задач, где конфиденциальность и контроль на первом месте. 

С каждым днём локальные модели становятся всё умнее и эффективнее при тех же требованиях к «железу» и уже сейчас они способны на многое. Посмотрите на свои рутинные текстовые задачи. Какую из них вы могли бы автоматизировать уже сегодня? 

Экспериментируйте!

Подписывайтесь на «Коммуналку аналитиков» телеграме. Там ещё больше кейсов из работы аналитиков Авито.

А если хотите вместе с нами помогать людям и бизнесу через технологии — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.