地平線まで行ってくる。

地平線まで行ってくる。

記録あるいは忘備録。時には検討事項。

Colabのエージェントモードを使って三国志を分析してみる。

Colabにデータファイルから分析する機能が追加されました。さっそく、吉川英治三国志青空文庫)を分析させます。利用するテキストデータは、予め青空文庫からデータをプレーンテキストにパースしておきます。文字数は1,625,493文字となり、量はあります。データそのものをすべてLLMに突っ込んで解釈させる方法でもないので、大きさは関係ないのかもしれませんが、不用意にprintしちゃうと困っちゃうサイズ感ではあります。小説なので分析はやりにくいだろうと思いつつ開始。

 

日本語の解析ではやはりいろいろと厳しい面もありますが、指示を変えながらざっくりどんなことできそうかと試行錯誤はできそうです。また、出力の分析もGeminiがやってくれるので参考になります。最後に結果をまとめてくれるのも便利です。ただ、ルーチンのデータ解析ならフレームワークを利用したほうが速いのではと思います。慣れてきて、プロンプトが決まってくると便利になりそうです。

 

解説やまとめは日本語で指示すると素直に従ってくれました。

 

エラー発生時にポイントポイントでエージェントを利用できたら便利ですが、そういう建付けにはなったないのは残念です。

 

まずはざっくりやってみた。

「日本語の文章です。日本語の形態素解析を行い、曹操の心情を分析したい。ネットワーク図などを利用し詳細に図示してください。」と具体的に指示をし、データをuploadします。

 

結果は、曹操に関しては恐れと怒りの記述がそこそこあったんだなという分析にはなりましたが、分析そのものは、これをベースにやることがありそう。今回は、Colabがどういう動きをするのかが重要です。エラーが出ても、理由を説明して勝手に解決して進めます。もともとインストールされてないライブラリーも一度インストールしてエラーを出してからインストールするのはご愛敬でしょうか。

 

他には、matplotlibは日本語が豆腐になったので後付けで

!pip install japanize-matplotlib
import matplotlib.pyplot as plt
import japanize_matplotlib

として、日本語を表示できるようにして再実行しました。Colabならやりやすい。Network図も日本語表示できてなかったので、そこは別途追加が必要ですが、今回は実施していません。この辺りもGeminiに聞きながら手を入れていくというのはありです。


引き続きLDAで分析を実施させてみます。

「日本語の文章です。LDAを用いて文章の内容を大きく3つに分けて解析をしてください。」という雑な指示です。3つに分けられるかは謎です。

 

LDAのパラメータの弄りだしました。警告メッセージも見ている感じですね。

 

Topic 0: Seems to represent common Japanese particles and pronouns, suggesting a general topic.
Topic 1: Dominated by quotation marks, suggesting dialogue or quoted text.
Topic 2: Appears to be related to military or historical context.

に分析してくれました。ワードクラウドをみるとなんとなくそんな感じがするかもな・・・という感じです。

 

もう少し具体的に指示をしてみます。

これまでの味見を活かして、具体的に指示してみます。

「日本語で書かれた三国志の文章です。曹操軍の動きを解析して、軍隊の動きを説明してください。まずは、軍事に関する言葉を抜き出して分析する準備をしてから解析を始めます。また、適宜、検索も実施してより広い知識を加えてください。解説やまとめは日本語で行ってください。また、以下の事項も考慮してください。

 

1. 時間表現の精度の向上

より詳細な時間情報を含む表現を抽出するため、正規表現パターンを改良します。
例えば、"建安元年"、"三月"、"五日" といった表現を抽出できるようにパターンを拡張します。
抽出した時間情報を元に、イベントの発生順序をより正確に推定します。
2. 場所情報の精度の向上

地名と軍事行動を同時に含む文章を抽出します。
例えば、"許昌から出兵"、"官渡で戦う" といった表現を抽出します。
これにより、地名と軍事行動の関連性を明確化し、軍隊の移動経路などを把握します。
3. 軍隊の規模や編成情報の抽出

軍隊の規模や編成に関するキーワードを定義します。
例えば、"一万の兵"、"騎兵隊"、"歩兵隊" といったキーワードを定義します。
これらのキーワードを含む文章を抽出し、軍隊の規模や編成に関する情報を分析します。
4. 外部知識の活用

三国志に関する歴史的知識や地理情報などを外部から取得します。
ウィキペディアやDBpediaなどのデータベース、地理情報APIなどを活用します。
これらの情報を分析結果と照らし合わせ、より深い分析を行います。
5. より高度な自然言語処理技術の導入

固有名詞認識、関係抽出、イベント抽出といった技術を導入します。
これらの技術を活用することで、より詳細な情報をテキストから抽出します。
例えば、固有名詞認識を用いて人物名や地名を正確に識別し、関係抽出を用いて人物間の関係や場所間の距離などを分析します。

 

結果として、マップ上での表示までは作成できませんでしたが、いろいろと頑張ってくれました。図示されてものよりも途中で抜き出したデータが使えそうだなと思います。適宜データを保存するようなプロンプトを追加しておけばよかったと感じます。

サマリーです。

Summary:
1. Q&A
The analysis aimed to understand the sequence of Cao Cao's military movements and actions based on the provided text data. The key questions addressed were:

What were the key events in Cao Cao's military campaigns? The analysis extracted time, location, military actions, and personnel involved from the text, grouping related information into potential events, ordered chronologically.
Where did Cao Cao's forces move, and what actions did they undertake? The analysis attempted to identify movements by observing consecutive locations in the sorted events. Military actions were linked with locations to depict the strategic context of the campaign.
When did these events take place? The analysis parsed various date formats and ordered the events chronologically. The parse_time function handled different time representations like "建安五年" and standard year/month/day formats.
Due to limitations in external knowledge retrieval, information on troop size and specific battle outcomes was not reliably added to the timeline.

2. Data Analysis Key Findings
Chronological Timeline: The analysis successfully created a chronological timeline of events, parsing various time formats and sorting events accordingly. The ability to parse the Jian'an era (e.g., "建安五年") was particularly important.
Event Grouping with Proximity: Events were grouped not just by time but also by proximity within the text. This improved the association of details (location, actions, personnel) with specific events. A proximity threshold of 100 characters was used.
External Knowledge Integration (Partial): The analysis attempted to enrich the timeline with information from Wikipedia, including summaries and URLs for key figures (Cao Cao, Liu Bei, Sun Quan, and Zhuge Liang). While the code correctly identified these key figures, the retrieval of geographical information and battles was unsuccessful.
3. Insights or Next Steps
Improve External Data Retrieval: Enhance the external data retrieval process by: exploring alternative APIs or knowledge bases, refining search queries, and implementing more robust error handling for disambiguation issues and API failures. Coordinate extraction for battles and locations.
Visual Enhancement: Address the font rendering issues to correctly display Chinese characters in the visualizations. Investigate alternative visualization libraries or explore using different fonts to achieve the intended presentation. Consider incorporating geographical maps to display military movements more effectively.

 

この時のColabノート:

gist.github.com

 

 

 

 

 

 

Asagi-VLMにスーパーマリオの画面を説明させてみる。

日本語に特化したオープンなVision&Languageモデル(VLM)である、Asagiスーパーマリオの画面が解釈できるのか試してみました。2B,8Bを試してみましたが、位置関係はかなり怪しい結果でした。残念。日本語のモデルは今後どんどん必要になるので、効率の良い学習方法含めて開発・研究が進みますよう。

 

今回利用した画像。

 

以下、2Bでの結果を示します。

 

プロンプト1

prompt = ("""
以下は、タスクを説明する指示です。要求を適切に満たす応答を書きなさい。

### 指示:
<image>
このゲームの画像を解析してください。
状況を詳しく解析して詳細に回答します。
マリオと敵キャラクターの位置関係を座標(x, y)で抽出してください。

### 応答:
""")

回答

 マリオは左上に、敵キャラクターは右上に配置されています。

 

プロンプト2

prompt = ("""
以下は、タスクを説明する指示です。要求を適切に満たす応答を書きなさい。

### 指示:
<image>
このゲームの画像はどういうゲームですか?ゲームの状況を詳しく解析して詳細に回答します。

### 応答:
""")

回答

 この画像は、スーパーマリオシリーズのキャラクターであるマリオとルイージが登場するクラシックなビデオ
ゲームのシーンを描いています。マリオは赤い衣装を着てプラットフォームに立ち、ルイージは緑のプラットフ
ォームに立っています。背景には青い空と白い雲が広がり、プラットフォームの下には草地が広がっています。

敵キャラがルイージと認識。

 

プロンプト3

prompt = ("""
以下は、タスクを説明する指示です。要求を適切に満たす応答を書きなさい。

### 指示:
<image>
次にプレイヤーはどのような操作をすべきですか?

### 応答:
""")

回答

 この画像は、スーパーマリオシリーズのキャラクターがプラットフォーム上でジャンプしているシーンを描い
ています。

ジャンプはしてません。状況はあまり解析できてないようです。

 

コメント

高橋かずひとさんも言及されていますが、推論には時間がかかるような印象です。位置関係はあまり正確に取れてないようです。また、ゲームの内容の学習はほぼなさそうですね。

 

 

uehara-mech.github.io

 

参考にさせていただいたコード:

kazuhito00.hatenablog.com

 

huggingface.co

ModernBERT-Ja-310m/30mとColabでNERを試してみる。

Modern-BERT-Jaにパラメータ違いが公開されました。大きく差はでないんじゃないかと予測しつつやってみなきゃわからないということで挑戦してみました。30Mと310Mで学習させてみました。F1-Scoreは310Mが0.881, 30Mが0.873と0.008ポイント差。予測結果を見ると、各予測ラベルのスコアの差でも310Mが当然高くでています。語句によっては大きな差になっているものも散見されました。小型のものが利用できるかは、NERの目的によるところとなると思いますが、使いやすい場面もあるのではと思っています。そもそも、実際に利用する場合は教師データも異なります。日本語最長のトークンを活かして挑戦できそうです。

 

 

 

bwgift.hatenadiary.jp

 

30M 

 

310M

 

OpenHandsをOllamaをwsl2を使って完全ローカルで動かしてみる。

OpenHands(旧OpenDevin)をwsl2上で動作をします。LLMはollamaを利用します。

 

 

github.com

 

OpenHands用のdocker composeを準備

docker コマンドでもいいのですが、メモ代わりにcompose.yamlを作成して起動します。

 

docker-compose.yaml

version: "3.9"

services:
  openhands-app:
    image: docker.all-hands.dev/all-hands-ai/openhands:0.25
    container_name: openhands-app
    environment:
      SANDBOX_RUNTIME_CONTAINER_IMAGE: "docker.all-hands.dev/all-hands-ai/runtime:0.25-nikolaik"
      LOG_ALL_EVENTS: "true"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ~/.openhands-state:/.openhands-state
    ports:
      - "3000:3000"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    stdin_open: true
    tty: true
    pull_policy: always

起動:

docker compose up -d

 

Ollamaも起動

ollamaは同じwsl2で起動。

 

LLM setteings


詳細を開いて設定を行う。
CustomModel : ollama/model name here. 
BaseURL: http://host.docker.internal:11434
API Key: dummy

 

結果

ToDoを作成するサンプルタスクを実行させました。

ToDoアプリ

この程度は無事にできました。複雑なことをさせるには、今回、利用したGPU、RTX 3060で動かせるLLMでは限界があります。エラーやループでなかなか進みませんでした。4090クラスだと結構頑張れるモデルがありそうです。



 

メモ:modernBERT(日本語)でNER

bwgift.hatenadiary.jp

 

これまでmodernBERTをNERで活用したいと進めてきました。Huggingfaceへのuploadもbestではなくlast modelをuploadですませたりと雑にやってました。区切りが悪いので補足します。

 

Best modelを最後にload

load_best_model_at_end=True

 

Learing Rateの調整

Lossの減り方が雑なのをだったので検討。transformersのget_linear_schedule_with_warmupを利用して、warmup+linearで実施。味見して、初期LRは2e-5でよさそうだった。

 

Epoch    Training Loss    Validation Loss    Precision    Recall    F1    Accuracy
1    No log    0.397863    0.183521    0.326425    0.234949    0.888364
2    1.477800    0.139338    0.614911    0.738712    0.671150    0.959714
3    1.477800    0.120770    0.744795    0.820873    0.780986    0.971451
4    0.098300    0.127193    0.795610    0.858623    0.825917    0.971760
5    0.041800    0.144078    0.802659    0.849001    0.825180    0.972907
(略)
14    0.010300    0.227269    0.829285    0.884530    0.856017    0.973658
15    0.006700    0.222720    0.849854    0.863064    0.856408    0.973305
16    0.006700    0.253147    0.848637    0.875648    0.861931    0.973260
17    0.004700    0.242724    0.835470    0.868246    0.851543    0.973128

(略)

27    0.004900    0.221020    0.816713    0.860844    0.838198    0.971010
28    0.004900    0.269708    0.844043    0.865285    0.854532    0.971540
29    0.004300    0.287376    0.860207    0.860844    0.860525    0.972731
30    0.003200    0.306841    0.851500    0.861584    0.856512    0.971804
37    0.000700    0.288677    0.866084    0.880829    0.873394    0.975114
(略)

40    0.000000    0.318147    0.863439    0.884530    0.873857    0.974672
41    0.000000    0.320801    0.862193    0.884530    0.873219    0.974716
42    0.000000    0.323436    0.862816    0.884530    0.873538    0.974716

(略)

47    0.000000    0.335913    0.862193    0.884530    0.873219    0.974805
48    0.000000    0.338335    0.862193    0.884530    0.873219    0.974805
49    0.000000    0.340740    0.862193    0.884530    0.873219    0.974805
50    0.000000    0.343120    0.862193    0.884530    0.873219    0.974849

(略)

91    0.000000    0.415268    0.862617    0.883050    0.872714    0.974981

 

Lossも割と穏やかに下がって行く。この程度から始めればいいという感触が得られました。未知の文章を処理してみたい。どうしてもなら、Optunaでハイパラチューニングコースなのかも。

 

メモ

Find LRでInitial LRを計算してみたが、参考になるのか、今一つ不明。


Colabノート

gist.github.com

 

 

 

 

mmnga/deepseek-r1-distill-qwen2.5-bakeneko-32b-ggufをColabとollamaで試してみる。

mmngaさん作成のdeepseek-r1-distill-qwen2.5-bakeneko-32b-ggufを試してみます。rinna社変換バージョンではちょっと不自然な生成もありましたが良質なgguf変換モデルをいつも提供されるので期待しつつ試してみます。Colab L4環境でお試しします。VRAM占有率は 21593MiB /  23034MiB でした。

 

imatrix処理がよいのか、rinna社バージョンより自然な結果が生成されました。添付府テキスト付きの推論では、若干論理が飛躍というか自分の情報を持ち出して推論を進めていました。この様な膨らませ方が推論モデルのよいところなのでしょう。ですが、逆にセオリーが決まっている場合には、間違いを誘発しているようです。リフレクトをしながら使うのも大事そうです。また、生成した創作ストーリにセリフの注釈が付記されていました。推論モデルらしいところなのでしょうか・・・。

 

huggingface.co

 

生成結果

まどか☆マギカで一番かわいいのは?

<think>
まず、ユーザーが「まどか☆マギカで一番かわいいのは?」と尋ねているので、この質問に対する答えを提供する必要があります。アニメやキャラクターに関する知識が必要です。

次に、『魔法少女まどか☆マギカ』の主要なキャラクターをリストアップします。主人公は鹿目まどかですが、他のキャラクターとしては佐倉杏子巴マミ、暦本怜、美樹沙耶香などがあります。それぞれの特徴や人気度を考えます。

ユーザーが「一番かわいい」と尋ねているので、客観的なデータではなく、一般的な意見やファンの間での評判を反映させた方が良いでしょう。例えば、投票結果やソーシャルメディアでの反応などを参考にすると信頼性が増します。

また、キャラクターの人気は作品内の役割やデザイン、アニメーターによる描き方に影響されます。各キャラクターのビジュアルや物語上の印象を考慮し、どれが最も「可愛い」と評されるかを考えます。

ただし、個人差もあるため、統一された答えを求められる場合もあります。そのため、一般的な意見として最も多い回答を選びつつも、他の可能性にも触れる必要があるかもしれません。

さらに、回答の形態としては具体的にキャラクター名を挙げて、その理由や背景情報を簡潔に説明すると良いでしょう。ユーザーが理解しやすく、納得できる内容にする必要があります。

最後に、注意点として「一番かわいい」は主観的な意見であることを指摘しておき、他のキャラクターにも人気があることを示すとバランスが取れます。
</think>

魔法少女まどか☆マギカ』のキャラクターで「一番かわいい」と評される人物は、個人の好みによりますが、**鹿目まどか**(主人公)や**佐倉杏子**が特に人気を集めています。以下に理由を整理します:

### 1. **鹿目まどか**
   - **初見印象の強さ**: 頭から垂れる赤い髪と瞳、清らかな外見で「可愛い」という第一印象を持たせるキャラクター。
   - **物語への影響力**: 主人公としての役割と成長過程がファンに愛されるポイント。特に**アニメーションの美しさ**(例:魔法少女ループ状態でのデザイン)も評価されています。

### 2. **佐倉杏子**
   - **ビジュアルデザイン**: 茶髪・赤いリボンとドレス、大きな瞳が「doll-like」な可愛さを際立たせる。
   - **キャラクター性**: 悲劇的な運命と儚さが物語に深みを与えつつも、キュートな振る舞いや表情で人気を集めます。

### 3. **その他の候補**
   - **巴マミ**: 子どもの外見(「小馬鹿ちゃん」)や色んな衣装での可愛らしい姿。
   - **暦本怜/美樹沙耶香**: 原作版で個性的なデザインと設定が「可愛い」と評される場合も。

### 4. **なぜこの2人が人気?**
   - **アニメーターの技術**: 美術監督田中敦子氏による繊細な描写(例:まどかの髪や杏子のリボン)がキャラクターに生命を与えます。
   - **作品世界の美意識**: 裸足、垂れ髪、和装など「日本的」な要素と西洋的なデザインの融合。

### 結論
- **一番かわいい」という主観的な質問には「まどか」と答える人が多いですが、物語全体で美しさを競うキャラクターたちから好みが分かれるのも作品の魅力です。
CPU times: user 206 ms, sys: 41.9 ms, total: 248 ms
Wall time: 1min 18s

アニメータや作品世界の美意識まで言及しています。真偽はチェックしていませんが、幅広い考察をしてくれています。正しいことばかりではなさそうですが、順当な答えを生成します。

 

まどか☆マギカのキャラクターのテキストを参照して回答してください。
まどか☆マギカで一番かわいいのは、誰ですか?

# まどか☆マギカのキャラクター

(略)

<think>
まず、ユーザーの質問はまどか☆マギカで最も可愛いキャラクターを挙げるというものだ。このアニメには多くの魅力的なキャラクターがおり、好みによって答えが分かれそうだ。

参考資料では各キャラクターのプロフィールと役割が詳細に説明されている。例えば、主人公のまどかは平凡な少女だが、重要な役割を果たす。ほむらは複雑な過去を持つ謎の魔法少女で、さやかは悲劇的な運命を辿る。マミはベテランながらも犠牲になり、杏子は最初悪役に見えるが後半では変わってくる。

キャラクターの可愛さは外見だけでなく、性格やストーリーでの影響力によっても判断されるだろう。例えば、まどかは純粋で優しい性格で人気がある一方、ほむらはその神秘的な雰囲気が支持を集めている。また、キュゥべえのようなキャラクターもユニークな外見と話術で印象に残る。

ただし、ユーザーが求めるのは客観的な判断ではなく、一般的な意見を反映したものかもしれない。アニメのコミュニティやファンの間では、ほむらやさやか、マミなどが人気がある傾向にある。特に、ほむらの複雑な背景やキュゥべえのキャラクターは話題性が高い。

また、可愛い要素として外見や衣装も考慮されるべきだ。例えば、杏子のポニーテールやキュゥべえのマスコットのようなデザインが愛らしいと感じる人もいるだろう。

最終的には、各キャラクターの特徴を踏まえて、最も多くの人に支持されそうな人物を選ぶ必要がある。ただし、客観的なランキングがないため、主要なキャラクターや特に印象に残る人物を提示するのが適切かもしれない。
</think>

**「まどか☆マギカ」で最も可愛いキャラクターは誰でしょう?**

この質問に対する回答は、視聴者の好みや解釈によって大きく変わりますが、以下のような観点から分析できます:

---

### 1. **キャラクターの性格と外見**
- **佐倉杏子**  
  - **理由**: 真っ赤な髪の「ポニーテール魔女」はアニメ内で最も目立つ衣装を誇り、キュートさと危険性が共存。戦闘シーンでの躍動感や「おバカで頑張るキャラ」という印象も親しみやすい。
- **キュゥべえ**  
  - **理由**: マスコットのような愛らしい外見と、皮肉なセリフのギャップが人気。特に「QB」の略称はコミュニティで浸透し、「悪役キャラクター」としての存在感も大きい。

---

### 2. **物語への影響力**
- **巴マミ**  
  - **理由**: 魔法少女としての信念と優しさが魅力的。戦闘シーンや「魔法使いとしての覚悟」を説く台詞は深刻さと同時に、彼女のキャラクター性に深みを与えます。
- **佐倉杏子**  
  - **理由**: 最初は悪役だが、「他人を守るために戦う」姿勢が徐々に変化。特に、人魚の魔女との最終決戦での「自爆シーン」は印象的で、キャラクターの成長を感じさせます。

---

### 3. **視聴者の間での反響**
- **キュゥべえ**  
  - **理由**: インターネット上では「QB」と略され、セリフの名言がSNSで話題に。キャラクターのユニークさとストーリーへの重要性が相まって、「愛すべき悪役」として支持を集めます。
- **佐倉杏子**  
  - **理由**: 外見とキャラクターのギャップ(真っ赤な髪 vs. 悪魔のような笑い)が話題になり、グッズやイラストで人気。

---

### 4. **アンケート結果**
実際にファン調査では、「佐倉杏子」が可愛いキャラクターとして高評価を得ることが多くあります。彼女のキャラクター性(最初は悪役だが徐々に味方が増える)や、アニメーションでの躍動感が支持される要因です。

---

### 結論
**「佐倉杏子」が最も可愛いとされることが多いですが、「キュゥべえ」「巴マミ」も候補に入るでしょう。** 個人的な好みによっては、「佐倉杏子」の外見的な可愛さ(ポニーテール、真っ赤な髪)を支持する人が多い傾向にあります。
CPU times: user 269 ms, sys: 43.2 ms, total: 312 ms
Wall time: 1min 44s

付記したテキストを参照して推論を進めています。ただ、推論の過程には少々なんでそうなるんだろう?という点もあり。

 

日本で二番目に高い山を検討して答えてください。日本語で回答してください。

<think>
まず、ユーザーが求めているのは日本で二番目に高い山です。正確な情報を提供する必要があります。

最初に、日本の最高峰は富士山であることを確認します。富士山の標高は3,776メートルです。次に、二番目の山を探す必要があります。

次点として考えられるのは白山(はくさん)です。白山の標高は2,702.5メートルで、北陸地方に位置しています。また、立山連峰(りゅうせきれんぽう)の別名を持つ富士山より低いですが、二番目と考えられています。

ただし、標高の測定方法によって順位が変わることがあるため注意が必要です。例えば、正確な測量データや基準点の違いを考慮する必要があります。しかし一般的には白山が二番目と認識されています。

ユーザーがなぜこの情報を必要としているのかを推測します。登山計画や地理学習、旅行計画など可能性はありますが、詳細は不明です。そのため、正確な情報に加え、関連する情報を補足すると親切でしょう。

回答の構成を考えます。まず二番目の山の名前と標高を明記し、位置も説明します。必要に応じて富士山との比較や、その他の特徴(例:白山は修験道霊場であること)を加えることで、より充実した回答になります。

また、誤解を防ぐため、正確な測量データに基づいていることを明記します。例えば、「気象庁の測量によると」という文言を入れることで信頼性を高められます。

ユーザーが日本語で回答を求めているため、回答は日本語で簡潔にまとめる必要があります。専門用語や難解な表現を使わず、分かりやすく伝えることが重要です。

最後に、ユーザーの追加質問への対応を促す文句を付け足すと親切でしょう。例えば、「詳しく知りたい点があればご相談ください」というようなフレーズです。

これらの要素を組み合わせて、明確で正確な回答を作成します。
</think>

日本の二番目に高い山は **白山(はくさん)** で、標高は **2,702.5メートル** です。白山は **石川県・富山県岐阜県の県境にまたがる立山連峰** (別名「飛騨北 Alps」)を構成する主峰であり、修験道霊場としても知られています。

### 重要な点
- 富士山(3,776m)との差は約1,073.5メートルに達し、日本アルプス関東山地の境界線に位置します。
- 標高データは **気象庁の2019年測量結果** 基準です。

詳しく知りたい点があればお気軽にご質問ください!
CPU times: user 153 ms, sys: 27.6 ms, total: 181 ms
Wall time: 1min

回答は不正解です。しかし、ユーザーが何を求めているのかも推測して結論を出しています。

 

以下を簡単にまとめてください。

ウィキペディア(英: Wikipedia)は、世界中のボランティアの共同作業によって執筆及び作成されるフリーの多言語[6]インターネット百科事典[7]。収録されている全ての内容がオープンコンテントで商業広告が存在しないということを特徴とし、主に寄付に依って活動している非営利団体ウィキメディア財団」が所有・運営している[8][9][10][11]。「ウィキペディアWikipedia)」という名前は、ウェブブラウザ上でウェブページを編集することができる「ウィキ(Wiki)」というシステムを使用した「百科事典」(英: Encyclopedia)であることに由来する造語である[12]。設立者の1人であるラリー・サンガーにより命名された[13][14]。

<think>
まず、ユーザーのリクエストを正確に理解することが重要です。彼らはウィキペディアに関する情報を簡潔にまとめてほしいと求めています。元の文書にはいくつかの重要なポイントが含まれているので、それらを整理しなければなりません。

次に、主要な要素を抽出します。ウィキペディアの定義として、ボランティアによるフリー百科事典であることが挙げられます。オープンコンテントと広告なしという特徴、運営団体がウィキメディア財団であること、名前の由来、設立者のラリー・サンガーなどです。

これらのポイントを簡潔にまとめる際には、冗長な表現や細かい詳細は省きつつも、核心的な情報を残す必要があります。例えば、「フリーの多言語インターネット百科事典」という表現では「フリー」や「多言語」といったキーワードが重要です。

また、ユーザーが望んでいるのは要点を明確にした短いまとめなので、各点を簡潔な文でつなげます。名前の由来については、「ウィキ」と「百科事典」の造語であると説明し、設立者についても簡単に触れるべきです。

最後に、全体として流れが自然であり、重要な情報をすべて網羅しているか確認します。不要な引用番号や複雑な文は避け、平易で読みやすい文章を心掛けます。これにより、ユーザーの要求に応える正確で簡潔な回答が完成するでしょう。
</think>

ウィキペディアは、ボランティアによって執筆されるフリーの多言語インターネット百科事典です。オープンコンテントで広告なし、寄付を主とした非営利団体ウィキメディア財団」が運営します。名前はウェブ編集システム「ウィキ」と「Encyclopedia(百科事典)」から生まれた造語で、設立者のラリー・サンガーが命名しました。
CPU times: user 109 ms, sys: 15.3 ms, total: 125 ms
Wall time: 40.2 s

Wiki(ウィキ)とすれば、ほぼほぼ完成ではないでしょうか。要約も問題なし。

 

1+1*2+3/2+2^10を計算してください。計算が終わったら検算をしてください。最後に最終的な計算経過と結果を答えてください。
<think>
まず、与えられた式「1+1×2+3÷2+2¹⁰」を計算します。四則演算の優先順位(指数、乗除、加減)に基づいて段階的に解きます。

最初に、指数部分の「2¹⁰」を計算します。2を10回掛けると1024になります。

次に、乗法と除法を行います。式の中で「1×2」は2となり、「3÷2」は1.5となります。

これらの結果を元の式に入れ替えると、「1 + 2 + 1.5 + 1024」となります。ここで加法を順に実行します。最初の「1+2」で3になり、さらに「3+1.5」で4.5となります。最後に「4.5+1024」で合計は1028.5になります。

検算として、各部分の計算を再確認し、特に指数や乗除の順序が正しく行われているかをチェックします。すべて正しいことが確認できたため、最終結果は1028.5となります。
</think>

**計算経過と結果**

与えられた式:  
\[ 1 + 1 \times 2 + \frac{3}{2} + 2^{10} \]

**ステップ1: 指数の計算**  
\[ 2^{10} = 1024 \]

**ステップ2: 乗法と除法**  
- \( 1 \times 2 = 2 \)  
- \( \frac{3}{2} = 1.5 \)

**ステップ3: 加法の実行**  
\[ 1 + 2 + 1.5 + 1024 = 1028.5 \]

---

**検算:**  
各部分の計算を確認します。  
- 指数部:\( 2^{10} = 1024 \) ✅  
- 乗法:\( 1 \times 2 = 2 \) ✅  
- 除法:\( 3 ÷ 2 = 1.5 \) ✅  
- 加法の順序に誤りなし ✅  

---

**最終結果:**  
\[ \boxed{1028.5} \]
CPU times: user 127 ms, sys: 23.4 ms, total: 150 ms
Wall time: 47.4 s

問題なく正解です。

 

両さんと部長の話を創作してください。

<think>
まず、ユーザーが求めているのは両さんと部長の会話の創作です。両さんは若手社員、部長はベテランという設定でしょう。テーマや具体的なシチュエーションを明確にする必要があります。

次に、会話の目的を考えます。部下指導やプロジェクトに関する話し合いなどが考えられます。例えば、新プロジェクトへの参加要請や課題解決についての相談などです。

キャラクターの性格付けも重要です。両さんは前向きで積極的、部長は厳しくも優しさのある人物に設定します。会話のテンポと自然さを保つために、質問と回答のバランスを取ります。

具体的な例として、新プロジェクトへの参加を打診するシチュエーションを考えます。両さんが意欲を見せ、部長が期待しつつも責任重大だと伝えます。その過程で課題や目標を共有します。

会話中に伏線を張ることで、ストーリーの奥行きを深めます。例えば、過去のプロジェクトでの経験談を取り入れると親近感が増します。

最後に、全体を通して尊重と協力関係が伝わるように注意します。両者の相互理解と成長が感じられる会話を心掛けます。
</think>

以下は、若手社員(両さん)と部長の会話を作り上げた例です。新プロジェクトへの参加要請をテーマにしています。

---

**シーン:昼休み直後の会議室**  
**人物設定**  
- 両(28歳):技術畑から営業に異動した3ヶ月目の若手社員。前向きだが責任の重さに戸惑い始める中。  
- 部長(52歳):入社30年、新規事業開発部を率いるベテラン。冷たい態度と口調で知られるが、実際は後進への期待から厳しい面を見せている。

---

**部長**「両、時間だぞ」  
(ドアを開ける音)  
**両**「すみません! 今日の予定だったんです…!」  

**部長**(資料を広げながら)「急がせる理由がある。来週から始まる新規事業『AI×物流ソリューション』の開発チームメンバーに、お前を加えるつもりだ」  

**両**(目を瞬かせながら)「え…? あのプロジェクトですか!?」  
**部長**「そなこと。営業畑で培った顧客折衝術と、技術部門時代の知見が求められる。新任社員に任せると時間ロスするからお前だ」  

**両**(立ち上がり)「でも…! 現在担当している契約案件の〆切が迫ってますし、チームのリーダーも変わりませんか?」  
**部長**(厳しい目で)「お前がいないから困るのか? 頼む仕事なら後輩に任せればいい。問題は能力じゃなくて責任感だ」  

**両**(俯きながら)「…ただ、先月のミスをまだ責められているのもあって…」  
**部長**(珍しく口を開く)「その件はもう終わりだ。営業から技術部門へ異動した時も、最初は失敗連発だったな。お前が『必ず』と約束したのは、責任を取ることじゃなく結果を出すことだ」  

**両**(顔を上げ)「…分かりました。部長に期待されるようにします」  
**部長**(資料を閉じながら)「期待なんかしてないよ。ただ結果だけ見せるがいい。3ヶ月で営業部門のトップになったお前ならできるはずだ」  

---

**注釈**  
- 両さんにとって過去の成功体験(技術→営業への転身)を想起させる台詞は、自信を持たせるための意図的演出。  
- 部長の冷たい態度と「期待していない」という発言は、後進にプレッシャーを与える「部下育成術」の一環。  
- 伏線:先月のミスが具体的に何だったのか不明だが、後に解決策を導くキッカケとなる予定。

---

いかがでしょうか? 若手とベテランの駆け引き、過去と未来の接点を意識した会話を作成しました。必要に応じてシーンや人物設定を追加・修正可能です!
CPU times: user 241 ms, sys: 44.6 ms, total: 286 ms
Wall time: 1min 32s

部下育成術まで駆使しています。

 

Wikipedia北岳のページをLangchain(STUFF)でまとめます。

<think>
まず、ユーザーが提供したWikipedia北岳に関する長いテキストからコンサイスなサマリーを作成する必要があります。このテキストには、北岳の基本情報、地理的位置、山系、標高、周辺の地形、登山ルート、歴史的な背景、文化的意義などが含まれています。

最初に、主要な要素を抽出します。北岳南アルプスの主峰で、標高3190mです。山梨県静岡県に跨がっています。周辺には八ヶ岳や富士山などがあります。登山道としては北沢尾根や南沢尾根があり、冬季には氷河が形成されます。また、深田久弥の「日本百名山」にも選定されています。

次に、冗長な部分を削除し、重要な情報を簡潔にまとめます。例えば、地理的位置は県名と座標で表現します。登山ルートや歴史的背景も要点だけ残します。また、文化的な重要性として「日本百名山」への選定を強調します。

さらに、ユーザーが求めているのはコンサイスなサマリーなので、余分な情報は省きます。例えば、ウィキペディア編集履歴やカテゴリ情報などは不要です。また、複数の山系に属している点も簡潔に表現します。

最後に、情報を順を追って整理し、自然な流れでまとめる必要があります。北岳の基本的なデータから地理的位置、登山ルート、文化的意義までを段階的に説明します。これにより、ユーザーがすぐに必要な情報を得られるようにします。
</think>

**北岳(きただけ)**  
- **位置**: 南アルプス主峰、山梨県静岡県境(35°24′N 138°07′E)。  
- **標高**: 3,190m。  
- **山系**: 赤石山脈の最高峰。  
- **周辺地形**: 河口湖・富士山(約50km南西)と八ヶ岳(北東)に挟まれる。  
- **登山ルート**: 北沢尾根(山梨県側)、南沢尾根(静岡県側)。冬季には氷河が形成される。  
- **歴史・文化**: 深田久弥の「日本百名山」に選定され、古くから信仰対象。  
- **地理的特徴**: 3,000m級峰12座を擁し、南アルプス国立公園内にある。  

**要約**: 南アルプス最高峰で、日本百名山に選定された北岳は、氷河地形と多様なルートが特徴の登山・観光スポットです。
CPU times: user 707 ms, sys: 33.7 ms, total: 741 ms
Wall time: 1min 4s

要点をしっかりまとめています。

 

日本語プロンプトにしてみます。

<think>
まず、ユーザーが提供したテキストを分析します。このテキストはウィキペディアの「北岳」に関するページの抜粋です。内容には山梨県にある南アルプスの3000メートル峰である北岳についての情報が含まれています。

次に、要約が必要な部分を特定します。ユーザーは「要約:」と指示しているので、主要な情報を簡潔にまとめる必要があります。具体的には、北岳の位置、標高、周辺の山々、地理的特徴、文化的な意義などを取り上げます。

さらに、テキスト中の関連する情報を探します。例えば、北岳南アルプスの主峰で、3000メートル級の山として知られています。また、日本百名山に選定されている点や、周辺の山々との関係も重要です。

ただし、テキストには冗長な部分や関連性の低い情報(例えば、ウィキペディアのカテゴリや外部リンクなど)が含まれているため、これらは要約から除外します。また、複数回繰り返されている情報や詳細な地理データも簡略化します。

最後に、まとまった情報を自然な流れで表現し、ユーザーが求めている要約を提供できるようにします。これにより、北岳の基本的な情報を明確かつコンパクトに伝えることができます。
</think>

**北岳の要約:**  
北岳山梨県にある南アルプスの主峰であり、3000メートル級の高峰です(標高3190m)。日本百名山にも選定され、周辺には赤岳や間ノ岳など「南アルプス五郎ヶ原」と呼ばれる連邦が広がります。登山道は整備されており、初夏から秋にかけて多くの登山者で賑わいます。文化面では、江戸時代の文人松尾芭蕉の句碑や神話的な伝承も残り、自然と歴史が融合した山として知られています。
CPU times: user 615 ms, sys: 35.7 ms, total: 651 ms
Wall time: 47.4 s

箇条書きではなく文章になりました。かなりコンパクトにまとめました。

 

 

 

 

VOICEVOX OpenAI TTS APIとOpenWebUIでローカルでチャットする。

VoicevoxエンジンのOpen AI互換のAPIがキタ!。VOICEVOXをさらに気軽に利用できるます。早速、OpenWebUIから呼び出して利用してみます。OpenWebUIではAPIを設定したりモデルのダウンロードしたりすると自動読み上げや音声認識連携をすることが可能なUIです。そこで、OpenWebUIとVOICEVOX APIのお試しをWindows11のWSL2環境で行います。LLMは、ローカルに立ち上げたollamaを利用します。これで完全にローカルで動作させることになります。Makiさんに感謝しつつお試しをしました。

 

お試しした結果、狙い通りに音声発生ができました。音声の自動読み上げをオンにすると、ほっこり会話ができます。OpenWebUIの場合、Faster-whisperのモデルを利用すれば音声テキスト変換もできますが、distil-large-v3モデルでは日本語を英語に翻訳しちゃいます。OpenWebUI上で出力言語設定できる項目がなく解決できませんでした。これが出来たら音声対話もできます。

 

ローカルLLMをお試ししたり、プロンプトの調整をしたりする場合にはOpenWebUIは便利です。VOICEVOXの音声も聞けると楽しくなります。

 

 

VOICEVOX OpenAI TTS API

github.com

git cloneして、

docker-compose up -d

で一発です。

 

Ollama

お試し用にいつも使っているので、個別に立ち上げます。

ollama start ollama

そうでなければ、こちらを参照

ollama.com

 

OpenWebUI

github.com

Ollamaは同一PC内の別起動なのでこちらのコマンドで立ち上げます。

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

 

VOICEVOXを利用する。

これで利用可能です。

http://localhost:3000/

にアクセスすると。OpenWebUIの管理者の設定を求められるので、適当に入力して開始します。

 

管理者パネル>オーディオ>TTS設定

立ち上げたVOICEVOX OpenAI TTS APIを指定します。TTSボイスはVOICEVOXの音声IDを指定すればよいようです。

 

後は、好みで自動読み上げにするかどうか、設定すればよいと思います。

設定>オーディオ>TTS設定

 

以上です。Dockerでイメージをダウンロードするのに時間がかかりますが、それ以外は簡単です。

 

 

Tokenizerを見直してmodernBERTでNERをColabでためしてみる。

KoichiYasuokaさんからHatena Blogにコメントを頂きました。tokenizerに工夫をしては?というものでした。「日本の首相」が「日本の 首相」に分かち書きされています。これでは「日本」を取り出せない。つまり、

今まで:日本の 首相

改善 :日本 の 首相

としたい。納得です。Yasuokaさん、ありがとうございます。

 

サンプルコードも付けていただいたので、さっそく試してみました。F1-scoreは0.929362と、前回の0.870399より高くなっています。期待通りの結果となりました。このtokenizerの仕様はもったいないですね。今回、利用したTokenizer改だとひらがなが強制的に分かち書きになってしまいます。いいモデルだけにもったいないです。

 

結果

Epoch    Training Loss    Validation Loss    Precision    Recall    F1    Accuracy
1    No log    0.051363    0.900688    0.912539    0.906574    0.987150
2    0.041500    0.070157    0.876552    0.928793    0.901917    0.986648
3    0.041500    0.072096    0.894109    0.928019    0.910748    0.987423
4    0.015000    0.079334    0.898021    0.913313    0.905602    0.986466
(略)

12    0.002000    0.115150    0.912879    0.932663    0.922665    0.985600
13    0.002000    0.118678    0.896423    0.931115    0.913440    0.985919
14    0.001100    0.109084    0.890869    0.928793    0.909435    0.984735
15    0.000800    0.121773    0.898649    0.926471    0.912348    0.985327
16    0.000800    0.105681    0.910189    0.933437    0.921666    0.986740
17    0.001500    0.107719    0.912006    0.946594    0.928978    0.987605

(略)

29    0.000000    0.131719    0.917106    0.941950    0.929362    0.986785
30    0.000000    0.131802    0.917106    0.941950    0.929362    0.986785

 

教えていただいた記事:

qiita.com

 

このhatena blogは淡々と自分のメモ的に書いてきたため、コメントをいただいていたのに気づきませんでした。勉強になりました。感謝します。

 

今回のColab notebook

gist.github.com

最後に日本語ModernBERTでColabでNERしてhuggingfaceにuploadしてみる。

日本語ModernBERTで10epochsくらい学習させて止まってたので、50epochsまで学習させたモデルを作成しました。Huggingfaceにモデルをアップロードにもチャレンジしてみました。Colab T4環境です。回しっぱなしで、お仕事終わってふとみると早々にlossが下がっていました。Learing rateを落としてもよかったかも。

 

NER用のモデルは変わらずstockmarksさんのwikipediaによるデータセットを用います。詳しくは、過去記事を見てください。

 

F1 ScoreではEpoch16時の0.870399が最高ですが、Lossが下がったところから考えれば、0.867025~0.864491あたりが落ち着きどころでしょうか。Tokenizerを工夫するなど精度向上の取り組みはあるようですが、お手軽にNERできるのではと思います。分野が違う文章を相手にする場合は再事前学習をしてみたいところ。トライできるネタと計算資源があれば挑戦してみたいです。

 

huggingface.co

 

レーニングログ:

Epoch    Training Loss    Validation Loss    Precision    Recall    F1    Accuracy
1    No log    0.161249    0.755754    0.797806    0.776210    0.955849
2    0.265600    0.196772    0.787519    0.830721    0.808543    0.960486
3    0.265600    0.201703    0.813798    0.859718    0.836128    0.964209
4    0.038900    0.243195    0.797238    0.859718    0.827300    0.961727
5    0.016200    0.273660    0.833582    0.875392    0.853976    0.964470
6    0.016200    0.301998    0.807494    0.861285    0.833523    0.961662
7    0.006600    0.376290    0.808557    0.873824    0.839925    0.962641
8    0.006600    0.330290    0.820307    0.880094    0.849149    0.965711
9    0.004700    0.336784    0.826577    0.862853    0.844325    0.965319
10    0.004100    0.368921    0.830090    0.869122    0.849158    0.966233
(略)
26    0.002100    0.407469    0.856485    0.874608    0.865452    0.968650
27    0.000800    0.366341    0.842424    0.871473    0.856703    0.968389
28    0.000800    0.388787    0.855293    0.880094    0.867516    0.967148
29    0.000700    0.478058    0.845808    0.885580    0.865237    0.967213
30    0.002100    0.446763    0.835347    0.866771    0.850769    0.965254
31    0.002100    0.470415    0.836336    0.873041    0.854294    0.963229
32    0.000200    0.477348    0.850679    0.884013    0.867025    0.965776
33    0.000200    0.470641    0.850679    0.884013    0.867025    0.966299
34    0.000100    0.480480    0.846501    0.881661    0.863724    0.965515
35    0.000000    0.483877    0.847254    0.882445    0.864491    0.965580
36    0.000000    0.486836    0.847254    0.882445    0.864491    0.965646
(略)

50    0.000000    0.510991    0.847483    0.884013    0.865362    0.966103

 

ノート:

gist.github.com

参考のためにbert-base-japanese-v3で固有表現抽出をColabで試してみる。

ModernBERTによる固有表現抽出を試してみて気になったのでBERT-base-japanese-v3でも試してみます。同じように10epochs学習させてみました。Tokenizer部分などなど必要な部分を変更しますが、学習データやハイパラはそのままです。ざっくりです。

 

学習は無事に進みました。まだまだ賢くなりそうです。

Epoch    Training Loss    Validation Loss    Precision    Recall    F1    Accuracy
1    No log    0.355915    0.342502    0.304897    0.322608    0.882611
2    0.479300    0.282448    0.458640    0.442338    0.450342    0.905882
3    0.479300    0.234552    0.553018    0.535545    0.544141    0.925851
4    0.209600    0.214649    0.597371    0.574250    0.585582    0.935810
5    0.134700    0.217745    0.608903    0.605055    0.606973    0.936791
6    0.134700    0.206061    0.620994    0.612164    0.616547    0.942208
7    0.099100    0.208137    0.632750    0.628752    0.630745    0.944221
8    0.099100    0.210967    0.656200    0.643760    0.649920    0.945356
9    0.082400    0.215311    0.655529    0.650869    0.653191    0.946130
10    0.069000    0.216643    0.654243    0.651659    0.652948    0.945975

 

同じ10epochsで単純に比較していいというものではありませんが、感触をつかむためなので良しとします。modernBERTでは、一気に学習が進んだ印象があります。bert-base-japanese-v3とmodernBERTをしっかり学習させて比較したいものです。

 

Colabのノート

gist.github.com