CSDN パーソナライズド レコメンデーション システム - ネガティブ フィードバック テスト

記事ディレクトリ

序文

CSDN パーソナライズド レコメンデーション システム - ネガティブ フィードバック テスト

みなさん、こんにちは。私はコンコンスターです。この記事を皆さんにシェアします《CSDN个性化推荐系统-负反馈测试》

1. UC はラベル フィルタリング テストに興味がありません

ユーザー: weixin_38093452

1. uc はタグの取得に興味がありません (uc_unlike_tag_list)

1.1 パーソナルセンターインターフェース

1.2 ラベルから何がわかるか?

  • ラベルにはプライマリラベルとセカンダリラベルがあります
  • ラベルはすべて小文字ではなく、一部の文字は大文字です
  • 興味がある場合と興味がない場合の両方に同じラベルが表示されます

1.3 研究開発への確認事項

  • フィルタリング側でプライマリラベルとセカンダリラベルを別々に使用するのか、それともセカンダリラベルのみを使用するのか?
  • 取得したucタグと推奨ストリーム記事のタグを照合する際、照合前に一律に小文字または大文字に変換することはありますか?
  • 興味のあるタグと興味のないタグに同じタグが出現した場合、強化よりもブロックの優先度が高いのでしょうか?
  • uc タグが維持された後、推奨フローはいつ有効になりますか?

1.4 設計と開発

def get_uc_tag_list(username, interest_type):
    uc_tag_list = []
    # 获取uc不感兴趣标签
    url = f'http://xxx.csdn.net/user_csdn_tag/get_tag_list?username={
      
      username}&type={
      
      interest_type}'
    response = requests.get(url)
    res = response.json()
    for i in res['data']:
        name = i['name']
        for tag in i['tags']:
            if tag['select']:
                # 添加小写后的一级标签
                uc_tag_list.append(name.lower())
                # 添加小写后的二级标签
                uc_tag_list.append(tag['name'].lower())
    return uc_tag_list

1.5 結果を取得するインターフェース

unlike_uc_tag_list = get_uc_tag_list('weixin_38093452', 1)
print(unlike_uc_tag_list)

['python', '枕', 'java', 'java', 'プログラミング言語', 'php', 'ビッグデータ', 'odps', 'ビッグデータ', 'ビッグデータ', '人工知能', 「人工知能」、「aigc」、「chatgpt」]

2. 推奨ストリーム記事タグ(tag_list)の取得

ユーザー: weixin_38093452 が
推奨インターフェイスを 50 回リクエストしました

2.1 コードの一部

    items = result['data']['items']
    for data in items:
        # 过滤掉nps
        if 'username' in data:
            tags = data["tags"]
            temp_tag = []
            for tag in tags:
                # 用来判断一个item中返回的标签是否重复(ml和title合并,只保留ml)
                temp_tag.append(tag['name'])
                # 多次请求后,用来跟uc的不感兴趣标签/负反馈标签做对比
                tag_list.append(tag['name'])
                # 多次请求后,用来判断ml标签和title标签是否有返回
                tag_type_list.append(tag['type'])
                if tag['name'] == '':
                    print(f"存在空标签,博客:{
      
      data['product_id']},标签类型:{
      
      tag['type']},标签名称:{
      
      tag['name']}")
            if len(temp_tag) != len(set(temp_tag)):
                print(f"同一篇博客{
      
      data['product_id']}存在重复标签:{
      
      temp_tag}")
if len(set(tag_type_list)) == 2:
    print(f'返回文章标签类型:{
      
      set(tag_type_list)}')

2.2 基本的なラベル検証

  • ml タグと title タグの両方が返されるかどうか。
  • 返す空のラベル構造があるかどうか。
  • 同じブログが重複したタグを返すかどうか。

2.3 基本的なラベル検証結果

返される記事タグのタイプ: {'ml', 'title'}

3. 推奨フロー uc はラベル フィルタリングの検証には興味がありません

3.1 検証方法

  1. ユーザーの UC の興味のないタグ リスト (uc_unlike_tag_list) を取得します。
  2. ユーザーの 50 件の推奨ストリーム要求によって返された記事のタグ リスト (tag_list) を取得します。
  3. uc_unlike_tag_list と tag_list の共通部分を見つけます。

3.2 コードの一部

    print(f'【推荐返回的标签】:{
      
      set(tag_list)}')
    unlike_uc_tag_list = get_uc_tag_list(username, '1')
    print(f'【uc-不感兴趣标签】:{
      
      set(unlike_uc_tag_list)}')
    intersection_tag = list(set(tag_list).intersection(set(unlike_uc_tag_list)))
    print(f'【uc-不感兴趣标签过滤】验证结果,标签交集:{
      
      intersection_tag}')

3.3 チェック結果

3.4 結果の分析

タグの交差部分は空であり、不正なケースがないことを示しています。
[推奨される返されたタグ] の高頻度タグを uc に興味のないタグに維持し、スクリプトを再度実行して検証結果を観察し、サーバー uc に興味のないものを結合します。ログのフィルタリング (複数回) 実行ラベルの交差部分はまだ空であり、UC 無関心ラベルが推奨フロー フィルタリングで有効であることを示しています。

4. ユーザーシナリオの回帰

推奨インターフェイスに戻りデータがあり、戻りデータが正常であることを確認してください。

  • ログインユーザー (メンテナンスされていない UC に興味のないタグ)
  • ログインしていないユーザー

2. ユーザー推奨フローの負帰還フィルタリングテスト

1. コンテンツの否定的なフィードバック

1.1 API検証を送信する

ネガティブフィードバック項目(指令):

  • 重複: 重複コンテンツの推奨
  • コンテンツの品質が低い: コンテンツの品質が低い
  • 広告:誇張された内容、広告など。

リソースタイプ (タイプ):

  • ブログ
  • 聞く
  • まばたきする
  • ライブ

1.2 API検証の取得

  • last_unlike_time: 負のフィードバック操作のタイムスタンプ レコードが正しいかどうか。
  • num: 否定的なフィードバックの送信回数の記録が正しいかどうか。
  • 指示: 否定的なフィードバック項目の記録が正しいかどうか。
  • type と item_id の 2 つのフィールドを一意のキーとして使用するかどうか。

1.3 フィルタの検証

1.3.1 コンテンツのネガティブ フィードバック リソース リストの取得 (negative_item_list)

def get_negative_item_list(username):
    negative_item_list = []
    url = f'http://xxx.csdn.net/api/v2/recommend/insight/negative/items/by/{
      
      username}'
    response = requests.get(url)
    res = response.json()
    pprint.pprint(res)
    for i in res['result']['duplicate']:
        if 'object_id' in i.keys():
            negative_item_list.append(i['type']+':'+i['object_id'])
    for j in res['result']['content poor quality']:
        if 'object_id' in j.keys():
            negative_item_list.append(j['type']+':'+j['object_id'])
    for k in res['result']['advertising']:
        if 'object_id' in k.keys():
            negative_item_list.append(k['type']+':'+k['object_id'])
    return negative_item_list

1.3.2 推奨ストリームリソースリスト(item_list)の取得

item_list.append(data['product_type']+':'+data['product_id'])

1.3.3 item_list と negative_item_list の共通部分を見つける

    print(f'【推荐返回的item】:{
      
      set(item_list)}')
    negative_item_list = get_negative_item_list(username)
    print(f'【内容负反馈】:{
      
      set(negative_item_list)}')
    negative_intersection_item = list(set(item_list).intersection(set(negative_item_list)))
    print(f'【内容负反馈过滤】验证结果,item交集:{
      
      negative_intersection_item}')

1.3.4 交差点の結果

1.3.5 結果の分析

交差が空の場合は、Badcase がないことを意味します。
推奨結果によって返された部分的なリソース リストを、送信 API を介してコンテンツのネガティブ フィードバックに書き込み、交差を見つけます。複数の実行後に交差が空の場合は、は、コンテンツの否定的なフィードバックが推奨ストリーム フィルタリングで有効になることを意味します。

2. ネガティブなフィードバックにラベルを付ける

2.1 API検証を送信する

指令:

  • 減らす:減らす
  • ブロック:ブロック

2.2 API検証を取得する

  • tag: タグが一律に小文字に変換されるかどうか。
  • last_unlike_time: 負のフィードバック操作のタイムスタンプ レコードが正しいかどうか。
  • num: ネガティブフィードバックの投稿数の記録が正しいかどうか。

2.3 フィルタの検証

2.3.1 タグのネガティブフィードバックタグリストの取得(negative_tag_list)

def get_negative_tag_list(username):
    negative_tag_list = []
    url = f'http://xxx.csdn.net/api/v2/recommend/insight/negative/tags/by/{
      
      username}'
    response = requests.get(url)
    res = response.json()
    for i in res['result']:
        negative_tag_list.append(i['tag'].lower())
    return negative_tag_list

2.3.2 推奨ストリームタグリスト(tag_list)の取得

tag_list.append(tag['name'])

2.3.3 tag_list と negative_tag_list の共通部分を見つける

    negative_tag_list = get_negative_tag_list(username)
    print(f'【减少xx相似内容推荐】:{
      
      set(negative_tag_list)}')
    negative_intersection_tag = list(set(tag_list).intersection(set(negative_tag_list)))
    print(f'【减少xx相似内容推荐过滤】验证结果,标签交集:{
      
      negative_intersection_tag}')

2.3.4 交差点の結果

2.3.5 結果の分析

交差が空の場合は、Badcase がないことを意味します。
レコメンデーション結果で返されたタグのリストを、サブミッション API を介してタグのネガティブ フィードバックに書き込み、交差を見つけます。複数の実行後に交差が空の場合は、それを意味します。タグのネガティブ フィードバックがレコメンデーション フロー フィルタリングで有効になること。

3. 否定的なフィードバックを作成する

3.1 API検証を送信する

  • Like_user_id のケースのシナリオ

3.2 API検証の取得

  • 著者を小文字に変換するかどうか。
  • last_unlike_time: 負のフィードバック操作のタイムスタンプ レコードが正しいかどうか。
  • num: ネガティブフィードバックの投稿数の記録が正しいかどうか。

3.3 フィルタの検証

3.3.1 著者のネガティブフィードバック著者リスト(negative_user_list)を取得する

def get_negative_user_list(username):
    negative_user_list = []
    url = f'http://xxx.csdn.net/api/v2/recommend/insight/negative/users/by/{
      
      username}'
    response = requests.get(url)
    res = response.json()
    for i in res['result']:
        negative_user_list.append(i.lower())
    return negative_user_list

3.3.2 推奨ストリーム作成者のリスト (user_list) を取得する

user_list.append(data['username'])

3.3.3 user_list と negative_user_list の共通部分を見つける

    print(f'【推荐返回的作者】:{
      
      set(user_list)}')
    negative_user_list = get_negative_user_list(username)
    print(f'【不看此作者】:{
      
      set(negative_user_list)}')
    negative_intersection_user = list(set(user_list).intersection(set(negative_user_list)))
    print(f'【不看此作者过滤】验证结果,作者交集:{
      
      negative_intersection_user}')

3.3.4 交差点の結果

3.3.5 結果の分析

交差部分は空であり、不良ケースがないことを示します。
推奨結果によって返された著者リストが投稿 API を介して著者の否定的なフィードバックに書き込まれ、交差部分が取得されます。複数回実行すると交差部分が空になり、著者の否定的なフィードバックは、推奨ストリームのフィルタリングに影響します。

3. 非ログインユーザーに対するネガティブフィードバックフィルタリングテスト

1. API検証を送信する

PCはuuidを送信し、アプリはdevice_idを送信します

2. API認証を取得する

  • imei フィールドの値は大文字と小文字が区別されません。
  • imei フィールドの値に従って、負のフィードバック データを正しく取得できます。

3. フィルタの検証

ログインユーザーの検証プロセスと同様に、リクエスト推奨インターフェイスの入力パラメーターのみが調整されています。

4. 全体的な回帰

  • リコールポリシーの検証。
  • リソースタイプの検証を思い出してください。
  • ログアウト ユーザー/ログイン ユーザーのシナリオ検証 (UC インタレスト タグを維持するかどうか/ID タグを維持するかどうか)。
  • 単一のリクエスト結果でのリソース タイプの分散の検証。
  • 単一のリクエストの結果における重複著者の割合の検証。
  • リソースの検証が繰り返されると、単一のリクエストの結果が表示されます。
  • 同じ作成者のリソース検証は、単一のリクエストの結果に継続的に表示されます。
  • その他のチャンネルデータ検証(ストリームのフォロー、シティストリーム、人気ストリームの点滅、推奨ユーザーリストなど)
  • 複数端末検証(app/wap/pc/applet等)

5. hbaseに書き込まれた新旧のネガティブフィードバックの比較

古い否定的なフィードバック 新しい否定的なフィードバック
プロセス ユーザーが否定的なフィードバックを送信 -> SLS にレポート -> flink が SLS を消費 -> udf 処理が hbase に書き込む ユーザーが否定的なフィードバックを送信 -> API 経由で hbase に直接書き込み
応答 Flink タスクは遅延したり、Huawei Cloud やその他の要因で移行されることが多く、リファクタリングが必要です リアルタイム
コピーライティング wap側の【繰り返しのコンテンツ推奨】を【古いニュース、繰り返し】、【コンテンツの品質が低い】を【コンテンツの品質が悪い】、【この著者を読まない】と呼ぶなど、コピーライティングが統一されていません。 [この作者は好きではありません] すべてのテキストが統一されました
データ ブログ以外のリソースの否定的なフィードバック データが適切に解析されず、hbase への誤った書き込みが発生します。 すでにさまざまなリソースタイプと互換性があります

参考文献
[1] 「CSDNパーソナライズドレコメンドシステムの再構築に向けた研究開発支援の在り方」
[2] 「CSDNパーソナライズドレコメンドシステムの設計と進化」
[3] 「CSDNパーソナライズドレコメンドのデータガバナンス」


おすすめ

転載: blog.csdn.net/weixin_38093452/article/details/131374201
おすすめ