スケーラブルな IM ボット (別名 Automated Service Agent) の開発を検討しています。以前に行われたことがあり、信頼性を維持するためにどのような方法が使用されているのか疑問に思っています。スケーリングに関する 2 つの差し迫った問題が見られます。
1) AIM では、あまりにも多くのユーザーが警告すると、キックオフされる可能性があります。私のボットはスパムを送信したり、悪意のあることを行ったりしませんが、脆弱性は依然として存在します。
2) ネットワークに問題があり、ボットが連続して何度もサインオン/オフした場合、AOL は不明な期間、ボットをロックアウトします。
検出のためのいくつかの予防策は次のとおりです。
ボットは複数のユーザーアカウントを使用できるため、ボットのアクティビティが検出される可能性は低くなります。
ボットはプロキシサーバーを使用して、実際のIPアドレスを隠すことで検出をさらに隠すことができます。
ボットは、ネットワークのルールを念頭に置いてプログラムすることができ、そのロジックでこれらのルールを破ることを防ぐことができます。
また、最初の問題に対応して、実際に問題を報告する人は予想よりも少なくなります。
さらに、これは純粋に推測的なものであり、ネットワークのルールによっては、作成される実際のレポートを相殺するために、2つ以上のボット（および複数のユーザーアカウント）間の十分な正当なアクティビティをシミュレートできる可能性があります。
複数のアカウントを持つ問題2に対応して、ボットは障害が発生したときに次のアカウントに移動します。
いくつかの考え。
＃1に関しては、人間の相互作用を扱っています。ボットが人々を苛立たせたり怒らせたりしないのであれば、ほとんどの人が気にかけるとは思えません。チャットボット（IMHO）の一番のルールは、さまざまなバックグラウンドを持つ多数の人々でテストすることです。彼らの応答と、ボットとの対話について彼らがどのように感じているかを記録します。この方法でボットの理解スキルを向上させるために、優れたデータを収集することもできます。
＃2に関しては、効果的なレートリミッターをコーディングする必要があります。短期間にフレークアウトの数が少ない場合は、すぐに再接続しても問題ない可能性がありますが、フレークアウトの頻度が高くなる場合は、さらにバックオフする必要があります。これは実際にはサービス全般に適しています。サーバー側の問題が発生している場合、ボットが問題を引き起こそうとすると、ボットの大群が攻撃を仕掛けるからです。