Quelle est la meilleure façon de mettre en œuvre le poids des contraintes dans TensorFlow?

De TensorFlow 1.4, il y a un nouvel argument à tf.get_variable qui permet de passer d'une fonction de contrainte qui lui est appliquée après la mise à jour de l'optimiseur. Voici un exemple qui applique une contrainte de non-négativité:

with tf.variable_scope("MyScope"):
  v1 = tf.get_variable("v1", …, constraint=lambda x: tf.clip_by_value(x, 0, np.infty))

contrainte: Une option de fonction de projection pour être appliqué à la
variable
après avoir été mis à jour par un Optimizer (par exemple, utilisés pour mettre en œuvre la norme
des contraintes ou des contraintes de valeur pour la couche de poids). La fonction doit
prendre en entrée le unprojected Tenseur représentant la valeur de la
variable et retour le Tenseur de la valeur projetée
(qui doivent avoir la même forme). Les contraintes ne sont pas sûrs de
utilisation lors d'distribué asynchrone de formation.

Il existe une solution pratique: Votre fonction de coût peut être écrit par vous, de coût élevé sur le poids est négatif. Je l'ai fait en une factorisation de matrice modèle dans TensorFlow avec python, et cela a fonctionné assez bien. Droit? Je veux dire, c'est évident. Mais personne d'autre ne le mentionne si vous pouvez y aller. EDIT: je viens de voir que la Marque Borderding a également donné une autre perte et de coût basée sur l'implémentation de la solution avant que je n'.

Et si "la meilleure façon" est voulu, comme l'OP posé, que faire alors? Bien "meilleur" peut en fait être spécifique à l'application, dans ce cas, vous auriez besoin d'essayer quelques différentes façons avec votre dataset et d'envisager votre les exigences de l'application.

Voici code du travail pour augmenter le coût pour les négatifs solution variables:

cost = tf.reduce_sum(keep_loss) + Lambda * reg # Cost = sum of losses for training set, except missing data.        
if prefer_nonneg: # Optionally increase cost for negative values in rhat, if you want that.
    negs_indices = tf.where(rhat < tf.constant(0.0))
    neg_vals = tf.gather_nd(rhat, negs_indices)
    cost += 2. * tf.reduce_sum(tf.abs(neg_vals))  # 2 is a magic number (empirical parameter)         

Vous êtes libre d'utiliser mon code mais s'il vous plaît donnez-moi un peu de crédit si vous choisissez de l'utiliser. Donner un lien vers cette réponse sur stackoverflow.com s'il vous plaît.

Cette conception serait considérée comme une contrainte souple, parce que vous pouvez toujours obtenir le poids est négatif, si vous le permettez, selon votre définition du coût.

Il semble que la contrainte= est aussi disponible en TF v1.4+ en tant que paramètre à tf.get_variable(), où vous pouvez passer une fonction comme la tf.clip_by_value. Cela semble être une autre contrainte souple, pas de contrainte, à mon avis, parce qu'il dépend de votre fonction fonctionne bien ou pas. Il peut également être lent, comme les autres répondeur essayé la même fonction et a signalé qu'il était lent à converger, même si ils n'ont pas utilisé la contrainte= paramètre pour ce faire. Je ne vois pas pourquoi l'un serait plus rapide que l'autre, car ils utilisent tous les deux le même écrêtage approche. Donc, si vous utilisez la contrainte= paramètre alors vous devriez vous attendre lente convergence dans le contexte de l'affiche originale de l'application.

Il serait plus agréable si TF fourni vrai dur contraintes à l'API, et laissez-TF comprendre comment appliquer cela aussi bien que pour être efficace sur le back-end. Je veux dire, j'ai vu cette façon de faire dans la programmation linéaire solveurs déjà depuis longtemps. L'application déclare une contrainte, et à l'arrière il arrive.