Machine learning в простом проекте

    Я CTO проекта Preply и хочу рассказать немного о том, о чем мечтает каждый программист, а именно о сложных и интересных задачах в простых проектах.

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

    Проблема


    Мы платформа репетиторов Preply и нас все хотят обмануть.

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

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

    Мой скайп vasiliy.p, тел +789123456. Значит на 19:00 1 апреля!

    Добрый вечер! Вы могли бы написать свой номер или позвонить на мой +78-975-12-34

    Не хочу платить до урока, меня зовут Василий Пупкин – найдите меня вконтакте


    Опытный программист сразу скажет: «В чем проблема написать регулярные выражения под возможные варианты обмена сообщений?». Проблемы нет, но это решение имеет ряд недостатков:

    1. Сложно предусмотреть все варианты некорректных (то есть тех какие содержат контакты) сообщений. Например, в первой версии продукта был набор регулярных выражений под номер телефона, но он срабатывал и блокировал сообщения вида:
      пятница — с 13 00-15 00-15 30… сколько будет стоит групповое занятие?

      В более сложном случае использовалось регулярное выражение для эл. почты, которое предназначалось для блокировки сообщений типа:
      vasya (собака) pupkin (точка) ru

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

      Cо словом «скайп» еще сложнее: очень тяжело отличить сообщения, содержащие попытки обмена скайпом:
      please add me in Skype — vasya82pupkin

      от уточняющих сообщений:
      do you want to have skype or local lessons?

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


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

    Решение


    Я решил попробовать 3 метода машинного обучения для правильной классификации корректных/некорректных сообщений, которые мне запомнились из курса Coursera Machine Learning by Andrew Ng.

    Первая проблема заключается в подготовке базы для обучения. У нас было более 50 000 сообщений, предварительно классифицированных старой системой. Я взял только 5000 из них и потратил около 2-3 часов на то, чтобы исправить неверную классификацию в тех сообщениях, где прежняя система допускала ошибки. В теории чем больше база, тем лучше, но в реальном мире довольно сложно вручную подготовить большую выборку (проще говоря, лень).

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

    Было:
    Я хотел бы начать занятия с февраля месяца, это возможно? Точное время тоже смогу сказать в январе, но это точно будет не раньше 18:00

    Стало:
    время не занятия с февраля возможно? в Точное бы январе, тоже раньше 18:00 Я точно это но сказать смогу будет хотел начать месяца, это

    Было:
    Буду рада быть полезной, мой тел. (012)345-678 Звоните, будем договариваться, спасибо

    Стало:
    тел. быть рада Буду полезной, мой Звоните, будем договариваться, спасибо (012)345-678

    В результате получился csv файл с ~5000 строчками, где некорректные сообщения отмечены нулем, а корректные единицей. После этого на основе работы с данными мы определили набор характеристик сообщения, которые «на глаз» имеют влияние на классификацию.

    • подозрение на телефон;
    • подозрение на эл. почту;
    • подозрение на скайп контакты;
    • подозрение на url;
    • подозрение на соц. сети;
    • корректные слова, которые идут с цифрами (время, валюта);
    • длина сообщения;
    • подозрительные слова: найдите, добавьте, мой;
    • … и так далее.


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

    import re
    SEPARATOR = "|"
    reg_arr = [ re.compile(u'фейсбук|facebook|linkedin|vkontakt|вконтакт',re.IGNORECASE | re.UNICODE),
    			re.compile(u'соц.{1,10}сет', re.UNICODE)]
    			re.compile(u'скайп[^у]|skype', re.IGNORECASE | re.UNICODE),
    			re.compile(u'скайпу', re.IGNORECASE | re.UNICODE),
    			re.compile(u'[йцукенгшщздлорпавифячсмітьбю].*\s[a-zZ-Z]', re.IGNORECASE | re.UNICODE),
    			re.compile('\d{3}[-\.\s]??\d{3}[-\.\s]??\d{4}|\(\d{3}\)\s*\d{3}[-\.\s]??\d{4}|\d{3}[-\.\s]??\d{4}'),
    ...
    			re.compile('http|www|\.com', re.IGNORECASE),
    			re.compile(u'мой|my', re.IGNORECASE | re.UNICODE),
    			re.compile(u'найдите|find', re.IGNORECASE | re.UNICODE),
    			re.compile(u'добавь|add', re.IGNORECASE | re.UNICODE),
    ...
    			re.compile('\w+@\w+', re.IGNORECASE),
    			re.compile('.{0,50}', re.IGNORECASE),
    			re.compile('.{50,200}', re.IGNORECASE),
    ....
    		]	
    			
    def feature_vector(text):
    	return map(lambda x: 1 if x.search(text) else 0, reg_arr)
    
    fi=open('db_machine.csv', 'r')
    fo=open('db_machine_result.csv', 'w')
    
    for line in fi:	
    	[text, result] = line.split(SEPARATOR)
    	output = feature_vector(text).append(result)
    	fo.write(",".join(map(lambda x: str(x), output )) + "\n")	
    	
    fo.close()
    fi.close()
    


    Соответственно после обработки всех сообщений по всем характеристикам (у нас сейчас их около ста) мы записываем вектор характеристик и результат классификации в файл.

    После подготовки данных необходимо разбить выборку на три части: для обучения (train set), для подбора параметров (cross-validation set) и проверки (test set). Следуя совету из курса, размеры выборок обучения, подбора параметров, теста соотносятся в пропорции 60/20/20:

    import random
    with open('db_machine_result.csv','r') as source:
    	data = [ (random.random(), line) for line in source ]
    data.sort()
    
    n = len(data)
    with open('db_machine_result_train.csv','w') as target:
    	for _, line in data[:int(n*0.60)]:
    		target.write( line )
    with open('db_machine_result_cross.csv','w') as target:
    	for _, line in data[int(n*0.60):int(n*0.80)]:
    		target.write( line )		
    with open('db_machine_result_test.csv','w') as target:
    	for _, line in data[int(n*0.80):]:
    		target.write( line )
    


    Затем, руководствуясь принципом не изобретать велосипед и максимально быстро получить результат, мы использовали скрипты из курса Machine Learning Coursera и просто прогнали наши выборки по алгоритмам логистической регресии, SVM и нейронных сетей. Скрипты просто взяты из курса, например SVM выглядит так:

    clear ; close all; clc
    
    data_train = load('db_machine_result_train.csv'); 
    X = data_train(:, 1:end-1); y = data_train(:,end);
    
    data_val = load('db_machine_result_cross.csv'); 
    Xval = data_val(:, 1:end-1); yval = data_val(:,end);
    
    data_test = load('db_machine_result_test.csv'); 
    Xtest = data_test(:, 1:end-1); ytest = data_test(:,end);
    
    [C, sigma] = dataset3Params(X, y, Xval, yval); % подбор параметров на cross-validation set
    
    fprintf('C: %f\n', C);
    fprintf('sigma``: %f\n', sigma);
    
    model= svmTrain(X, y, C, @(x1, x2) gaussianKernel(x1, x2, sigma));
    
    p = svmPredict(model, X);
    fprintf('Training Accuracy: %f\n', mean(double(p == y)) * 100);
    
    p = svmPredict(model, Xtest);
    fprintf('Test Accuracy: %f\n', mean(double(p == ytest)) * 100);
    
    fprintf('Program paused. Press enter to continue.\n');
    pause;
    


    Посмотреть на то, как реализованы функции svmTrain/svmPredict можна на сайте курса или, например, здесь.

    Все алгоритмы на выборке cross-validation перебирали внутренние параметры (λ — для регуляризации, σ, C — для гауссовской функции, size — для размера скрытого слоя нейронной сети). Представим финальные результаты точности для некоторых из них ниже:

    Нейронные сети Логистическая регресия                       SVM
    size=30, λ=1 size=30, λ=0.01 size=30, λ=0.001 λ=0 λ=0.01 λ=1 Linear (λ 0.001, σ=0.001) Gaussian (λ 0.1, σ=0.1) Gaussian (λ 0.001, σ=0.001)
    96.41% 97.88% 98.16% 97.51% 97.88% 98.16% 96.48% 97.14% 98.89%


    Здесь нужно уточнить, что в процесе подготовки системы результат был намного хуже (96.6% для SVM, например), и очень ощутимые улучшения дала отладка. Мы запустили логистическую регресию, как самую простую и быструю на реальных данных всей выборки, и пересмотрели результат классификации. С удивлением обнаружили, что система оказалась умнее меня, так как в 30% случаев была ошибка в классификации сообщений человеком (как я писал, я просмотрел ~5000 сообщений и, как оказалось, допустил где-то 30-40 ошибок классификации), а система классифицировала все правильно. В процесе отладки мы исправляли ошибки в базе и соответственно точность метода росла. Более того, мы расширяли вектор характиристик, если видели что какой-то интересный паттерн не обрабатывается системой.

    Выбрали использовать метод SVM, характеристики на общей выборке были следующие:

    Сообщение
    Факт
    Корректное
    Некорректное
    Прогноз
    Корректное
    4998 36
    Некорректное
    11 390


    Поскольку система имеет свойство того, что классы «перекошены» (skewed classes), то для сравнения алгоритма приведу также параметры:

    Precision Recall Accuracy
    99.28% 99.78% 99.13%


    В итоге мы решили использовать SVM с ядром гауссовской функции для фильтрации сообщений на сайте. Он сложнее, чем логистическая регрессия, но дает существенно лучший результат, хотя и работает медленнее.
    Полностью путь обработки сообщения выглядит следующим образом:
    • Пользователь отправляет сообщение на сайте, Backbone JS создает модель на машине клиента и POST запросом отправляет ее API сервера;
    • API сервера, написанное на Django TastyPie, использует Django форму валидации модели;
    • первый валидатор подтягивает с базы профиль пользователя и проверяет не отмечен ли пользователь как нарушитель (не нужно проверять дальше, 403 ответ) или он уже делал платежи через сайт (не нужно проверять дальше, сразу 201 ответ);
    • валидатор svmPredict возвращает результат проверки текста сообщения. Если пользователь нарушил правила, в его профиль ставится соответствующий флаг, иначе все хорошо и пользователь получает 201 ответ от API и сообщение пишется в базу;
    • если сообщение содержало контакты или пользователь был нарушителем, клиенту возвращается 403 ответ, при получении которого Backbone рендерит сообщение пользователю, что он нарушает правила. Пользователь в базе отмечается как нарушитель;

    Пока работает хорошо и мы этому рады.

    Выводы


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

    Сейчас мы действительно используем SVM в продакшене для классификации сообщений ввиду хороших показателей точности. Используем в очень простой способ — мы взяли набор весов оптимальной модели и используем портированную на Python функцию svmPredict, упомянутую выше, для классификации. В идеальном мире нужно было бы сделать систему обратной связи с учителем, чтобы администратор указывал на ошибки классификации, а система корректировала веса и улучшалась. Но наш проект живет в реальном мире, где время=деньги и мы пока наслаждаемся тем, что количество обращений в поддержку по поводу неправильной блокировки упало в 2 раза. Также интересная мысль балансировать порог доверия и соответственно ошибки первого и второго типа, но пока нас все устраивает. Измерять количество ошибок типа «пропуск сообщения» довольно сложно. Уточню только, что конверсия заявок в платежи после внедрения системы не упала. Иными словами, даже если пропусков стало больше, на бизнес это не влияет. Но на глаз пропусков тоже стало меньше. Так что это очень хороший результат за одни выходные.

    Если тема интересна вам, то я готов написать о collaborative filtering подходе для рекомендаций репетитора, который мы делаем. Если нужен код, также обращайтесь, — там ничего секретного нет, а в статье больше хотелось описать pipeline.

    P.S.: Мы растем и в перспективе ищем в наш киевский офис 2 умных и ответственных программистов: стажера и более опытного для закрытия задач, на которые не хватает моих двух рук. Наш стек Python/Django и JS/Backbone. Много интересных задач и лучших практик. Пишите dmytro@preply.com

    Preply

    28,00

    Компания

    Поделиться публикацией
    Комментарии 43
      +6
      Уважаемые, а нельзя пересмотреть модель коммуникации между клиентом и репетитором, чтобы договориться об оплате в обход сайта было технически невозможно? Скажем, запретить обмен сообщениями в свободной форме, а вместо этого сделать возможность посылать несколько типов стандартных запросов через фиксированные формы — запрос на изменение времени занятия и тд? Детали, важные для репетитора — уровень английского и тд, тоже передавать через фиксированные формы в стандартизованном виде.
        +3
        Мы рассматривали такой вариант. Но в нашем проекте многое решает бизнес-модель — платежи студентов через сайт.
        Возможность обмениваться сообщениями очень хорошо влияет на конверсию. Студенту психологически приятно общаться с репетитором, а не посредником, что очень важно для маркетплейса. Более того, мы работаем без колл-центра и наши репетиторы сами ведут пользователя по воронке продажи первого урока посредством сообщений.
        Кроме того запросы студентов разные: кто-то ищет «репетитора-няню детям на лето в лагерь» и предусмотреть интерфейс всех возможных шаблонов запросов сложно. Мы видели сайты с механикой «мастера заказа», но пока не готовы думать о переходе.
        Обратите внимание, что у нас на форме заказа многое из перечисленного вами реализовано.
          +1
          Тут скорее не модель коммуникации надо пересматривать, а модель монетизации.
          Например, чтобы платили не за свершившееся взаимодействие, а за возможность это взаимодействие начать или облегчить.
          Ибо автоматически запрещать говорить на определённые темы через средство открытого общения — это бессмысленная гонка вооружений и как-то этически и социально мерзко.
          –1
          Простите, но все эти перемешивания слов при чтении личных сообщений — самообман.
          Вы читаете личку пользователей, этого в принципе не должно быть, точка.
            +2
            Если под «личкой пользователя» понимать перемешанный текст случайных сообщений без указания автора, то вы, конечно, правы.
            Но какой альтернативный вариант настройки подобной системы вы видите без просмотра текста на первых этапах?
              –4
              Не знаю. Не факт, что он существует. Ваша схема монетизации не совсем этична, поэтому искать этичные решения частных задач, созданных ей, — дело довольно бессмысленное.

              На каком основании вы берёте деньги за уроки по скайпу? Вы оплачиваете учителю и ученику канал связи или другие средства непосредственно для проведения занятий? Вы участвуете в проведении урока?

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

              Кратко — деньги честно брать за конкретные затраты своих ресурсов.
                +7
                Разработка и поддержка платформы, маркетинг это разве не затраты ресурсов?
                  –8
                  Разработка (если иметь в виду создание первой рабочей версии, я не беру дальнейшую разработку) — это одна большая фиксированная затрата. Когда юзер пользуется платформой, она уже готова, разработчики больше не вкладывают ресурсов непосредственно в эту работу, а значит это не должно быть основанием для оплаты.

                  Поддержка и допиливание кода — ОК, я посчитаю честным платить фиксированную повременную сумму за пользование ресурсом (в которую входит девелопмент платформы, износ оборудования за мой счёт и т.д.). Но никакой платы за скайп. Мне неважно, что это тоже способ дать деньги разработчикам отбить затраты — он неправилен.

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

                    Разовый труд по разработке платформы должен быть вознаграждён из других источников, напр. как фиксированная оплата вперёд за разработку от инвестора.
                      +6
                      Интересно было бы услышать как, по вашему мнению, инвестор который профинансировал разработку, должен зароботать на проетке, который не зарабатывает?
                      Маркетинг — сложный вопрос. Долго объяснять, но я считаю, что это должно относиться к внутренним тратам владельцев ресурса.

                      Не менее интересный вопрос о том какая должна быть мотивация у владельцев ресурсов платить за маркетинг платформы если за пользование платформы никто не платит.
                        +1
                        Во-первых, я не говорил, что проект будет зарабатывать 0 — выше я говорил, например, о повременной плате.

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

              Вы это расскажите тем, кто болезни диагностирует :).
                0
                Естественно это зависит от задачи :) В поиске оптимума и заключается роль человека в машинном обучении.
                0
                Пробовали WebRTC? чтобы миновать общение через скайп?
                  0
                  Не пробывали пока, но смотрели на tokbox.com/opentok который использует WebRTC. В перспективе будем переводить уроки на платформу используя или их API или Google Hangout API, как например делают verbling.com.

                  Сходу очень сложно построить видеокоммуникацию через платформу через проблемы доверия и отсутствия базы пользователей. Сейчас у нас есть база пользователей и их намного проще перевести на уроки через платформу со Скайпа, чем было бы год назад.
                  +3
                  Вместо того, чтобы сделать удобный интерфейс (оплаты, коммуникации) вы решили блокировать обмен контактов. О дивный новый мир, история фриланс.ру ничем не учит.
                    –1
                    Мы очень стараемся найти баланс между удобством пользователя и жизнеспособностью бизнес-модели. К сожалению, в этом вопросе нет простых решений.
                    Проект wyzant.com, который работает по похожей механике в США, спрашивает данные карты Visa/Mastercard до момента оставления заявки и после этого пользователи могут писать личные сообщения. В нашем случае после оплаты первого урока тоже нет никаких ограничений.
                      +1
                      Аналогичным образом действуют, например, ebay, airbnb.
                      Было бы очень интересно познакомиться с проектами, интерфейс которых настолько удобен, что они смело отказываются от страховки подобных бизнес-рисков.
                        0
                        Задача все-таки состоит в сведении к минимуму рисков, а не их страховке.
                        0
                        Согласен, работа над интерфейсами нужна, но одно не исключает другого. Успешные мировые платформы, такие как airbnb.com, wyzant.com тоже блокируют обмен контактами.
                        +5
                        Опытный программист сразу скажет: «В чем проблема написать регулярные выражения под возможные варианты обмена сообщений?».


                        Опытный программист ТАК совершенно точно не скажет :)
                          +1
                          Интересно услышать, как бы опытный программист, по вашему мнению, решал бы проблему обмена контактами?
                            +1
                            Небольшой Disclaimer. Я совершенно точно не опытный программист, а поэтому могу лишь высказать свои догадки.
                            0) Опытный программист, по моему мнению, даже, если и пишет код, должен больше думать про бизнес (как Consultant, в терминах США), а не про код. В связи с этим, первое, что нужно делать — это пересматривать бизнес процесс и думать о том, как решить эту проблему, а не воткнуть костыль в виде регулярок.
                            1) Сейчас, как мне кажется, идёт некий бум применения AI. В связи с этим, можно пытаться решать проблему различными средствами из этой сферы (собственно, как вы это и сделали).
                            2) Можно, например, брать с репетиторов некоторую абонентскую плату — это избавит вообще от проблемы, описанной вами.
                            3) Как уже было выше сказано, шаблонные сообщения — вполне хороший ход. С одной стороны вы потеряете часть клиентов, зато не придётся тратить время саппорта для ответов по данной проблеме. Также и Ваша проблема исчезнет.
                              +1
                              «Некоторые люди, сталкиваясь с проблемой, думают: «О! Воспользуюсь-ка я регулярными выражениями!»
                              После этого у них становится на одну проблему больше.»
                              Классика
                            0
                            удалено.
                              0
                              Не планируете расширять направления обучения? Из стандартного: музыка, школьный курс, егэ?
                                0
                                Планируем конечно, и не только на стандартный набор предметов, а и на другие сферы онлайн образования. Сейчас слишком быстро растем — не хватает рук чтобы успевать все делать.
                                0
                                Почему сайт так сильно тормозит? Из-за Django или Хабраэффект?
                                  +3
                                  Мы мониторим состояние сайта с помощью New relic — вот график APDEX score за последние 24 часа: image
                                  Как видим минут 10-30 назад производительность упала, но скорее всего не из-за Хабраэффекта (с Хабра у нас довольно мало людей ~10 пользователей в минуту), так как сайт справлялся с пиковым трафиком в 150 пользователей одновременно. Возможно запустились какие-то тяжеловесные задачи на сервере или пользователи на страницах которые используют много ресурсов (нарпимер создание профиля репетитора).

                                  Если вы подскажете станицу которая у вас тормозит я постараюсь дать более точный ответ. На производительность Django пока не жалуюсь — нам хватает, а если что скейлинг через Amazon AWS и оптимизация поможет.
                                    0
                                    Видимо отрабатывали какие-то задачи. Сейчас попробовал еще раз воспользоваться формой поиска — всё летает ✌
                                  +2
                                  re.compile(u'фейсбук|facebook|linkedin|vkontakt|вконтакт',re.IGNORECASE | re.UNICODE),


                                  В таком случае вы упускаете такие сети, как twitter, livejornal, google+, etc. и плюс еще различные вариации их написаний.
                                  Или же вы закладываетесь на то, что в сообщениях пользователи их не употребляют? Или же как фильтр сработает на +7-111-111-11-11 или +7(111)111-11-11?
                                    0
                                    По соц. сетях — согласен twitter, livejornal, google+ именно в указаном выражении не обрабатываются, нужно добавить. Причина в том что пока не было прецендентов обмена через эти слова. По поводу телефона который вы указали уточню, что в статье приведен только пример регулярных выражений, но далеко не все которые мы используем.
                                    +2
                                    Статья очень интересная и полезная, спасибо за труды. Но вот причина побудившая вас проделать этот труд меня интересует несколько больше: не вы один сталкиваетесь с подобной проблемой. Проводили ли вы анализ того почему репетиторы и студенты пытаются проводить обучение в обход системы? Каковы причины этого по вашему мнению?
                                      0
                                      Со стороны репетитора причина попыток обмена в том что не все понимают правила как работает платформа, и есть вредные репетиторы которые не хотят ждать оплаты от пользвоателя. С ними есть иная проблема, после оплаты первого урока и обмена контактами очень сложно заставить их проводить следующие оплаты через сайт, но у нас это вроде получается)

                                      Со стороны пользователя статистика следующая: ~7% из них, на данный момент, пробуют пересылать контакты. Для половины нарушителей причина в том что они не знают правил работы платформы. Мы часто упоминаем то что до оплаты обмен запрещен в пользовательском интерфесе, но пользователи, к сожалению, не читаю тексты на сайте. С этими все ясно: попробывали обменяться -> получили предупреждение -> работают дальше в системе без нарушений.

                                      Другая половина это те кто принципиально не хочет платить за услугу через сайт. Глубинная проблема в доверии, на постсоветском рынке слабое понимание escrow механик, пользователь боится мошенничества, так как не уверен что сможет легко вернуть оплату через банк в случае чего. С ними сложнее но можно работать. Среди этой части есть пользователи которые привыкли к тому что первый урок должен быть бесплатный — этих переубедить сложно но понемногу тоже стараемся находить к ним подход.
                                        0
                                        У меня брат так же недавно занимался и преподаватель через несколько занятий предложил ему перейти на оплату без посредника. Но я не знаю, сколько берет себе школа, какой % у вас? И какое количество репетиторов пытаются переманить студентов?
                                          0
                                          У нас сетка комиссии от 18% до 33% в зависимости от общего количества уроков проданых через платформу. По нашим рассчетам такая комиссия в долгосрочной перспективе будет прибыльной для нас (если меньше то будут убытки).

                                          Количество недобросовесных репетиторов посчитать сложно, так как мы не знаем о всех фактах обмана.

                                          По сути задача системы поиска и рейтинга на платформе найти честных и качественных репетиторов и именно их показывать пользователю. По мере работы виявлять обманщиков, неквалифицированых и удалять их с платформы или понижать в рейтинге.
                                            +1
                                            То есть, рейтинг преподавателей на вашей платформе будет не только показывать их педагогическую компетентность, но и лояльность к оплате процентов со своей работы Вам, как каталогизатору? LOL
                                              –1
                                              Репетиторы которые работают с нами, при регистрации принимают правила работы с нами. Если репетитор нарушает эти правила — он обманщик (с моральной точки зрения). Советовать такого репетитора пользователю мы не будем и удалим его с платформы. На странице поиске у нас есть разные способы выдачи репетитора (сортировки), и если пользователь не хочет доверять нашему рейтингу он может отсортировать репетиторов например по популярности (сколько раз на репетитора оставляли заявки), количеству отзывов или других параметрах. Не вижу здесь никакой проблемы.
                                              +2
                                              Это очень напоминает прошлогоднюю попытку freelance.ru запретить общение вне ресурса. В результате чего они потеряли часть аудитории и понесли серьезные репутационные потери. Подобные компании забывают, что какую бы роль они себе не отводили, по сути они посредники (агенты), а такса агента жестко привязана к его способности контролировать рынок. В вашем случае контроля над рынком у вас нет: чем вы отличаетесь от обычной доски объявлений, которых тысячи? Могут ли 30 % дохода привести репетитору новых клиентов, если он пустит их на рекламу? Ваша комиссия в таком случае не может превышать 10 %. Таким образом, вы должны давать репетиторам дополнительные возможности, либо искать дополнительные источники заработка, предоставляя своим клиентам и репетиторам возможность общаться любым способом, почему я не могу провести урок с репетитором по дороге на работу по сотовому? Вместо того чтобы загонять их в рамки сайта, вы должны расширить имеющиеся возможности. Вам нужно сформировать для преподавателей ценность работы именно с вашим ресурсом, иначе вы рискуете ввязаться в бесполезную борьбу с собственными же исполнителями, что вряд ли пойдет на пользу ресурсу: они начнут пересылать контакты в виде картинок или по одной букве. И тут суть вовсе не в сокращении размера комиссии: даже самую маленькую комиссию вам никто не заплатит, если ваша роль как посредника не очевидна.

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

                                              В ближайшее время я планирую выходить на рынок персонализированных услуг, но в другой сфере и так же в роли посредника, а все вышеизложенное — это мое мнение, основанное на личном опыте ведения бизнеса, от которого я отталкиваюсь делая свое предложение рынку.
                                                –1
                                                Интересная точка зрения, и мы многие из ваших мыслей нас посещали. Мы никого не загоняем в рамки сайта и вы совершенно правы что делать это бесполезно. Наши репетиторы могут работать с другими сайтами (и наверное делают это), но если они работают с нами то пусть соблюдают наши правила. Уточню, что мы довольны лояльностью наших репетиторов сейчас, и всегда она будет главной метрикой того что размер комиссии имеет допустимое значение. Размер нашей комиссии привязан к нашим планам развития проекта, при меньшей комиссии как я писал выше проект будет убыточным. Я не исключаю того что комиссия со временем может уменьшиться.

                                                  +1
                                                  Уточню, что мы довольны лояльностью наших репетиторов сейчас...

                                                  Остается верить, что это взаимно!

                                                  Расскажите, как ваши студенты могут оценить свой уровень и эффективность преподавания? Если я студент и изучаю английский впервые, мне нравится преподаватель и меня вроде бы все устраивает, но как я могу оценить насколько я продвинулся за n-занятий? Действительно ли моя индивидуальная программа эффективнее общеобразовательной? Другими словами есть ли у вас система тестов для самоконтроля?

                                                  И каким образом вы оцениваете преподавателей и их педагогические способности? Когда я проходил мастер-классы по той же фотографии, то столкнулся с ситуацией, когда фотограф не способен наладить диалог в группе, либо не может объяснить какие-либо приемы логически, предлагая ориентироваться «на глаз» (но на глаз я могу ориентироваться и бесплатно). Кто оценивает уровень подготовки преподавателя, есть ли отдел качества? Или это должен делать студент самостоятельно и за свой счет, пробуя разных преподавателей? Либо он защищен иным способом?
                                                    +1
                                                    Делать из принципиально убыточного бизнеса выгодный, закручивая гайки — тупиковый путь. Надо менять сам бизнес.

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

                                        Самое читаемое