Мышление на основе одномерной линейной регрессии Tensorflow

Архитектура

1 Искусство спрашивать

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

Минималистский код линейной регрессии может выглядеть так:

data = pd.read_csv('./dataset/Income1.csv')
plt.scatter(data.Education, data.Income)

x = data.Education
y = data.Income

# 顺序模型
model = tf.keras.Sequential()
# 添加Dense层 建立模型 输出维度1 输入维度1
model.add(tf.keras.layers.Dense(1, input_shape=(1,)))
# 输出模型信息
model.summary()
# 模型编译 优化算法:adam 损失函数:mse
model.compile(optimizer='adam', loss="mse")
# 训练 训练次数5000
history = model.fit(x, y, epochs=5000)
# 预测
y_predict = model.predict(x)
print(y_predict)

Изучив одномерную линейную регрессию Tensorflow, какие вопросы мы можем задать новичку?

Анализ приведенного выше кода показывает, что его можно условно разделить на три этапа: загрузка данных -> обучение -> прогнозирование.

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

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

Сбор и хранение данных

Когда объем данных достигает определенного масштаба, необходимо разделение вычислений (обучения\прогнозирования) и хранения.

Если взять в качестве примера рекомендацию Douyin, объем данных массивных пользователей довольно велик, нужно ли здесь использовать механизм хранения больших данных, такой как HDFS?

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

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

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

Еще один вопрос, который необходимо учитывать, — это полный объем и приращение данных.

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

Для добавочного сбора данных мы будем использовать websocket+minio для моделирования в будущем.

Метод триггера

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

  • автоматический триггер

Когда объем непрерывно собираемых данных достигает порогового значения, запускается программа обучения, запланированное планирование задач или когда завершается программа восходящего потока (например, ETL).

  • Ручной триггер

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

Интернет вещей

В частности, рассмотрим здесь периферийные устройства IoT.

Противоречие заключается в ограниченности ресурсов пограничных устройств и надежности облачных вычислений (включая соображения надежности сети и сетевой безопасности).Ожидается, что вычислительная мощность облачных вычислений может быть использована при обеспечении надежности.Когда пограничные устройства продолжают собирать data , загружать их на облачный сервер пакетами (или в режиме реального времени), облачный сервер выполняет обучение данных (очистку), а затем загружает обученную модель на граничное устройство, что обеспечивает безопасность за счет ограничения разрешений конкретных портов. и облачные серверы Даже в случае отключения периферийные устройства могут по-прежнему использовать старую модель для выполнения прогнозов, более того, граничные устройства могут временно взять на себя задачу обучения.

Для управления непрофильными терминалами (такими как датчики) не исключено обращение напрямую в облако, однако шифрование данных по-прежнему является проблемой, которую необходимо учитывать.

предсказывать

Прогнозирование — это процесс в реальном времени, а оперативность прогнозирования — ключевой показатель (можно ли лаг назвать прогнозированием? Рассмотрим прогнозирование запасов).

Рассмотрим два сценария прогнозирования:

  • Интерактивный прогноз

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

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

  • прогноз в реальном времени

Всевозможные потоковые данные, будь то flv\websocket\mqtt\flink\kafka и т.д.

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

Здесь основное внимание уделяется интеллектуальным устройствам (например, автономным вождения\беспилотным (истребителям) самолетам).

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

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

состязательная модель

Рассмотрим следующие сценарии: Игра в шахматы\Соревнование компании\Львы, охотящиеся на антилоп\Бой с БПЛА\Работа (официальная) полевая борьба -> Теория игр

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

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

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

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

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

2 Реализация

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

Бэкенд-код фляги

Здесь уместно использовать глобальный объект модели, модель не связана с сеансом (т.е. не привязана к пользовательскому потоку).

model = None
training_flag = 0


# 训练模型(手动触发)
@app.route('/train', methods=['POST'])
def train():
    global model, training_flag
    training_flag = 0
    data = pd.read_csv('./dataset/Income.csv')
    x = data.Education
    y = data.Income
    model = tf.keras.Sequential()
    model.add(tf.keras.layers.Dense(1, input_shape=(1,)))
    model.compile(optimizer='adam', loss="mse")
    model.fit(x, y, epochs=500)
    training_flag = 1
    return 'success'


# 训练结束标识
@app.route('/training_flag', methods=['GET'])
def training_flag():
    global training_flag
    return {
        'training_flag': training_flag
    }


# 预测
@app.route("/predict", methods=['POST'])
def predict():
    json_data = request.get_json()
    x_predict = json_data['x_predict']
    global model
    y_predict = model.predict(tuple(x_predict))
    return {
        'y_predict': np.array(y_predict).tolist()
    }


# 上传
@app.route('/upload', methods=['POST'])
def upload():
    f = request.files['file']
    f.save('./dataset/Income.csv')
    return 'success'

интерфейсный код

визуализация

3.gif

журнал изменений


2020-10-20 21:00 Обновление веб-интерактивной реализации фляги


20.10.2020 22:00 Обновлены мысли о хранении и сборе данных

б список дел

  • websocket + minio имитирует сбор данных в реальном времени