خریدی که دستیار هوش مصنوعی کرده، داده‌ مشتری محسوب می‌شود؟

مزدک پاکزاد، کارآفرین فناوری و هم‌بنیان‌گذار و مدیرعامل بین‌وبان، درباره‌ اقتصاد داده، بازاریابی و تأثیر هوش مصنوعی بر کسب‌وکار می‌نویسد.

در قسمت اول این سری نوشتم که در تجارت Agent-محور ممکن است فروشگاه سفارش را نگه دارد ولی مالکیت تصمیم را از دست بدهد. حالا می‌خواهم یک لایه پایین‌تر بروم به جایی که به‌نظرم خسارت زودتر و بی‌سروصداتر اتفاق می‌افتد: پایگاه داده‌ی مشتری.

بگذارید با یک مثال ساده شروع کنم و تا آخر همین مقاله رهایش نکنم.

کاربری از Agent خود می‌خواهد برای تولد فرزندِ یکی از دوستانش هدیه‌ای پیدا کند. Agent ده‌ها اسباب‌بازی را بررسی می‌کند، چند گروه سنی را مقایسه می‌کند، نقدها را می‌خواند و در نهایت یک محصول را می‌خرد.

فردای آن روز پلتفرم فروش چه چیزی درباره‌ی این کاربر می‌داند؟

اگر تمام رفتار Agent را مثل رفتار مستقیم انسان وارد پروفایل مشتری کند به این نتیجه‌ها می‌رسد: کاربر به اسباب‌بازی کودک علاقه دارد، احتمالاً بچه‌ای در آن گروه سنی دارد و گزینه‌ی خوبی برای خریدهای مشابه است. بعد او را وارد یک گروه مخاطب هدف می‌کند، پیام شخصی‌سازی‌شده می‌فرستد و مدل‌های پیش‌بینی‌اش را با همین داده تغذیه می‌کند.

هیچ‌کدام از این نتیجه‌ها درست نیست. کاربر بچه ندارد. به اسباب‌بازی علاقه ندارد. و احتمالاً تا سال دیگر همین موقع هم دوباره سراغ این دسته نمی‌رود.

این مثال ساده یکی از سخت‌ترین مسائل داده‌ی مشتری در سال‌های پیش‌روست: وقتی بازیگر واقعیِ یک تعامل Agent است چه بخشی از رفتارش متعلق به پروفایل انسان است؟

جواب پایه‌ای من: Agent باید به مشتری وصل شود اما نباید با او یکی شود.

Agent با «دوقلوی دیجیتال» فرق دارد

Digital Twin یا دوقلوی دیجیتال، یک بازنمایی است. کارش توصیف یا شبیه‌سازی وضعیت و ترجیحات یک شخص است.

Agent عمل می‌کند. ممکن است از مدلی شبیه دوقلوی دیجیتال استفاده کند ولی خودش آن نیست. ابزار دارد، با محیط بیرون تعامل می‌کند و در محدوده‌ی اختیاری که گرفته تصمیم می‌گیرد.

این تفاوت فلسفی نیست بلکه معماری است. دوقلوی دیجیتال بخشی از مدل شناخت ما از مشتری است. Agent یک بازیگر مستقل با هویت، ارائه‌دهنده، توانمندی، مجوز و سابقه‌ی عمل.

برگردیم به همان خرید هدیه. چند واقعیت را ببینید:

▪        آن Agent ممکن است فقط برای یک مأموریت ده‌دقیقه‌ای ساخته شده باشد و بعدش دیگر وجود نداشته باشد.

▪        ممکن است بین چند عضو خانواده یا کارکنان یک شرکت مشترک باشد.

▪        همان کاربر ممکن است برای سفر، امور مالی و کار سازمانی Agentهای کاملاً متفاوتی داشته باشد.

▪        خرید ممکن است برای شخص دیگری انجام شده باشد که در مثال ما دقیقاً همین‌طور است.

▪        بخشی از تصمیم Agent محصولِ محدودیت‌های ارائه‌دهنده و مدل و ابزارهای اوست نه ترجیح کاربر.

▪        بخش بزرگی از آن ده‌ها محصولی که بررسی شد هیچ انسانی هرگز ندیده است.

در بهترین حالت Agent یک نماینده‌ی مأموریت‌محور از قصد کاربر است. محدود، موقت و وابسته به هدف.

چهار موجودیت که نباید قاطی شوند

مدل هویت در تجارت سنتی حول یک سؤال ساخته شده بود: این کوکی، شناسه‌ی دستگاه، شماره تلفن و شماره‌ی مشتری مال کدام آدم است؟

در تجارتی که هم انسان و هم ماشین در آن عمل می‌کنند این سؤال کافی نیست. هر تعامل باید دست‌کم چهار چیز را از هم جدا نگه دارد.

بازیگر (Actor) — چه موجودیتی عمل را انجام داده؟ انسان، Agent، خزنده‌ی موتور جست‌وجو، ابزار خودکار یا سیستم سازمانی؟

صاحب اختیار (Principal) — این عمل با اجازه‌ی چه انسان یا سازمانی انجام شده؟

ذی‌نفع (Beneficiary) — نتیجه برای چه کسی است؟ صاحب حساب، عضو دیگری از خانواده، گیرنده‌ی هدیه یا یک واحد سازمانی؟

مأموریت (Mission) — Agent برای چه هدف مشخصی عمل می‌کند؟

در مثال ما بازیگر یک Agent است، صاحب اختیار کاربر است، ذی‌نفع بچه‌ی یک نفر دیگر است و مأموریت یک خرید هدیه‌ی یک‌باره. اگر سیستم فقط صاحب اختیار را ثبت کند هر سه‌ی دیگر گم می‌شوند و پروفایل بلافاصله دروغ می‌گوید.

نمونه‌ی سازمانی‌اش هم دقیقاً همین شکل است: مدیر خرید به Agent شرکت اجازه می‌دهد برای یک شعبه کالا سفارش دهد، پرداخت از حساب شرکت انجام می‌شود و مصرف‌کننده کارکنان آن شعبه‌اند. سه موجودیت متفاوت و یک تراکنش.

مدل درست رابطه این است:

Agent -- acts_for [scope, purpose, expiry] --> Principal

یعنی Agent هویت مستقل خودش را نگه می‌دارد و رابطه‌اش با صاحب اختیار در یک mandate ثبت می‌شود؛ یک اختیار تفویض‌شده‌ی مشخص که دامنه، هدف، بودجه، محدودیت و تاریخ انقضا دارد.

چرا ادغام کامل خطرناک است؟

در پلتفرم‌های داده‌ی مشتری فرایندی هست به اسم Identity Resolution که تلاش می‌کند شناسه‌های پراکنده‌ی متعلق به یک شخص را با اطمینان کافی به یک پروفایل وصل کند. برای شماره تلفن، ایمیل و شماره‌ی مشتری منطق درستی است. برای Agent نتیجه‌ی معکوس می‌دهد.

اگر Agent و انسان کاملاً در هم ادغام شوند:

▪        علاقه‌های موقت به ویژگی‌های دائمی تبدیل می‌شوند (همان «این آدم بچه دارد»)

▪        رفتار چند صاحب اختیار در یک پروفایل مخلوط می‌شود

▪        سقف نمایش تبلیغ و فهرست حذف‌شده‌ها اشتباه عمل می‌کنند

▪        گروه‌های مخاطب تبلیغاتی با داده‌ی مأموریت‌محور تغذیه می‌شوند

▪        مرز بین تصمیم انسان و جست‌وجوی مستقل Agent در انتساب فروش محو می‌شود

▪        رضایت یک کاربر ممکن است به Agent یا مأموریت یا فرد دیگری سرایت کند

▪        مدل‌های پیش‌بینی به‌جای رفتار مشتری سیاست‌های ارائه‌دهنده‌ی Agent را یاد می‌گیرند

این آخری را جدی بگیرید. مدل شما فکر می‌کند دارد سلیقه‌ی مشتری را یاد می‌گیرد در حالی که دارد الگوریتم رتبه‌بندی یک شرکت دیگر را یاد می‌گیرد.

و بدتر آن که این آلودگی به‌سادگی برگشت‌پذیر نیست. وقتی هزاران تعامل اشتباه وارد ویژگی‌ها و دسته‌بندی‌ها و سناریوهای ارتباطی شد، حذف شناسه‌ی Agent مشکل را حل نمی‌کند. باید سراغ همه‌ی استنتاج‌هایی بروید که از آن داده ساخته شده و معمولاً هیچ‌کس نمی‌داند آن‌ها کجا رفته‌اند.

اما همه‌ی رفتار Agent را هم دور نریزید

راه‌حل این نیست که رفتار Agent را کنار بگذاریم. Agent می‌تواند سیگنال قدرتمندی از قصد باشد. مسئله این است که هر سیگنال با وزن، منشأ و طول عمر درست ذخیره شود.

قاعده‌ی من ساده است: هرچه سیگنال به تصمیم یا تأیید انسان نزدیک‌تر است، وزن و ماندگاری بیشتری دارد. هرچه به جست‌وجوی مستقل Agent نزدیک‌تر است، باید موقت‌تر و محدودتر بماند.

در عمل یعنی این:

خرید قطعی و تحویل‌شده می‌تواند وارد تاریخچه‌ی تراکنش صاحب اختیار شود به شرطی که ثبت شود بازیگر واقعی یک Agent بوده و اگر ذی‌نفع شخص دیگری است این هم حفظ شود. در مثال ما سفارش ثبت می‌شود ولی با برچسبی که می‌گوید «خرید هدیه، ذی‌نفع دیگری».

تأیید صریح انسان — انتخاب مشخص، ذخیره‌ی محصول، سبد تأییدشده — سیگنال پرقدرتی است و با اطمینان بالا وارد پروفایل می‌شود.

فهرست کوتاهی که Agent ساخته به‌عنوان قصد موقت نگه داشته می‌شود، مشروط به اینکه ارائه‌دهنده، مأموریت، میزان اطمینان و تاریخ انقضا مشخص باشد.

گشت‌وگذار و مقایسه‌ی اولیه — آن ده‌ها اسباب‌بازی که Agent باز کرد در پروفایل مأموریت می‌ماند و هرگز وارد ویژگی‌های بلندمدت انسان نمی‌شود.

پیشنهاد حمایت‌شده‌ای که Agent دیده مواجهه‌ی انسانی نیست و به‌تنهایی نباید مبنای بازاریابی مجدد برای انسان شود.

استنتاج ساخته‌ی Agent بدون منشأ، هدف و تاریخ انقضا نباید به ویژگی دائمی مشتری تبدیل شود.

پروفایل آینده یک رکورد تخت نیست

پروفایل مشتری سنتی معمولاً مجموعه‌ای از شناسه‌ها، ویژگی‌ها، دسته‌بندی‌ها و یک خط زمانی رفتار است. در محیطی که انسان و ماشین کنار هم عمل می‌کنند این مدل باید لایه‌دار شود:

▪        پروفایل صاحب اختیار: هویت، رضایت، ویژگی‌ها و تاریخچه‌ی انسان یا سازمان

▪        پروفایل Agent: ارائه‌دهنده، نسخه، توانمندی، مجوز، وضعیت احراز و سابقه‌ی عمل

▪        اختیار تفویض‌شده: دامنه‌ی اختیار، هدف، بودجه، سیاست تأیید و تاریخ انقضا

▪        پروفایل مأموریت: قصد، محدودیت‌ها، دسته، ذی‌نفع و طول عمر مأموریت

▪        منشأ رخداد: چه بازیگری، از چه منبعی و در چه زمینه‌ای این رخداد را ساخته

▪        نتیجه: سفارش، پرداخت، تحویل، لغو و مرجوعی

این لایه‌ها می‌توانند در یک گراف هویت به هم وصل باشند ولی نباید در یک رکورد بی‌تمایز فرو بریزند.

سه مجوزی که یکی نیستند

خطرناک‌ترین ساده‌سازی این است که اجازه‌ی خرید Agent را معادل رضایت کاربر برای استفاده از داده بدانیم.

رضایت (Consent) می‌گوید داده برای چه هدفی قابل‌پردازش است؛ ارائه‌ی سرویس، تبلیغات شخصی‌سازی‌شده، تحلیل، یا اشتراک با شریک تجاری.

تفویض اختیار (Delegation) می‌گوید Agent چه کاری می‌تواند به نمایندگی از صاحب اختیار انجام دهد؛ جست‌وجو، مقایسه، ساخت سبد، پرداخت، مدیریت سفارش.

مجوز تراکنش (Transaction Authorization) می‌گوید کدام معامله‌ی مشخص با چه مبلغ و چه فروشنده‌ای مجاز شده است.

کاربر مثال ما اجازه داده یک هدیه خریده شود. اجازه نداده پروفایلش غنی‌سازی شود، در گروه مخاطب اسباب‌بازی قرار بگیرد یا قصدش به یک تبلیغ‌دهنده منتقل شود. این سه چیز کاملاً جدا هستند و باید جدا ثبت شوند.

استانداردها دارند در همین جهت حرکت می‌کنند. پروتکل AP2 در گوگل از اختیارهای امضاشده برای ثبت دستور و محدودیت‌های کاربر استفاده می‌کند. Delegated Payment در OpenAI مجوز پرداخت را یک‌بارمصرف، محدود به مبلغ و دارای انقضا مدل می‌کند. Visa Trusted Agent Protocol بین Agent معتبر، کاربر احرازشده و اختیار خرید تفاوت می‌گذارد هرچند ویزا خودش صریح می‌گوید هنوز در مرحله‌ی توسعه است.

اصل مشترک هر سه یکی است: اختیار Agent باید محدود، قابل‌اثبات و قابل‌لغو باشد. و رضایت جدا و وابسته به هدف بماند.

حداقل چیزی که باید در هر رخداد بماند

اگر بخواهم عملی‌ترین بخش این مقاله را در یک جدول خلاصه کنم این است. هر تعاملی که Agent در آن نقش دارد باید این اطلاعات را حمل کند:

هدف جمع‌آوری حداکثری داده نیست. هدف نگه‌داشتن به‌اندازه‌ی منشأ است تا بعداً تفسیر اشتباه نکنیم.

و یک نکته که معمولاً فراموش می‌شود: هر تصمیم اتصال یا انتقال سیگنال باید قابل‌بازگشت باشد. باید بتوانید بپرسید «این ویژگی از کجا آمد؟» و بتوانید حذفش کنید بدون اینکه کل پروفایل را بازسازی کنید. مدل داده‌ی Verifiable Credentials در W3C — استانداردی برای ادعاهایی که می‌شود صحتشان را مستقلاً راستی‌آزمایی کرد — یکی از زیرساخت‌های ممکن است ولی فناوری مجوز به‌تنهایی کافی نیست. سیستم داده باید بداند این ادعا برای چه هدفی و تا چه زمانی قابل‌استفاده است.

چرا این مسئله در ایران حادتر است؟

بازار ایران چند ویژگی دارد که آن را بیشتر از بازارهای بالغ در معرض ادغام اشتباه می‌گذارد. و این‌ها ربطی به Agent ندارند. از قبل بوده‌اند.

حساب‌های مشترک خانوادگی رایج‌اند. یک حساب دیجی‌کالا یا اسنپ‌مارکت که پدر، مادر و بچه‌ها از آن استفاده می‌کنند کاملاً عادی است. پروفایلی که از آن ساخته می‌شود از همین حالا ترکیبی از چند نفر است.

شماره تلفن شناسه‌ی غالب است. در بازارهای دیگر ایمیل، کوکی و شناسه‌ی دستگاه سیگنال‌های متعدد و گاهی متناقض می‌دهند که سیستم را وادار به احتیاط می‌کند. در ایران شماره تلفن یک کلید قطعی و پرقدرت است. هر چیزی که به آن بچسبد با اطمینان بالا ادغام می‌شود چه درست باشد چه غلط.

استاندارد مشترکی برای اختیار تفویض‌شده وجود ندارد. نه پروتکلی، نه توافقی و نه حتی زبان مشترکی برای اینکه بگوییم این خرید با چه اختیاری انجام شده.

حالا Agent را به این ترکیب اضافه کنید. فروشگاهی که همه‌ی فعالیت‌ها را به صاحب شماره تلفن نسبت می‌دهد، در یک پروفایل واحد این‌ها را قاطی می‌کند: رفتار خود کاربر، رفتار بقیه‌ی اعضای خانواده، جست‌وجوی مستقل Agent و خریدی که اصلاً برای شخص دیگری بوده.

بعد روی این پروفایل، گروه مخاطب می‌سازد و بودجه‌ی تبلیغات خرج می‌کند.

مسئله قبل از اینکه فنی باشد مربوط به تعریف است. ما هنوز درست تعریف نکرده‌ایم «مشتری» یعنی چه کسی.

هویت در تجارت آینده، رابطه است نه رکورد

برگردیم به همان خرید هدیه. Agent ترجیحات کاربر را می‌دانست، برایش گشت و در محدوده‌ی اختیارش خرید کرد. هیچ‌کدام از این‌ها Agent را به خودِ کاربر تبدیل نمی‌کند.

پروفایل آینده هم نباید انباری از هر تعاملی باشد که به‌نوعی به حساب مشتری چسبیده. باید بتواند بین رفتار مستقیم انسان، رفتار مأموریت‌محور Agent، اختیار داده‌شده، رضایت معتبر و نتیجه‌ی قطعی تفاوت بگذارد.

در تجارت انسان‌محور کار هویت عمدتاً یکی‌کردن شناسه‌های پراکنده بود. از این به بعد بلوغ هویت در توانایی حفظ تفاوت‌هاست.

در قسمت آخر این سری سراغ پول می‌روم: اگر Agent روی تبلیغ کلیک کند، بابت چه چیزی و به چه کسی باید پول داد؟