মেশিন লার্নিং এর নিয়ম:

সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।

এমএল ইঞ্জিনিয়ারিং এর জন্য সেরা অনুশীলন

মার্টিন জিনকেভিচ

এই দস্তাবেজটি যাদের মেশিন লার্নিং সম্পর্কে প্রাথমিক জ্ঞান রয়েছে তাদের মেশিন লার্নিংয়ে Google-এর সেরা অনুশীলনের সুবিধা পেতে সাহায্য করার উদ্দেশ্যে। এটি মেশিন লার্নিংয়ের জন্য একটি স্টাইল উপস্থাপন করে, Google C++ স্টাইল গাইড এবং ব্যবহারিক প্রোগ্রামিংয়ের অন্যান্য জনপ্রিয় গাইডের মতো। আপনি যদি মেশিন লার্নিং-এ ক্লাস নিয়ে থাকেন, বা মেশিন-লার্নিং মডেলে তৈরি বা কাজ করেন, তাহলে এই নথিটি পড়ার জন্য আপনার প্রয়োজনীয় পটভূমি রয়েছে।

মার্টিন জিনকেভিচ মেশিন লার্নিং এর তার প্রিয় 10টি নিয়ম চালু করেছেন। সমস্ত 43 টি নিয়ম শিখতে পড়ুন!

পরিভাষা

আমাদের কার্যকর মেশিন লার্নিং আলোচনায় নিম্নলিখিত পদগুলি বারবার উঠে আসবে:

  • উদাহরণ : আপনি যে বিষয়ে ভবিষ্যদ্বাণী করতে চান। উদাহরণস্বরূপ, উদাহরণটি একটি ওয়েব পৃষ্ঠা হতে পারে যা আপনি "বিড়াল সম্পর্কে" বা "বিড়াল সম্পর্কে নয়" হিসাবে শ্রেণীবদ্ধ করতে চান।
  • লেবেল : একটি ভবিষ্যদ্বাণী কাজের জন্য একটি উত্তর হয় একটি মেশিন লার্নিং সিস্টেম দ্বারা উত্পাদিত উত্তর, অথবা প্রশিক্ষণ ডেটাতে সরবরাহ করা সঠিক উত্তর৷ উদাহরণস্বরূপ, একটি ওয়েব পৃষ্ঠার লেবেল হতে পারে "বিড়াল সম্পর্কে"।
  • বৈশিষ্ট্য : একটি ভবিষ্যদ্বাণী কার্যে ব্যবহৃত একটি উদাহরণের একটি বৈশিষ্ট্য। উদাহরণস্বরূপ, একটি ওয়েব পৃষ্ঠায় একটি বৈশিষ্ট্য থাকতে পারে "বিড়াল শব্দটি রয়েছে"।
  • বৈশিষ্ট্য কলাম : সংশ্লিষ্ট বৈশিষ্ট্যের একটি সেট, যেমন ব্যবহারকারীরা বসবাস করতে পারে এমন সমস্ত সম্ভাব্য দেশের সেট। একটি উদাহরণে একটি বৈশিষ্ট্য কলামে এক বা একাধিক বৈশিষ্ট্য থাকতে পারে। "ফিচার কলাম" হল Google-নির্দিষ্ট পরিভাষা। একটি বৈশিষ্ট্য কলাম VW সিস্টেমে একটি "নেমস্পেস" হিসাবে উল্লেখ করা হয় (Yahoo/Microsoft এ), বা একটি ক্ষেত্র
  • উদাহরণ : একটি উদাহরণ (এর বৈশিষ্ট্য সহ) এবং একটি লেবেল৷
  • মডেল : একটি ভবিষ্যদ্বাণী কাজের একটি পরিসংখ্যান উপস্থাপনা. আপনি উদাহরণগুলির উপর একটি মডেলকে প্রশিক্ষণ দেন তারপর ভবিষ্যদ্বাণী করতে মডেলটি ব্যবহার করুন।
  • মেট্রিক : একটি সংখ্যা যা আপনি যত্নশীল। সরাসরি অপ্টিমাইজ করা হতে পারে বা নাও হতে পারে।
  • উদ্দেশ্য : একটি মেট্রিক যা আপনার অ্যালগরিদম অপ্টিমাইজ করার চেষ্টা করছে।
  • পাইপলাইন : একটি মেশিন লার্নিং অ্যালগরিদমের চারপাশের অবকাঠামো। সামনের প্রান্ত থেকে ডেটা সংগ্রহ করা, এটি প্রশিক্ষণ ডেটা ফাইলগুলিতে স্থাপন করা, এক বা একাধিক মডেলকে প্রশিক্ষণ দেওয়া এবং মডেলগুলিকে উত্পাদনে রপ্তানি করা অন্তর্ভুক্ত।
  • ক্লিক-থ্রু রেট একটি ওয়েব পৃষ্ঠায় দর্শকদের শতাংশ যারা একটি বিজ্ঞাপনের লিঙ্কে ক্লিক করে।

ওভারভিউ

দুর্দান্ত পণ্য তৈরি করতে:

আপনি যেমন মহান প্রকৌশলী, তেমন মহান মেশিন লার্নিং বিশেষজ্ঞের মতো নয়।

আপনি যে সমস্যার মুখোমুখি হবেন তার বেশিরভাগই আসলে ইঞ্জিনিয়ারিং সমস্যা। এমনকি একজন দুর্দান্ত মেশিন লার্নিং বিশেষজ্ঞের সমস্ত সংস্থান থাকা সত্ত্বেও, বেশিরভাগ লাভগুলি দুর্দান্ত বৈশিষ্ট্যগুলি থেকে আসে, দুর্দান্ত মেশিন লার্নিং অ্যালগরিদম নয়। সুতরাং, মৌলিক পদ্ধতি হল:

  1. নিশ্চিত করুন যে আপনার পাইপলাইন শেষ থেকে শেষ শক্ত।
  2. একটি যুক্তিসঙ্গত উদ্দেশ্য দিয়ে শুরু করুন।
  3. একটি সহজ উপায়ে সাধারণ জ্ঞান বৈশিষ্ট্য যোগ করুন.
  4. নিশ্চিত করুন যে আপনার পাইপলাইন শক্ত থাকে।

এই পদ্ধতিটি দীর্ঘ সময়ের জন্য ভাল কাজ করবে। এই পদ্ধতি থেকে বিচ্যুত হন শুধুমাত্র তখনই যখন আপনাকে আরও দূরে নিয়ে যাওয়ার জন্য আর কোন সহজ কৌশল নেই। জটিলতা যোগ করা ভবিষ্যত রিলিজকে ধীর করে দেয়।

একবার আপনি সহজ কৌশলগুলি শেষ করে ফেললে, অত্যাধুনিক মেশিন লার্নিং সত্যিই আপনার ভবিষ্যতে হতে পারে। তৃতীয় ধাপের মেশিন লার্নিং প্রকল্পের বিভাগটি দেখুন।

এই নথিটি নিম্নরূপ সাজানো হয়েছে:

  1. প্রথম অংশটি আপনাকে বুঝতে সাহায্য করবে যে সময়টি একটি মেশিন লার্নিং সিস্টেম তৈরির জন্য সঠিক কিনা।
  2. দ্বিতীয় অংশটি আপনার প্রথম পাইপলাইন স্থাপন সম্পর্কে।
  3. তৃতীয় অংশটি আপনার পাইপলাইনে নতুন বৈশিষ্ট্য যুক্ত করার সময় লঞ্চ করা এবং পুনরাবৃত্তি করা, মডেলগুলি এবং প্রশিক্ষণ-সার্ভিং স্ক্যু কীভাবে মূল্যায়ন করা যায় সে সম্পর্কে।
  4. আপনি যখন একটি মালভূমিতে পৌঁছান তখন কী করবেন সে সম্পর্কে চূড়ান্ত অংশ
  5. এর পরে, এই নথিতে উদাহরণ হিসাবে সাধারণত ব্যবহৃত সিস্টেমগুলির কিছু পটভূমি সহ সম্পর্কিত কাজের একটি তালিকা এবং একটি পরিশিষ্ট রয়েছে।

মেশিন লার্নিং এর আগে

নিয়ম #1: মেশিন লার্নিং ছাড়া একটি পণ্য লঞ্চ করতে ভয় পাবেন না।

মেশিন লার্নিং দুর্দান্ত, তবে এর জন্য ডেটা প্রয়োজন। তাত্ত্বিকভাবে, আপনি একটি ভিন্ন সমস্যা থেকে ডেটা নিতে পারেন এবং তারপরে একটি নতুন পণ্যের জন্য মডেলটি টুইক করতে পারেন, তবে এটি সম্ভবত মৌলিক হিউরিস্টিকসকে কম করবে। আপনি যদি মনে করেন যে মেশিন লার্নিং আপনাকে 100% বুস্ট দেবে, তাহলে হিউরিস্টিক আপনাকে সেখানে 50% পথ পাবে।

উদাহরণস্বরূপ, আপনি যদি একটি অ্যাপ মার্কেটপ্লেসে অ্যাপের র‍্যাঙ্কিং করেন, আপনি হিউরিস্টিক হিসাবে ইনস্টলের হার বা ইনস্টলের সংখ্যা ব্যবহার করতে পারেন। আপনি যদি স্প্যাম শনাক্ত করেন তবে প্রকাশকদের ফিল্টার করুন যারা আগে স্প্যাম পাঠিয়েছেন। মানব সম্পাদনা ব্যবহার করতে ভয় পাবেন না। আপনার যদি পরিচিতিগুলিকে র‌্যাঙ্ক করার প্রয়োজন হয়, তবে সম্প্রতি ব্যবহৃত সর্বোচ্চ (অথবা এমনকি বর্ণানুক্রমিকভাবে র‌্যাঙ্ক করুন)। আপনার পণ্যের জন্য যদি মেশিন লার্নিং একেবারেই প্রয়োজন না হয়, আপনার ডেটা না থাকা পর্যন্ত এটি ব্যবহার করবেন না।

নিয়ম #2: প্রথমে, মেট্রিক্স ডিজাইন এবং বাস্তবায়ন করুন।

আপনার মেশিন লার্নিং সিস্টেম কী করবে তা আনুষ্ঠানিক করার আগে, আপনার বর্তমান সিস্টেমে যতটা সম্ভব ট্র্যাক করুন। নিম্নলিখিত কারণে এটি করুন:

  1. এর আগে সিস্টেমের ব্যবহারকারীদের কাছ থেকে অনুমতি পাওয়া সহজ।
  2. আপনি যদি মনে করেন যে ভবিষ্যতে কিছু উদ্বেগের কারণ হতে পারে তবে এখনই ঐতিহাসিক তথ্য পাওয়া ভাল।
  3. আপনি যদি মেট্রিক ইন্সট্রুমেন্টেশনের কথা মাথায় রেখে আপনার সিস্টেম ডিজাইন করেন, তাহলে ভবিষ্যতে আপনার জন্য আরও ভাল হবে। বিশেষভাবে, আপনি আপনার মেট্রিক্সের উপকরণের জন্য লগগুলিতে স্ট্রিংগুলির জন্য নিজেকে গ্রেপিং খুঁজে পেতে চান না!
  4. আপনি লক্ষ্য করবেন কি জিনিস পরিবর্তন হয় এবং কি একই থাকে। উদাহরণস্বরূপ, ধরুন আপনি একদিনের সক্রিয় ব্যবহারকারীদের সরাসরি অপ্টিমাইজ করতে চান। যাইহোক, আপনার সিস্টেমের প্রাথমিক ম্যানিপুলেশনের সময়, আপনি লক্ষ্য করতে পারেন যে ব্যবহারকারীর অভিজ্ঞতার নাটকীয় পরিবর্তনগুলি এই মেট্রিকটিকে লক্ষণীয়ভাবে পরিবর্তন করে না।

Google Plus টিম পরিমাপ করে প্রতি পঠিত, পুনঃভাগ, পাঠ প্রতি plusones, মন্তব্য/পড়া, ব্যবহারকারী প্রতি মন্তব্য, ব্যবহারকারী প্রতি পুনঃভাগ, ইত্যাদি যা তারা পরিবেশনের সময়ে একটি পোস্টের ভালতা গণনা করতে ব্যবহার করে। এছাড়াও, মনে রাখবেন যে একটি পরীক্ষামূলক কাঠামো, যেখানে আপনি ব্যবহারকারীদের বালতিতে গোষ্ঠী করতে পারেন এবং পরীক্ষার মাধ্যমে পরিসংখ্যান একত্রিত করতে পারেন, গুরুত্বপূর্ণ। নিয়ম #12 দেখুন।

মেট্রিক্স সংগ্রহের বিষয়ে আরও উদার হয়ে, আপনি আপনার সিস্টেমের একটি বিস্তৃত চিত্র পেতে পারেন। একটি সমস্যা লক্ষ্য করুন? এটি ট্র্যাক করতে একটি মেট্রিক যোগ করুন! শেষ প্রকাশে কিছু পরিমাণগত পরিবর্তন সম্পর্কে উত্তেজিত? এটি ট্র্যাক করতে একটি মেট্রিক যোগ করুন!

নিয়ম #3: একটি জটিল হিউরিস্টিক থেকে মেশিন লার্নিং বেছে নিন।

একটি সাধারণ হিউরিস্টিক আপনার পণ্যটি দরজার বাইরে পেতে পারে। একটি জটিল হিউরিস্টিক অপরিবর্তনীয়। একবার আপনার কাছে ডেটা এবং আপনি কী অর্জন করার চেষ্টা করছেন তার একটি প্রাথমিক ধারণা পেয়ে গেলে, মেশিন লার্নিংয়ে যান। বেশিরভাগ সফ্টওয়্যার ইঞ্জিনিয়ারিং কাজের মতো, আপনি আপনার পদ্ধতিকে ক্রমাগত আপডেট করতে চাইবেন, তা হিউরিস্টিক বা মেশিন-লার্নড মডেল হোক, এবং আপনি দেখতে পাবেন যে মেশিন-লার্নড মডেলটি আপডেট করা এবং বজায় রাখা সহজ ( বিধি #16 দেখুন) )

ML ফেজ I: আপনার প্রথম পাইপলাইন

আপনার প্রথম পাইপলাইনের জন্য আপনার সিস্টেম অবকাঠামোতে ফোকাস করুন। আপনি যে সমস্ত কল্পনাপ্রসূত মেশিন লার্নিং করতে যাচ্ছেন সে সম্পর্কে চিন্তা করা মজাদার হলেও, আপনি যদি প্রথমে আপনার পাইপলাইনে বিশ্বাস না করেন তবে কী ঘটছে তা বোঝা কঠিন হবে।

নিয়ম #4: প্রথম মডেলটিকে সরল রাখুন এবং সঠিক পরিকাঠামো পান।

প্রথম মডেলটি আপনার পণ্যের সবচেয়ে বড় বুস্ট প্রদান করে, তাই এটি অভিনব হওয়ার প্রয়োজন নেই। কিন্তু আপনি আপনার প্রত্যাশার চেয়ে অনেক বেশি পরিকাঠামোগত সমস্যায় পড়বেন। কেউ আপনার অভিনব নতুন মেশিন লার্নিং সিস্টেম ব্যবহার করার আগে, আপনাকে নির্ধারণ করতে হবে:

  • কিভাবে আপনার শেখার অ্যালগরিদম উদাহরণ পেতে.
  • আপনার সিস্টেমে "ভাল" এবং "খারাপ" বলতে কী বোঝায় তা প্রথম কাটা।
  • আপনার অ্যাপ্লিকেশনে আপনার মডেলকে কীভাবে একত্রিত করবেন। আপনি হয় মডেলটি লাইভ প্রয়োগ করতে পারেন, অথবা অফলাইনে উদাহরণগুলিতে মডেলটিকে প্রি-কম্পিউট করতে পারেন এবং ফলাফলগুলি একটি টেবিলে সংরক্ষণ করতে পারেন৷ উদাহরণস্বরূপ, আপনি ওয়েব পৃষ্ঠাগুলিকে প্রাক-শ্রেণীবদ্ধ করতে এবং একটি টেবিলে ফলাফল সংরক্ষণ করতে চাইতে পারেন, কিন্তু আপনি চ্যাট বার্তাগুলিকে লাইভ শ্রেণিবদ্ধ করতে চাইতে পারেন।

সাধারণ বৈশিষ্ট্যগুলি নির্বাচন করা এটি নিশ্চিত করা সহজ করে তোলে যে:

  • বৈশিষ্ট্যগুলি আপনার শেখার অ্যালগরিদমে সঠিকভাবে পৌঁছায়।
  • মডেল যুক্তিসঙ্গত ওজন শেখে.
  • বৈশিষ্ট্য সঠিকভাবে সার্ভারে আপনার মডেল পৌঁছান.

একবার আপনার একটি সিস্টেম আছে যা এই তিনটি জিনিস নির্ভরযোগ্যভাবে করে, আপনি বেশিরভাগ কাজ সম্পন্ন করেছেন। আপনার সাধারণ মডেল আপনাকে বেসলাইন মেট্রিক্স এবং একটি বেসলাইন আচরণ প্রদান করে যা আপনি আরও জটিল মডেল পরীক্ষা করতে ব্যবহার করতে পারেন। কিছু দল একটি "নিরপেক্ষ" প্রথম লঞ্চের লক্ষ্য রাখে: একটি প্রথম লঞ্চ যা স্পষ্টভাবে মেশিন লার্নিং লাভকে বঞ্চিত করে, যাতে বিভ্রান্ত না হয়।

নিয়ম #5: মেশিন লার্নিং থেকে স্বাধীনভাবে পরিকাঠামো পরীক্ষা করুন।

নিশ্চিত করুন যে পরিকাঠামো পরীক্ষাযোগ্য, এবং সিস্টেমের শেখার অংশগুলি এনক্যাপসুলেট করা হয়েছে যাতে আপনি এটির চারপাশের সবকিছু পরীক্ষা করতে পারেন। বিশেষভাবে:

  1. অ্যালগরিদমে ডেটা পাওয়ার পরীক্ষা করুন। পরীক্ষা করা উচিত যে বৈশিষ্ট্য কলাম জনবহুল করা উচিত. যেখানে গোপনীয়তা অনুমতি দেয়, ম্যানুয়ালি আপনার প্রশিক্ষণ অ্যালগরিদমে ইনপুট পরীক্ষা করুন। যদি সম্ভব হয়, অন্যত্র প্রক্রিয়া করা একই ডেটার পরিসংখ্যানের তুলনায় আপনার পাইপলাইনে পরিসংখ্যান পরীক্ষা করুন।
  2. ট্রেনিং অ্যালগরিদম থেকে মডেল পাওয়ার পরীক্ষা করুন। নিশ্চিত করুন যে আপনার প্রশিক্ষণ পরিবেশে মডেলটি আপনার পরিবেশন পরিবেশের মডেলের মতো একই স্কোর দেয় ( বিধি #37 দেখুন)।

মেশিন লার্নিং-এ অনির্দেশ্যতার একটি উপাদান রয়েছে, তাই নিশ্চিত করুন যে আপনার কাছে প্রশিক্ষণ এবং পরিবেশনের উদাহরণ তৈরি করার জন্য কোডের জন্য পরীক্ষা রয়েছে এবং আপনি পরিবেশনের সময় একটি নির্দিষ্ট মডেল লোড এবং ব্যবহার করতে পারেন। এছাড়াও, আপনার ডেটা বোঝা গুরুত্বপূর্ণ: বড়, জটিল ডেটা সেটগুলির বিশ্লেষণের জন্য ব্যবহারিক পরামর্শ দেখুন।

নিয়ম #6: পাইপলাইন অনুলিপি করার সময় ড্রপ করা ডেটা সম্পর্কে সতর্ক থাকুন।

প্রায়শই আমরা একটি বিদ্যমান পাইপলাইন অনুলিপি করে একটি পাইপলাইন তৈরি করি (অর্থাৎ, কার্গো কাল্ট প্রোগ্রামিং ), এবং পুরানো পাইপলাইন নতুন পাইপলাইনের জন্য প্রয়োজনীয় ডেটা ফেলে দেয়। উদাহরণস্বরূপ, Google Plus What's Hot এর পাইপলাইন পুরানো পোস্টগুলিকে ড্রপ করে (কারণ এটি নতুন পোস্টগুলিকে র‌্যাঙ্ক করার চেষ্টা করছে)৷ এই পাইপলাইনটি Google প্লাস স্ট্রীমের জন্য ব্যবহার করার জন্য অনুলিপি করা হয়েছে, যেখানে পুরানো পোস্টগুলি এখনও অর্থবহ, কিন্তু পাইপলাইনটি এখনও পুরানো পোস্টগুলি বাদ দিচ্ছে৷ আরেকটি সাধারণ প্যাটার্ন হল শুধুমাত্র ব্যবহারকারীর দ্বারা দেখা ডেটা লগ করা। এইভাবে, এই ডেটাটি অকেজো যদি আমরা মডেল করতে চাই কেন একটি নির্দিষ্ট পোস্ট ব্যবহারকারী দ্বারা দেখা যায়নি, কারণ সমস্ত নেতিবাচক উদাহরণ বাদ দেওয়া হয়েছে। একটি অনুরূপ সমস্যা Play এ ঘটেছে. প্লে অ্যাপস হোমে কাজ করার সময়, একটি নতুন পাইপলাইন তৈরি করা হয়েছিল যাতে প্রতিটি উদাহরণ কোথা থেকে এসেছে তা স্পষ্ট করার জন্য কোনও বৈশিষ্ট্য ছাড়াই প্লে গেমগুলির জন্য ল্যান্ডিং পৃষ্ঠার উদাহরণগুলিও রয়েছে৷

নিয়ম #7: হিউরিস্টিকসকে বৈশিষ্ট্যে পরিণত করুন, বা বাহ্যিকভাবে পরিচালনা করুন।

সাধারণত মেশিন লার্নিং যে সমস্যাগুলি সমাধান করার চেষ্টা করছে তা সম্পূর্ণ নতুন নয়। র‌্যাঙ্কিং, বা শ্রেণীবিভাগ, বা আপনি যে সমস্যাটি সমাধান করার চেষ্টা করছেন তার জন্য একটি বিদ্যমান সিস্টেম রয়েছে। এর অর্থ হল একগুচ্ছ নিয়ম এবং হিউরিস্টিকস রয়েছে। এই একই হিউরিস্টিকগুলি মেশিন লার্নিং এর সাথে টুইক করার সময় আপনাকে একটি লিফট দিতে পারে। আপনার হিউরিস্টিকস দুটি কারণের জন্য তাদের কাছে যাই হোক না কেন তথ্যের জন্য খনন করা উচিত। প্রথমত, একটি মেশিন লার্নড সিস্টেমে রূপান্তর মসৃণ হবে। দ্বিতীয়ত, সাধারণত এই নিয়মগুলিতে আপনি যে সিস্টেমটি ফেলে দিতে চান না সে সম্পর্কে প্রচুর অন্তর্দৃষ্টি থাকে। আপনি একটি বিদ্যমান হিউরিস্টিক ব্যবহার করতে পারেন এমন চারটি উপায় রয়েছে:

  • হিউরিস্টিক ব্যবহার করে প্রিপ্রসেস। যদি বৈশিষ্ট্যটি অবিশ্বাস্যভাবে দুর্দান্ত হয়, তবে এটি একটি বিকল্প। উদাহরণস্বরূপ, যদি, একটি স্প্যাম ফিল্টারে, প্রেরক ইতিমধ্যেই কালো তালিকাভুক্ত হয়ে থাকে, তাহলে "ব্ল্যাকলিস্টেড" এর অর্থ কী তা পুনরায় শেখার চেষ্টা করবেন না৷ বার্তাটি ব্লক করুন। এই পদ্ধতিটি বাইনারি শ্রেণীবিভাগের কাজগুলিতে সবচেয়ে বেশি অর্থবহ করে তোলে।
  • একটি বৈশিষ্ট্য তৈরি করুন। হিউরিস্টিক থেকে সরাসরি একটি বৈশিষ্ট্য তৈরি করা দুর্দান্ত। উদাহরণ স্বরূপ, আপনি যদি কোনো প্রশ্নের ফলাফলের জন্য প্রাসঙ্গিক স্কোর গণনা করতে হিউরিস্টিক ব্যবহার করেন, তাহলে আপনি স্কোরটিকে একটি বৈশিষ্ট্যের মান হিসেবে অন্তর্ভুক্ত করতে পারেন। পরবর্তীতে আপনি মানটি ম্যাসেজ করার জন্য মেশিন লার্নিং কৌশল ব্যবহার করতে চাইতে পারেন (উদাহরণস্বরূপ, মানটিকে বিচ্ছিন্ন মানগুলির একটি সীমিত সেটে রূপান্তর করা, বা এটিকে অন্যান্য বৈশিষ্ট্যের সাথে একত্রিত করা) তবে হিউরিস্টিক দ্বারা উত্পাদিত কাঁচা মান ব্যবহার করে শুরু করুন।
  • হিউরিস্টিক এর কাঁচা ইনপুট খনি. যদি অ্যাপগুলির জন্য একটি হিউরিস্টিক থাকে যা ইনস্টলের সংখ্যা, পাঠ্যের অক্ষরের সংখ্যা এবং সপ্তাহের দিনগুলিকে একত্রিত করে, তাহলে এই টুকরোগুলিকে আলাদা করে নেওয়ার কথা বিবেচনা করুন এবং এই ইনপুটগুলিকে আলাদাভাবে শেখার মধ্যে খাওয়ান৷ ensembles প্রযোজ্য কিছু কৌশল এখানে প্রযোজ্য ( বিধি #40 দেখুন)।
  • লেবেল পরিবর্তন করুন. এটি একটি বিকল্প যখন আপনি মনে করেন যে হিউরিস্টিক ক্যাপচার তথ্য বর্তমানে লেবেলে নেই। উদাহরণস্বরূপ, আপনি যদি ডাউনলোডের সংখ্যা সর্বাধিক করার চেষ্টা করছেন, তবে আপনি মানসম্পন্ন সামগ্রীও চান, তাহলে সমাধানটি হল অ্যাপটি প্রাপ্ত তারার গড় সংখ্যা দ্বারা লেবেলটিকে গুণ করা। এখানে অনেক অবকাশ আছে। "আপনার প্রথম উদ্দেশ্য" দেখুন।

একটি ML সিস্টেমে হিউরিস্টিক ব্যবহার করার সময় অতিরিক্ত জটিলতা সম্পর্কে সচেতন হন। আপনার নতুন মেশিন লার্নিং অ্যালগরিদমে পুরানো হিউরিস্টিকস ব্যবহার করে একটি মসৃণ রূপান্তর তৈরি করতে সাহায্য করতে পারে, তবে একই প্রভাবটি সম্পাদন করার একটি সহজ উপায় আছে কিনা তা নিয়ে ভাবুন।

মনিটরিং

সাধারণভাবে, ভাল সতর্কতামূলক স্বাস্থ্যবিধি অনুশীলন করুন, যেমন সতর্কতাগুলিকে কার্যকর করা এবং একটি ড্যাশবোর্ড পৃষ্ঠা থাকা।

নিয়ম #8: আপনার সিস্টেমের সতেজতা প্রয়োজনীয়তা জানুন।

আপনার যদি একটি দিনের পুরানো মডেল থাকে তবে কর্মক্ষমতা কতটা হ্রাস পায়? এক সপ্তাহ বয়সী? এক চতুর্থাংশ বয়সী? এই তথ্য আপনাকে আপনার পর্যবেক্ষণের অগ্রাধিকার বুঝতে সাহায্য করতে পারে। যদি মডেলটি একদিনের জন্য আপডেট না করা হয় তবে আপনি উল্লেখযোগ্য পণ্যের গুণমান হারালে, একজন প্রকৌশলী এটিকে ক্রমাগত দেখছেন তা বোঝা যায়। বেশিরভাগ বিজ্ঞাপন পরিবেশন সিস্টেমে প্রতিদিন পরিচালনা করার জন্য নতুন বিজ্ঞাপন রয়েছে এবং প্রতিদিন আপডেট করতে হবে। উদাহরণস্বরূপ, যদি Google Play অনুসন্ধানের জন্য ML মডেল আপডেট না করা হয়, তাহলে এটি এক মাসের মধ্যে নেতিবাচক প্রভাব ফেলতে পারে। Google Plus- এ What's Hot-এর জন্য কিছু মডেল তাদের মডেলে কোনো পোস্ট শনাক্তকারী নেই তাই তারা এই মডেলগুলি কদাচিৎ রপ্তানি করতে পারে। পোস্ট আইডেন্টিফায়ার রয়েছে এমন অন্যান্য মডেলগুলি অনেক বেশি ঘন ঘন আপডেট করা হয়। এছাড়াও লক্ষ্য করুন যে সতেজতা সময়ের সাথে পরিবর্তিত হতে পারে, বিশেষ করে যখন আপনার মডেল থেকে বৈশিষ্ট্য কলাম যোগ করা বা সরানো হয়।

নিয়ম #9: মডেল রপ্তানি করার আগে সমস্যা সনাক্ত করুন।

অনেক মেশিন লার্নিং সিস্টেমের একটি স্টেজ থাকে যেখানে আপনি মডেলটিকে পরিবেশন করতে রপ্তানি করেন। যদি রপ্তানি করা মডেলের সাথে কোনও সমস্যা থাকে তবে এটি ব্যবহারকারীর মুখোমুখি সমস্যা।

আপনি মডেল রপ্তানি করার ঠিক আগে বিবেক চেক করুন. বিশেষভাবে, নিশ্চিত করুন যে মডেলের কর্মক্ষমতা ধরে রাখা ডেটাতে যুক্তিসঙ্গত। অথবা, যদি আপনার ডেটা নিয়ে দীর্ঘস্থায়ী উদ্বেগ থাকে, তাহলে একটি মডেল রপ্তানি করবেন না। অনেক দল ক্রমাগত মডেল মোতায়েন করে রপ্তানি করার আগে ROC বক্ররেখা (বা AUC) এর অধীনে এলাকা পরীক্ষা করে। রপ্তানি করা হয়নি এমন মডেলগুলির সমস্যাগুলির জন্য একটি ইমেল সতর্কতা প্রয়োজন, তবে ব্যবহারকারী-মুখী মডেলের সমস্যাগুলির জন্য একটি পৃষ্ঠার প্রয়োজন হতে পারে৷ সুতরাং ব্যবহারকারীদের প্রভাবিত করার আগে অপেক্ষা করা এবং নিশ্চিত হওয়া ভাল।

নিয়ম #10: নীরব ব্যর্থতার জন্য দেখুন।

এটি এমন একটি সমস্যা যা অন্যান্য ধরণের সিস্টেমের তুলনায় মেশিন লার্নিং সিস্টেমের জন্য বেশি ঘটে। ধরুন যে একটি নির্দিষ্ট টেবিল যা যুক্ত হচ্ছে তা আর আপডেট করা হচ্ছে না। মেশিন লার্নিং সিস্টেম সামঞ্জস্য করবে, এবং আচরণ যুক্তিসঙ্গতভাবে ভাল হতে থাকবে, ধীরে ধীরে ক্ষয় হবে। কখনও কখনও আপনি সারণীগুলি খুঁজে পান যেগুলি কয়েক মাস পুরানো হয়ে গেছে এবং একটি সাধারণ রিফ্রেশ সেই ত্রৈমাসিকে অন্য যেকোন লঞ্চের তুলনায় কর্মক্ষমতা উন্নত করে! বাস্তবায়ন পরিবর্তনের কারণে একটি বৈশিষ্ট্যের কভারেজ পরিবর্তিত হতে পারে: উদাহরণস্বরূপ একটি বৈশিষ্ট্যের কলাম 90% উদাহরণে পপুলেট হতে পারে এবং হঠাৎ উদাহরণগুলির 60% এ নেমে যায়। প্লে-তে একবার একটি টেবিল ছিল যা 6 মাস ধরে বাসি ছিল, এবং শুধুমাত্র টেবিলটি রিফ্রেশ করলে ইনস্টল রেট 2% বৃদ্ধি পায়। আপনি যদি ডেটার পরিসংখ্যান ট্র্যাক করেন, সেইসাথে উপলক্ষ্যে ম্যানুয়ালি ডেটা পরিদর্শন করেন, আপনি এই ধরণের ব্যর্থতা কমাতে পারেন।

নিয়ম #11: বৈশিষ্ট্য কলাম মালিক এবং ডকুমেন্টেশন দিন।

যদি সিস্টেমটি বড় হয়, এবং অনেকগুলি বৈশিষ্ট্য কলাম থাকে, তাহলে জানুন কে প্রতিটি বৈশিষ্ট্য কলাম তৈরি করেছে বা রক্ষণাবেক্ষণ করছে। আপনি যদি দেখেন যে যে ব্যক্তি একটি বৈশিষ্ট্য কলাম বুঝতে পারে সে চলে যাচ্ছে, নিশ্চিত করুন যে কারো কাছে তথ্য আছে। যদিও অনেক বৈশিষ্ট্যের কলামের বর্ণনামূলক নাম রয়েছে, তবে বৈশিষ্ট্যটি কী, এটি কোথা থেকে এসেছে এবং এটি কীভাবে সাহায্য করবে তার আরও বিশদ বিবরণ থাকা ভাল।

আপনার প্রথম উদ্দেশ্য

আপনি যে সিস্টেমের বিষয়ে যত্নশীল সেই সিস্টেম সম্পর্কে আপনার অনেক মেট্রিক্স বা পরিমাপ আছে, কিন্তু আপনার মেশিন লার্নিং অ্যালগরিদমকে প্রায়ই একটি একক উদ্দেশ্যের প্রয়োজন হবে, এমন একটি সংখ্যা যা আপনার অ্যালগরিদম অপ্টিমাইজ করার জন্য "চেষ্টা করছে"। আমি এখানে উদ্দেশ্য এবং মেট্রিক্সের মধ্যে পার্থক্য করছি: একটি মেট্রিক হল যেকোনো সংখ্যা যা আপনার সিস্টেম রিপোর্ট করে, যা গুরুত্বপূর্ণ হতে পারে বা নাও হতে পারে। এছাড়াও নিয়ম #2 দেখুন।

নিয়ম #12: আপনি কোন উদ্দেশ্যটি সরাসরি অপ্টিমাইজ করতে চান তা নিয়ে বেশি চিন্তা করবেন না।

আপনি অর্থ উপার্জন করতে চান, আপনার ব্যবহারকারীদের খুশি করতে চান এবং বিশ্বকে একটি ভাল জায়গা করে তুলতে চান৷ এমন অনেকগুলি মেট্রিক রয়েছে যা আপনি যত্নশীল, এবং আপনার সেগুলি সমস্ত পরিমাপ করা উচিত ( বিধি #2 দেখুন)। যাইহোক, মেশিন লার্নিং প্রক্রিয়ার শুরুর দিকে, আপনি লক্ষ্য করবেন যে সেগুলি সব বেড়ে যাচ্ছে, এমনকি যেগুলিকে আপনি সরাসরি অপ্টিমাইজ করেন না। উদাহরণ স্বরূপ, ধরুন আপনি সাইটটিতে কত ক্লিক এবং সময় ব্যয় করেন সে বিষয়ে যত্নশীল। আপনি যদি ক্লিকের সংখ্যার জন্য অপ্টিমাইজ করেন, তাহলে আপনি ব্যয়িত সময় বৃদ্ধি দেখতে পাবেন।

সুতরাং, এটিকে সহজ রাখুন এবং বিভিন্ন মেট্রিক্সের ভারসাম্য বজায় রাখার বিষয়ে খুব কঠিন চিন্তা করবেন না যখন আপনি এখনও সহজেই সমস্ত মেট্রিক বাড়াতে পারেন। যদিও এই নিয়মটিকে খুব বেশি দূরে নিয়ে যাবেন না: সিস্টেমের চূড়ান্ত স্বাস্থ্যের সাথে আপনার উদ্দেশ্যকে বিভ্রান্ত করবেন না ( বিধি #39 দেখুন)। এবং, যদি আপনি নিজেকে সরাসরি অপ্টিমাইজ করা মেট্রিক বাড়াচ্ছেন, কিন্তু লঞ্চ না করার সিদ্ধান্ত নেন, কিছু উদ্দেশ্যমূলক সংশোধনের প্রয়োজন হতে পারে।

নিয়ম #13: আপনার প্রথম উদ্দেশ্যের জন্য একটি সহজ, পর্যবেক্ষণযোগ্য এবং বৈশিষ্ট্যযুক্ত মেট্রিক চয়ন করুন।

প্রায়শই আপনি জানেন না আসল উদ্দেশ্য কী। আপনি মনে করেন আপনি করবেন কিন্তু তারপরে আপনি যখন আপনার পুরানো সিস্টেম এবং নতুন এমএল সিস্টেমের ডেটা এবং পাশাপাশি বিশ্লেষণের দিকে তাকাচ্ছেন, আপনি বুঝতে পারবেন আপনি উদ্দেশ্যটি পরিবর্তন করতে চান। আরও, বিভিন্ন দলের সদস্যরা প্রায়শই প্রকৃত উদ্দেশ্য নিয়ে একমত হতে পারে না। ML উদ্দেশ্য এমন কিছু হওয়া উচিত যা পরিমাপ করা সহজ এবং "সত্য" উদ্দেশ্যের জন্য একটি প্রক্সি। আসলে, প্রায়ই কোন "সত্য" উদ্দেশ্য থাকে না ( বিধি#39 দেখুন)। তাই সাধারণ ML উদ্দেশ্যের উপর প্রশিক্ষণ নিন এবং শীর্ষে একটি "পলিসি লেয়ার" থাকার কথা বিবেচনা করুন যা আপনাকে চূড়ান্ত র‌্যাঙ্কিং করতে অতিরিক্ত যুক্তি (আশা করি খুব সহজ যুক্তি) যোগ করতে দেয়।

মডেল করার সবচেয়ে সহজ জিনিস হল একটি ব্যবহারকারীর আচরণ যা সরাসরি পর্যবেক্ষণ করা হয় এবং সিস্টেমের একটি ক্রিয়াকলাপের জন্য দায়ী:

  • এই র্যাঙ্ক করা লিঙ্কটি কি ক্লিক করা হয়েছিল?
  • এই র‌্যাঙ্ক করা বস্তুটি কি ডাউনলোড করা হয়েছে?
  • এই র‌্যাঙ্ক করা বস্তুটি কি ফরোয়ার্ড করা হয়েছে/ইমেল করা হয়েছে?
  • এই র্যাঙ্ক করা অবজেক্ট রেট ছিল?
  • এই দেখানো বস্তুটিকে কি স্প্যাম/পর্নোগ্রাফি/আপত্তিকর হিসেবে চিহ্নিত করা হয়েছে?

প্রথমে পরোক্ষ প্রভাব মডেলিং এড়িয়ে চলুন:

  • ব্যবহারকারী কি পরের দিন পরিদর্শন করেছেন?
  • ব্যবহারকারী কতক্ষণ সাইট পরিদর্শন করেছেন?
  • দৈনিক সক্রিয় ব্যবহারকারীরা কি ছিল?

পরোক্ষ প্রভাবগুলি দুর্দান্ত মেট্রিক্স তৈরি করে এবং A/B পরীক্ষার সময় এবং লঞ্চের সিদ্ধান্তের সময় ব্যবহার করা যেতে পারে।

অবশেষে, মেশিন লার্নিং বের করার চেষ্টা করবেন না:

  • ব্যবহারকারী কি পণ্য ব্যবহার করে খুশি?
  • ব্যবহারকারী কি অভিজ্ঞতার সাথে সন্তুষ্ট?
  • পণ্যটি কি ব্যবহারকারীর সামগ্রিক সুস্থতার উন্নতি করছে?
  • এটি কীভাবে কোম্পানির সামগ্রিক স্বাস্থ্যকে প্রভাবিত করবে?

এই সব গুরুত্বপূর্ণ, কিন্তু পরিমাপ করা অবিশ্বাস্যভাবে কঠিন. পরিবর্তে, প্রক্সি ব্যবহার করুন: ব্যবহারকারী খুশি হলে, তারা আরও বেশি সময় সাইটে থাকবে। ব্যবহারকারী সন্তুষ্ট হলে, তারা আগামীকাল আবার পরিদর্শন করবে। সুস্বাস্থ্য এবং কোম্পানির স্বাস্থ্যের ক্ষেত্রে, আপনি যে পণ্যটি বিক্রি করছেন তার প্রকৃতি এবং আপনার ব্যবসায়িক পরিকল্পনার সাথে যে কোনও মেশিন শেখা উদ্দেশ্যকে সংযুক্ত করার জন্য মানুষের বিচার প্রয়োজন।

নিয়ম #14: একটি ব্যাখ্যাযোগ্য মডেল দিয়ে শুরু করা ডিবাগিংকে সহজ করে তোলে।

লিনিয়ার রিগ্রেশন, লজিস্টিক রিগ্রেশন এবং পয়সন রিগ্রেশন সরাসরি একটি সম্ভাব্য মডেল দ্বারা অনুপ্রাণিত হয়। প্রতিটি ভবিষ্যদ্বাণী একটি সম্ভাব্যতা বা একটি প্রত্যাশিত মান হিসাবে ব্যাখ্যাযোগ্য। এটি তাদের উদ্দেশ্যগুলি ব্যবহার করে এমন মডেলগুলির তুলনায় ডিবাগ করা সহজ করে তোলে (শূন্য-এক ক্ষতি, বিভিন্ন কব্জা ক্ষতি, এবং আরও অনেক কিছু) যা সরাসরি শ্রেণিবিন্যাস নির্ভুলতা বা র‌্যাঙ্কিং কর্মক্ষমতা অপ্টিমাইজ করার চেষ্টা করে। উদাহরণ স্বরূপ, যদি প্রশিক্ষণের সম্ভাব্যতাগুলি পাশে-পাশে বা উৎপাদন ব্যবস্থা পরিদর্শন করে ভবিষ্যদ্বাণী করা সম্ভাব্যতা থেকে বিচ্যুত হয়, তাহলে এই বিচ্যুতি একটি সমস্যা প্রকাশ করতে পারে।

উদাহরণস্বরূপ, রৈখিক, লজিস্টিক বা পয়সন রিগ্রেশনে, ডেটার উপসেট রয়েছে যেখানে গড় পূর্বাভাসিত প্রত্যাশা গড় লেবেলের সমান (1- মুহূর্ত ক্যালিব্রেট করা, বা শুধু ক্যালিব্রেট করা) । আপনার কোন নিয়মিতকরণ নেই এবং আপনার অ্যালগরিদম একত্রিত হয়েছে, এবং এটি সাধারণভাবে প্রায় সত্য। আপনার যদি এমন একটি বৈশিষ্ট্য থাকে যা প্রতিটি উদাহরণের জন্য 1 বা 0 হয়, তাহলে 3টি উদাহরণের সেট যেখানে সেই বৈশিষ্ট্যটি 1 হয় তা ক্যালিব্রেট করা হয়। এছাড়াও, আপনার যদি এমন একটি বৈশিষ্ট্য থাকে যা প্রতিটি উদাহরণের জন্য 1 হয়, তাহলে সমস্ত উদাহরণের সেটটি ক্রমাঙ্কিত করা হয়।

সাধারণ মডেলগুলির সাথে, প্রতিক্রিয়া লুপগুলি মোকাবেলা করা সহজ ( বিধি #36 দেখুন)। প্রায়শই, আমরা সিদ্ধান্ত নেওয়ার জন্য এই সম্ভাব্য ভবিষ্যদ্বাণীগুলি ব্যবহার করি: যেমন প্রত্যাশিত মান হ্রাসে র‌্যাঙ্ক পোস্টগুলি (যেমন ক্লিক/ডাউনলোড/ইত্যাদির সম্ভাবনা)। যাইহোক, মনে রাখবেন কোন মডেলটি ব্যবহার করতে হবে তা চয়ন করার সময়, সিদ্ধান্তটি মডেলের প্রদত্ত ডেটার সম্ভাবনার চেয়ে বেশি গুরুত্বপূর্ণ ( বিধি #27 দেখুন)।

নিয়ম #15: একটি পলিসি লেয়ারে আলাদা স্প্যাম ফিল্টারিং এবং কোয়ালিটি র‍্যাঙ্কিং।

গুণমানের র‌্যাঙ্কিং একটি সূক্ষ্ম শিল্প, কিন্তু স্প্যাম ফিল্টারিং একটি যুদ্ধ। উচ্চ মানের পোস্টগুলি নির্ধারণ করতে আপনি যে সংকেতগুলি ব্যবহার করেন তা তাদের কাছে স্পষ্ট হয়ে উঠবে যারা আপনার সিস্টেম ব্যবহার করে এবং তারা এই বৈশিষ্ট্যগুলি থাকার জন্য তাদের পোস্টগুলিকে পরিবর্তন করবে৷ এইভাবে, আপনার মানের র‌্যাঙ্কিংকে র‌্যাঙ্কিং বিষয়বস্তুর উপর ফোকাস করা উচিত যা সরল বিশ্বাসে পোস্ট করা হয়। স্প্যাম র‌্যাঙ্কিং করার জন্য আপনার গুণমানের র‌্যাঙ্কিং লার্নারকে ছাড় দেওয়া উচিত নয়। একইভাবে, কোয়ালিটি র‍্যাঙ্কিং থেকে "বৈষম্যপূর্ণ" বিষয়বস্তু আলাদাভাবে পরিচালনা করা উচিত। স্প্যাম ফিল্টারিং একটি ভিন্ন গল্প। আপনাকে আশা করতে হবে যে আপনার যে বৈশিষ্ট্যগুলি তৈরি করতে হবে তা ক্রমাগত পরিবর্তিত হবে। প্রায়শই, আপনি সিস্টেমে যে সুস্পষ্ট নিয়মগুলি রাখেন (যদি একটি পোস্টে তিনটির বেশি স্প্যাম ভোট থাকে, তা পুনরুদ্ধার করবেন না, ইত্যাদি)। যেকোনো শেখা মডেলকে প্রতিদিন আপডেট করতে হবে, যদি দ্রুত না হয়। কন্টেন্ট নির্মাতার সুনাম একটি মহান ভূমিকা পালন করবে.

কিছু স্তরে, এই দুটি সিস্টেমের আউটপুট একত্রিত করতে হবে। মনে রাখবেন, সার্চ ফলাফলে স্প্যাম ফিল্টার করা সম্ভবত ইমেল বার্তাগুলিতে স্প্যাম ফিল্টার করার চেয়ে বেশি আক্রমনাত্মক হওয়া উচিত। আপনার কোন নিয়মিতকরণ নেই এবং আপনার অ্যালগরিদম একত্রিত হয়েছে বলে ধরে নেওয়া এটি সত্য। এটি সাধারণভাবে প্রায় সত্য। এছাড়াও, মান শ্রেণীবদ্ধকারীর প্রশিক্ষণের ডেটা থেকে স্প্যাম অপসারণ করা একটি আদর্শ অনুশীলন।

এমএল ফেজ II: ফিচার ইঞ্জিনিয়ারিং

একটি মেশিন লার্নিং সিস্টেমের জীবনচক্রের প্রথম পর্যায়ে, গুরুত্বপূর্ণ বিষয়গুলি হল প্রশিক্ষণের ডেটা শেখার পদ্ধতিতে যোগ করা, আগ্রহের যেকোন মেট্রিকগুলিকে ইনস্ট্রুমেন্ট করা এবং একটি পরিবেশনকারী পরিকাঠামো তৈরি করা। আপনার ইউনিট এবং সিস্টেম পরীক্ষার উপকরণ সহ সিস্টেম থেকে শেষ পর্যন্ত কাজ করার পরে, দ্বিতীয় পর্যায় শুরু হয়।

দ্বিতীয় দফায় অনেক কম ঝুলন্ত ফল রয়েছে। সিস্টেমের মধ্যে টানা যেতে পারে যে সুস্পষ্ট বৈশিষ্ট্য বিভিন্ন আছে. এইভাবে, মেশিন লার্নিং-এর দ্বিতীয় ধাপে যতটা সম্ভব বৈশিষ্ট্যগুলি টেনে আনা এবং স্বজ্ঞাত উপায়ে সেগুলিকে একত্রিত করা জড়িত। এই পর্বে, সমস্ত মেট্রিক্স এখনও বাড়তে হবে। প্রচুর লঞ্চ হবে, এবং সত্যিকারের একটি দুর্দান্ত শিক্ষা ব্যবস্থা তৈরি করতে আপনার প্রয়োজনীয় সমস্ত ডেটা যোগ করতে পারে এমন প্রচুর প্রকৌশলীকে টেনে নেওয়ার এটি একটি দুর্দান্ত সময়।

নিয়ম #16: চালু এবং পুনরাবৃত্তি করার পরিকল্পনা করুন।

আশা করবেন না যে আপনি এখন যে মডেলটিতে কাজ করছেন সেটিই শেষ হবে যেটি আপনি লঞ্চ করবেন, বা এমনকি আপনি কখনও মডেল চালু করা বন্ধ করবেন। এইভাবে বিবেচনা করুন যে আপনি এই লঞ্চের সাথে যে জটিলতা যুক্ত করছেন তা ভবিষ্যতের লঞ্চগুলিকে ধীর করবে কিনা। অনেক দল বছর ধরে প্রতি ত্রৈমাসিক বা তার বেশি একটি মডেল চালু করেছে। নতুন মডেল চালু করার তিনটি মৌলিক কারণ রয়েছে:

  • আপনি নতুন বৈশিষ্ট্য নিয়ে আসছেন।
  • আপনি নিয়মিতকরণ টিউন করছেন এবং নতুন উপায়ে পুরানো বৈশিষ্ট্যগুলিকে একত্রিত করছেন৷
  • আপনি উদ্দেশ্য টিউন করছেন.

যাই হোক না কেন, একটি মডেলকে কিছুটা ভালবাসা দেওয়া ভাল হতে পারে: উদাহরণের মধ্যে থাকা ডেটার দিকে তাকানো নতুন সংকেতগুলির পাশাপাশি পুরানো, ভাঙাগুলি খুঁজে পেতে সহায়তা করতে পারে৷ সুতরাং, আপনি আপনার মডেল তৈরি করার সময়, বৈশিষ্ট্যগুলি যোগ করা বা অপসারণ করা বা পুনরায় সংযুক্ত করা কতটা সহজ তা নিয়ে ভাবুন৷ পাইপলাইনের একটি নতুন অনুলিপি তৈরি করা এবং এর সঠিকতা যাচাই করা কতটা সহজ তা নিয়ে ভাবুন। দুই বা তিনটি কপি সমান্তরালভাবে চালানো সম্ভব কিনা তা নিয়ে ভাবুন। অবশেষে, 35 এর মধ্যে 16 বৈশিষ্ট্যটি পাইপলাইনের এই সংস্করণে এটি তৈরি করে কিনা তা নিয়ে চিন্তা করবেন না। আপনি এটা পরের ত্রৈমাসিক পাবেন.

নিয়ম #17: শেখা বৈশিষ্ট্যগুলির বিপরীতে সরাসরি পর্যবেক্ষণ করা এবং রিপোর্ট করা বৈশিষ্ট্যগুলি দিয়ে শুরু করুন।

এটি একটি বিতর্কিত পয়েন্ট হতে পারে, কিন্তু এটি অনেক ক্ষতি এড়ায়। প্রথমত, একটি শেখা বৈশিষ্ট্য কী তা বর্ণনা করা যাক। একটি শেখা বৈশিষ্ট্য হল একটি বৈশিষ্ট্য যা হয় একটি বাহ্যিক সিস্টেম (যেমন একটি তত্ত্বাবধানহীন ক্লাস্টারিং সিস্টেম) দ্বারা বা শিক্ষার্থী নিজেই (যেমন একটি ফ্যাক্টরড মডেল বা গভীর শিক্ষার মাধ্যমে) দ্বারা উত্পন্ন হয়। এই উভয়ই দরকারী হতে পারে, তবে তাদের অনেক সমস্যা থাকতে পারে, তাই তাদের প্রথম মডেলে থাকা উচিত নয়।

আপনি যদি একটি বৈশিষ্ট্য তৈরি করতে একটি বাহ্যিক সিস্টেম ব্যবহার করেন তবে মনে রাখবেন যে বাহ্যিক সিস্টেমের নিজস্ব উদ্দেশ্য রয়েছে। বাহ্যিক সিস্টেমের উদ্দেশ্য শুধুমাত্র দুর্বলভাবে আপনার বর্তমান উদ্দেশ্য সঙ্গে সম্পর্কযুক্ত হতে পারে. আপনি যদি বাহ্যিক সিস্টেমের একটি স্ন্যাপশট দখল করেন, তাহলে এটি পুরানো হয়ে যেতে পারে। আপনি যদি বাহ্যিক সিস্টেম থেকে বৈশিষ্ট্য আপডেট করেন, তাহলে অর্থ পরিবর্তন হতে পারে। যদি আপনি একটি বৈশিষ্ট্য প্রদান করার জন্য একটি বহিরাগত সিস্টেম ব্যবহার করেন, তাহলে সচেতন থাকুন যে এই পদ্ধতির জন্য অনেক যত্নের প্রয়োজন।

ফ্যাক্টরযুক্ত মডেল এবং গভীর মডেলগুলির প্রাথমিক সমস্যা হল যে তারা অ-উত্তল। সুতরাং, কোন গ্যারান্টি নেই যে একটি সর্বোত্তম সমাধান আনুমানিক বা পাওয়া যেতে পারে, এবং প্রতিটি পুনরাবৃত্তিতে পাওয়া স্থানীয় মিনিমাম ভিন্ন হতে পারে। এই বৈচিত্রটি আপনার সিস্টেমে পরিবর্তনের প্রভাব অর্থপূর্ণ বা এলোমেলো কিনা তা বিচার করা কঠিন করে তোলে। গভীর বৈশিষ্ট্য ছাড়া একটি মডেল তৈরি করে, আপনি একটি চমৎকার বেসলাইন কর্মক্ষমতা পেতে পারেন। এই বেসলাইনটি অর্জন করার পরে, আপনি আরও রহস্যময় পদ্ধতির চেষ্টা করতে পারেন।

নিয়ম #18: বিষয়বস্তুর বৈশিষ্ট্যগুলির সাথে অন্বেষণ করুন যা প্রসঙ্গ জুড়ে সাধারণীকরণ করে৷

প্রায়শই একটি মেশিন লার্নিং সিস্টেম অনেক বড় ছবির একটি ছোট অংশ। উদাহরণ স্বরূপ, আপনি যদি এমন একটি পোস্ট কল্পনা করেন যা হোয়াটস হট-এ ব্যবহার করা হতে পারে, তবে অনেক লোক হোয়াটস হট-এ দেখানো হওয়ার আগে একটি পোস্টকে প্লাস-ওয়ান, পুনঃভাগ বা মন্তব্য করবে৷ আপনি যদি শিক্ষার্থীকে সেই পরিসংখ্যানগুলি প্রদান করেন, তাহলে এটি এমন নতুন পোস্টগুলিকে প্রচার করতে পারে যেগুলির জন্য এটি অপ্টিমাইজ করা প্রসঙ্গে কোনও ডেটা নেই৷ ইউটিউব ওয়াচ নেক্সট ইউটিউব অনুসন্ধান থেকে সংখ্যক ঘড়ি, বা সহ-ঘড়ি (একটি ভিডিওর পর অন্যটি কতবার দেখা হয়েছে তার গণনা) ব্যবহার করতে পারে। আপনি স্পষ্ট ব্যবহারকারী রেটিং ব্যবহার করতে পারেন. পরিশেষে, আপনার যদি একটি ব্যবহারকারীর ক্রিয়া থাকে যা আপনি একটি লেবেল হিসাবে ব্যবহার করছেন, একটি ভিন্ন প্রসঙ্গে নথিতে সেই ক্রিয়াটি দেখা একটি দুর্দান্ত বৈশিষ্ট্য হতে পারে৷ এই সমস্ত বৈশিষ্ট্য আপনাকে প্রসঙ্গে নতুন বিষয়বস্তু আনতে অনুমতি দেয়। মনে রাখবেন যে এটি ব্যক্তিগতকরণের বিষয়ে নয়: এই প্রসঙ্গে প্রথমে কেউ বিষয়বস্তু পছন্দ করে কিনা তা খুঁজে বের করুন, তারপর বের করুন কে এটি কম বা বেশি পছন্দ করে।

নিয়ম #19: আপনি যখন পারেন খুব নির্দিষ্ট বৈশিষ্ট্য ব্যবহার করুন।

প্রচুর ডেটা সহ, কয়েকটি জটিল বৈশিষ্ট্যের চেয়ে লক্ষ লক্ষ সাধারণ বৈশিষ্ট্যগুলি শেখা সহজ৷ পুনরুদ্ধার করা নথিগুলির শনাক্তকারী এবং ক্যানোনিকালাইজ করা প্রশ্নগুলি খুব বেশি সাধারণীকরণ প্রদান করে না, তবে প্রধান প্রশ্নের উপর আপনার লেবেলের সাথে আপনার র‌্যাঙ্কিং সারিবদ্ধ করে। সুতরাং, বৈশিষ্ট্যগুলির গ্রুপগুলিকে ভয় পাবেন না যেখানে প্রতিটি বৈশিষ্ট্য আপনার ডেটার খুব ছোট অংশে প্রযোজ্য, তবে সামগ্রিক কভারেজ 90% এর উপরে। খুব কম উদাহরণে প্রযোজ্য বৈশিষ্ট্যগুলিকে বাদ দিতে আপনি নিয়মিতকরণ ব্যবহার করতে পারেন।

নিয়ম #20: মানুষের বোধগম্য উপায়ে নতুন বৈশিষ্ট্য তৈরি করতে বিদ্যমান বৈশিষ্ট্যগুলিকে একত্রিত করুন এবং সংশোধন করুন৷

বৈশিষ্ট্য একত্রিত এবং সংশোধন করার বিভিন্ন উপায় আছে। মেশিন লার্নিং সিস্টেম যেমন টেনসরফ্লো আপনাকে ট্রান্সফর্মেশনের মাধ্যমে আপনার ডেটা প্রাক-প্রসেস করতে দেয়। দুটি সবচেয়ে আদর্শ পদ্ধতি হল "বিচক্ষণতা" এবং "ক্রস"।

বিচ্ছিন্নকরণ একটি অবিচ্ছিন্ন বৈশিষ্ট্য গ্রহণ করে এবং এটি থেকে অনেকগুলি পৃথক বৈশিষ্ট্য তৈরি করে। বয়সের মতো একটি অবিচ্ছিন্ন বৈশিষ্ট্য বিবেচনা করুন। আপনি একটি বৈশিষ্ট্য তৈরি করতে পারেন যা বয়স 18 এর কম হলে 1 হয়, আরেকটি বৈশিষ্ট্য যা 1 হয় যখন বয়স 18 থেকে 35 এর মধ্যে হয়, ইত্যাদি। এই হিস্টোগ্রামের সীমানা নিয়ে চিন্তা করবেন না: মৌলিক কোয়ান্টাইলগুলি আপনাকে বেশিরভাগ প্রভাব দেবে।

ক্রস দুটি বা ততোধিক বৈশিষ্ট্য কলাম একত্রিত করে। টেনসরফ্লো-এর পরিভাষায় একটি বৈশিষ্ট্য কলাম হল সমজাতীয় বৈশিষ্ট্যগুলির একটি সেট, (যেমন {পুরুষ, মহিলা}, {মার্কিন, কানাডা, মেক্সিকো}, ইত্যাদি)। একটি ক্রস হল একটি নতুন বৈশিষ্ট্যের কলাম যেখানে বৈশিষ্ট্য রয়েছে, উদাহরণস্বরূপ, {পুরুষ, মহিলা} × {মার্কিন, কানাডা, মেক্সিকো}। এই নতুন বৈশিষ্ট্যের কলামে বৈশিষ্ট্যটি থাকবে (পুরুষ, কানাডা)। আপনি যদি TensorFlow ব্যবহার করেন এবং আপনি TensorFlow কে আপনার জন্য এই ক্রস তৈরি করতে বলেন, তাহলে এই (পুরুষ, কানাডা) বৈশিষ্ট্যটি পুরুষ কানাডিয়ানদের প্রতিনিধিত্বকারী উদাহরণগুলিতে উপস্থিত থাকবে। মনে রাখবেন যে তিনটি, চার বা তার বেশি বেস বৈশিষ্ট্য কলামের ক্রস সহ মডেলগুলি শিখতে প্রচুর পরিমাণে ডেটা লাগে।

যে ক্রসগুলি খুব বড় বৈশিষ্ট্য কলাম তৈরি করে সেগুলি ওভারফিট হতে পারে। উদাহরণস্বরূপ, কল্পনা করুন যে আপনি কিছু ধরণের অনুসন্ধান করছেন, এবং আপনার কাছে ক্যোয়ারীতে শব্দ সহ একটি বৈশিষ্ট্য কলাম রয়েছে এবং নথিতে শব্দ সহ আপনার একটি বৈশিষ্ট্য কলাম রয়েছে। আপনি এগুলিকে একটি ক্রসের সাথে একত্রিত করতে পারেন, তবে আপনি অনেক বৈশিষ্ট্যের সাথে শেষ হবে ( বিধি #21 দেখুন)।

পাঠ্যের সাথে কাজ করার সময় দুটি বিকল্প রয়েছে। সবচেয়ে কঠোর একটি বিন্দু পণ্য হয়. একটি ডট প্রোডাক্ট তার সহজতম আকারে কেবল কোয়েরি এবং নথির মধ্যে সাধারণ শব্দের সংখ্যা গণনা করে। এই বৈশিষ্ট্য তারপর discretized করা যেতে পারে. আরেকটি পদ্ধতি হল একটি ছেদ: এইভাবে, আমাদের একটি বৈশিষ্ট্য থাকবে যা যদি এবং শুধুমাত্র যদি "টাট্টু" শব্দটি নথি এবং ক্যোয়ারী উভয় ক্ষেত্রেই থাকে, এবং আরেকটি বৈশিষ্ট্য যা উপস্থিত থাকে যদি এবং শুধুমাত্র যদি "the" শব্দটি হয়। নথি এবং প্রশ্ন উভয় ক্ষেত্রেই।

নিয়ম #21: একটি রৈখিক মডেলে আপনি যে বৈশিষ্ট্যের ওজন শিখতে পারেন তার সংখ্যা আপনার কাছে থাকা ডেটার পরিমাণের মোটামুটি সমানুপাতিক।

একটি মডেলের জন্য জটিলতার যথাযথ স্তর সম্পর্কিত আকর্ষণীয় পরিসংখ্যানগত শিক্ষা তত্ত্বের ফলাফল রয়েছে, তবে এই নিয়মটি মূলত আপনার যা জানা দরকার। আমি এমন কথোপকথন করেছি যেখানে লোকেরা সন্দেহ করেছিল যে এক হাজার উদাহরণ থেকে কিছু শেখা যেতে পারে, বা আপনার এক মিলিয়নেরও বেশি উদাহরণের প্রয়োজন হবে, কারণ তারা শেখার একটি নির্দিষ্ট পদ্ধতিতে আটকে যায়। আপনার ডেটার আকারে আপনার শেখার স্কেল করা মূল বিষয়:

  1. আপনি যদি একটি অনুসন্ধান র‌্যাঙ্কিং সিস্টেমে কাজ করেন, এবং নথি এবং ক্যোয়ারীতে লক্ষ লক্ষ বিভিন্ন শব্দ থাকে এবং আপনার কাছে 1000টি লেবেলযুক্ত উদাহরণ থাকে, তাহলে আপনার ডকুমেন্ট এবং ক্যোয়ারী বৈশিষ্ট্যগুলির মধ্যে একটি ডট পণ্য ব্যবহার করা উচিত, TF-IDF , এবং দেড় - ডজন ডজন অন্যান্য উচ্চ মানব-প্রকৌশলী বৈশিষ্ট্য। 1000টি উদাহরণ, এক ডজন বৈশিষ্ট্য।
  2. আপনার যদি এক মিলিয়ন উদাহরণ থাকে, তাহলে নিয়মিতকরণ এবং সম্ভবত বৈশিষ্ট্য নির্বাচন ব্যবহার করে নথি এবং ক্যোয়ারী বৈশিষ্ট্য কলামগুলিকে ছেদ করুন। এটি আপনাকে লক্ষ লক্ষ বৈশিষ্ট্য দেবে, তবে নিয়মিতকরণের সাথে আপনার কাছে কম থাকবে। দশ মিলিয়ন উদাহরণ, হয়তো এক লক্ষ বৈশিষ্ট্য।
  3. আপনার যদি বিলিয়ন বা শত বিলিয়ন উদাহরণ থাকে, আপনি বৈশিষ্ট্য নির্বাচন এবং নিয়মিতকরণ ব্যবহার করে নথি এবং ক্যোয়ারী টোকেন সহ বৈশিষ্ট্য কলামগুলি অতিক্রম করতে পারেন৷ আপনার কাছে এক বিলিয়ন উদাহরণ এবং 10 মিলিয়ন বৈশিষ্ট্য থাকবে। পরিসংখ্যানগত শিক্ষার তত্ত্ব খুব কমই শক্ত সীমানা দেয়, তবে একটি শুরুর বিন্দুর জন্য দুর্দান্ত দিকনির্দেশনা দেয়।

শেষ পর্যন্ত, কোন বৈশিষ্ট্যগুলি ব্যবহার করবেন তা নির্ধারণ করতে নিয়ম #28 ব্যবহার করুন৷

নিয়ম #22: আপনি আর ব্যবহার করছেন না এমন বৈশিষ্ট্যগুলি পরিষ্কার করুন৷

অব্যবহৃত বৈশিষ্ট্য প্রযুক্তিগত ঋণ তৈরি করে। আপনি যদি দেখেন যে আপনি একটি বৈশিষ্ট্য ব্যবহার করছেন না, এবং এটি অন্যান্য বৈশিষ্ট্যগুলির সাথে একত্রিত করা কাজ করছে না, তাহলে এটিকে আপনার পরিকাঠামো থেকে বাদ দিন। আপনি আপনার অবকাঠামো পরিষ্কার রাখতে চান যাতে সবচেয়ে প্রতিশ্রুতিশীল বৈশিষ্ট্যগুলি যত দ্রুত সম্ভব চেষ্টা করা যায়। প্রয়োজন হলে, কেউ সবসময় আপনার বৈশিষ্ট্য ফিরে যোগ করতে পারেন.

কোন বৈশিষ্ট্যগুলি যোগ করতে বা রাখতে হবে তা বিবেচনা করার সময় কভারেজটি মাথায় রাখুন। বৈশিষ্ট্য দ্বারা আচ্ছাদিত করা হয় কত উদাহরণ? For example, if you have some personalization features, but only 8% of your users have any personalization features, it is not going to be very effective.

At the same time, some features may punch above their weight. For example, if you have a feature which covers only 1% of the data, but 90% of the examples that have the feature are positive, then it will be a great feature to add.

Human Analysis of the System

Before going on to the third phase of machine learning, it is important to focus on something that is not taught in any machine learning class: how to look at an existing model, and improve it. This is more of an art than a science, and yet there are several antipatterns that it helps to avoid.

Rule #23: You are not a typical end user.

This is perhaps the easiest way for a team to get bogged down. While there are a lot of benefits to fishfooding (using a prototype within your team) and dogfooding (using a prototype within your company), employees should look at whether the performance is correct. While a change which is obviously bad should not be used, anything that looks reasonably near production should be tested further, either by paying laypeople to answer questions on a crowdsourcing platform, or through a live experiment on real users.

There are two reasons for this. The first is that you are too close to the code. You may be looking for a particular aspect of the posts, or you are simply too emotionally involved (eg confirmation bias). The second is that your time is too valuable. Consider the cost of nine engineers sitting in a one hour meeting, and think of how many contracted human labels that buys on a crowdsourcing platform.

If you really want to have user feedback, use user experience methodologies . Create user personas (one description is in Bill Buxton's Sketching User Experiences ) early in a process and do usability testing (one description is in Steve Krug's Don't Make Me Think ) later. User personas involve creating a hypothetical user. For instance, if your team is all male, it might help to design a 35-year-old female user persona (complete with user features), and look at the results it generates rather than 10 results for 25-to-40 year old males. Bringing in actual people to watch their reaction to your site (locally or remotely) in usability testing can also get you a fresh perspective.

Rule #24: Measure the delta between models.

One of the easiest and sometimes most useful measurements you can make before any users have looked at your new model is to calculate just how different the new results are from production. For instance, if you have a ranking problem, run both models on a sample of queries through the entire system, and look at the size of the symmetric difference of the results (weighted by ranking position). If the difference is very small, then you can tell without running an experiment that there will be little change. If the difference is very large, then you want to make sure that the change is good. Looking over queries where the symmetric difference is high can help you to understand qualitatively what the change was like. Make sure, however, that the system is stable. Make sure that a model when compared with itself has a low (ideally zero) symmetric difference.

Rule #25: When choosing models, utilitarian performance trumps predictive power.

Your model may try to predict click-through rate. However, in the end, the key question is what you do with that prediction. If you are using it to rank documents, then the quality of the final ranking matters more than the prediction itself. If you predict the probability that a document is spam and then have a cutoff on what is blocked, then the precision of what is allowed through matters more. Most of the time, these two things should be in agreement: when they do not agree, it will likely be on a small gain. Thus, if there is some change that improves log loss but degrades the performance of the system, look for another feature. When this starts happening more often, it is time to revisit the objective of your model.

Rule #26: Look for patterns in the measured errors, and create new features.

Suppose that you see a training example that the model got "wrong". In a classification task, this error could be a false positive or a false negative. In a ranking task, the error could be a pair where a positive was ranked lower than a negative. The most important point is that this is an example that the machine learning system knows it got wrong and would like to fix if given the opportunity. If you give the model a feature that allows it to fix the error, the model will try to use it.

On the other hand, if you try to create a feature based upon examples the system doesn't see as mistakes, the feature will be ignored. For instance, suppose that in Play Apps Search, someone searches for "free games". Suppose one of the top results is a less relevant gag app. So you create a feature for "gag apps". However, if you are maximizing number of installs, and people install a gag app when they search for free games, the "gag apps" feature won't have the effect you want.

Once you have examples that the model got wrong, look for trends that are outside your current feature set. For instance, if the system seems to be demoting longer posts, then add post length. Don't be too specific about the features you add. If you are going to add post length, don't try to guess what long means, just add a dozen features and the let model figure out what to do with them (see Rule #21 ). That is the easiest way to get what you want.

Rule #27: Try to quantify observed undesirable behavior.

Some members of your team will start to be frustrated with properties of the system they don't like which aren't captured by the existing loss function. At this point, they should do whatever it takes to turn their gripes into solid numbers. For example, if they think that too many "gag apps" are being shown in Play Search, they could have human raters identify gag apps. (You can feasibly use humanlabelled data in this case because a relatively small fraction of the queries account for a large fraction of the traffic.) If your issues are measurable, then you can start using them as features, objectives, or metrics. The general rule is " measure first, optimize second ".

Rule #28: Be aware that identical short-term behavior does not imply identical long-term behavior.

Imagine that you have a new system that looks at every doc_id and exact_query, and then calculates the probability of click for every doc for every query. You find that its behavior is nearly identical to your current system in both side by sides and A/B testing, so given its simplicity, you launch it. However, you notice that no new apps are being shown. Why? Well, since your system only shows a doc based on its own history with that query, there is no way to learn that a new doc should be shown.

The only way to understand how such a system would work long-term is to have it train only on data acquired when the model was live. This is very difficult.

Training-Serving Skew

Training-serving skew is a difference between performance during training and performance during serving. This skew can be caused by:

  • A discrepancy between how you handle data in the training and serving pipelines.
  • A change in the data between when you train and when you serve.
  • A feedback loop between your model and your algorithm.

We have observed production machine learning systems at Google with training- serving skew that negatively impacts performance. The best solution is to explicitly monitor it so that system and data changes don't introduce skew unnoticed.

Rule #29: The best way to make sure that you train like you serve is to save the set of features used at serving time, and then pipe those features to a log to use them at training time.

Even if you can't do this for every example, do it for a small fraction, such that you can verify the consistency between serving and training (see Rule #37 ). Teams that have made this measurement at Google were sometimes surprised by the results. YouTube home page switched to logging features at serving time with significant quality improvements and a reduction in code complexity, and many teams are switching their infrastructure as we speak.

Rule #30: Importance-weight sampled data, don't arbitrarily drop it!

When you have too much data, there is a temptation to take files 1-12, and ignore files 13-99. This is a mistake. Although data that was never shown to the user can be dropped, importance weighting is best for the rest. Importance weighting means that if you decide that you are going to sample example X with a 30% probability, then give it a weight of 10/3. With importance weighting, all of the calibration properties discussed in Rule #14 still hold.

Rule #31: Beware that if you join data from a table at training and serving time, the data in the table may change.

Say you join doc ids with a table containing features for those docs (such as number of comments or clicks). Between training and serving time, features in the table may be changed. Your model's prediction for the same document may then differ between training and serving. The easiest way to avoid this sort of problem is to log features at serving time (see Rule #32 ). If the table is changing only slowly, you can also snapshot the table hourly or daily to get reasonably close data. Note that this still doesn't completely resolve the issue.

Rule #32: Re-use code between your training pipeline and your serving pipeline whenever possible.

Batch processing is different than online processing. In online processing, you must handle each request as it arrives (eg you must do a separate lookup for each query), whereas in batch processing, you can combine tasks (eg making a join). At serving time, you are doing online processing, whereas training is a batch processing task. However, there are some things that you can do to re-use code. For example, you can create an object that is particular to your system where the result of any queries or joins can be stored in a very human readable way, and errors can be tested easily. Then, once you have gathered all the information, during serving or training, you run a common method to bridge between the human-readable object that is specific to your system, and whatever format the machine learning system expects. This eliminates a source of training-serving skew . As a corollary, try not to use two different programming languages between training and serving. That decision will make it nearly impossible for you to share code.

Rule #33: If you produce a model based on the data until January 5th, test the model on the data from January 6th and after.

In general, measure performance of a model on the data gathered after the data you trained the model on, as this better reflects what your system will do in production. If you produce a model based on the data until January 5th, test the model on the data from January 6th. You will expect that the performance will not be as good on the new data, but it shouldn't be radically worse. Since there might be daily effects, you might not predict the average click rate or conversion rate, but the area under the curve, which represents the likelihood of giving the positive example a score higher than a negative example, should be reasonably close.

Rule #34: In binary classification for filtering (such as spam detection or determining interesting emails), make small short-term sacrifices in performance for very clean data.

In a filtering task, examples which are marked as negative are not shown to the user. Suppose you have a filter that blocks 75% of the negative examples at serving. You might be tempted to draw additional training data from the instances shown to users. For example, if a user marks an email as spam that your filter let through, you might want to learn from that.

But this approach introduces sampling bias. You can gather cleaner data if instead during serving you label 1% of all traffic as "held out", and send all held out examples to the user. Now your filter is blocking at least 74% of the negative examples. These held out examples can become your training data.

Note that if your filter is blocking 95% of the negative examples or more, this approach becomes less viable. Even so, if you wish to measure serving performance, you can make an even tinier sample (say 0.1% or 0.001%). Ten thousand examples is enough to estimate performance quite accurately.

Rule #35: Beware of the inherent skew in ranking problems.

When you switch your ranking algorithm radically enough that different results show up, you have effectively changed the data that your algorithm is going to see in the future. This kind of skew will show up, and you should design your model around it. There are multiple different approaches. These approaches are all ways to favor data that your model has already seen.

  1. Have higher regularization on features that cover more queries as opposed to those features that are on for only one query. This way, the model will favor features that are specific to one or a few queries over features that generalize to all queries. This approach can help prevent very popular results from leaking into irrelevant queries. Note that this is opposite the more conventional advice of having more regularization on feature columns with more unique values.
  2. Only allow features to have positive weights. Thus, any good feature will be better than a feature that is "unknown".
  3. Don't have document-only features. This is an extreme version of #1. For example, even if a given app is a popular download regardless of what the query was, you don't want to show it everywhere. Not having document-only features keeps that simple. The reason you don't want to show a specific popular app everywhere has to do with the importance of making all the desired apps reachable. For instance, if someone searches for "bird watching app", they might download "angry birds", but that certainly wasn't their intent. Showing such an app might improve download rate, but leave the user's needs ultimately unsatisfied.

Rule #36: Avoid feedback loops with positional features.

The position of content dramatically affects how likely the user is to interact with it. If you put an app in the first position it will be clicked more often, and you will be convinced it is more likely to be clicked. One way to deal with this is to add positional features, ie features about the position of the content in the page. You train your model with positional features, and it learns to weight, for example, the feature "1stposition" heavily. Your model thus gives less weight to other factors for examples with "1stposition=true". Then at serving you don't give any instances the positional feature, or you give them all the same default feature, because you are scoring candidates before you have decided the order in which to display them.

Note that it is important to keep any positional features somewhat separate from the rest of the model because of this asymmetry between training and testing. Having the model be the sum of a function of the positional features and a function of the rest of the features is ideal. For example, don't cross the positional features with any document feature.

Rule #37: Measure Training/Serving Skew.

There are several things that can cause skew in the most general sense. Moreover, you can divide it into several parts:

  • The difference between the performance on the training data and the holdout data. In general, this will always exist, and it is not always bad.
  • The difference between the performance on the holdout data and the "nextday" data. Again, this will always exist. You should tune your regularization to maximize the next-day performance. However, large drops in performance between holdout and next-day data may indicate that some features are time-sensitive and possibly degrading model performance.
  • The difference between the performance on the "next-day" data and the live data. If you apply a model to an example in the training data and the same example at serving, it should give you exactly the same result (see Rule #5 ). Thus, a discrepancy here probably indicates an engineering error.

ML Phase III: Slowed Growth, Optimization Refinement, and Complex Models

There will be certain indications that the second phase is reaching a close. First of all, your monthly gains will start to diminish. You will start to have tradeoffs between metrics: you will see some rise and others fall in some experiments. This is where it gets interesting. Since the gains are harder to achieve, the machine learning has to get more sophisticated. A caveat: this section has more blue-sky rules than earlier sections. We have seen many teams go through the happy times of Phase I and Phase II machine learning. Once Phase III has been reached, teams have to find their own path.

Rule #38: Don't waste time on new features if unaligned objectives have become the issue.

As your measurements plateau, your team will start to look at issues that are outside the scope of the objectives of your current machine learning system. As stated before, if the product goals are not covered by the existing algorithmic objective, you need to change either your objective or your product goals. For instance, you may optimize clicks, plus-ones, or downloads, but make launch decisions based in part on human raters.

Rule #39: Launch decisions are a proxy for long-term product goals.

Alice has an idea about reducing the logistic loss of predicting installs. She adds a feature. The logistic loss drops. When she does a live experiment, she sees the install rate increase. However, when she goes to a launch review meeting, someone points out that the number of daily active users drops by 5%. The team decides not to launch the model. Alice is disappointed, but now realizes that launch decisions depend on multiple criteria, only some of which can be directly optimized using ML.

The truth is that the real world is not dungeons and dragons: there are no "hit points" identifying the health of your product. The team has to use the statistics it gathers to try to effectively predict how good the system will be in the future. They need to care about engagement, 1 day active users (DAU), 30 DAU, revenue, and advertiser's return on investment. These metrics that are measureable in A/B tests in themselves are only a proxy for more longterm goals: satisfying users, increasing users, satisfying partners, and profit, which even then you could consider proxies for having a useful, high quality product and a thriving company five years from now.

The only easy launch decisions are when all metrics get better (or at least do not get worse). If the team has a choice between a sophisticated machine learning algorithm, and a simple heuristic, if the simple heuristic does a better job on all these metrics, it should choose the heuristic. Moreover, there is no explicit ranking of all possible metric values. Specifically, consider the following two scenarios:

Experiment Daily Active Users Revenue/Day
A 1 million $4 million
B 2 million $2 million

If the current system is A, then the team would be unlikely to switch to B. If the current system is B, then the team would be unlikely to switch to A. This seems in conflict with rational behavior; however, predictions of changing metrics may or may not pan out, and thus there is a large risk involved with either change. Each metric covers some risk with which the team is concerned.

Moreover, no metric covers the team's ultimate concern, "where is my product going to be five years from now"?

Individuals, on the other hand, tend to favor one objective that they can directly optimize. Most machine learning tools favor such an environment. An engineer banging out new features can get a steady stream of launches in such an environment. There is a type of machine learning, multi-objective learning, which starts to address this problem. For instance, one can formulate a constraint satisfaction problem that has lower bounds on each metric, and optimizes some linear combination of metrics. However, even then, not all metrics are easily framed as machine learning objectives: if a document is clicked on or an app is installed, it is because that the content was shown. But it is far harder to figure out why a user visits your site. How to predict the future success of a site as a whole is AI-complete : as hard as computer vision or natural language processing.

Rule #40: Keep ensembles simple.

Unified models that take in raw features and directly rank content are the easiest models to debug and understand. However, an ensemble of models (a "model" which combines the scores of other models) can work better. To keep things simple, each model should either be an ensemble only taking the input of other models, or a base model taking many features, but not both. If you have models on top of other models that are trained separately, then combining them can result in bad behavior.

Use a simple model for ensembling that takes only the output of your "base" models as inputs. You also want to enforce properties on these ensemble models. For example, an increase in the score produced by a base model should not decrease the score of the ensemble. Also, it is best if the incoming models are semantically interpretable (for example, calibrated) so that changes of the underlying models do not confuse the ensemble model. Also, enforce that an increase in the predicted probability of an underlying classifier does not decrease the predicted probability of the ensemble .

Rule #41: When performance plateaus, look for qualitatively new sources of information to add rather than refining existing signals.

You've added some demographic information about the user. You've added some information about the words in the document. You have gone through template exploration, and tuned the regularization. You haven't seen a launch with more than a 1% improvement in your key metrics in a few quarters. Now what?

It is time to start building the infrastructure for radically different features, such as the history of documents that this user has accessed in the last day, week, or year, or data from a different property. Use wikidata entities or something internal to your company (such as Google's knowledge graph ). Use deep learning. Start to adjust your expectations on how much return you expect on investment, and expand your efforts accordingly. As in any engineering project, you have to weigh the benefit of adding new features against the cost of increased complexity.

Rule #42: Don't expect diversity, personalization, or relevance to be as correlated with popularity as you think they are.

Diversity in a set of content can mean many things, with the diversity of the source of the content being one of the most common. Personalization implies each user gets their own results. Relevance implies that the results for a particular query are more appropriate for that query than any other. Thus all three of these properties are defined as being different from the ordinary.

The problem is that the ordinary tends to be hard to beat.

Note that if your system is measuring clicks, time spent, watches, +1s, reshares, et cetera, you are measuring the popularity of the content. Teams sometimes try to learn a personal model with diversity. To personalize, they add features that would allow the system to personalize (some features representing the user's interest) or diversify (features indicating if this document has any features in common with other documents returned, such as author or content), and find that those features get less weight (or sometimes a different sign) than they expect.

This doesn't mean that diversity, personalization, or relevance aren't valuable. As pointed out in the previous rule, you can do postprocessing to increase diversity or relevance. If you see longer term objectives increase, then you can declare that diversity/relevance is valuable, aside from popularity. You can then either continue to use your postprocessing, or directly modify the objective based upon diversity or relevance.

Rule #43: Your friends tend to be the same across different products. Your interests tend not to be.

Teams at Google have gotten a lot of traction from taking a model predicting the closeness of a connection in one product, and having it work well on another. Your friends are who they are. On the other hand, I have watched several teams struggle with personalization features across product divides. Yes, it seems like it should work. For now, it doesn't seem like it does. What has sometimes worked is using raw data from one property to predict behavior on another. Also, keep in mind that even knowing that a user has a history on another property can help. For instance, the presence of user activity on two products may be indicative in and of itself.

There are many documents on machine learning at Google as well as externally.

Acknowledgements

Thanks to David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira, and Hrishikesh Aradhye for many corrections, suggestions, and helpful examples for this document. Also, thanks to Kristen Lefevre, Suddha Basu, and Chris Berg who helped with an earlier version. Any errors, omissions, or (gasp!) unpopular opinions are my own.

Appendix

There are a variety of references to Google products in this document. To provide more context, I give a short description of the most common examples below.

YouTube Overview

YouTube is a streaming video service. Both YouTube Watch Next and YouTube Home Page teams use ML models to rank video recommendations. Watch Next recommends videos to watch after the currently playing one, while Home Page recommends videos to users browsing the home page.

Google Play Overview

Google Play has many models solving a variety of problems. Play Search, Play Home Page Personalized Recommendations, and 'Users Also Installed' apps all use machine learning.

Google Plus Overview

Google Plus used machine learning in a variety of situations: ranking posts in the "stream" of posts being seen by the user, ranking "What's Hot" posts (posts that are very popular now), ranking people you know, et cetera. Google Plus closed down all personal accounts in 2019, and was replaced by Google Currents for business accounts on July 6, 2020.