Комментарии

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

С 2003 года я работал с многими веб-разработчиками в Европе и — последние два года — в России. На основании своего опыта могу сказать: ДСТ — это самые быстрые и адекватные разработчики из всех, с кем мне доводилось работать.

Хотели бы выразить благодарность Компании ДСТ за отличную работу. Заказали корпоративный сайт. Сроки выполнения работ минимальные. Подобрали оптимальный формат, разработали стиль, со вкусом оформили содержание. Со знанием дела консультировали на каждом этапе разработки, предлагая более грамотные решения. Планируем и дальше сотрудничать с этой компанией. Рекомендуем…

Хотели бы выразить благодарность Компании ДСТ за отличную работу. Заказали корпоративный сайт. Сроки выполнения работ минимальные. Подобрали оптимальный формат, разработали стиль, со вкусом оформили содержание. Со знанием дела консультировали на каждом этапе разработки, предлагая более грамотные решения. Планируем и дальше сотрудничать с этой компанией. Рекомендуем…

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

Плюсы сотрудничества:

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

С DST Global мы чувствуем себя в безопасности, зная, что наши клиенты всегда получают актуальную информацию. Настоятельно советуем компанию всем, кто ищет качественное и доступное сопровождение сайтов.

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

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

Мы уверены, что с помощью DST Global наш сайт будет всегда актуален и привлекателен для клиентов. Рекомендуем всем, кто ищет надежного партнера в области сопровождения сайтов!

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

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

Мы уверены, что с помощью DST Global наш сайт будет всегда актуален и привлекателен для клиентов. Рекомендуем всем, кто ищет надежного партнера в области сопровождения сайтов!

Ну я считаю вот как:
Как IT-компании организовать круглосуточную техподдержку

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

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

Как правило, организация службы техподдержки осуществляется по одному из трех следующих сценариев:

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

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

В этом случае в службу техподдержки входит не более 2–5 человек. Работа осуществляется обычно по основному графику 5/2 с дежурством одного сотрудника в выходные дни и ночное время.

При таком формате работы есть некоторые ограничения – вне основного графика сотрудник техподдержки решает вопросы, соответствующие его квалификации, а более сложные откладывает до прихода разработчиков. Фактически разработчики остаются перегруженными. Это негативно сказывается на соблюдении сроков, поставленных в уровне сервиса SLA, а также влияет на отношение клиентов и репутацию компании.

На основе сменного графика сотрудников равной квалификации

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

Такое количество квалифицированных сотрудников нелегко найти в короткие сроки, поскольку их достаточно мало на трудовом рынке. Зарплата инженеров технической поддержки высокая, и не у каждой компании есть ресурсы для ее выплаты.

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

Часто при таком сценарии работы службы техподдержки выполнение условий SLA становится невозможным.

Разделение специалистов по квалификации

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

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

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

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

Сложности перехода в формат работы 24/7

Переход службы поддержки на круглосуточную работу – непростая задача. Здесь могут возникнуть сложности в следующих случаях:

— Нет OLA между линиями техподдержки (OperationalLevelAgreement – соглашение операционного уровня), так что подключение сотрудников к нетиповым задачам затруднено.
— SLA недостаточно прозрачно – если ожидания клиента и возможности службы поддержки не совпадают, есть риск потерять контракт; как следствие – удар по репутации компании.
— Служба не автоматизирована изнутри – инженеры вынуждены тратить время на выполнение рутинных задач.

Чтобы обеспечить работоспособность службы техподдержки, важно выбрать подходящие характеристики SLA и KPI.

Выбор SLA и KPI

Самыми важными параметрами SLA для службы технической поддержки являются скорость ответа, время обслуживания клиента, выбранный заказчиком уровень сервиса. Каким должен быть первый ответ на обращение пользователя:

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

Для KPI наиболее целесообразными метриками являются выполнение SLA и оценка удовлетворенности пользователя.

Основные инструменты

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

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

Благодаря грамотно подобранным инструментам на портале клиент может не только связаться со службой поддержки, но и по возможности решить свою проблему самостоятельно. Или предпринять первичные меры по решению проблемы, ускорив процесс. Пример портала с подобным функционалом – Jira Service Management.

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

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

Что стоит знать при организации круглосуточной поддержки

Чтобы круглосуточная служба поддержки работала эффективно, необходимо обеспечить следующие условия:

— Регламенты для сотрудников

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

— Обучение сотрудников

Сотрудник должен хорошо знать продукты компании, чтобы решать проблемы пользователей.

— Автоматизация рутинных задач

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

Грамотное внедрение автоматизации в бизнес помогает существенно повысить SLA.

— OLA между линиями поддержки

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

Это вдвое сократит время на обработку одного обращения и повысит эффективность работы техподдержки в целом.

— Прозрачные для клиента SLA

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

— Ведение статистики

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

Хорошо Марина, Вы считаете както можно сделать лучше?

Единственное впечатляющее в этом эссе на тему «как мы изобретали дежурного инженера» это, конечно, слово «ВСЕГО» в заголовке.

Расскажу как мы развернули круглосуточную техническую поддержку с нуля всего за 1 год.

Техподдержка — одна из головных болей стартапов и молодых компаний.

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

Начинаем с малого: ты, да я, да мы с тобой

Мы не собирались строить все из ничего, сходу создавая сложную структуру саппорта. Начали с малого в апреле 2020 года. Тогда мы пригласили тимлида и попросили его найти коллегу-инженера. Вместе они занимались решением технических вопросов, которые нужно было решать партнерам и клиентам. Чуть подробнее о том какие вопросы решались — ниже, в подразделе “Диверсификация обязанностей”. Ни о какой круглосуточной работе изначально не было и речи, это была стандартная пятидневка и график с 9:00 до 18:00.

Первые пару месяцев они без проблем справлялись со своими обязанностями. Во многом благодаря тому, что мы не афишировали создание нового отдела. Не скрывали, но и не анонсировали — хотели проверить, как все работает. Но когда пользователи, партнеры и коллеги узнали, что появился отдел, который помогает разобраться в нюансах работы продукта, может решить сложные проблемы и задачи, то нагрузка этих двух героев фронта поддержки резко возросла. Стало ясно, что отдел поддержки нужно расширять, и мы пригласили еще пару специалистов. В течение еще 2-3 месяцев все шло относительно неплохо.

Суббота и воскресенье? Работаем!

Через 2-3 месяца работы саппорта стало ясно, что клиентов и партнеров нужно поддерживать и по выходным. У бизнеса задачи не ограничиваются рабочей неделей, многие компании выполняют те либо иные задачи и тогда, когда все отдыхают.

В отделе технической поддержки на тот момент было уже 3 инженера и 1 тимлид. Задумались мы тогда и о круглосуточной поддержке, но эту идею пришлось отложить. Не потому, что организовать ее сложно, а потому, что это дорого.

Подсчитали, сколько еще людей нужно добрать, прокалькулировали связанные с расширением операционные расходы, посмотрели статистику звонков. Как оказалось, основной трафик идет по будням с 10:00 до 20:30, так что смысла оплачивать дополнительные 14 часов в день пока не было. Но вот субботу и воскресенье решили добавить.

Решение нашли быстро: недельный дежурный с дополнительной оплатой по выходным.

А теперь — диверсификация обязанностей

Компания росла, расширялся и отдел поддержки. Не очень быстро — к октябрю 2020 года количество сотрудников в нем достигло 6 человек. Это 1 тимлид и 5 инженеров.

Клиенты и партнеры саппортом были вполне довольны. Но задач, конечно, стало больше, увеличилось и их разнообразие. С течением времени мы стали замечать, что отдел сам по себе разделился на две части, как раз по типам решаемых задач. Условно это было разделение на «Help Desk» и на «мониторинг». Работа стала эффективнее, и мы уже официально разделили отдел на два подразделения:

— Help Desk — 2 человека

— Мониторинг — 3 человека

Единственное — тимлида разделить не удалось, поскольку он был один и не хотел, чтобы его делили. Пришлось оставить его как есть, с условием, чтобы он координировал работу всего отдела.

Задачи Help Desk:

— Поддержка платформы и локализация ее проблем (ошибки API; кнопка работает не так, как должна; нет доступа и тд.).

— Поддержка сервисов платформы и локализация проблем с ними (робот не звонит, вместо «привет» распознает «вечер, море, хочу в отпуск», тарабанит фразы как… робот и становится не похож на человека).

— Поддержка SIP-телефонии (сетевые проблемы телефонии).

— Поддержка External API.

Задачи мониторинга:

— Мониторинг сетевой инфраструктуры и своевременная реакция на возникающие проблемы (сервера, базы данных, сетевое оборудование).

— Мониторинг коммерческого трафика и своевременная реакция на возникающие проблемы (прослушивание некоторого кол-ва звонков, отслеживание ключевых показателей проектов).

Спустя некоторое время оценили преимущества разделения:

— Специалисты саппорта прекрасно знали свои обязанности и не мешали друг другу.

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

— Задачи выстроились в стройную систему.

— Выходные можно закрывать без дежурного.

Последний пункт стоит немного пояснить. Дело в том, что на этом этапе мы отказались от дежурного в подразделении Help Desk. Вместо этого мы предложили подразделению мониторинга 7-часовой рабочий день по будням с тем, чтобы на выходные у сотрудников оставалось 10 дополнительных часов. Это решение обсуждалось вместе с сотрудниками, которые были не против. Схема простая: сначала один человек работает по 7 часов по будням и в выходные, потом второй, потом третий и так далее. Ну а затем — наша песня хороша, начинай сначала.

Ну привет, круглосуточная поддержка

Выше уже упоминалось, что круглосуточную поддержку мы не вводили, поскольку подавляющее большинство клиентов и партнеров обращались с вопросами в обычное время — с 10:00 до 20:30. Почему так? Все просто — те, с кем мы работали ранее, находились в одном с нами часовом поясе.

Все изменилось после того, как Neuro.net стала выходить на зарубежный рынок. Сразу же появились обращения во “внеурочное время” и здесь пришлось взять быка за рога, т.е. все же ввести круглосуточный саппорт.

Сначала получалось так:

— Help Desk — c 9:00 до 18:00 по будням. Здесь пока что ничего не менялось.

— Мониторинг — 3 смены: 9:00-18:00 (2 человека), 14:00-21:00 (1 человек), 1:00-9:00 (1 человек, добрали позже из другого часового пояса на ГПХ).
Но чуть позже количество зарубежных клиентов значительно выросло, увеличился и трафик. И мы ввели круглосуточную поддержку для двух подразделений — как мониторинга, так и хелп деска.

Изначально выбирали из трех перспективных вариантов реализации полноценного круглосуточного саппорта:

— Три смены по 9 часов — утро, вечер, ночь.

— 2/2 по 12 часов

— Сутки через трое (Why not? как гипотеза подойдет)

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

— Желание сохранить команду (многим не нравится сменный график, и в этом нельзя никого винить)

— Необходимость сделать оплату смен достойной (текучка кадров никому не нужна)

— Необходимость рассчитать количество сотрудников, которых нужно пригласить дополнительно.

— Поиск сотрудников.

Поразмыслив, мы решили оставить первый вариант — три смены по 9 часов. Почему так? Режим “сутки через трое” рассматривался просто как экзотичный вариант. Но работать 24 часа, а потом трое суток быть дома — на это соглашаются далеко не все, и это понятно. Суточные смены очень сложные.

Два дня по 12 часов через каждые 48 часов — вариант вроде бы неплохой. Но мы — молодая компания с развивающимися технологиями. И не хотелось, чтобы сотрудники выпадали на 48 часов каждые два дня, ведь новая информация и задачи у нас появляются буквально каждый день.

Что было сразу, до глобального перехода на круглосуточную работу?

— Help Desk — 4 инженера.

— Мониторинг — 3 инженера + 1 инженер ночью.

Теперь решаем наши задачи:

Сохраняем команду — оставляем у всех все так, как есть сейчас. Пусть продолжают работу по стандартному графику — 9:00-18:00

Рассчитываем минимальное количество людей на смене — тут все зависит от нагрузки и трафика в вечер и ночь. В нашем случае достаточно по 1 человеку на ночную смену для каждого подразделения:

Итого нужно:

— Help Desk — 4 утро, 1 вечер, 1 ночь.

— Мониторинг — 3 утро, 1 вечер, 1 ночь.

После решения этой задачи приступаем уже к реализации. Набрасываем график с 18-20 обязательными сменами (естественно, его можно варьировать), чтобы был запас на больничные/отпуска и ребята могли добрать смен вплоть до 25+.

Где мы искали дополнительных сотрудников для вечерних и ночных смен? Да где и все, собственно — HH, Rabota, LinkedIn и др. Кстати, были даже попытки найти разработчиков на Tinder, но об этом уже в другой раз.

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

Вообще, на лямбдах можно сделать почти все, что и на обычных сервера, от простых порталов (как статических сайтов, так и одностраничных приложений), до сложных процессов с распределением нагрузки. Но лучше всего лямбды конечно же подходят для прототипирования, чат-ботов, IoT (Internet of Things), обработкой файлов и т.п. На лямбдах можно без проблем запустить реакт приложение — с серверным рендерингом:

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

Для бессерверного масштабирования в AWS можно использовать следующие сервисы:

— AWS Lambda. Вычислительный сервис без серверов, предназначенный для запуска программного кода в ответ на событие без необходимости управлять инфраструктурой. Когда поступает запрос на выполнение кода, Lambda запускает необходимое количество экземпляров функции для обработки нагрузки. Если нагрузка увеличивается, Lambda автоматически масштабирует функцию, добавляя больше экземпляров.
— AWS Step Functions. Бессерверный сервис для создания, выполнения и отслеживания составных задач на основе различных сервисов AWS и собственных функций AWS Lambda. Он позволяет создавать рабочие процессы — конечные автоматы, состоящие из серии шагов, где каждый шаг — это состояние, которое представляет отдельную операцию или сервис.

Также для автоматического масштабирования в AWS можно использовать AWS Auto Scaling. Сервис выполняет мониторинг приложений и автоматически настраивает ресурсы для поддержания стабильной прогнозируемой производительности при минимально возможных затратах.

Замечаю, что контроль бизнес-процессов с помощью DST CRM становится не просто необходимостью, а залогом успешной работы малых и средних предприятий. Интеграция функций CRM и BPM действительно улучшает общую прозрачность и управление процессами, что, как упомянуто в статье, существенно увеличивает продуктивность. Следует отметить, что гибкость в настройках DST CRM позволяет компаниям моментально реагировать на изменения в их бизнес-среде. Это не только оптимизирует внутренние процессы, но и помогает создавать качественные отношения с клиентами, что крайне важно для долгоиграющего успеха.

Статья отлично подчеркивает важность интеграции CRM и BPM-систем для оптимизации бизнес-процессов, особенно в условиях конкурентного рынка. DST CRM действительно предоставляет мощные инструменты для анализа данных и контроля взаимодействия с клиентами, что дает возможность выявлять узкие места в работе компании. Автоматизация рутинных задач — это важный шаг к повышению производительности, который позволяет командам сосредоточиться на стратегическом развитии. Гибкость настройки системы для быстрой адаптации к изменениям — это еще одно весомое преимущество, которое явно поможет малым и средним предприятиям выжить и процветать.

Долгосрочная память (LTM) является основой самоэволюции искусственного интеллекта (AI). Она позволяет моделям хранить и управлять обработанными данными взаимодействия, что поддерживает развитие на основе накопленного опыта.

Например, помощник на основе искусственного интеллекта может запоминать предпочтения в отношении кофе, расставлять приоритеты для повторяющихся задач или отслеживать текущие проекты.

Также в январе 2025 года стало известно, что исследователи Google разработали новый тип модели ИИ с долгосрочной памятью — архитектуру «Titans». Она объединяет искусственную краткосрочную и долгосрочную память и позволяет системе работать с длинными последовательностями информации. При этом ИИ «не забывает» то, что изучил до этого.

Я полностью поддерживаю идею о том, что объединение серверлес-архитектуры и микросервисов с AI Services от AWS может кардинально изменить подход к созданию интеллектуальных решений. Преимущества, такие как готовые решения для обработки естественного языка и компьютерного зрения, позволяют разработчикам сосредоточиться на функциональности, а не на сложных алгоритмах машинного обучения. Эти инструменты облегчают интеграцию и придают проектам большую гибкость. Впечатляет, что безопасность остается на высоком уровне с соблюдением стандартов отрасли!

Статья отлично подчеркивает значимость микросервисной архитектуры в разработке современных интеллектуальных приложений. Использование Golang в сочетании с AWS AI Services открывает новые горизонты для разработчиков. Параллелизм, предлагаемый Go, действительно значительно упрощает процесс разработки и позволяет эффективно использовать ресурсы. Особенно мне понравилось, что AWS предоставляет гибкие возможности масштабирования и оплаты за фактически используемые ресурсы, что делает их решения еще более привлекательными для стартапов и малых бизнесов.

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

— Генеративные алгоритмы ИИ изучают основные закономерности и структуру определённого набора данных для генерации новых данных. Модель фиксирует распределение вероятностей обучающих данных и генерирует новый контент на основе этих вероятностей.
— Для изучения возможных ответов используются различные модели вероятностей. Это означает, что алгоритм выбирает ответ на основе того, что статистически наиболее вероятно будет подходящим ответом (то есть он рассматривает вероятности с различных точек зрения).
— Нейронные сети и методы глубокого обучения используются для моделирования сложных взаимосвязей данных.
— В чистом подходе генеративного искусственного интеллекта данные не маркируются (никакие метаданные не требуются) — система учится на самих данных без ссылки (есть предостережения, которые мы рассмотрим позже в этой статье). Проблема с немаркированными данными заключается в том, что в контенте может быть упущен важный контекст и детали.
— Согласно ChatGPT, «генеративным моделям требуется значительный объем обучающих данных, чтобы точно отразить сложность базового распределения. Большие наборы данных позволяют моделям изучать разнообразные закономерности и генерировать более реалистичные и разнообразные результаты».
— «Применение генеративного ИИ следует рассматривать в более широком социальном контексте», — говорится там же. « Генераторный ИИ может использоваться в полезных приложениях, таких как искусство, развлечения и исследования, но он также может использоваться не по назначению, например, в дипфейках или вводящих в заблуждение синтетических медиа».

Обработка естественного языка (НЛП) в генеративном искусственном интеллекте

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

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

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

Графовое представление создает математическую модель объекта (скажем, документа) в многомерном пространстве (сложная концепция для понимания, поскольку мы не можем мыслить более чем в трех измерениях — четырех, если вы добавите время как измерение). Но графовое пространство допускает столько измерений, сколько атрибутов, то есть сотни или тысячи. Документы также вводятся в базу данных графа знаний и могут быть представлены как один большой граф или разбиты на компоненты, причем каждый компонент имеет графовое представление.

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

Метаданные могут быть связаны с контентом для предоставления явных атрибутов контента, которые обеспечивают контекст для запроса и ответа. В случае обобщенной языковой модели размеры графового пространства определяются «изученными особенностями» информации. Однако явные метаданные также могут быть частью графового представления контента, или «встраиваниями».
Роль управления знаниями в генеративном искусственном интеллекте

Священным Граалем управления знаниями (УЗ) является предоставление нужной информации нужному человеку в нужное время.

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

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

Эта информация включает в себя «цифровой язык тела» клиента или сотрудника. Это цифровые сигналы, которые люди излучают всякий раз, когда взаимодействуют с электронной системой.

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

Однако путь клиента — это путь к знаниям. Путешествие сотрудника — это путешествие знаний. На каждом этапе процесса людям нужны ответы на вопросы.

Системы управление знаниями (КМ) всегда пытались организовать информацию осмысленным образом, чтобы снизить когнитивную нагрузку на человека, то есть облегчает им выполнение своей задачи.

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

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

Заключение

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

Ваше конкурентное преимущество – это наличие 2х элементов: онтологической модели знаний о бизнесе и генеративный ИИ с настроенной на вашу отрасль языковой моделью.

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

— Генеративные алгоритмы ИИ изучают основные закономерности и структуру определённого набора данных для генерации новых данных. Модель фиксирует распределение вероятностей обучающих данных и генерирует новый контент на основе этих вероятностей.
— Для изучения возможных ответов используются различные модели вероятностей. Это означает, что алгоритм выбирает ответ на основе того, что статистически наиболее вероятно будет подходящим ответом (то есть он рассматривает вероятности с различных точек зрения).
— Нейронные сети и методы глубокого обучения используются для моделирования сложных взаимосвязей данных.
— В чистом подходе генеративного искусственного интеллекта данные не маркируются (никакие метаданные не требуются) — система учится на самих данных без ссылки (есть предостережения, которые мы рассмотрим позже в этой статье). Проблема с немаркированными данными заключается в том, что в контенте может быть упущен важный контекст и детали.
— Согласно ChatGPT, «генеративным моделям требуется значительный объем обучающих данных, чтобы точно отразить сложность базового распределения. Большие наборы данных позволяют моделям изучать разнообразные закономерности и генерировать более реалистичные и разнообразные результаты».
— «Применение генеративного ИИ следует рассматривать в более широком социальном контексте», — говорится там же. « Генераторный ИИ может использоваться в полезных приложениях, таких как искусство, развлечения и исследования, но он также может использоваться не по назначению, например, в дипфейках или вводящих в заблуждение синтетических медиа».

Обработка естественного языка (НЛП) в генеративном искусственном интеллекте

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

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

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

Графовое представление создает математическую модель объекта (скажем, документа) в многомерном пространстве (сложная концепция для понимания, поскольку мы не можем мыслить более чем в трех измерениях — четырех, если вы добавите время как измерение). Но графовое пространство допускает столько измерений, сколько атрибутов, то есть сотни или тысячи. Документы также вводятся в базу данных графа знаний и могут быть представлены как один большой граф или разбиты на компоненты, причем каждый компонент имеет графовое представление.

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

Метаданные могут быть связаны с контентом для предоставления явных атрибутов контента, которые обеспечивают контекст для запроса и ответа. В случае обобщенной языковой модели размеры графового пространства определяются «изученными особенностями» информации. Однако явные метаданные также могут быть частью графового представления контента, или «встраиваниями».
Роль управления знаниями в генеративном искусственном интеллекте

Священным Граалем управления знаниями (УЗ) является предоставление нужной информации нужному человеку в нужное время.

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

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

Эта информация включает в себя «цифровой язык тела» клиента или сотрудника. Это цифровые сигналы, которые люди излучают всякий раз, когда взаимодействуют с электронной системой.

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

Однако путь клиента — это путь к знаниям. Путешествие сотрудника — это путешествие знаний. На каждом этапе процесса людям нужны ответы на вопросы.

Системы управление знаниями (КМ) всегда пытались организовать информацию осмысленным образом, чтобы снизить когнитивную нагрузку на человека, то есть облегчает им выполнение своей задачи.

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

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

Заключение

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

Ваше конкурентное преимущество – это наличие 2х элементов: онтологической модели знаний о бизнесе и генеративный ИИ с настроенной на вашу отрасль языковой моделью.