Scikit-learn: تكون قيمة MSE سالبة عند إرجاعها بواسطة cross_val_score

أنت تشير إلى

greater_is_better : boolean, default=True

Whether score_func is a score function (default), meaning high is good, 
or a loss function, meaning low is good. In the latter case, the scorer 
object will sign-flip the outcome of the score_func.

في http://scikit-learn.org/stable/modules/generated/sklearn.metrics.make_scorer.html
؟ (فقط للإشارة)

أوافق على أنه يمكن أن يكون أكثر وضوحًا في مستندات cross_val_score

شكرا على الإبلاغ

في الواقع ، لقد أغفلنا هذه المشكلة عند إعادة هيكلة المسجل. ما يلي غير بديهي للغاية:

>>> import numpy as np
>>> from sklearn.datasets import load_boston
>>> from sklearn.linear_model import RidgeCV
>>> from sklearn.cross_validation import cross_val_score

>>> boston = load_boston()
>>> np.mean(cross_val_score(RidgeCV(), boston.data, boston.target, scoring='mean_squared_error'))
-154.53681864311497

/ cc larsmans

راجع للشغل لا أوافق على أنها مشكلة توثيق. يجب أن تُرجع القيمة cross_val_score القيمة مع الإشارة التي تتطابق مع اسم التسجيل. من الناحية المثالية ، يجب أن يكون GridSearchCV(*params).fit(X, y).best_score_ ثابتًا أيضًا. وإلا فإن واجهة برمجة التطبيقات مربكة للغاية.

أوافق أيضًا على أن التغيير لإرجاع MSE الفعلي بدون تبديل العلامة سيكون هو الخيار الأفضل.

يمكن أن يخزن كائن المسجل فقط علامة greater_is_better وكلما تم استخدام المسجل ، يمكن قلب العلامة في حالة الحاجة إليها ، على سبيل المثال في GridSearchCV .

أوافق على أن لدينا مشكلة متعلقة بقابلية الاستخدام هنا ، لكنني لا أتفق تمامًا مع حل

إرجاع القيمة مع العلامة التي تتطابق مع اسم التسجيل

لأن هذا اختراق غير موثوق به على المدى الطويل. ماذا لو قام شخص ما بتعريف مسجل مخصص باسم مثل mse ؟ ماذا لو اتبعوا نمط التسمية لكنهم قاموا بلف المحرر في ديكور يغير الاسم؟

يمكن أن يخزن كائن المسجل فقط علامة أكبر_is_better وكلما تم استخدام المسجل ، يمكن قلب العلامة في حالة الحاجة إليها ، على سبيل المثال في GridSearchCV.

هذا ما فعله المسجلون في الأصل ، أثناء التطوير بين إصدارات 0.13 و 0.14 وجعل تعريفهم أكثر صعوبة. كما أنه جعل من الصعب متابعة الكود لأن السمة greater_is_better بدت وكأنها تختفي في كود المسجل ، فقط لتظهر مرة أخرى في منتصف كود بحث الشبكة. كانت هناك حاجة إلى فئة Scorer خاصة للقيام بشيء مثالي ، وظيفة بسيطة ستفعله.

أعتقد أنه إذا أردنا تحسين النتائج ، فيجب أن يتم تعظيمها. من أجل سهولة الاستخدام ، أعتقد أننا قد نقدم معلمة score_is_loss ∈ ["auto", True, False] التي تغير فقط _display_ من الدرجات ويمكنها استخدام الكشف عن مجريات الأمور على أساس الأسماء المضمنة.

كانت تلك استجابة سريعة لأنني اضطررت للنزول من القطار ما قصدته بكلمة "عرض" هو قيمة الإرجاع من cross_val_score . أعتقد أنه يجب أن يكون الهدافون بسيطين وموحدين ويجب أن تزيد الخوارزميات دائمًا.

هذا يقدم عدم تناسق بين المصححين المدمجين والمخصصين.

تضمين التغريدة

يعجبني حل Score_is_loss ، أو أي شيء بهذا المعنى .. يبدو أن تغيير العلامة لتتناسب مع اسم التسجيل يبدو من الصعب الحفاظ عليه قد يسبب مشاكل كما ذكر larsmans

ما الخاتمة وما الحل الذي يجب أن نذهب إليه؟ :)

larsmansjaquesgroblertdomhan هل تعرف ما إذا كان هذا ينطبق على r2 كذلك؟ ألاحظ أن درجات r2 التي تم إرجاعها بواسطة GridSearchCV هي أيضًا سلبية في الغالب لـ ElasticNet و Lasso و Ridge .

يمكن أن تكون R² موجبة أو سالبة ، وتعني السالبة ببساطة أن أداء النموذج ضعيف جدًا.

IIRC ، GaelVaroquaux كان مؤيدًا لإرجاع رقم سالب عند greater_is_better=False .

r2 هي دالة للنتيجة (الأكبر هو الأفضل) ، لذا يجب أن يكون ذلك إيجابيًا إذا كان نموذجك جيدًا - لكنه أحد مقاييس الأداء القليلة التي يمكن أن تكون سلبية بالفعل ، مما يعني أسوأ من 0.

ما هو الإجماع على هذه المسألة؟ في رأيي ، cross_val_score هي أداة تقييم وليست أداة اختيار نموذج. وبالتالي يجب أن ترجع القيم الأصلية.

يمكنني إصلاحه في رقم PR # 2759 الخاص بي ، لأن التغييرات التي أجريتها تجعل من السهل حقًا الإصلاح. الحيلة هي عدم قلب التسجيل مقدمًا ، ولكن بدلاً من ذلك ، الوصول إلى السمة greater_is_better على المسجل عند إجراء بحث الشبكة.

ما هو الإجماع على هذه المسألة؟ في رأيي ، cross_val_score هو
أداة تقييم وليس اختيار نموذج. وبالتالي يجب أن تعود
القيم الأصلية.

الحالة الخاصة هي السلوكيات المتفاوتة مصدر مشاكل في البرامج.

أعتقد ببساطة أنه يجب علينا إعادة تسمية "mse" إلى "negated_mse" في القائمة
سلاسل التهديف المقبولة.

ماذا لو قام شخص ما بتعريف مسجل مخصص باسم مثل MSE؟ ماذا لو اتبعوا نمط التسمية لكنهم قاموا بلف المحرر في ديكور يغير الاسم؟

لا أعتقد أن ogrisel كان يقترح استخدام مطابقة الاسم ، فقط ليكون متسقًا مع المقياس الأصلي. صححني إذا كنت مخطئاogrisel.

أعتقد ببساطة أنه يجب علينا إعادة تسمية "mse" إلى "negated_mse" في قائمة سلاسل التهديف المقبولة.

هذا غير بديهي تمامًا إذا كنت لا تعرف الأجزاء الداخلية لـ scikit-Learn. إذا كان عليك ثني النظام بهذه الطريقة ، أعتقد أنه علامة على وجود مشكلة في التصميم.

هذا غير بديهي تمامًا إذا كنت لا تعرف الأجزاء الداخلية لـ scikit-Learn.
إذا كان عليك ثني النظام بهذه الطريقة ، أعتقد أنه علامة على وجود ملف
مشكلة التصميم.

أنا أعترض. يفهم البشر الأشياء بالكثير من المعرفة المسبقة و
سياق الكلام. كلهم ما عدا نظام. تحاول تضمين هذا في البرنامج
يعطي قائمة التسوق مثل مجموعة من الحالات الخاصة. لا يصنع فقط
برامج يصعب صيانتها ، ولكن هذا يعني أيضًا أن الأشخاص الذين ليس لديهم
في الاعتبار أن هذه الاستثناءات تصطدم بسلوكيات مفاجئة وتكتب عربات التي تجرها الدواب
كود باستخدام المكتبة.

ما هي الحالة الخاصة التي تفكر فيها؟

للتوضيح ، أعتقد أن درجات التحقق المتبادل المخزنة في الكائن GridSearchCV يجب أن تكون _ أيضًا_ القيم الأصلية (وليس مع الإشارة المقلوبة).

AFAIK ، تم تقديم قلب العلامة لجعل تنفيذ بحث الشبكة أبسط قليلاً ولكن لم يكن من المفترض أن يؤثر على قابلية الاستخدام.

ما هي الحالة الخاصة التي تفكر فيها؟

حسنًا ، حقيقة أنه بالنسبة لبعض المقاييس الأكبر تكون أفضل ، بينما بالنسبة إلى مقاييس أخرى
إنه العكس.

AFAIK ، تم تقديم علامة التقليب من أجل إجراء بحث في الشبكة
التطبيق أبسط قليلاً ولكن لم يكن من المفترض أن يؤثر
سهولة الاستخدام.

لا يتعلق الأمر ببحث الشبكة ، بل يتعلق بفصل الاهتمامات: النتائج
يجب أن تكون قابلة للاستخدام دون معرفة أي شيء عنها ، أو كتابة التعليمات البرمجية لـ
التعامل مع خصوصياتهم سينتشر إلى قاعدة الكود بأكملها. هناك
بالفعل الكثير من رمز التسجيل.

ولكن هذا إلى حد ما يؤجل المشكلة إلى رمز المستخدم. لا أحد يريد أن يرسم "رفضت MSE" حتى يضطر المستخدمون إلى قلب الإشارات مرة أخرى في التعليمات البرمجية الخاصة بهم. هذا أمر غير مريح ، خاصة بالنسبة لتقارير التحقق من الصحة متعددة المقاييس (PR # 2759) ، حيث تحتاج إلى التعامل مع كل مقياس على حدة. أتساءل عما إذا كان بإمكاننا الحصول على أفضل ما في العالمين: الشفرة العامة والنتائج البديهية.

ولكن هذا إلى حد ما يؤجل المشكلة إلى رمز المستخدم. لا أحد يريد
لرسم "MSE المنفي" بحيث يتعين على المستخدمين قلب الإشارات مرة أخرى في ملفات
الشفرة.

بالتأكيد ليست نهاية العالم. لاحظ أنه عند قراءة أوراق أو
عند النظر إلى العروض التقديمية لدي نفس المشكلة: عندما لا يكون الرسم البياني كذلك
أحسنت صنعًا ، فقد فقدت القليل من الوقت وعرض النطاق الترددي العقلي في محاولة لذلك
الرقم إذا كان الأكبر هو الأفضل أم لا.

هذا غير مريح ، خاصةً بالنسبة للتحقق متعدد المقاييس
التقارير (PR # 2759) ، حيث تحتاج إلى التعامل مع كل مقياس على حدة.

لماذا ا. إذا قبلت فقط أن الحجم الأكبر دائمًا هو الأفضل ، فإنه يجعل
كل شيء أسهل ، بما في ذلك تفسير النتائج.

أتساءل عما إذا كان بإمكاننا الحصول على أفضل ما في العالمين: الشفرة العامة و
نتائج بديهية.

يكمن الخطر في وجود كود معقد للغاية يؤدي إلى إبطاء عملية الصيانة
و تطور. Scikit-Learn يكتسب الوزن.

إذا قبلت فقط أن الأكبر دائمًا هو الأفضل

هذا ما قالته :)

والأكثر جدية ، أعتقد أن أحد أسباب هذا إرباك الناس هو أن ناتج cross_val_score لا يتوافق مع المقاييس. إذا اتبعنا منطقك ، فيجب أن تتبع جميع المقاييس في sklearn.metrics "الأكبر هو الأفضل".

هذا ما قالته :)

هذا لطيف!

الأكثر جدية ، أعتقد أن أحد أسباب هذا إرباك الناس هو ذلك
ناتج cross_val_score لا يتوافق مع المقاييس. اذا نحن
اتبع منطقك ، يجب أن تتبع جميع المقاييس في sklearn.metrics "أكبر
أفضل".

متفق عليه. لهذا السبب أحب فكرة تغيير الاسم: سيظهر
في عيون الناس.

والأكثر جدية ، أعتقد أن أحد أسباب هذا إرباكًا للناس هو أن ناتج cross_val_score لا يتوافق مع المقاييس.

وهذا بدوره يجعل scoring يبدو أكثر غموضًا مما هو عليه.

تعرضت للعض من هذا اليوم في 0.16.1 عند محاولة القيام بانحدار خطي. في حين يبدو أن علامة النتيجة لم تعد مقلوبة بالنسبة للمصنفات ، إلا أنها لا تزال مقلوبة للانحدار الخطي. للإضافة إلى الارتباك ، تقوم LinearRegression.score () بإرجاع إصدار غير مقلوب من الدرجة.

أود أن أقترح جعلها كلها متسقة وإرجاع النتيجة غير المقلوبة للنماذج الخطية أيضًا.

مثال:

from sklearn import linear_model
from sklearn.naive_bayes import GaussianNB
from sklearn import cross_validation
from sklearn import datasets
iris = datasets.load_iris()
nb = GaussianNB()
scores = cross_validation.cross_val_score(nb, iris.data, iris.target)
print("NB score:\t  %0.3f" % scores.mean() )

iris_reg_data = iris.data[:,:3]
iris_reg_target = iris.data[:,3]
lr = linear_model.LinearRegression()
scores = cross_validation.cross_val_score(lr, iris_reg_data, iris_reg_target)
print("LR score:\t %0.3f" % scores.mean() )

lrf = lr.fit(iris_reg_data, iris_reg_target)
score = lrf.score(iris_reg_data, iris_reg_target)
print("LR.score():\t  %0.3f" % score )

هذا يعطي:

NB score:     0.934    # sign is not flipped
LR score:    -0.755    # sign is flipped
LR.score():   0.938    # sign is not flipped

يقلب التحقق المتقاطع جميع علامات النماذج حيث يكون الأكبر هو الأفضل. ما زلت أعارض هذا القرار. أعتقد أن المؤيد الرئيسي لذلك كان GaelVaroquaux وربما mblondel [تذكرت أنك

أوه لا تهتم ، كل النقاش أعلاه.
أشعر بتقليب العلامة بشكل افتراضي في MSE و r2 أقل حدسية: - /

Huitzilo GaussianNB هو مصنف ويستخدم الدقة

صحيح ، لقد كنت مرتبكًا بعض الشيء بشأن ما يحدث ، لم يتم قلب r2 ... فقط mse سيكون.

ربما يكون حل المشكلة برمتها هو إعادة تسمية الشيء negmse ؟

mblondel بالطبع أنت على حق ، آسف. كنت أصفع معًا بسرعة مثالًا على الانحدار ، وفي ثقتي المفرطة ببيانات قزحية العين اعتقدت أن توقع الميزة رقم 4 من الآخرين سيعمل (مع R2 الموجب). لكنها لم تكن ، بالتالي ، سلبية R2. لا توجد علامة تقلب هنا. حسنا. خطأي.

ومع ذلك ، انقلبت العلامة في MSE التي أحصل عليها من cross_val_score .

ربما أنا فقط ، لكني أجد هذا التناقض مربكًا إلى حد كبير (وهو ما دفعني إلى هذه المشكلة). لماذا يجب قلب علامة MSE ، وليس R2؟

ربما أنا فقط ، لكني أجد هذا التناقض مربكًا إلى حد كبير (وهو ما دفعني إلى هذه المشكلة). لماذا يجب قلب علامة MSE ، وليس R2؟

لأن دلالة الدرجة الأعلى أفضل. ارتفاع MSE أمر سيء.

ربما يحل Negmse المشكلة

amueller أوافق ، فإن جعل علامة التقليب صريحة في اسم معلمة التسجيل سيساعد بالتأكيد على تجنب الالتباس.

ربما يمكن أن تكون الوثائق الموجودة في [1] أكثر وضوحًا حول كيفية تقليب العلامات لبعض الدرجات. في حالتي ، كنت بحاجة إلى المعلومات بسرعة ولم ألقي نظرة إلا على الجدول تحت 3.1.1.1 ، لكنني لم أقرأ النص (الذي يفسر مبدأ "الأكبر هو الأفضل"). IMHO ، إضافة تعليق لـ mse و median و يعني الخطأ المطلق في الجدول تحت 3.1.1.1 ، مما يشير إلى نفيها ، من شأنه أن يساعد كثيرًا بالفعل ، دون أي تغييرات على الكود الفعلي.

[1] http://scikit-learn.org/stable/modules/model_evaluation.html#scoring -parameter

لقد صادفت حالة مثيرة جدًا للاهتمام:

from sklearn.cross_validation import cross_val_score
model = LinearRegression()
scores = cross_val_score(model, X, target, cv=2, scoring='r2')
scores

النتائج في

array([-0.17026282, -2.21315179])

لنفس مجموعة البيانات الكود التالي

model = LinearRegression()
model.fit(X, target)
prediction = model.predict(X)
print r2_score(target, prediction)

ينتج عنه قيمة معقولة

0.353035789318

AFAIK لنموذج الانحدار الخطي (مع التقاطع) لا يمكن للمرء الحصول على R ^ 2> 1 أو R ^ 2 <0

وبالتالي ، فإن نتيجة السيرة الذاتية لا تبدو مثل R ^ 2 بعلامة مقلوبة. هل أنا مخطئ في مرحلة ما؟

يمكن أن تكون r2 سالبة (للنماذج السيئة). لا يمكن أن يكون أكبر من 1.

ربما كنت أكثر من اللازم. محاولة:

from sklearn.cross_validation import train_test_split

X_train, X_test, y_train, y_test = train_test_split(X, target, test_size=0.2, random_state=0)
model = LinearRegression()
model.fit(X_train, y_train)
pred_train = model.predict(X_train)
print("train r2: %f" % r2_score(y_train, pred_train))

pred_test = model.predict(X_test)
print("test r2: %f" % r2_score(y_test, pred_test))

جرب باستخدام قيم مختلفة للعدد الأولي الصحيح random_state الذي يتحكم في التقسيم العشوائي.

ربما يحل Negmse المشكلة

+1 لـ "neg_mse" (أعتقد أن الشرطة السفلية تجعل الأشياء أكثر قابلية للقراءة).

هل هذا يحل كل المشاكل؟ هل هناك درجات أخرى كانت أكبر وليس أفضل؟

هناك:

• log_loss
• mean_absolute_error
• median_absolute_error

وفقًا لـ doc/modules/model_evaluation.rst ، يجب أن يكون هذا كل منهم.

و hinge_loss أعتقد؟

تبدو إضافة البادئة neg_ لكل هذه الخسائر أمرًا محرجًا.

تتمثل الفكرة في إرجاع الدرجات الأصلية (بدون علامة الوجه) ولكن بدلاً من إرجاع ndarray ، نعيد فئة تمتد ndarray بطرق مثل best() ، arg_best() ، best_sorted() . بهذه الطريقة النتائج غير مفاجئة ولدينا طرق مريحة لاسترداد أفضل النتائج.

لا يوجد سجل لفقدان المفصلة (ولم أره يستخدم للتقييم).

لا يقوم المسجل بإرجاع مصفوفة عددية ، فإنه يقوم بإرجاع عدد عشري ، أليس كذلك؟
يمكننا إرجاع كائن النتيجة الذي يحتوي على ">" مخصص ولكن يبدو وكأنه عائم.
يبدو لي هذا أكثر اختراعًا من الحل السابق ، والذي كان يميز المسجل بعلامة "low_is_better" المنطقية التي تم استخدامها بعد ذلك في GridSearchCV.

cross_val_score بإرجاع مصفوفة.

في الواقع ، لا تحتاج الدرجات التي تم إرجاعها بواسطة cross_val_score عادةً إلى فرزها ، فقط احتسب المتوسط.

فكرة أخرى هي إضافة طريقة sorted إلى _BaseScorer .

my_scorer = make_scorer(my_metric, greater_is_better=False)
scores = my_scorer.sorted(scores)  # takes into account my_scorer._sign
best = scores[0]

يُرجع cross_val_score مصفوفة ، لكن المُحدد يُرجع عددًا عشريًا. أشعر أنه سيكون من الغريب أن يكون لديك منطق محدد في cross_val_score لأنك ترغب في أن يكون لديك نفس السلوك في GridSearchCV وفي جميع كائنات السيرة الذاتية الأخرى.

ستحتاج أيضًا إلى طريقة argsort ، لأنك في GridSearchCV تريد أفضل نتيجة وأفضل مؤشر.

كيف يتم تنفيذ "تقدير الوسائل والفروق لأخطاء العمال من أسئلة الضبط ، ثم حساب المتوسط ​​المرجح بعد إزالة التحيز المقدر للتنبؤات" بواسطة scikit-Learn؟

لقد ناقشنا IIRC هذا في السباق (الصيف الماضي ؟!) وقررنا الذهاب مع neg_mse (أو هل كان neg-mse ) وإهمال جميع الهدافين / السلاسل حيث لدينا علامة سلبية الآن.
هل ما زال هذا الإجماع؟ يجب أن نفعل ذلك قبل 0.18 بعد ذلك.
بينغGaelVaroquauxagramfortjnothmanogriselraghavrv

نعم اتفقنا على Neg_mse AFAIK

كان neg_mse

نحن بحاجة أيضا:

• neg_log_loss
• neg_mean_absolute_error
• neg_median_absolute_error

النموذج = تسلسلي ()
keras.layers.Flatten ()
model.add (كثيف (11، input_dim = 3، kernel_initializer = keras.initializers.he_normal (بذرة = 2) ،
kernel_ucationizer = نظام منتظم. l2 (2)))
keras.layers.LeakyReLU (ألفا = 0.1)
model.add (كثيف (8، kernel_initializer = keras.initializers.he_normal (بذرة = 2)))
keras.layers.LeakyReLU (ألفا = 0.1)
model.add (كثيف (4، kernel_initializer = keras.initializers.he_normal (بذرة = 2)))
keras.layers.LeakyReLU (ألفا = 0.1)
model.add (كثيف (1، kernel_initializer = keras.initializers.he_normal (بذرة = 2)))
keras.layers.LeakyReLU (ألفا = 0.2)
adag = RMSprop (lr = 0.0002)
model.compile (الخسارة = الخسائر. mean_squared_error ،
محسن = adag
)
history = model.fit (X_train ، Y_train ، عهود = 2000 ،
حجم_الدفعة = 20 ، خلط ورق اللعب = صحيح)

كيفية عبور التحقق من صحة الرمز أعلاه؟ أريد ترك طريقة تحقق متقاطعة لاستخدامها في هذا.

shreyassks ، هذا ليس المكان الصحيح لسؤالك لكنني أود التحقق من ذلك: https://keras.io/scikit-learn-api . لف شبكتك في مقدر scikit-learn ثم استخدم w / model_selection.cross_val_score

نعم. انا موافق تماما! حدث هذا أيضًا لـ Brier_score_loss ، إنه يعمل بشكل جيد تمامًا باستخدام Brier_score_loss ، لكنه يصبح مربكًا عندما يأتي من GridSearchCV ، إرجاع Brier_score_loss السلبي. على الأقل ، سيكون من الأفضل إخراج شيء مثل ، نظرًا لأن Brier_score_loss يمثل خسارة (كلما كان الانخفاض أفضل) ، فإن وظيفة التسجيل هنا تقلب العلامة لتجعلها سالبة.

الفكرة هي أن cross_val_score يجب أن تركز بالكامل على القيمة المطلقة للنتيجة. في علمي ، لم يتم تحديد أهمية العلامة السلبية (-) التي تم الحصول عليها لـ MSE (متوسط ​​الخطأ التربيعي) في cross_val_score. دعنا ننتظر الإصدار المحدث من sklearn حيث يتم الاهتمام بهذه المشكلة.

لحالة استخدام الانحدار:
model_score = cross_val_score (model، df_input، df_target، scoring = 'neg_mean_squared_error'، cv = 3)
أحصل على القيم على النحو التالي:

SVR:
[-6.20938025 -1.397376 -1.94519]
-3.183982080147279

الانحدارالخطي:
[-5.94898085 -9.30931808-1.15760676]
-5.4719685646934275

لاسو:
[-7.22363814 -10.47734135 -2.20807684]
-6.6363521107522345

ريدج:
[-5.95990385 -4.17946756 -1.36885809]
-3.8360764993832004

حتى واحد الذي هو أفضل ؟
SVR؟

لحالة استخدام الانحدار:
أحصل على نتائج مختلفة عندما أستخدم
(1) "cross_val_score" مع التهديف = 'neg_mean_squared_error'
و
(2) لنفس المدخلات عندما أستخدم "GridSearchCV" وتحقق من "best_score_"

لنماذج الانحدار أيهما أفضل؟

• "cross_val_score" مع التهديف = 'neg_mean_squared_error'
  (أو)
• استخدم "GridSearchCV" وتحقق من "best_score_"

تضمين التغريدة
أنت تسأل سؤال استخدام. أداة تعقب المشكلات مخصصة بشكل أساسي للأخطاء والميزات الجديدة. بالنسبة لأسئلة الاستخدام ، يوصى بتجربة Stack Overflow أو القائمة البريدية .