来るべきAIプロンプトによるモデリング実装のために、とりあえず勉強しなければ、
と思っていました。
来るべきAIプロンプトによるモデリング実装のために、とりあえず勉強しなければ、
と思っていました。
久保先生のビデオ。面白いです。
NotebookLMを使って、男女の会話を自動生成したようです。
これ凄いですね。自然すぎて、ビックリです。
【1番使える‼️】無料のGoogle最強AI「NotebookLM」に日本語版音声Audio Overview機能が爆誕!徹底解説
スケジュールナースで、どうすれば良いか分からないときは、リソースを指定して、NotebookLM化しておくと、ヒントになると思います。スケジュールナースは、日々アップデートしているのであまり古い情報は見ないようにした方がよいでしょう。(ハルシネーション対策)
リソースの検索先を示しておきます。
本ブログ (スケジュールナースⅢ以降・2021年以降)
しかし、どんなに情報整理しても、分からない制約が存在する可能性はあります。ありきたりのよくある制約については、解る可能性がありますが、そうではない制約もあるかもしれません。その場合は、サポートをご活用ください。
モデリングは、私自身悩むこともまれではありません。看護師・介護士関連では、ほぼ定型的な処理ですので、悩むことはないのですが、新規の他業種プロジェクトでは、本当に悩むことがあります。お客さま自身が仕様を分かっていないことがあること、にも起因していると思いますが、それだけではなく、どういうモデリングをしたら上手くそしてメンテナンスが容易なプロジェクトになるかというのは、試行錯誤の部分が多々ある、ということでもあります。私自身・そしてお客さまもよく分かっていない、そうした問題は、依然として存在し、AIから最も遠い領域であると思います。
消えるプログラマ、残るソフトウェア開発者 と言われているように、お客さまとの開発作業が含まれている分野が最後は残ると思います。
最近のサポートにおいて、ZOOMは必須で、多いときは週に4回位こなします。ZOOMで、お客さまのご質問に答えたり、その場でご要求を実装したりします。実装するのは、私ではなくお客さまPCを共有して、私の指示を基にお客さまのスケジュールナース上で実装していきます。そうするのは時間がかかるのですが、少しでも覚えて頂くことを目的としてお客さまご自身で手を動かして頂くことを行っています。しかし、その場でやって頂くのは、定型処理であり、ありふれた制約であることが殆どです。
で、思ったことですが、それを私の代わりにAIにやらせるには、ちょっとハードルが高すぎるということです。そもそもGUIを直接に弄るのは難しい、そこでRPAツールを使えばどう?という発想が生まれてきます。
一方、何かスケジュールナース上で、看護研究で、勤務パターンによる急な欠勤者による影響度の調査、というテーマがあったとしましょう。この場合、パラメータを変えて大量の求解処理の必要があります。それをいちいち手で行うのはやってられない、RPAツールで出来ないか?という発想があると思います。
市井のツール、Power Automateを少し弄ってみたのですが、例えば特定の予定セルを操作するのは、とてもつもなく面倒で遅いということです。これは、外部からアプリの中身は分からないので、仕方がないということだと思います。
ならば、ツールに頼るのではなく、スケジュールナース自身で、スケジュールナースGUIを直接プログラミング言語で操作できるライブラリがあれば、その目的に叶うことになります。現状は、Pythonで制約処理と、ポスト処理を各々別プロセスで行わせていますが、それとは別に、Pythonで、GUIを操作できるようにしたいと思います。いわば、RPAツールの内製化です。
夢は、日本語で指示すると、例えば「遅番を分けて!」と指示すると遅番シフトを分けて、自動的に遅番⇒遅番集合にしてくれる、みたいな定型処理・ありきたりの処理の自動化を実現させることです。モデリング的発想だと、一気にモデル化しようとするから訳がわからなくなりますが、一つ一つの制約を実装・変更・追加・確認しながら組み込んで行ければ、人間と対話しながら人間の理解できるペースで実装できる、というところが、モデリングコンペティションのそれとは実際的に違います。
そのためには、やはりGUIとの橋渡し部分で、PythonでGUIを操れるようにする必要がある、ということです。
現状は、NSP問題の解決に注力していて余力がないのですが、来期以降取り組みたいテーマです。全てのNSP問題の解決は勿論ですが、市井のモデリングをAIと対話しながら出来るようになって、初めてスケジュールナースが完成する と思います。
Ans.
解を見ると最大夜勤回数設定の多い方が、夜勤間隔エラーを生じています。
以上です。
<Notes>
一般に、予定が入力されていない状態(ブランク予定)よりUBが良くなることはありません。制約を追加変更したときは、必ずブランク予定で求解し、UB==0を確認しましょう。
もしも、UB==0になっていなかったのなら、原因を解析しリーズナブルなエラーであるかどうかを見極めるようにしましょう。
Ans.
ペア制約AならばBで実装します。
仕様的には、
■今月の毎日について、夜勤専門スタッフが1名以上入りならば、遅出が3名以上
■今月の毎日について、夜勤専門スタッフが1名以上明けならば、早出が2名以上
となります。演算子「または」は、1名以上(≧1) と同じ意味になります。
以上で実装終了です。
<Notes>
この制約も、Default仕様に対する特殊ケースなので、矛盾しません。書き連ねることが出来ます。
ペア集合の不等式制約結果は、黄色・赤色マーキングが現在出来ません。要改善アイテムとしてリストしています。