Внутри AI | Кейсы ИИ Агентов в бизнесе
648 subscribers
11 photos
2 files
41 links
AI Агенты и их применение в бизнесе
Обзоры, кейсы, практика
Download Telegram
Channel name was changed to «Внутри AI | Кейсы ИИ Агентов в бизнесе»
Привет!

Здесь мы будем рассказывать про то, как ИИ-агенты используются в бизнесе для повышения эффективности и простым языком объяснять, как они устроены внутри.

В канале будем рассказывать про:
– Кейсы крупных компаний и стартапов по всему миру
– Как мы сами внедряем AI в работу компании и что делаем для российских клиентов
– Устройство AI-агентов на понятном языке с упором на бизнес-эффект

Канал ведут основатели KTS — IT–компании со штатом в 170+ специалистов, основанной выпускниками МГТУ, которая создает IT-продукты для крупного бизнеса с 2015 года.

Что мы уже делали в ML и AI?
– Разработали MLOps-платформу вместе с Альфа-банком.
– Создавали виртуального помощника для банка ДОМ.РФ (читать кейс)
– Сделали собственную платформу для создания чат-ботов с ИИ
– Разработали ML–сервис с оценкой психологических характеристик кандидатов по резюме для автоматического подбора на массовые вакансии в США и Канаде.
– Сделали рекламный спецпроект с CV, который распознаёт родинки на фото и превращает их в мелодию. Проект выиграл премию Effie
– Занимались анализом временных рядов для приоритизации биржевых стратегий

и многое другое
🎉112
Внутри AI | Кейсы ИИ Агентов в бизнесе pinned «Привет! Здесь мы будем рассказывать про то, как ИИ-агенты используются в бизнесе для повышения эффективности и простым языком объяснять, как они устроены внутри. В канале будем рассказывать про: – Кейсы крупных компаний и стартапов по всему миру – Как мы…»
Что такое агенты?
На мой взгляд, одно из наиболее понятных объяснений сделал Anthropic. Кратко расскажу и дополню основные мысли статьи.

Из чего состоит агент?
- Ядро (LLM call) — планирует и принимает решения. Ядро анализирует входные данные, сопоставляет их с контекстом, решает, какой следующий шаг будет оптимальным, и вызывает его.
- Память (context) — здесь агент хранит контекст последнего взаимодействия и, опционально, долговременные данные, например: историю действий, результаты предыдущих операций и т.д.
- Действие (Action). Действия можно разделить на модули восприятия и исполнения. Модули восприятия обогащают контекст взаимодействия с окружающей средой. Так, например, они: получают данные из API, выполняют поиск по интернету и прочее. Модули исполнения — это руки агента; с помощью этих модулей агент может создавать задачи в трекере, отправлять письма, вызывать API и выполнять любые другие действия.

Ключевым отличием агента от LLM с “руками” является многоэтапность и цикл обратной связи. Агент не пытается решить поставленную задачу за одно действие, он автоматически разбивает ее на подзадачи. Выполняя подзадачи, он получает новые знания из окружающей среды и на основе этих новых знаний корректирует план выполнения, и таким образом точнее решает поставленную задачу.
52
Теперь разберемся, как работает кодовый агент, например: Claude Code. На картинке выше показана диаграмма последовательности работы агента. В главных ролях: Человек (Human), Интерфейс (Interface), Модель (LLM) и среда выполнения (Environment):

Запрос от человека (Human)
Пользователь формулирует задачу и отправляет запрос через интерфейс.

Стадия уточнения задачи (Interface LLM, “Until tasks clear”)
Пользователь «общается» с LLM, чтобы уточнить детали задачи:
- Clarify – модель может задавать наводящие вопросы или просить дополнительные данные, уточнения, форматы;
- Refine – модель (при необходимости вместе с человеком) переформулирует или корректирует задачу, пока её формулировка не станет конкретной и понятной.

Отправка контекста модели (Send context)
Как только задача сформулирована достаточно четко, передается контекст и вся необходимая информация модели.

Обогащение контекста: поиск файлов / данных в среде (Search files → Return paths)
LLM делает запрос в среду (Environment), чтобы найти необходимые ресурсы, файлы и участки кода.

Решение задачи (Until tests pass)
- Write code – модель (LLM) генерирует код.
- Status – модель или среда может сообщать текущее состояние работы, например, процесс компиляции.
- Test – запускаются тесты или проверки, чтобы понять, корректен ли полученный результат.
- Results – возвращаются результаты тестирования (успешные или с ошибками).
- GoTo “Write code” – на основе полученных результатов (ошибках компиляции / тестирования) агент обогащает контекст и с новыми знаниями переходит на этап Write code.
Этот цикл «Write code → Test → Results» повторяется, пока все тесты не будут пройдены успешно, либо пока не будет достигнут условленный критерий завершения.

Завершение и отправка результата
После успешного выполнения задачи модель возвращает итоговый результат (Complete).

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

Представьте, что у вас есть умный помощник (AI), который знает очень многое, но не всё. Что, если этому помощнику дать возможность что-то подсмотреть в справочнике или интернете, прежде чем ответить?

Именно эту идею реализует RAG (Retrieval-Augmented Generation) — «генерация с дополнением извлечённой информации». Проще говоря, благодаря RAG языковая модель не полагается только на свою внутреннюю «память», а подтягивает свежие данные из внешних источников, чтобы ответы были точнее и актуальнее. Такой подход помогает модели опираться на реальные факты и снижает риск, что она уверенно выдаст ложное утверждение.

Ограничения классического RAG

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

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

- Система не умеет рассуждать или планировать шаги: она берёт запрос как есть и ищет по нему, даже если он сформулирован неточно или расплывчато. RAG-пайплайн не адаптируется под сложные или многоэтапные вопросы. В результате сложные, многосоставные задачи (где, скажем, надо и поискать в нескольких местах, и сделать вычисления) ставят такую систему в тупик.

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

Иными словами, традиционный RAG-подход хорош для ответов на простой фактологический вопрос из базы данных, но ему не хватает гибкости. Он не «подумает» сам, какой инструмент лучше использовать для решения нестандартной задачи, потому что умеет только искать по тексту. В эпоху, когда промпты пользователей становятся всё сложнее и разноплановее, такой узконаправленный подход начинает устаревать.
👍421
RAG умер. Да здравствует RAG!

Новая волна ИИ-систем идет по своему пути. Вместо того, чтобы жестко пришивать RAG ко всем запросам, современные подходы дают модели набор инструментов и возможность самостоятельно выбирать, что и когда использовать. Модель превращается в агента, который может планировать действия: если понадобилась актуальная информация — агент решает выполнить поиск через RAG, если нужно посчитать — берёт в руки калькулятор, и так далее.

В таких системах RAG интегрирован внутрь более общей архитектуры. Например, OpenAI в своем новом Agents API позволяет подключить сразу несколько разных инструментов. Один и тот же AI-ассистент может в ходе диалога по необходимости:

- искать информацию — в интернете или по внутренней базе знаний (тот самый RAG, но вызывается только при необходимости);

- считать на калькуляторе — если вопрос про цифры или требует расчётов;

- просматривать веб-страницы — например, открыть ссылку и прочитать содержимое;

- запускать код — чтобы, к примеру, трансформировать данные или выполнить сложные действия;

- и многое другое (запросить данные из базы через API, использовать календарь и т.п.).

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

Если вы спросите у такого помощника что-то про статистику компании, он сначала дернет RAG, найдёт цифры в вашей корпоративной базе знаний, а потом может тут же вычислить проценты на калькуляторе и выдать связный ответ. Если же вы спросите прогноз погоды, он обратится к веб-API погоды, а RAG не потребуется вовсе. Важно, что RAG-инструмент используется только тогда, когда нужен, в контексте общего интеллектуального планирования.

От систем, где приходилось вручную склеивать поиск, модель и другие сервисы, мы пришли к универсальным агентам, которые сами определяют все необходимые действия. Такой подход упрощает разработку и повышает интеллект системы, ведь агент умеет адаптироваться под задачу. Для бизнеса же это означает появление более умных чат-ботов и ассистентов, которые могут и на вопрос по документации ответить, и расчёт сделать, и по необходимости свежие данные подтянуть.
4👍3🔥2