GoogleのAIサービス「Gemini Advanced」に含まれるAIを用いた情報検索機能「Deep Research」が日本語に対応しました。Deep Researchを使うと、AIがユーザーの指示に沿ってインターネット上から情報を収集し、詳細なレポートを作成してくれます。
人力で数時間かかる情報収集作業を数分で実行できるGoogle製AI検索機能「Deep Research」が日本語でも利用可能に - GIGAZINE
なお、Deep Researchを使うにはGemini Advancedへの加入が必要で、月額料金は2900円です。
人力で数時間かかる情報収集作業を数分で実行できるGoogle製AI検索機能「Deep Research」が日本語でも利用可能に - GIGAZINE
⇧ なるほど、だが、しかし、
AIが生成したデータセットを次世代の機械学習モデルの学習に使用すると、その出力が汚染される可能性があることを報告する論文が、Natureに掲載される。
コンピューターサイエンス：生成AIのデータで訓練されたAIモデルが崩壊する可能性 | Nature | Nature Portfolio
この研究は、数世代以内にオリジナルのコンテンツが無関係のナンセンスなものに置き換えられてしまうことを示しており、AIモデルの学習に信頼性の高いデータを使用することの重要性を示している。
コンピューターサイエンス：生成AIのデータで訓練されたAIモデルが崩壊する可能性 | Nature | Nature Portfolio
⇧ インターネット上のデータは玉石混合であるので、対策されているのかは気になりますな。
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。
⇧ 適切な情報の取捨選択がAIにできるのか疑問なのだよね...
docker-compose logsでPython標準のloggingライブラリの正常ログ出力されない原因はログレベルの設定か
Docker Composeで稼働したDockerコンテナ内の「Python」の標準ライブラリの「logging」で正常なログが出力されない事象に遭遇し、いろいろ調べたので備忘録として。
結論、
ネット上の情報が錯綜し過ぎていて辛いのだけど、
⇧ いろいろな要因がありますと。
ネットの情報を漁っていたところ、
DEBUG < INFO < WARNING < ERROR < CRITICAL
https://medium.com/nerd-for-tech/python-logging-simplification-e24824a748f9
⇧「Python」の「logging」について整理してくれている方がおられるのだが、「level」の関係がいまいち分からない...
15.7.2. Logging Levels
The numeric values of logging levels are given in the following table. These are primarily of interest if you want to define your own levels, and need them to have specific values relative to the predefined levels. If you define a level with the same numeric value, it overwrites the predefined value; the predefined name is lost.
⇧ どうやら、深刻なエラーになるほど、対応可能な範囲が狭くなっていく模様。
「Python」の「logging」とは関係ないのだが、
⇧ 上図のような感じで、ログ出力の対応範囲が狭まっていくと。
つまり、「logging.level=Error」とかにしていると、
- DEBUG
- INFO
- WARN
のログは出力されないことになるわけだ。
で、
⇧ 上記のように、「logging.baseConfig」の設定で「level=logging.INFO」とか設定していれば、通常のログも出力されるのだが、「level=logging.ERROR」とかにしていると、「logger.info」などは出力されないのである。
そして、今回、エラーの場合しかログを出力しない実装にしていたから仕様通りなのだが、気付くのに時間を要してしまった...
ログが出力されないと、正常に動作しているのかの確認がし辛いよね...
とは言え、実際にシステムが稼働し始めた場合、アプリケーションのログって障害とか発生した場合の原因の究明に必要なのであって、エラーに関するログ以外は必要ないというアプローチは合理的ではある。
クリティカルなシステムであれば、データベースとかで情報を管理していると思いますし...
ログローテーションさせるというアプローチもありますが。
決めの問題というやつですかね。
毎度モヤモヤ感が半端ない…
今回はこのへんで。
