Перейти к основному содержимому
megapromotingДавайте обсудим

Экспертиза · Интеграции и автоматизации

Чтобы ваши системы говорили друг с другом, без того чтобы кто-то заново вводил те же данные.

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

Уже построеноСобственные интеграции, написанные и запущенные, измеренные сегодня в коде: коннектор для системы бронирования Altegio (946 строк, с шестью инструментами, доступными агенту), коннектор CRM amoCRM (2.888 строк на платформе сообщений, плюс 12 серверных функций на голосовой платформе), Bitrix24 (903 строки, плюс 4 функции), Google Sheets (615 строк, плюс 10 функций и выделенная служебная учетная запись), живой каталог поверх магазина (сервис платформы, 318 строк), уведомления о lead в Telegram (1.776 строк), SMS через Infobip с антиабьюз-лимитами, запланированные автоматизации (1.088 строк) и чат-канал локальной платформы объявлений (2.459 строк). В исполнении агент может вызывать 15 типов внутренних инструментов, помимо инструментов через webhook и инструментов со своим кодом, запускаемым в изоляции.

Интеграция — это не логотип на странице. Это ответ на очень конкретный вопрос: может ли эта система читаться и записываться в реальном времени, кем, с какими правами, и что происходит, когда она не отвечает? Поэтому наш первый вопрос к любой интеграции — не «с каким API», а «какой у неё публичный вход». Иногда ответ полностью меняет стоимость работы: магазины на WooCommerce, например, публично предоставляют API магазина, который не требует никакого ключа потребителя, поэтому новый клиент подключается только с адресом своего сайта — не с учётными данными, которые нужно сгенерировать, отправить, а затем ротировать.

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

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

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

Прозрачная автоматизация — интеграции, которые можно проверить · видео на румынском, с субтитрами и расшифровкой на русском

Полная расшифровка

Давайте сразу к сути. Сегодня мы разберём технические и, честно говоря, часто игнорируемые реалии автоматизации с помощью ассистентов на базе искусственного интеллекта. Мы сосредоточимся на суперпрагматичном подходе платформы iCat.md, разработанной Mega Promoting. Сегодня у нас нет маркетинговых обещаний и, конечно, нет расплывчатых концепций. Мы говорим о платформе, которая прямо в production, с функциональностью, объяснённой прямо из архитектуры базы данных. Так что давайте посмотрим, как на самом деле выглядит полностью прозрачная автоматизация. Повестка этого анализа проста и по делу. Мы пройдём через проблему времени, механику технологии, реальный кейс, чёткие ограничения системы, управление данными и следующие шаги. Начнём с первого раздела, проблемы времени. Вы все знаете этот крайне раздражающий вопрос? Почему целая служба поддержки теряет часы каждый день, вручную пиша ответы на одни и те же пять вопросов?

Информация уже есть на сайте компании, но, несмотря на это, клиенты продолжают снова и снова запрашивать детали. И именно в этом суть нашей проблемы. Без подходящего технического решения все эти повторяющиеся обращения просто забивают direct messages, не важно, Instagram это или Messenger. В результате ответы сильно запаздывают для клиентов, у которых действительно сложная проблема, запросы теряются в море сообщений, а весь процесс поддержки становится по сути чёрным ящиком, который нельзя ни проверить, ни измерить. Часть вторая. Как на самом деле работает технология под капотом? Вот как обстоят дела. Настройка платформы основана на четырёх очень логичных шагах. Сначала мы подключаем каналы коммуникации с помощью собственного кода. Затем индексируется вся база знаний. Далее идёт связка инструментов, которые могут выполнять действия в ваших существующих системах.

А в конце, и эта деталь жизненно важна, настраивается чёткий маршрут, записанный прямо в базе данных, по которому бот передаёт разговор живому оператору. Всё это — видимая и полностью настраиваемая система. Теперь один абсолютно fascinating момент. Мы не говорим здесь о глюках. Это настройки, взятые прямо из схемы базы данных. Когда ассистенту нужен ответ, он использует так называемый гибридный поиск. По умолчанию алгоритм извлекает 5 фрагментов текста, применяет строгий порог сходства 0-70 и придаёт 30% веса точному совпадению слов. Всё обрабатывается через модель Text Embedding 3 Small. По сути, система превращает слова в математические концепты, чтобы уловить точный контекст. Ответы — не гадание, а чистая математика. Запомните это число. 15. Это абсолютное техническое ограничение в системе. Оно обозначает максимальное время, в секундах, выделенное на запуск любого инструмента или поиска.

Если внешняя интеграция длится дольше, скажем, ей нужно 40 секунд, мы не можем оставить её в live-потоке разговора. Она должна обрабатываться асинхронно, иначе полностью сломается естественный ритм диалога. И ещё кое-что. Люди пишут в чат рывками, верно? 2, 3, 4 коротких сообщения одно за другим. Чтобы не сводить систему с ума, существует буфер concatenation на 15 секунд. Всё, что приходит в это окно, склеивается и становится одним чётким запросом. Более того, на платформах вроде Meta, где иногда приходится сталкиваться с дублирующими сообщениями, отправленными по ошибке, система применяет фильтр памяти на 120 секунд по ID сообщения. Так клиент получает один связный ответ, а не 3 ложных тревоги. Раздел третий. Посмотрим на реальный кейс. У нас есть этот классический e-commerce сценарий. Есть онлайн-магазин с безупречным каталогом на сайте, но который получает лавину личных сообщений в Instagram и Messenger?

Есть в наличии? Какая цена? Здесь интеграция была сделана элегантно: ассистент был подключён напрямую к публичному Store API от WooCommerce. Без сложностей с безопасностью, живой каталог магазина просто был передан в руки ассистента. Но здесь вмешивается техническая реальность каждой платформы, даже под зонтиком одной и той же компании, как Meta. В Messenger ассистент может показывать вам красивые карусели товаров. В Instagram бот ответит вам только текстом и максимум одним простым изображением. Почему? Просто потому, что Meta не поддерживает эти generic templates в Instagram. Ассистент должен играть ровно по правилам канала, где он находится. Здесь критический момент. Что происходит, когда бот не справляется? Ну, в базе данных разговор имеет явные состояния. Когда вопрос выходит за пределы каталога, нить диалога сразу переходит из состояния bot в состояние human.

И гениальная часть в том, что система считает время, в течение которого отвечает живой оператор, чётко помечая всё: status OK, avertiziment или превышенный срок. Весь контекст передаётся человеку, без того чтобы что-либо потерялось по дороге. Раздел A4 Ограничения системы Потому что прозрачность означает знать, что она не может делать. Есть несколько жёстких ограничений, которые мы должны принять. Вы не можете отправлять proactive messages в WhatsApp, если прошло более 24 часов с момента сообщения клиента. Meta выдаст ошибку, точнее ошибку 131047, и действие не выполнится. Система не делает RPDF-файлы, не читает вложения. Что касается иностранных языков, переводы работают только в одном направлении. Клиент получает переведённый ответ, а оператор видит оригинал. И хотя интеграция с 999.md работает, она неофициальная и основана на cookie из браузера.

Если платформа изменит свои механизмы, соединение упадёт и потребует ремонта. И обязательно запомните это. Ассистент — это зеркало ваших данных. Неправильная цена на сайте гарантированно станет неправильной ценой в разговоре. Он действует как читатель, а не как менеджер магазина. Он не будет по собственной инициативе исправлять человеческие ошибки в каталогах. Техническая инфраструктура здесь — не шутка. Всё держится на частном сервере Microsoft Azure. Мы говорим о крайне структурированной базе данных MySQL, с более чем 80 таблицами, четко смоделированными для разделения каналов и для аудита. Ключи доступа для WhatsApp, которые являются сверхчувствительными, используют шифрование fernet. Кроме того, на веб-уровне домены для чат-виджета вручную добавляются в белый список. Никто не подключается без явного разрешения. Но нужно затронуть очевидную реальность. Люди будут писать самые разные персональные данные в этих окнах чата: номера телефонов, адреса.

Технически невозможно заблокировать поле свободного текста. Поэтому решение — административное. Когда вы внедряете такую систему, вам с первой секунды нужны четкие политики хранения, которые точно определяют, кто имеет право видеть эти данные и как долго они хранятся. И мы дошли до пункта 6. Следующие шаги. Центральную философию всей системы можно резюмировать этой цитатой. Умный помощник — это не тот, кто сочиняет стихи или красиво пишет, а тот, кто подключён к реальной информации и, что очень важно, точно знает, где ему нужно остановиться. Эффективная автоматизация в бизнесе означает корректный сбор данных и уверенность, с которой вы передаёте контроль человеку-оператору в нужный момент. Поэтому следующий шаг — не покупать софт, а внимательно проанализировать ваши текущие процессы. Оцените, какие рабочие потоки действительно стоит построить и автоматизировать, как их можно безопасно связать и, самое главное, определите, как вы будете измерять результаты с реальными данными, а не с иллюзиями маркетинга.

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

Что входит

Работа, по составляющим

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

Для магазинов на WooCommerce мы используем публичный магазинный API, которому не нужен consumer key: клиент подключается только по адресу сайта. Это выбор, у которого есть реальные последствия, а не только эстетические — мы заменили им написанные вручную инструменты, которые хранили ключи магазина в открытом виде в базе данных. Когда у системы нет публичного входа, мы переходим к аутентификации, но тогда ключ становится элементом, которым управляют, а не тем, который забывают в строке базы данных.

Ключи остаются на сервере, не в инструменте и не в странице

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

Агент вызывает инструмент во время разговора, с параметрами и сроком

У каждого инструмента есть написанное для модели описание, типизированные параметры с обязательными и необязательными полями, и собственный срок выполнения — от 15 секунд для списка услуг до 30 для поиска доступности. Срок для каждого инструмента — не деталь: без него медленная интеграция блокирует разговор, а человек на другом конце слышит тишину.

Реальные записи в системе салона или клиники

Шесть инструментов над Altegio: список услуг с реальными ценами, специалисты, полная доступность, создание записи, отмена и изменение. Доступность возвращает не только «свободен/занят»: она возвращает, какие специалисты оказывают запрошенную услугу, и первые свободные часы для каждого, отсортированные по самому раннему, именно чтобы агент мог предложить конкретную альтернативу вместо того, чтобы говорить «недоступно».

Каталог магазина, читаемый вживую

Цена и доступность читаются из магазина в момент вопроса, а не из устаревшей копии. Каталог загружается постранично, до 30 страниц по 100 товаров, хранится в временной памяти десять минут на сайте и нормализуется в единую форму, читаемую без изменений всеми потребителями — включая карусель товаров в мессенджере, которой нужна числовая цена, и виджет на странице, которому нужен заголовок.

CRM, таблицы и каналы сообщений

amoCRM и Bitrix24 с полным OAuth, обновлением токена и проверкой состояния. Google Sheets через отдельную учетную запись службы, отделенную от остальных учетных данных, с записью, запускаемой агентом. Telegram для уведомлений о лидах. SMS через Infobip. Плюс чат-канал локальной платформы объявлений, подключенный с собственным refresh token — тип интеграции, которого нет ни в одном международном каталоге и который очень важен локально.

Автоматизации, которые выполняются со временем, со счетчиками

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

Антиабузные лимиты, потому что решение принимает модель

Инструмент, вызываемый языковой моделью, нуждается в границах, которые модель не может перейти. Для SMS: в режиме «к фирме» получатель берется из конфигурации, никогда не от модели; в режиме «к клиенту» номер нормализуется и проверяется. Помимо этого, дневной лимит на одного агента, пауза в одну минуту на тот же номер и ограничение длины сообщения. Это ограждения, написанные в коде, а не инструкции в prompt — prompt можно обойти, ограждение нельзя.

Выходные фильтры, для данных, которые не должны выходить

Когда интеграция возвращает больше, чем должен знать клиент, мы фильтруем на выходе, а не надеемся, что агент удержится. Реальный пример: для клиента в сфере транспорта политика запрещает агенту диктовать номер телефона водителя, но API возвращал эти номера в ответе. Мы написали фильтр, который рекурсивно проходит результат инструмента и удаляет контактные поля водителя, сохраняя номера диспетчерской. Фильтр применяется ровно там, где нужно, а не глобально, чтобы случайно не скрыть что-то другое.

Как это выглядит

Путь, шаг за шагом.

01

Инвентарь: какие системы, какие шлюзы, какие права

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

02

Коннектор: объявленные инструменты, ключи на сервере, сроки

Каждое действие становится инструментом с названием, описанием, написанным для модели, типизированными параметрами и собственным сроком. Ключи остаются в серверной среде. В конце агент не «умеет делать» что-то расплывчатое: у него есть конечный набор действий, каждое со своими границами.

03

Тест на случае, который ломается, а не только на том, который работает

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

04

Устойчивость к нестабильности другой системы

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

05

Передача: что меняется, когда меняется поставщик

Мы отмечаем, что ломается, если другая система меняет свой API, какие учетные данные истекают и когда, что нужно обновить вручную. Интеграция без этого списка — скрытый долг: она работает безупречно до того дня, когда перестает работать, и никто не знает почему.

Один центр. Вокруг — что входит в него, по отдельным маршрутам.ЦЕНТР ОПИРАЕТСЯ НА ВСЁ, ЧТО ЕСТЬ ВОКРУГ НЕГО
Внешние системы вокруг разговора: записи на приём, каталог магазина, CRM, таблицы, SMS и каналы сообщений — каждая читается по запросу, а ключи остаются на сервере.

Данные

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

Вопросы, которые задаёт всякий, у кого есть ответственный за защиту данных, — заданы здесь раньше, чем их задаст он.

Где хранятся учетные данные
Ключи поставщика платформы хранятся в серверной среде, а не в базе данных и никогда не на клиентской странице. Собственные учетные данные клиента — там, где интеграция их требует — хранятся в зашифрованном виде. Разница важна: скомпрометированный ключ платформы затрагивает всех, учетные данные клиента затрагивают один аккаунт; мы относимся к ним по-разному, потому что риск разный.
Что сохраняется из внешних систем, а что нет
Каталог товаров не копируется: он читается по запросу и хранится во временной памяти десять минут, чтобы десять последовательных вопросов об одном и том же магазине не означали десять полных обходов. Записи у нас не дублируются — источником истины остается система салона. Мы сохраняем след разговора и результат действия, а не копию базы другой системы.
Что попадает в языковую модель
Результат инструмента входит в разговор, значит, входит и в контекст модели. Поэтому фильтрация выполняется на результате, до того как он будет передан модели, а не в инструкциях. Поля, которые клиент не имеет права слышать, удаляются у источника; то, что удалено, нельзя продиктовать, независимо от того, как спрашивают агента.
Кто может подключить интеграцию
Подключение интеграции — это аутентифицированная операция, привязанная к аккаунту бизнеса, а полученные инструменты прикрепляются к конкретному агенту — не ко всем. У агента есть ровно те инструменты, которые нужны для его роли. Это та же логика, что и с доступом сотрудника: ему не дают все ключи только потому, что так проще.
Что осталось исправить, сказано открыто
Не все интеграционные модули в нашей платформе находятся на одном уровне. Перечисленные здесь написаны и запущены. Есть и начатые модули, в несколько десятков строк, которые пока не делают ничего полезного — мы не представляем их как доступные и не включаем ни в одно предложение. Если вам нужна система, которая у нас находится на этой стадии, мы рассматриваем ее как работу, которую нужно построить, с предварительной проверкой совместимости, а не как пункт для галочки.

Случай

Интеграция падала периодически, и проблема была не у нас

Ситуация

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

Что мы построили

Причина была в сети, на другой стороне. Доменное имя аккаунта CRM разрешается в несколько IP-адресов, а часть узлов кластера была нездоровой. Обычный HTTP-запрос выбирает один адрес и, если тот не отвечает, не пробует остальные адреса, возвращённые DNS — автоматического перехода к следующему ответу нет. Исправление состояло в том, чтобы больше не использовать стандартный HTTP-клиент для этого домена: мы сами разрешаем имя, открываем зашифрованные соединения напрямую к каждому адресу параллельно, с коротким сроком ожидания на каждый, и используем первый, который отвечает; если в одном раунде все холодные, процесс повторяется.

Что получилось

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

Чего этот случай не говорит

Это исправление компенсирует проблему другого, и это нужно говорить. Оно добавляет сложность в наш код из-за дефекта в инфраструктуре поставщика; если тот исправит свой кластер, сложность останется у нас. Мы документируем это именно так, чтобы её можно было убрать, когда она больше не понадобится.

Вопросы

О чём нас спрашивают перед тем, как позвонить

Какие системы вы реально, а не теоретически, подключили?

Систему записи Altegio, с шестью действиями, вызываемыми агентом. amoCRM и Bitrix24, с полным OAuth и обновлением токена. Google Sheets, с отдельным сервисным аккаунтом. Магазины на WooCommerce, через публичный API магазина. Telegram, для уведомлений. Infobip, для SMS. Чат-канал локальной платформы объявлений. Плюс каналы сообщений Meta и Telegram для разговоров. Для любой другой системы — включая платформы магазинов, которые мы не довели до конца — честный ответ таков: по запросу, после проверки совместимости, рассматриваемой как работа, а не как настройка.

Мой магазин должен генерировать мне API-ключи?

Для WooCommerce — нет. Мы используем публичный API магазина, который не требует ключа потребителя — вы подключаетесь через адрес сайта. Это и безопаснее, не только проще: таким подходом мы заменили более старые инструменты, которые держали ключи магазина в открытом виде в базе данных. Для других платформ это зависит от того, что они предоставляют; мы проверяем это до того, как что-либо обещать.

Может ли агент реально создать запись, а не только сказать, что делает это?

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

Куда попадают мои ключи?

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

Может ли агент отправлять SMS кому захочет?

Нет, и это намеренное ограничение. В режиме уведомления компании получатель берется из конфигурации — модель не может выбрать его сама. В режиме для клиента номер нормализуется и проверяется. Сверху есть суточный лимит на агента, пауза в одну минуту на тот же номер и ограничение по длине сообщения. Это ограждения в коде, а не инструкции в prompt; prompt можно обойти в разговоре, ограждение — нет.

Что происходит, когда чужая система падает или отвечает медленно?

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

Что происходит, если поставщик меняет свой API?

Что-то ломается, и именно поэтому мы предпочитаем официальные шлюзы вместо чтения страниц. Инструменты, которые извлекают информацию из HTML сайта, ломаются при любом изменении темы — мы намеренно заменили их одной реализацией поверх официального API, именно чтобы не поддерживать десятки хрупких вариантов. Когда альтернативы нет, мы говорим, что это хрупкое решение, и относимся к нему соответственно.

Вы можете делать автоматизации без агента, только по расписанным правилам?

Да. Повторный запуск разговоров без ответа, первое сообщение новому контакту, остановка и запуск агента по рабочему графику — это запланированные задачи, которые работают сами. У каждой есть собственные счетчики запусков, отправленных сообщений, пропущенных сообщений и ошибок, чтобы на вопрос «запустилось ли?» можно было ответить цифрой, а не предположением.

Как вы гарантируете, что агент не скажет лишнего из-за интеграции?

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

На чём основаны утверждения выше (18 источников)

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

Что вы хотели бы наладить?

Расскажите о своём процессе. Вместе определим, что стоит построить, что можно подключить и как проверим результат.

Давайте обсудим