地平線まで行ってくる。

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

メモ:RAGのハイブリッド検索を構築してみる

RAGのハイブリット検索を試してみます。ハイブリットということで複数の検索方法で検索した結果をRAGで利用するというものです。Langchainでは、multiple retrieversとして、EmsambleRetrieverを使った実装が紹介されています。

 

python.langchain.com

 

ベクトル検索とキーワード検索を組み合わせたものが、多いようです。密なベクトルと疎なベクトルの組み合わせです。RAGでは、ベクトル検索が主力のようですが、キーワード検索もいろいろな利点があります。例えば「RAGって何?」という問いかけの場合は、単純に「RAG」というキーワード検索の方がヒットするかもしれません。実際に、検索していてもキーワード検索の方が望む結果になったり、ベクトル検索の方が望む結果になったりします。どちらを利用するかといった戦略は、結果をみながら使い分けているのがヒトによる検索手法ではないでしょうか。

 

RAGにおけるハイブリット検索は当初から検討・実装されていました。今更やるのか案件です。サンプル見ながら実装するにしても、日本語の実装の場合は形態素解析を伴います。実際に利用するには、ベクトルデータの永続化くらいは考慮しないと実用に耐えません。それだけでは寂しいので、ハイブリット検索とキーワード検索のウェイト調整に加えて、それを動的に用いる実装を簡単に行いました。

 

手軽に日本語のテキストのデータを永続化(保存)したHybrid retrieverが欲しかったので、お勉強がてら実装をGamini君やCopilotのアシストで実装してみました。小規模のRAGなら利用には耐えられるのではと思います。

 

他の方が高度に実装されているだろうと思いますが、やってみることに(自己満足的)意義があります(笑)

 

盛り込む機能:

- 検索戦略の追加・重み調整: ハイブリット検索の戦略関数や重みを決定できるようにした。
- HybridRetrieverとして単体でも利用可能にして、既存のベクトル/BM25リトリーバーと組み合わせて使います。
- キーワード検索には、SudachiPyによる形態素解析とBM25を組み合わせます。

- streamlitを使った簡単なUIでお試しができる。

 

おいてきぼりの機能:

- キーワード検索のデータの状態保存はpickleを使っています。大規模なデータの取り扱いになると、語彙数が増えるとメモリ不足になるかも。

 

ちゃんと実装するなら:

 - elasticsearchを使って、キーワード検索とベクトル検索を実装する。

 

できたもの:

github.com

 

 

bartowski/mistralai_Magistral-Small-2506-GGUFをollamaとColabでためしてみる。

Mistral AIの小型モデルをollamaで試してみます。ColabのL4環境で試します。VRAM占有率は15525MiB /  23034MiBでした。

 

日本語の出力もしっかりです。英語が混じりになることもわずかにありますが、GUFFファイル作成時に日本語チューニングがしっかりすれば減るんじゃないか。また、参照文章を与えて回答させると情報を付け加えはしましたが、それなりに整合はしていました。総じて癖は多い方と感じました。推論プロセスを積極的に試せてないという前提で、同サイズのモデルより性能が突出している印象はありません。Mistral AI初の推論モデルとのことで、推論の積極的お試しは後日にとなりそうです。

 

mistral.ai

 

huggingface.co

huggingface.co

 

生成例:

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

まどか☆マギカ」シリーズで「一番かわいい」は、個人によって意見が分かれるでしょう!しかし、多くのファンに愛されてきたキャラクターをいくつか紹介します。参考になれば幸いです!

1. **新井美緒 (きんぎょ)**
   - 赤毛がトレードマークの元気いっぱいな少女。優しい性格と「きんぎょ」の愛称で親しまれ、無邪気さが魅力です。

2. **鶴宮千明**
   - 眼鏡をかけたクールな印象の美人。実際は天然ボケな一面もあり、矛盾する魅力が人気です。

3. **佐倉みき**
   - 双馬尾の活発な少女。強い正義感と「おにーさん」愛で知られ、ファンを笑わせるシーンも多いです。

4. **巴マドカ**
   - マドカ本人(通常時)はおっとり系の優等生。魔法少女として成長する過程が感動的で、可愛さを実感します。

5. **ななせ(第2期・劇場版の新キャラ)**
   - 後期に加わった謎めいた少女。その正体と成長が話題になりました。

**人気投票やアンケートで上位だったキャラクター**は、美緒と千明です。特に美緒は「まどか☆マギカ」のマスコット的存在として愛されていますが、**「自分にとって一番かわいい子」**を探すのも楽しいのでは? (^▽^)/
CPU times: user 75.7 ms, sys: 11 ms, total: 86.6 ms
Wall time: 25.5 s

どんな作品なのか気になりますね。

 

 

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

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

(略)

まどか☆マギカ』における「一番かわいらしさ」は、キャラメカ的な要素や物語の展開によって多様に解釈されますが、特に以下の点から**「暁美 ほむら」**が注目を集める根拠があります。

### 1. **外見と声優の魅力**
   - ほむらは、**「不思議な雰囲気」と「愛くるしさ」**の化身。黄緑色の髪と瞳、無邪気そうな表情が特徴で、初見から親近感を与えます。
   - 声優の**斎藤千和さん**は、幼い高音と柔らかいトーンを使い分け、ほむらの「時空を超える孤独」と「まどかに対する無垢な想い」を表現しています。

### 2. **性格と内面のコンtraste**
   - **表向きは天然ボケ**で他愛のない言動もありますが、実は過去の繰り返し(やり直し)の果てに到達した「最強の魔法少女」という悲壮な背景を持っています。
   - この「表面と内面のギャップ」が、 fans には「守ってあげたくなる」という感情を喚起します。

### 3. **ファンからの支持**
   - 公式アンケートやSNS上では、**「ほむほむ」**の愛称で親しまれ、2次創作(同人・コスプレ)でも人気です。
   - 特に**「時空を変えるために孤独に戦う姿」**が、物語の核心的なテーマと深く結びつき、感情移入されやすい点も強みです。

### 4. **他のキャラとの比較**
   - **さやか**:美しい容貌と曲折に満ちた人生が「悲劇のヒロイン」として支持される反面、ほむらの「単純で純粋な魅力」は対照的です。
   - **マミ**:ベテラン魔法少女としてのカリスマ性がありますが、ほむらの「未来を背負った子どもっぽさ」と比べると、年齢相応の重圧感が感じられます。

### 5. **エピソード・名場面**
   - 第12話で「まどかを救うために時空を変える」という行動は、その純粋さと犠牲的な愛情が象徴されています。
   - 「**『魔法少女』の真実を知りながらも前向きに生きる姿**」が、視聴者に希望や勇気を与える要素にもなっています。

### 結論
「かわいさ」は主観的ですが、**ほむらは「外見の愛らしい雰囲気」「複雑な内面とのギャップ」「 Fan への深い影響力」**の3点で突出しています。ただし、個人的に**「マミやさやか」が好み**という方も多く、キャラの魅力は多様です。
> 「一番かわいいのは、誰か?」と問うなら、**「ほむらの純粋さと悲壮感を simultaneously 表現する存在そのもの」**という答えになるでしょう。
CPU times: user 168 ms, sys: 19.6 ms, total: 187 ms
Wall time: 57.7 s

与えてない情報もありますが、ますますでしょうか。

 

 

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

日本で2番目に高い山は、北岳(きただけ)です。

- **標高**:3,190メートル(主峰・剣が峰)
- **位置**:甲斐路山塊の最高峰。長野県と山梨県の境界に位置し、南アルプスに属します。
- **特徴**:白根山間ノ岳と並び、南アルプスを代表する山で、登山やハイキングの人気スポットです。

1位の富士山(3,776m)に次ぐ高さを誇り、日本三百名山にも選ばれています。
CPU times: user 37.7 ms, sys: 421 µs, total: 38.1 ms
Wall time: 10.2 s

Wikipediaのまとめっぽいですね。

 

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

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

**ウィキペディアの簡単なまとめ**

- **概要**: 世界中のボランティアが共同で作成・更新する無料の多言語百科事典。全ての内容は無料で利用可能で、広告なし。
- **運営**: 非営利団体ウィキメディア財団」が所有・運営(主に寄付で資金調達)。
- **特徴**:
  - どなたでも編集可能な「ウィキシステム」を採用。
  - 「Wiki(ウェブ上の共同作成ツール)」と「Encyclopedia(百科事典)」の合成語が由来。
  - 設立者ラリー・サンガーが命名

簡潔に言えば、**「誰でも編集できる無料百科事典」**です。
CPU times: user 46 ms, sys: 2.95 ms, total: 49 ms
Wall time: 13.1 s

特徴あるまとめですが、問題なくまとめています。

 

1+1*2+3/2+2^10を計算してください。計算が終わったら検算をしてください。最後に最終的な計算経過と結果を答えてください。

さぁ、一緒に計算していきましょう!以下の式を順番に解いていきます:

\[ 1 + 1 \times 2 + 3 / 2 + 2^{10} \]

### 計算手順:
1. **括弧や指数が無い場合、優先して「×」と「÷」を計算**します。
   - \(1 \times 2 = 2\)
   - \(3 / 2 = 1.5\)

   現在の式は、\(1 + 2 + 1.5 + 2^{10}\) になります。

2. **次に「指数(^)」を計算**します。
   - \(2^{10} = 1024\)

   現在の式は、\(1 + 2 + 1.5 + 1024\) になります。

3. **最後に「+」を順番に左から右へ計算**します。
   - \(1 + 2 = 3\)
   - \(3 + 1.5 = 4.5\)
   - \(4.5 + 1024 = 1028.5\)

### 検算:
- 和を足し直して確認します。
  \[
  1 + 2 + 1.5 + 1024 = (1 + 2) + (1.5 + 1024) = 3 + 1025.5 = 1028.5
  \]
- 正しく計算できています。

### 最終的な結果:
\[
\boxed{1028.5}
\]
CPU times: user 76.2 ms, sys: 7.32 ms, total: 83.6 ms
Wall time: 24.5 s

これは卒なく正解です。

 

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

 

**タイトル: 部署移動の提案**

【場面】会議室。机上に資料が広げられたまま、二人は真剣な表情で向き合っている。

---

**部長**: 「両さん、この度の業績低下の原因について、改善策を急いで考える必要がある。君の意見を聞かせてもらおう」

**両さん**: 「はい。現状では主力商品の需要が鈍っておりますが、新規市場への参入も検討すべきかと。特に海外進出は今後5年で20%の成長が見込まれる分野です」

**部長**: 「それは面白い提案だ。しかし予算と人員の問題がある。現行事業の維持も必要なため、資源配分の調整を徹底しなければならない」

**両さん**: 「承知しております。現行プロジェクトは最小限の人員で回す形にした上で、新規チームを立ち上げる提案です。初期投資は300万円程度と見込んでいますが、2年目には黒字化する可能性があります」

**部長**: 机上の数値を指差して、「資料によれば、競合他社の動向も速やかだ。先手を打つためには今すぐ準備に入る必要があるな」

**両さん**: 「その通りです。既に調査チームが現地視察を始めております。来週までには報告書をまとめ、予算の承認を得て動き出せれば最適です」

**部長**: (腕組みをして考え込む)「……では、まずは管理職会議で提案しよう。ただし、リスク管理には特に注意することだ」

**両さん**: 「了解しました。全ての可能性を検討し、最適な形で進めます」

(二人は握手を交わす)

---

**エピローグ**
この会話をきっかけに、社内で「海外戦略プロジェクト」が立ち上げられ、3年後には新市場での売上高は前年比25%増加。部長も両さんも功労者として表彰されることになった。

(フィクションです)
CPU times: user 104 ms, sys: 15.2 ms, total: 119 ms
Wall time: 35.1 s

エピローグまでついた生成は初めてかも・・・。

 

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

The **Kitadake (北岳)** is the second-highest peak in Japan, located in the Akaishi Mountains (Southern Alps) of Yamanashi Prefecture. Standing at 3,190 meters, it is part of the **Japanese 100 Famous Mountains** and **New 100 Famous Mountains**, known for its rugged terrain and challenging climbing routes.

### Key Features:
- **Geography**: Part of the **Minami-Alps National Park**, surrounded by steep cliffs and alpine vegetation.
- **Climbing**: Popular routes include the **Nakano Route (中ノ道)** and **Kita Route (北ルート)**, with technical sections requiring rock climbing skills.
- **Flora/Fauna**: Home to rare high-altitude plants like **Kitadake-sou (キタダケソウ)** and alpine wildlife.
- **Access**: Nearest town is **Minami-Alps City**, with trailheads accessible via bus or car.

### Cultural Significance:
- Featured in literature by **Hyotaro Hirano** and **Deepda Kuroda**.
- A symbol of Japan’s alpine challenges, often compared to the **Northern Alps**.

For detailed maps, weather forecasts, and climbing permits, visit [Yamanashi Prefecture’s official site](https://www.yamanashi-kankou.jp/).

*(Note: External links may require updates; verify before use.)*

---
**Categories**: Yamanashi Mountains | Japanese 100 Famous Mountains | Alpine Climbing
**Coordinates**: [36.2589°N, 137.945°E](https://www.openstreetmap.org/relation/123456) *(example; replace with actual OSM link)*

*(Text adapted from Wikipedia under CC-BY-SA license.)*
CPU times: user 676 ms, sys: 23.4 ms, total: 700 ms
Wall time: 32.2 s

英語になりましたが、位置情報を入れているのは珍しいかも。

 

日本語のプロンプトにしてためします。

北岳は、日本の山で、標高3,190メートルの高峰です。南アルプスに位置し、山梨県南アルプス市に属しています。日本百名山の一つとして知られ、高山植物キタダケソウ」が自生することで有名です。登山ルートや天気予報、地図情報などの外部リンクも提供されており、詳細な情報を得ることができます。
CPU times: user 485 ms, sys: 14.5 ms, total: 499 ms
Wall time: 14.4 s

かなりコンパクトなまとめです。

 

寿限無とは?

寿限無(じゅげむ)」は、平安時代後期の12世紀初頭に成立したとされる日本の長歌の題名です。この詞書(しよう)には、当時の貴族や武士が関与していたと考えられる高度な文芸的・文化的活動の一端がうかがえます。

寿限無の概要
内容

詞書は「寿限無(じゅげむ)」で始まり、 subsequently、各節に「せめて」や「しなさる」「つげぬる」などの語句が繰り返される。このリズミカルな構成は、現代のラップやシンガーソングライターの作詞スタイルと比較され、創造性と技巧性が高いと評価されています。
具体的な内容は「お互いに長生きを願い合う」という恋愛的な文脈や、風景描写、季節の移り変わりなどが詠まれており、日本の古典文学の代表作として知られています。
文化的意義

詞書は「源氏物語」などの平安文学と並び、日本の古典的な文芸形式を代表するものとして重要視されています。現代でも、そのリズムや表現方法が現代詩や音楽に影響を与えている事例もあります。
この作品は「万葉集」などと共に日本最古の歌集「古今和歌集」の成立と関連付けられることがあり、平安時代の貴族社会の価値観が反映されていると解釈されています。
現代での影響

寿限無のリズミカルな節回しは、現代のポップスやラップ曲にインスピレーションを与え、日本国外でもその独自性が注目されています。例えば、アメリカのヒップホップアーティストがこの形式を参考にした楽曲を制作する事例もあります。
文芸的・言語学的に見ても、この詞書は「日本語の表現技法」として研究対象とされることがあり、古典文学から現代まで受け継がれる文化遺産です。
寿限無を深く理解するために
平安時代の貴族社会:詞書の成立背景を理解するには、当時の貴族や武士の生活、恋愛観、儀礼などを学ぶことが役立ちます。
古典文学と現代の比較:源氏物語枕草子との共通点や違いを分析すると、日本の文学史の流れが見えてきます。
言語学的分析:詞書のリズムや反復構造を解説する解説書(例:大野 Jin'ichi の研究)を参考にすると、創作技術が明確になります。
寿限無」は単なる古典文学ではなく、現代的な文芸創作のヒントが詰まった作品です。興味がある方は、詞書の全文や関連する研究資料を読むと、さらに深い理解が得られるでしょう。

このモデルもしっかり語ってくれます。みなさん、寿限無が大好きですね。

 

mmnga/Qwen3-EZO-8B-beta-ggufをColabとollamaでためしてみる。

Qwen3ベースのEZO-8Bベータ版を試してみます。mmngaさんがGGUFに変換したモデルを利用してcolab L4環境で動作させました。 VRAM占有率は6545MiB /  23034MiBでした。これまでもEZOモデルはいい感じでベースモデルから性能を上げています。今回は、8Bでも高い性能ということで期待しながら試してみます。

 

huggingface.co

chat-ui-seven-sigma.vercel.app

 

さすがに8Bのモデルなので知識を求めるのは厳しいとは思いますが、ここまで答えられるといろいろ実用が見えてきていると感じます。もちろん、量子モデルだということは割り引くと可能性を感じます。参照文章から答えてほしい場面では、参照文章として入力していない情報も付け加えた答えでした。ちょっと感がりすぎですね。もちろん、基本的な計算もできます。残念なのは、英語のプロンプトだと日本語でも中国語の答えになってしまうケースがありました。推論は英語を経由する点を日本語にチューニングできれば、日本語の性能は上がる余地があるのかも・・・。小型でも推論が入ると生成時間が増える。このあたりのバランスもこれからの課題になるのでしょうか。それとも、マシンパワーが上がるのが先でしょうか。

生成例:

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

<think>
Okay, the user is asking about the most cutest character in Madoka Magica. I need to consider the characters and their traits. Madoka is the main character, known for her kindness and determination. Homura is very serious and emotional, so maybe not the cutest. Sayaka is more laid-back, but she has a softer side. Mami is the most popular, especially for her cute appearance and kind personality. She's often the favorite for cuteness. The user might be looking for a recommendation, so I should highlight Mami's traits and maybe mention others briefly. Also, the user might be a fan of the anime, so providing a positive and detailed answer would be good. Need to make sure the answer is friendly and engaging.
</think>

まどか☆マギカ」で一番かわいいキャラクターといえば、やはり**マミ(乙坂うみ)**が多くのファンから絶賛されています!✨

### マミの「かわいさ」の理由:
1. **見た目**:柔らかなピンクの髪と、いつも笑顔で優しい雰囲気。制服姿もとてもかわいいです。
2. **性格**:優しくて思いやりのある性格。誰に対しても親しみやすい態度で、心が癒されます。
3. **行動**:危険な状況でも冷静に行動し、仲間を守る姿が「かわいさ」に加えて「頼りになる」魅力も持っています。

### 他のキャラクターもかわいい!
- **まどか**:純粋で真剣な気持ちが伝わってきて、無邪気なところが癒されます。
- **サヤカ**:明るく元気な性格で、笑顔がとてもかわいいです。
- **ホムラ**:優しくて気遣いがちの性格。時折切ない言葉も、逆にかわいさを感じさせます。

### まとめ:
「かわいい」という基準によっても答えは変わりますが、**マミ**は「見た目」「性格」「行動」のすべてで、多くの人にとって「一番かわいい」とされることが多いです!🌸  
ご自身の好みに合わせてチェックしてみてくださいね~!
CPU times: user 42.7 ms, sys: 2.65 ms, total: 45.3 ms
Wall time: 11.9 s

微妙におかしなところはありますが、頑張っています。

 

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

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

(略)

<think>
Alright, the user is asking which character from Madoka Magica is the cutest. They provided detailed character descriptions, so I need to consider all the characters mentioned. Let me go through each one.

First, Madoka herself. She's the protagonist, kind and has a lot of depth. Her design is soft with white hair and pastel colors. But she's more of a main character, so maybe not the cutest in terms of visual appeal.

Homura is a key character with a mysterious vibe. Her design is cute with a pink color scheme, but her personality is more complex, which might make some people find her less cute in the traditional sense.

Sakura is cheerful and has a vibrant pink color. She's a bit more playful, which could make her seem cuter. However, she's more of a supporting character.

Mami is elegant with a blue color. She's a veteran and has a mature look, which might not be as cute as others.

Kyoko is more serious but has a fiery personality. Her design is maybe less cute.

Kyubey is an animal-like character with a cute design, but as a villain, he might not be considered cute by all.

So, based on visual design and character traits, Sakura (Kyouko) might be seen as the cutest due to her vibrant colors and playful nature. However, Homura's design is also very cute with her pink color and soft features. The user might have different opinions based on personal preferences, but the answer should mention that it's subjective and highlight the cutest based on design and character.
</think>

まどか☆マギカ」のキャラクターの「かわいさ」は、視聴者の好みによって異なりますが、**デザインや性格の要素**を考慮すると、以下のようなキャラクターが特に「かわいい」とされる傾向があります。

---

### **1. 暁美ほむら(あけみほむら)**
- **デザイン**:ピンクの髪と瞳、柔らかな色合い、幼さを感じるキャラクター。  
- **性格**:優しくて、まどかに忠誠を尽くす「私」の一人称。  
- **特徴**:魔法少女としての強さと、悲劇的な運命の「最強の魔女」へと変貌するドラマチックなストーリー。  
- **人気**:視聴者からは「ほむほむ」という愛称で呼ばれ、**かわいさと深み**が融合したキャラクターとして人気があります。

---

### **2. 巴マミ(ともえマミ)**
- **デザイン**:青と白の髪と瞳、エレガントなデザイン。  
- **性格**:優しくて、他者を守る信念を貫くベテラン魔法少女。  
- **特徴**:まどかやさやかに大きな影響を与えた「象徴的な存在」。  
- **人気**:**大人っぽい優しさ**と「魔法少女の象徴」としての存在感が魅力。

---

### **3. 佐倉杏子(さくらきょうこ)**
- **デザイン**:明るいピンクの髪と瞳、ポップなデザイン。  
- **性格**:元気で、さやかを助けたい一心の熱血的な性格。  
- **特徴**:最初は悪役に見えるが、最後に「良心的存在」として成長するキャラクター。  
- **人気**:**ポップで元気なデザイン**と「成長のストーリー」が魅力。

---

### **4. 鹿目まどか(かなめまどか)**
- **デザイン**:白髪と淡いピンクの瞳、柔らかな見た目。  
- **性格**:優しくて、内向的な主人公。  
- **特徴**:魔法少女としての成長と、悲劇を終わらせるための覚悟を持つ「真の願い」を描く。  
- **人気**:**純粋な優しさ**と「成長物語」が魅力。

---

### **総合的な「かわいい」キャラクター**
- **視覚的デザイン**:**ほむら**(ピンクの髪と瞳)や**杏子**(ポップなピンク)が特徴的。  
- **性格の柔らかさ**:**マミ**(優しさ)や**まどか**(純粋な優しさ)が「かわいさ」を感じさせる。  

---

### **結論**
「かわいい」とは**個人の好み**に大きく左右されるため、**一概に誰が「一番」かわいいとは言えません**が、  
**視覚的デザインと性格の柔らかさ**を両立しているキャラクターとしては、  
**「暁美ほむら」**が多くの視聴者から「かわいい」とされる傾向があります。  
また、**「魔法少女の象徴」**としての存在感や、**「悲劇のヒロイン」**としてのドラマチックな要素も、彼女の「かわいさ」を際立たせています。
CPU times: user 94.8 ms, sys: 7.81 ms, total: 103 ms
Wall time: 30.4 s

デザインの情報はほぼ与えてないので、情報を少し加えて答えています。

 

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

<think>
Okay, the user is asking for the second highest mountain in Japan. Let me recall the list of Japanese mountains. The highest is Mount Fuji at 3,776 meters. Then, the next one is Mount Tateyama, which I think is part of the Japanese Alps. Wait, is it Mount Tateyama or Mount Kita? Wait, I need to confirm the exact names and their elevations.

Actually, the second highest is Mount Tateyama, also known as Tateyama-san. It's located in the Japanese Alps, in the Nagano Prefecture. Its elevation is 3,134 meters. But wait, another mountain called Mount Kita is sometimes mentioned. Let me check. Mount Kita is actually part of the same mountain range as Tateyama but is a different peak. However, the official second highest is Tateyama. Some sources might list Mount Kita as the second, but I think the correct answer is Mount Tateyama. I should make sure that there's no confusion between the two peaks. Also, the user might be interested in the name, location, and elevation. So the answer should state that Mount Fuji is the highest, and the second is Mount Tateyama at 3,134 meters, located in the Japanese Alps, Nagano Prefecture. That should cover the main points.
</think>

日本で二番目に高い山は**富士山**(3,776メートル)に次いで、**立山(たてやま)**です。立山は長野県と岐阜県の県境に位置し、日本アルプスの一部に属しています。その標高は**3,134メートル**で、日本で二番目に高い山とされています。立山はまた、日本で最も高い山とされる「富士山」に次ぐ、日本代表的な山岳観光地の一つでもあります。
CPU times: user 33.1 ms, sys: 2.3 ms, total: 35.4 ms
Wall time: 9.73 s

不正解です。しかし、正解も推論の中には含まれていたので、正解を出すパターンもあるでしょう。

 

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

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

<think>
Okay, I need to summarize the given Japanese text about Wikipedia. Let me read through it carefully.

The main points are: Wikipedia is a free, multilingual encyclopedia created by volunteers worldwide. It's open content with no ads, run by the Wikimedia Foundation as a non-profit. The name comes from "Wiki" and "Encyclopedia," and it was named by Larry Sanger.

I should make sure to mention all key elements: free, volunteer-driven, multilingual, open content, no ads, non-profit, Wikimedia Foundation, origin of the name, and Larry Sanger's role. Keep it concise and in Japanese. Avoid any extra details not in the original text. Check for clarity and flow. Make sure the summary is easy to understand without losing important information.
</think>

ウィキペディアは、世界中のボランティアが共同で作成するフリーの多言語インターネット百科事典です。オープンコンテントであり、広告なしで運営され、非営利団体ウィキメディア財団」が管理しています。名称は「ウィキ(Wiki)」と「百科事典(Encyclopedia)」を組み合わせた造語で、設立者の1人であるラリー・サンガーによって命名されました。
CPU times: user 23.4 ms, sys: 1.64 ms, total: 25 ms
Wall time: 6.54 s

要約はいい感じですね。

 

1+1*2+3/2+2^10を計算してください。計算が終わったら検算をしてください。最後に最終的な計算経過と結果を答えてください。

<think>
Okay, let's see. I need to calculate this expression: 1 + 1*2 + 3/2 + 2^10. Hmm, where do I start? I remember that order of operations is important here. So parentheses first, then exponents, multiplication and division, and finally addition and subtraction. Let's break it down step by step.

First, the exponents. There's 2^10. Wait, what's 2 to the 10th power? Let me calculate that. 2^1 is 2, 2^2 is 4, 2^3 is 8, 2^4 is 16, 2^5 is 32, 2^6 is 64, 2^7 is 128, 2^8 is 256, 2^9 is 512, and 2^10 is 1024. So that part is 1024.

Now the next part is 3 divided by 2. That's 3/2, which is 1.5. Okay.

Then there's the multiplication: 1*2. That's straightforward, 1 times 2 is 2.

So putting it all together: 1 + (1*2) + (3/2) + 2^10. Plugging in the numbers we found: 1 + 2 + 1.5 + 1024. Let me add them step by step.

Start with 1 + 2 = 3. Then add 1.5 to that: 3 + 1.5 = 4.5. Finally, add 1024: 4.5 + 1024 = 1028.5. Wait, is that right? Let me check again to make sure I didn't mix up any steps.

Wait, 1 + 2 is 3. Then 3 + 1.5 is 4.5. Then 4.5 + 1024 is indeed 1028.5. Hmm, but maybe I should verify each operation again to be safe.

Let me write down each part with parentheses to make sure the order is correct. The original expression is 1 + 1*2 + 3/2 + 2^10. According to order of operations, exponents first, then multiplication/division left to right, then addition. So exponents: 2^10 is 1024. Then multiplication: 1*2 is 2. Division: 3/2 is 1.5. Then addition: 1 + 2 + 1.5 + 1024. So yes, adding them all up gives 1028.5. But maybe I should check if there are any parentheses that I missed. The original problem didn't have any, so the order is correct.

Wait, another way to think about it: if I convert all to fractions, maybe it's clearer. 1 is 1/1, 2 is 2/1, 1.5 is 3/2, and 1024 is 1024/1. Adding them all up:

First, 1 + 2 = 3. Then 3 + 3/2 = 3 + 1.5 = 4.5. Then 4.5 + 1024 = 1028.5. Yeah, same result. So I think that's correct.

But just to be thorough, let me do the calculation using decimal numbers step by step again:

Start with 1. Add 1*2: 1 + 2 = 3. Add 3/2: 3 + 1.5 = 4.5. Add 2^10: 4.5 + 1024 = 1028.5. Yep, same as before.

So the final result is 1028.5. Now, to make sure I didn't make any mistakes, maybe I should check each component again.

2^10: 2*2=4, 4*2=8, 8*2=16, 16*2=32, 32*2=64, 64*2=128, 128*2=256, 256*2=512, 512*2=1024. Correct. 3/2 is 1.5. 1*2 is 2. All the steps are right.

Another way to check is to convert all terms to fractions with a common denominator. Let's see:

1 is 2/2, 2 is 4/2, 3/2 is 3/2, and 1024 is 2048/2. So adding them all over 2: (2 + 4 + 3 + 2048)/2 = (2057)/2 = 1028.5. Perfect, same answer. So that confirms it.

Therefore, the calculation is correct. The final answer is 1028.5.
</think>

**計算過程と結果:**

1. **指数計算**: $ 2^{10} = 1024 $
2. **乗法計算**: $ 1 \times 2 = 2 $
3. **除法計算**: $ 3 \div 2 = 1.5 $
4. **加法計算**: 
   - $ 1 + 2 = 3 $
   - $ 3 + 1.5 = 4.5 $
   - $ 4.5 + 1024 = 1028.5 $

**検算**:  
分数形式で確認:
- $ 1 = \frac{2}{2} $, $ 2 = \frac{4}{2} $, $ 1.5 = \frac{3}{2} $, $ 1024 = \frac{2048}{2} $  
- 合計: $ \frac{2 + 4 + 3 + 2048}{2} = \frac{2057}{2} = 1028.5 $

**最終結果**:  
$ 1 + 1 \times 2 + \frac{3}{2} + 2^{10} = \boxed{1028.5} $
CPU times: user 103 ms, sys: 11.3 ms, total: 114 ms
Wall time: 34.3 s

少々時間がかかりますが、問題なく正解を算出できました。

 

 

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

<think>
Okay, I need to create a fictional dialogue between a guy named Ren and a department head. Let's start by setting the scene. Maybe they're in an office, discussing a project or a problem. I should give them distinct personalities. Ren could be a young, enthusiastic employee, and the department head is more experienced and maybe a bit strict. They need to have a natural conversation that shows their dynamic. Maybe Ren is excited about a new idea, but the department head is concerned about risks. Let's include some conflict and resolution. Maybe the department head agrees to support the idea after some discussion. I should make sure the dialogue flows smoothly and includes realistic interactions, like interruptions or pauses. Also, add some details about the environment to make it vivid, like the time of day or the setting. Check for any inconsistencies and ensure the characters are well-defined. Alright, let's put it all together.
</think>

**場面:**  
午後2時。会社のオフィスで、社長室のドアの前。若い社員の**両さん(両太郎)**と**部長(山田部長)**が、プロジェクトの進捗について話し合っている。両さんは少し緊張しているが、熱心に話している。

---

**両さん**:  
「山田部長、ちょっとお時間をいただけますか?今、新規プロジェクトの進捗についてご確認したいんですけど……」

**山田部長**:  
「ああ、そういえば、今週の打ち合わせで話した新規プロジェクト、進捗どう?」

**両さん**:  
「はい、先週からリリース予定のアプリの開発が進んでいます。ただ、今週中にテスト環境を整えるのがちょっと厳しくて……」

**山田部長**:  
「テスト環境?ああ、クラウドのインフラ構築の件ね。我々が契約したアカウントの容量が足りなくなってきてるからだな。」

**両さん**:  
「はい。それに、今度のバージョンには新機能を追加する予定で、それに伴ってデータベースのスケーラビリティも考慮しないといけないんです。」

**山田部長**:  
「なるほど。新機能はユーザーに好評で、今後の成長に必要な要素だ。でも、インフラの負担が増えるのは避けたい。」

**両さん**:  
「その点、我々も課題を認識してます。ただ、リリース延期はユーザーに不満が出る可能性も……」

**山田部長**:  
「ユーザーの期待は当然大切だ。でも、品質を犠牲にした開発は、長期的には損害になる。我々の信頼を失う可能性もある。」

**両さん**:  
「そうですね……。では、今週中にはテスト環境を再構築する予定ですが、必要なら部長のサポートもいただけますか?」

**山田部長**:  
「もちろん。私の部下も含め、チームを動員してサポートする。ただし、リリースは来月の初めに延期する覚悟は必要だ。」

**両さん**:  
「ありがとうございます。その場合は、今週中にリソースの再配分を調整して、来月のスケジュールに合わせる準備をします。」

**山田部長**:  
「頑張れ。我々のチームは信頼できるから、焦らずに進めよ。」

**両さん**:  
「はい!頼りにします!」

---

**後日、両さんがテスト環境を整え、リリースを延期する準備を進めている場面。**  
山田部長はチームの士気を鼓舞し、プロジェクトの長期的な成長を重視する姿勢を示している。

---

**ポイント:**  
- 両さん:熱意ある若手社員。ユーザーの期待と品質のバランスを模索中。  
- 山田部長:経験豊富な部長。短期的な成果よりも、長期的な信頼と品質を重視。  
- テスト環境の問題は、技術的課題と、リーダーの意思決定の両面を描く。
CPU times: user 63.3 ms, sys: 12.8 ms, total: 76.1 ms
Wall time: 22.9 s

話に破綻はみられず。悪くないですね。

 

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

<think>
Okay, I need to create a concise summary of the information provided about Mount Hakone (北岳). Let me start by reading through the given text carefully.

First, the text mentions that 北岳 is a mountain in Japan, part of the South Alps (南アルプス) in Yamanashi Prefecture. It's a 3000-meter peak, which is significant. The text also states it's one of the 100 Famous Mountains of Japan (日本百名山), which is a key point. There's a mention of its elevation, which is 3,193 meters, and that it's a World Natural Heritage Site, part of the South Alps. 

The text includes details about the surrounding area, like the nearby mountains such as 赤石岳 (Akishima-dake), 聖岳 (Seitaku), and others. It also talks about the geological features, like the volcanic activity and the formation of the mountain. There's information about the flora, especially the キタダケソウ (Hakone primrose), which is a notable plant found there. 

The text also includes historical and cultural aspects, such as the mountain being a place of pilgrimage and the presence of shrines and temples. There are references to the natural beauty, including the view of Lake Kawaguchi and the surrounding areas. The text mentions the importance of the mountain in the context of the South Alps World Natural Heritage Site and its role in the region's ecosystem.

I need to make sure the summary is concise, covering the main points: location, elevation, status as a famous mountain, part of the World Heritage Site, geological and ecological significance, and cultural aspects. Also, include the key plant species and nearby mountains. Avoid any unnecessary details like specific dates or links. Keep it structured and clear.
</think>

**北岳 (Hakone-dake)**  
北岳是日本山梨县南阿尔卑斯山脉的3000米级山峰,海拔3,193米,为日本百名山之一。作为南阿尔卑斯世界自然遗产的核心部分,其地质构造独特,由火山活动形成,拥有丰富的生态系统。山体覆盖针叶林,是日本高山植物的宝库,尤以**北岳素馨花**(キタダケソウ)闻名。周边山岳包括赤石岳、圣岳等,与富士山、御岳山等共同构成日本阿尔卑斯山脉的自然景观。该山不仅是登山胜地,也是文化与自然的交汇点,吸引众多游客与学者。
CPU times: user 534 ms, sys: 27.7 ms, total: 562 ms
Wall time: 17.8 s

残念。中国語での回答になりました。

 

日本語のプロンプトを準備して同じように要約をしてもらいます。

<think>
Okay, I need to summarize the given text about Mount Hakone. Let me start by reading through the content carefully. The text is in Japanese, so I'll need to parse it accurately. 

First, the main subject is Mount Hakone, which is part of the Japanese Alps. It's a 3000-meter peak, so it's listed in the 3000m peaks of Japan. The text mentions it's part of the Minami Alps National Park and the Japanese 100 Famous Mountains. There's a lot of information about its location in Yamanashi Prefecture, the surrounding areas like the Kiso Mountains and the Kiso River. 

The text also talks about the history of the mountain, including its name origin from the local deity "Hakone" and the legend of the fire god. It's a popular hiking destination, with trails like the Hakone Ropeway and the Hakone Ropeway. The text lists several peaks in the area, such as the Kiso Mountains, the Kiso River, and the Hakone Ropeway. 

There's a mention of the Hakone Ropeway, which is a famous cable car line. The text also includes a list of other mountains in the region, like the Kiso Mountains, the Kiso River, and the Hakone Ropeway. It's part of the Japanese 100 Famous Mountains and the New Japanese 100 Famous Mountains. 

The text also includes a list of related topics, such as the Minami Alps National Park, the Japanese 100 Famous Mountains, and the New Japanese 100 Famous Mountains. There are external links provided, like the Hakone Ropeway and the Japanese Meteorological Agency's weather forecast

I need to make sure the summary includes the key points: location, elevation, status as a famous mountain, historical significance, nearby areas, and the Hakone Ropeway. Also, mention the national park and the list of related mountains. Avoid including too much detail about the specific trails or the exact number of peaks unless it's essential. Keep it concise but comprehensive.
</think>

**北岳の概要要約:**

北岳は、日本の山脈である赤石山脈に位置し、長野県と山梨県の境にある3000メートル級の山。日本百名山の一つで、南アルプス国立公園に属する。山頂は標高2,940メートルで、日本百名山の代表的な山として知られる。地名は、地元の神話に登場する神「北岳」に由来し、山の周辺には多くの伝説が残る。

北岳は、登山や観光の中心地として人気があり、山頂への道は「北岳山頂道」として知られる。山の周辺には、赤石岳悪沢岳塩見岳などの山々が分布し、南アルプスの代表的な山脈を形成している。また、山の北麓には、山梨県南アルプス市が位置し、自然と文化が融合した観光地として発展している。

北岳は、日本百名山と新・花の百名山にも選出されており、登山者や観光客にとって重要な山である。山の周辺には、北岳ロープウェイなどの交通機関があり、アクセスが便利。また、日本気象協会の天気予報や国土地理院の地図サービスも利用可能。山の生態系や自然環境は、南アルプス世界自然遺産登録の対象として注目されている。
CPU times: user 671 ms, sys: 32.6 ms, total: 704 ms
Wall time: 24.4 s

今度は日本語で回答してくれました!

 

寿限無とは?

この質問は日本語の「寿限無」の意味を尋ねています。寿限無は、日本語で「長寿に限らない」という意味を持つ言葉です。この言葉は、日本語の文法や文化において、長生きするという概念を逆に表現しているため、ユーモラスで、時折、皮肉として使われることも。
寿限無(じゅげむ)は、一般的に、人間は長寿であることを期待しても、それが必ず成り立つわけではない、つまり「長寿に限らない」という意味です。これは、ある特定の状態や結果が常に成立するとは限らないことを指します。例えば、長生きすることを願っても、それが必ず叶うとは限らない、という意味になります。

この言葉は、日本語の古典や文芸作品、あるいは現代の口語でも使われ、時折、冗談として使われることもあります。また、寿限無は、日本文化における「長寿」に対する否定的な視点を示す言葉として、文化的な意味も持つことがあります。

寿限無の語源としては、中国語の「無」が「ない」という意味で、「寿」は「寿命」、「限」は「限界」、つまり「寿命に限らない」という意味です。日本語では、この中国語の言葉を借用し、文化に取り入れたものです。

さらに、寿限無は、日本語の言語学的な観点からも興味深い存在です。なぜなら、この言葉は、日本語の文法構造に応じて、文法的にも意味的にもユニークな表現であるためです。

寿限無は、長寿の願いを否定する、あるいは、人間の長生きは必然ではないという意味を持つ言葉です。また、日本文化において、寿限無は、長寿を願う人に対して、現実的な視点や、人生の無常性を示すものとして使われることもあります。

このように、寿限の無は、日本語の文法や文化、さらには哲学的な意味も含んでおり、一つの言葉で多くの意味を含んでいる言葉です。

寿限無」とは、日本語で「長寿に限らない」という意味を持つ言葉です。この言葉は、通常、人間が長生きするという願いを否定し、そのような願いが必ず叶うわけではないという現実的な視点を表しています。以下に詳しく説明します。

基本的な意味:

「寿」(じゅ)は「寿命」や「長生き」を意味します。
「限」(げん)は「限界」や「制限」を表します。
「無」(む)は「ない」や「否定」を意味します。
したがって、「寿限無」は「寿命に限らない」という意味を持ちます。
文化的・哲学的背景:

日本では、長寿は幸せとされることが多いですが、「寿限無」は、その願いが必ず叶うとは限らないという現実的で、無常を強調する表現です。
中国語の「無」を借用した言葉で、日本語の語彙に取り入れられています。
ユーモラスな使用:

また、この言葉は、冗談や皮肉として使われることもあります。例えば、「寿限無だから、長生きするのではなく、死ぬのが自然です」といった具合に、現実的な口調で使われることがあります。
文法的・言語学的特徴:

日本語では「寿限無」は、文脈に応じて意味が変わることがありますが、基本的には「長寿に限らない」という否定的な意味を持つ表現です。
現代への適用:

今日では、長寿への願いが依然として重要ですが、「寿限無」は、その願いを現実的に捉えるための言葉として、人間の無常性や、人生の限界を示す象徴的な表現となっています。
このように、「寿限無」は、単なる言葉ではなく、日本の文化的・哲学的な価値観を反映した表現として、多くの人々の間で知られています。

寿限無って聞くとどのモデルも結構ちゃんと答えます。これはWikipediaを学習しているからでしょうか・・・。

 

 

 

 

 

メモ:JulesでDeep Researchみたいなものをお試しで作ってみる

GoogleのAIコーディングアシスタントJulesを試してみます。題材はDeep Researchもどきです。OpenAIなりのAPIを使わずにローカルのgemma3:4b-it-qatを利用してテストします。UIはstreamlitを使って実装します。それなりに利用できるようなものを目指します。

 

ざっくり言うと・・・。

0. 自動モードで検索→吟味→検索・・・と所定の回数loopして調査を行います。

1. PDFを読み込んで参照します。

2. ナレッジグラフで可視化機能を盛り込みます。

3. Follow upの質問が出来るようにします。

 

まず、Deep ReasarchのOSS版はきっと誰か実装しているはずです。そこで調べてみると、すでにLangchain-aiで実装されているものが公開されています。

Open Deep Research: https://github.com/langchain-ai/open_deep_research
Local Deep Researcher: https://github.com/langchain-ai/local-deep-researcher

これらを参考に設計します。ChatGPTを使いながら、まとめていきます。例えば、Core Logic部は以下のようになりました。このままそっくり作るのではありません。必要な機能を分解して理解して、自分に必要な機能を選択したり入れ込んで設計していきました。実際に組み上げる時にはコードレベルで参照せずに、考え方を整理して構成したものをベースにjulesと組み上げていきます。

 

Core Logic

 

Both repos automate multi-step research by interleaving search and generation:

  • Planning/Outline: (open_deep_research only) The assistant first creates a report plan. An LLM planner analyzes the topic and breaks it into sections or sub-questions. In the graph mode, this plan is shown to the user for feedback (accept or refine) before proceeding.

  • Search Query Generation: For each section or iteration, an LLM generates one or more web search queries tailored to the sub-topic. In Local Deep Researcher, the LLM uses the topic (and later the current summary) to form a query. In Open Deep Research, per-section queries may be generated by a chain or agent prompt.

  • Document Retrieval: The system uses web search tools to retrieve relevant pages. LocalDeepResearcher defaults to DuckDuckGo (no API key needed) but can be configured to use SearXNG, Tavily, or Perplexity. OpenDeepResearch (Graph) supports multiple APIs (Tavily, Perplexity, Exa, ArXiv, PubMed, LinkUp). OpenDeepResearch (Multi-agent) currently uses only the Tavily API for its researcher agents.

  • Summary Generation: Retrieved documents are passed to an LLM to summarize relevant information. In graph-based OpenDeepResearch, this happens sequentially for each section, often with “reflection” steps between search iterations. In LocalDeepResearcher, each loop uses the LLM to produce an updated summary of all findings so far.

  • Reflection and Iteration: After summarizing, the assistant (via the LLM) examines the summary to find what was missed. It then generates a follow-up query to dig deeper. The Local Deep Researcher explicitly “reflects on the summary to identify knowledge gaps” and creates a refined query. The graph-based OpenDeepResearch workflow similarly iterates per section (controlled by parameters like max_search_depth) to deepen research.

  • Aggregation: Finally, the gathered information is combined into a single report. In the graph workflow, the final markdown report is assembled from section outputs. In multi-agent mode, the Supervisor concatenates or formats each researcher’s section into the final document. In local mode, all collected sources are formatted into a markdown summary with citations.

 

Julesを使います。

最初は順調でした。まずはCLIで基本機能を実装した後にStreamlitでUIまで、さほど問題なく実装してくれました。Webページをスクレイピングしたテキストをチャンクさせ、その設定を設定ファイルで行えるようにしたり、対象のデータの最大量を制限したり、と細かいところを指示していけば、淡々とコードをしてくれます。待ち時間で動画見た後に作業もできるくらいに余裕です。無料のためか、待ち時間は長めです。止まったようになったときには、どうなんってんの?と茶々を入れるとはっと気づいたように再開することもありました。

 

大きくコケそうになったのはStreamlitでボタンを押すとUIがクラッシュする案件でした。最終的には原因は分かったのですが、それまでに何度もテストし、その結果をjulesに教えてあげて・・・を繰り返します。streamlitは癖が強いので、Coplotでもハマると解決できないことがありますが、julesは十分に経緯を遡って考えるため、千日手のようなループに入ることは少ないように感じました。自分で手を出そうかと思ったのですが、時々、可能性を助言する程度でとどめました。結果、このFixだけ丸一日くらい時間のロス。(だけど、ながら対応なので、苦にはならず)

 

その機能を達成するために、どのライブラリを選定するか、も重要です。pythonだけで実装してあって環境に左右されにくいのがいいのか、バイナリも提供されてて速さ優先させるのか、等です。具体的に実装させる前に議論するような指示を与えたのは正解でした。

 

そうして出来上がったものは、利用したLLMは、gemma3:4b-it-qatでしたが、予想より良好な出力が得られました。テストのためループ数5、検索はTOP3と少なめの設定です。また、基本は英語で出力させています。

 

「日本の最近のコメ不足について」についての調査出力例(冒頭の日本語訳)

要約:

日本は現在、深刻な米不足に直面しており、それは価格の大幅な上昇と農業の変化によって明らかになっています。米先物取引の復活、消費者の嗜好の変化、そして農家の戦略的な方向転換が、この不安定な状況の主な要因となっています。本報告は、米不足に関する最近の調査結果を統合し、その要因、国内農業への影響、そして政府の対応を明らかにしています。

1. 問題の根源: 価格の上昇と米先物取引の再開

現在の米不足の直接的な原因は、米価格の急騰です。2024年9月までに、5kgの米袋の価格が約2,000~3,000円に上昇しました。この価格高騰は、大阪堂島取引所 (ODEX) における米先物取引の再開と密接に関連しています。この市場は2016年以前は休止していましたが、最近の再開によって市場の不安定化と価格の変動を引き起こしています。この動きが価格の上昇を大きく促進し、国内市場および輸出市場に関する懸念を増幅させています。加えて、国際市場の変動、特に人民元の価値上昇が世界的な米価格にも影響を及ぼしていますが、日本国内における核心的な問題は、米先物市場の復活にあると考えられています。

(以下略)

結論:

現在の日本の米不足は、市場の動向、消費者の嗜好の変化、そして農家の戦略的適応が重なり合った結果として発生しています。特に、米先物取引の復活は、この危機の中心的な要因となっており、価格設定や生産判断、さらには消費者への供給状況に大きな影響を及ぼしています。今後も継続的な監視と分析、そして積極的な対策——農家への的確な支援や長期的な需要への対応戦略——が、この困難な状況を乗り越え、日本の重要な米市場の安定を確保するために不可欠となるでしょう。

(以下、参考リンクが続く)

 

しっかり、無料でお試しできました。非同期コーディングも楽で良かった。有料化時の価格も気になるところです。

 

良くを言えば、VS Codeと連携がしっかりできたら・・・。これから期待ですね。

 

できたもの:

github.com

ABEJA-Qwen2.5-32b-Japanese-v1.0をollamaとColabで試す。

v1.0となったABEJA-Qwen2.5-32b-Japanese。v0.1の頃もいい感じだったので、期待してお試しします。mmngaさんの手によってGGUFとしたモデルを利用し、Colab L4環境でお試しします。21673MiB /  23034MiBのVRAM占有率でした。

 

32Bの量子化モデルであれば、実用的なレベルの回答が得られるようになってきています。ABEJAのモデルはバランスも良くQwn2.5ベースのモデルの中では、使いやすいのではと思います。Qwen3ベースの小型モデルも優秀なので、もっと小さいサイズが待ち遠しいです。

 

huggingface.co

 

 

生成例:

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

魔法少女まどか☆マギカ」には多くの魅力的なキャラクターがいますが、「かわいい」と感じる基準は人それぞれなので、以下に主要なキャラクターを紹介します。

1. **鹿目 まどか(ししずめ まどか)**:主人公の一人で、優しさと強さを持つ魔法少女。無垢な性格が魅力的です。
2. **美樹さやか(みき さやか)**:おてんばで元気な性格で、仲間思いの一面も持ち合わせています。
3. **佐倉 妃郁実(さくら ひゆみ)**:「キュウべぇ」としても知られ、最初は謎めいた存在ですが、物語が進むにつれてその役割や性格が明らかになります。デザイン的にもかわいらしいです。
4. **巴 マミ(ともえ まみ)**:先輩魔法少女として登場し、優雅さと大人の魅力を持つキャラクターです。

どのキャラクターもそれぞれに魅力的で「かわいい」と感じる要素があります。あなたがどのような点を重視するかによって、一番「かわいい」キャラクターは変わるかもしれません。
CPU times: user 82 ms, sys: 9.16 ms, total: 91.1 ms
Wall time: 24.9 s

一見、さすがだな・・・と思ったら、なかなかユニークな仕上がりです。

 

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

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

(割愛)

キャラクターの可愛さは個人の好みによりますが、「まどか☆マギカ」の主要魔法少女キャラクターについて以下に特徴を挙げてみます。

- **鹿目 まどか**:
  - 優しさと強さを兼ね備えた主人公。
  - 真っ直ぐな性格が魅力的で、彼女の成長過程は多くのファンの心を捉えている。
  
- **暁美 ほむら**:
  - 悲しみと執念に満ちた複雑なキャラクター設定。
  - 冷静さと同時に深い愛情を持つ姿が印象的。

- **美樹 さやか**:
  - 熱血で自信家、明るい性格だが、挫折感との戦いも描かれている。
  - 悲劇的な最期は多くのファンの心を揺さぶった。

- **巴 マミ**:
  - 成熟した先輩としての面と、魔法少女としての厳しさが共存するキャラクター。
  - 華やかさと優雅さを持つ一方で、強い使命感も持っている。

- **佐倉 杏子**:
  - 冷たさを装いつつも、内面には深い思いやりがある。
  - 独特の美学と強さが魅力的。

それぞれに異なる個性があり、「かわいい」と感じるポイントは人それぞれです。どのキャラクターにも魅力的な要素がありますので、好みに合わせて選んでみてください。
CPU times: user 105 ms, sys: 15 ms, total: 120 ms
Wall time: 35.6 s

参照文章を与えるとしっかりした答えになってきています。

 

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

日本の二番目に高い山は北岳(きただけ)で、標高3,193メートルです。ただし、一般的には富士山が一番高く、それに次ぐ高峰として知られているのは北アルプス槍ヶ岳(やりがたけ)ですが、正確な二位は南アルプスにある北岳となります。
CPU times: user 21.2 ms, sys: 4.06 ms, total: 25.3 ms
Wall time: 6.96 s

よい答えですね。

 

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

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

まずます。

 

1+1*2+3/2+2^10を計算してください。計算が終わったら検算をしてください。最後に最終的な計算経過と結果を答えてください。

この問題を段階的に解いていきましょう。

### 計算の順序(優先順位):
1. べき乗 (2^10)
2. 掛け算と割り算 (左から右へ)
3. 足し算と引き算 (左から右へ)

### ステップバイステップでの計算:

1. **べき乗の計算:**
   \[
   2^{10} = 1024
   \]

2. **掛け算と割り算の計算:**
   \[
   1 + (1 \times 2) + (3 \div 2) + 1024
   \]
   - 掛け算:
     \[
     1 \times 2 = 2
     \]
   - 割り算:
     \[
     3 \div 2 = 1.5
     \]

3. **足し算と引き算の計算:**
   \[
   1 + 2 + 1.5 + 1024
   \]
   - 足し算を順番に進める:
     \[
     1 + 2 = 3
     \]
     \[
     3 + 1.5 = 4.5
     \]
     \[
     4.5 + 1024 = 1028.5
     \]

### 最終的な結果:
\[
1 + 1 \times 2 + 3 \div 2 + 2^{10} = 1028.5
\]

### 検算:
同じ計算を再度確認して、正しく計算されていることを確認します。
- \(2^{10} = 1024\) (OK)
- \(1 \times 2 = 2\) (OK)
- \(3 \div 2 = 1.5\) (OK)
- \(1 + 2 + 1.5 + 1024 = 1028.5\) (OK)

最終的な答えは **1028.5** です。
CPU times: user 122 ms, sys: 21 ms, total: 143 ms
Wall time: 42.9 s

問題ありません。

 

 

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

ある日、部署内で新しいプロジェクトについて話し合う会議が開かれました。

「皆さん、今日は新しいプロジェクトについての話し合いを始めましょう」と部長が切り出しました。「このプロジェクトには全員の力が必要です。特に両さん、あなたの専門的な知識と経験がとても役立つと思いますよ」

両さんは、「ありがとうございます。精一杯頑張ります」と答えた後で、「ただ一つだけ気になっていることがあります」と続けました。

部長は興味深く聞き返しました。「それは何ですか?」

「このプロジェクトには新しい技術が必要となりますが、私自身まだその最新のスキルを持っていません。しかし、学ぶ意欲と時間を確保する準備ができています。」両さんの率直な態度に、部長も頷き、「それは素晴らしいですね、一緒に成長しましょう」と答えた。

それから二人は定期的にミーティングを設け、新しい技術について勉強しつつプロジェクトの進捗を確認しました。
CPU times: user 57.9 ms, sys: 10.1 ms, total: 68 ms
Wall time: 19 s

 

 

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

北岳は、山梨県に位置する日本の3000メートル峰で、標高3193メートル。南アルプス国立公園内にあり、日本百名山の一つとして知られる。周辺には仙丈ヶ岳甲斐駒ヶ岳など他の高峰も存在し、登山者に人気がある。北岳は独立峰で、その頂上からは富士山を含む多くの山々が見える。また、高山植物の宝庫でもあり、特にキタダケソウなどの希少種が見られる。

主な特徴:
- 標高:3193メートル
- 位置:山梨県南アルプス市
- 日本百名山の一つ
- 南アルプス国立公園内に位置
- 高山植物の宝庫

アクセスはバスやタクシーを利用し、北岳山荘まで行くことができる。登山ルートも複数あり、初心者から上級者まで楽しめる。ただし、天候によっては危険な場合もあるため注意が必要だ。
CPU times: user 556 ms, sys: 27.5 ms, total: 583 ms
Wall time: 33 s

 

 

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

北岳は、山梨県静岡県にまたがる赤石山脈南アルプス)の最高峰で、標高3,193メートル。日本で2番目に高い独立峰であり、日本百名山や新・花の百名山にも選ばれている。周辺には間ノ岳農鳥岳などの高峰があり、北岳山荘から約4時間で頂上に到達可能。また、キタダケソウなど希少な高山植物が見られる。
CPU times: user 598 ms, sys: 16.1 ms, total: 614 ms
Wall time: 20.9 s

こんな簡潔なまとめも良いですね。

 

メモ:RAGを実装してみる。理解、分解、再構築。

これまで、論文をヒントに幾つかのRAGを作成しました。折角なので、それらの機能を分解し、それぞれの機能を組み合わせてみます。今回もローカルLLMで挑戦です。ollamaで動作させたgemma3:4b-it-qatを利用します。4Bクラスとしては高い性能を有していますが、さらに性能の高いAPIを利用したら精度が確保できるという期待も込めて遊びます。コストもかかりません(笑)

 

まずは、機能を分解します。それぞれのRAGの特徴的な機能を分解して、それぞれの機能を実装して揃えます。その結果以下のような状況になりました。色んなパターンが準備できました。

- query_decomposition: Breaks down complex queries into simpler sub-queries. Useful for multi-faceted questions.
- retrieval: Searches the vector database for relevant documents based on a query. Requires 'query' and 'k' (number of results).
- evaluation: Assesses the relevance of retrieved documents to the original question.
- refinement: Generates a refined query based on initial retrieval and evaluation results. Sets 'refined_query' in state.
- reflection: Evaluates the sufficiency of the current answer. Sets 'reflection_result' in state as 'sufficient' or 'insufficient'.
- multi_agent_debate: Uses multiple agents to debate and synthesize information from documents. Good for complex or ambiguous topics. Requires 'documents', 'num_agents', 'max_rounds'.
- aggregation: Combines outputs from multiple sources (e.g., debate agents) into a final answer. Requires 'inputs'.
- reranking: Re-orders retrieved documents based on specific criteria (e.g., RRA, dynamic reranking). Requires 'query', 'documents'.
- synthesis: Generates a final answer based on retrieved documents or other context. Requires 'context'.

 

これらをLLMで組み合わせるようにすれば良いという単純な発想です。ClineとGithub Copilotを利用しつつ実装を進めました。テストも不十分な不具合上等、動けばOKの精神です。

 

Query

Qwen3とDeepRagの違いは?それぞれの特徴も詳しく述べてください。その結果を詳細にレポート形式で述べてください。

QwenとDeepRagの論文や他の論文をベクトル化したデータベースを参照するようにしています。もちろん、QwenはLLMで、DeepRagはRAGの手法です。あえて情報を混ぜるようにしてみました。

 

経過

Loop 1: Evaluating query: 'Qwen3とDeepRagの違いは?それぞれの特徴も詳しく述べてください。その結果を詳細にレポート形式で述べてください。'

Execution plan: query_decomposition_retrieval_synthesis_reflection
Components to execute: query_decomposition, retrieval, synthesis, reflection
Executing component: query_decomposition
Component 'query_decomposition' executed successfully.
Executing component: retrieval
Component 'retrieval' executed successfully.
Executing component: synthesis
Component 'synthesis' executed successfully.
Executing component: reflection
Component 'reflection' executed successfully.

LLMが考えたプランでは、

  1. query_decomposition
  2. retrieval_synthesis
  3. reflection

を順に利用しています。

 

その結果です。

Final Answer
Here’s a concise comparison of Qwen3 and DeepRAG, followed by a report-style summary:

Key Differences & Features:

Qwen3: Primarily a MoE (Mixture of Experts) based model. It’s focused on achieving high performance with efficient inference through expert activation. It excels in STEM, coding, and reasoning benchmarks.
DeepRAG: Emphasizes iterative retrieval and adaptively utilizes its internal knowledge. It is designed for time-sensitive QA tasks, achieving strong performance by decomposing queries and using faithful intermediate answers.
Report-Style Summary:

Qwen3 vs. DeepRAG: A Comparative Analysis

1. Overview

Qwen3 and DeepRAG represent distinct approaches to Retrieval-Augmented Generation (RAG). Qwen3 is built upon a Mixture of Experts (MoE) architecture, prioritizing efficient inference and leveraging specialized knowledge subsets. Conversely, DeepRAG employs iterative retrieval and adaptive knowledge utilization to address time-sensitive QA scenarios.

2. Architectural Differences

Qwen3 (MoE): Utilizes a MoE structure, allowing only a subset of its parameters to be active during inference. This dramatically reduces computational cost while maintaining high performance. It demonstrates comparable performance to Qwen2.5 at higher parameter scales, particularly in STEM, coding, and reasoning.
DeepRAG: Relies on iterative retrieval – repeatedly querying its internal knowledge base to refine the answer. It adapts its approach based on the query and the retrieved context.
3. Performance Characteristics

Time-Sensitive QA: DeepRAG is designed to excel in time-sensitive scenarios, outperforming Qwen3 and gpt-4o in this category.
STEM/Coding/Reasoning: Qwen3 generally surpasses Qwen2.5 and even some other models in these benchmarks.
Comparable Performance with Less Computation: Qwen3 can achieve similar performance to larger Qwen2.5 models with significantly fewer activated parameters.
4. Key Strengths

Qwen3: Efficiency, particularly in large-scale inference; strong performance in specialized tasks (STEM, coding).
DeepRAG: Robustness in time-sensitive QA, effective knowledge boundary recognition, and adaptability.
5. Conclusion

While Qwen3 presents advantages in efficiency and specific benchmarks, DeepRAG excels in dynamic, time-sensitive QA. The choice of model ultimately depends on the specific application requirements. Further research continues to demonstrate the distinct capabilities and trade-offs between these approaches.

Qwen3がRAGのアプローチの一つの様な書き方も見受けられます。混線した様な部分もあります。生成結果をGPT-4oに入れると問題を指摘してくれました。モデル置き換えればいい感じで答えを生成してくれるかもと期待させます。もっとも、4Bモデルでここまで出来たら立派だなと私は考えます。

 

やってみて色んな気づきがありました。例えば、multi_agent_debateといった一部の機能はなかなかLLMが選択しませんでした。その効果をより明文化する必要があるのかもしれません。他にも気になる点は多々ありました。また、強化すべき点もあります。検索した情報のみから答えるような制限をもっと厳しく判定したい、などなど、実際に利用するとなると、改良点は多々あります。さらに、重要なretrievalの部分は、簡単な実装にしてています。最近のcontext lengthの大きいモデルを考慮したり、構造を意識したデータにしたりする必要もあるでしょう。

 

自分で作らなくても、NotebookLLMのような無料で高機能なツールが使えます。が、仕組みの一端を自分で試せたり、論文を参考に手を動かせるのは楽しいです。

 

今回作成したコードです。

github.com

 

 

 

 

 

 

メモ:Rag実装してみる。AgentRagだったんだけど・・・。

引き続き、RAG実装で遊んでみます。AgenticRagをChatGPTに読ませて骨子を確認したら、『「Retrieval → Evaluation → Query Refinement → 再検索 → Response Synthesis」という順序が、まさに論文中の処理パイプラインそのものになっています。各フェーズの出力が次フェーズの入力になっているため、DAG(有向非巡回グラフ)としてもきれいに一次元のフローを保っています。と言い張ったので、そのままプロラムをしてみました。もちろん、論文にはもっと有益なことが書かれています。

 

arxiv.org

 

つまり、シンプルな流れで

  1. Query: 入力
  2. Retrieval: 検索
  3. Evaluation: 結果評価
  4. Query Refinement: クエリを改良
  5. Retrieval : 検索
  6. Final Answer:  最終的な結果を返す。

という流れです。これはこれで良さそうなので続けて作りました。

 

Qwenのテクニカルレポート(2,2.5,3)のPDFを利用させて回答をさせました。ollamaで動作させたgemma3:4b-it-qatをLLMとして利用します。

 

Original Query

What is Qwen

この入力がリファインされました。

Refined Query
“Explain what Qwen is, including its different versions like Qwen3 and Qwen2.5, and its key features.”

いい感じですね。最終回答です。

Final Answer
Qwen is the latest version of a large language model family. Qwen3, the most recent iteration, features both thinking and non-thinking modes for dynamic task management. It’s pre-trained on 36 trillion tokens and supports 119 languages. Qwen3 models come in various sizes, including 0.6B, 1.7B, 4B, and 8B parameter versions, and a 235B parameter model. Notably, Qwen3 outperforms larger models like Qwen2.5-14B and DeepSeek-V3 Base on many benchmarks, demonstrating strong performance in areas like code generation, mathematics, and reasoning. Qwen3’s architecture includes dense and Mixture-of-Expert (MoE) models, and it’s designed to be more efficient and cost-effective compared to other models with similar or greater parameter counts.

最終的な答えはQwen3ですが、他の方法だと学習パラメータ数を間違ったりしていたのに対しては良い答えです。

 

github.com

 

mmnga/Gemma-2-Llama-Swallow-27b-it-v0.1-ggufをColabとollamaで試す。

Swallowの新しいモデルが公開されましたので、早速試してみます。mmngaさんがGUFFに変換したモデルを利用します。ColabのL4環境を利用します。VRAM占有率は19773MiB /  23034MiBでした。

 

日本語は、さすがに自然です。比較的簡潔な文章を生成していました。基本的な性能はGemma-2の性能も手伝って問題なさそうです。が、長めのテキストを参照用として入れ込んだ場合には、それをうまく活かした回答ができませんでした。量子モデルで十分な検証ではありませんが、気になった点です。

 

公式サイトでも述べられていましたが、27Bクラスだと、Gemma 3 27B ITの性能は高いですね。今回発表されたGemma-2-Llama-Swallowでは2B/9Bといった小型のモデルでも自然な日本語が期待でき、商利用も可能なモデルとして活用できます。ローカルLLMの選択肢が広がるのは嬉しいです。

 

huggingface.co

swallow-llm.github.io

mmnga/Gemma-2-Llama-Swallow-27b-it-v0.1-gguf · Hugging Face

 

 

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

それは人それぞれ好みが分かれるところですね!

* **キュートな可愛さなら**、きっと**さやか**が人気でしょう。明るい笑顔と元気な性格は、見ている人を幸せにしますよね。
* **ミステリアスな可愛さなら**、**まどか**かもしれません。少し大人びた雰囲気と、優しい瞳が魅力的です。
* **クールな可愛さなら**、**マミさん**でしょうか。強い意志と凛とした佇まいは、まさにカッコいい!

もちろん、**ほむら**のクールビューティーも捨てがたいですし、**杏子**の自由奔放さも魅力的です。

結局のところ、一番かわいいのは、あなたにとって誰なのか、ということですね!

CPU times: user 37.3 ms, sys: 5.57 ms, total: 42.9 ms
Wall time: 12.3 s

 

 

 

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

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

(割愛)

まどか☆マギカで一番かわいいのは、**暁美 ほむら**だと思います。

理由は以下の通りです。

* **ミステリアスでクールな雰囲気:** 赤い瞳と黒髪ボブの組み合わせが、どこか影のある魅力を醸し出しています。
* **強い意志と決意:**  時間操作の魔法を使うなど、強い力を持っているだけでなく、まどかを救うために何度も過去へ戻ろうとする強い意志を感じさせます。
* **戦闘シーンのかっこよさ:** 魔法少女としての戦闘シーンは、華麗で力強いアクションが印象的です。

もちろん、他のキャラクターもそれぞれ魅力的ですが、私はほむらのミステリアスさと強さに惹かれます。

CPU times: user 48.2 ms, sys: 4.67 ms, total: 52.9 ms
Wall time: 14.9 s

参照テキストと比較してみると根拠として採用されていません。

 

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

日本で二番目に高い山は **北岳** です。 

標高は3,190メートルです。

CPU times: user 11.7 ms, sys: 61 µs, total: 11.8 ms
Wall time: 2.25 s

正しいですね。

 

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

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

Wikipediaは、世界中のボランティアが協力して作る無料のオンライン百科事典です。

* **特徴:**
    * オープンコンテントで誰でも自由に利用可能
    * 商業広告なし
    * 寄付によって運営されている非営利団体ウィキメディア財団」が運営

* **名前の由来:**
    * 「ウィキ(Wiki)」というウェブページ編集システムと「百科事典(Encyclopedia)」を組み合わせた造語

 

CPU times: user 26.4 ms, sys: 4.31 ms, total: 30.7 ms
Wall time: 7.98 s

シンプルですけど、分かりやすいまとめです。

 

1+1*2+3/2+2^10を計算してください。計算が終わったら検算をしてください。最後に最終的な計算経過と結果を答えてください。

## 計算経過:

**1. 指数計算:** 2^10 = 1024

**2. 掛け算:** 1 * 2 = 2

**3. 割り算:** 3 / 2 = 1.5

**4. 足し算と引き算 (左から右へ):**
   * 1 + 2 = 3
   * 3 + 1.5 = 4.5
   * 4.5 + 1024 = 1028.5


## 結果:

1 + 1 * 2 + 3 / 2 + 2^10 = **1028.5**

 

## 検算:

電卓で計算すると、1028.5 となります。

CPU times: user 40.9 ms, sys: 6.38 ms, total: 47.3 ms
Wall time: 13.8 s

シンプルに答えてくれます。

 

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

 

##  部長と両さん

薄暗い居酒屋の片隅で、部長と両さんは向かい合っていた。テーブルには、ほとんど手つかずの料理と、冷え切ったビールが並んでいる。

両さん、本当に申し訳ない。こんな形で…」

部長の言葉は、かすれた声で、まるで自責の念に押しつぶされそうだった。彼は、両さんに頭を下げたまま、しばらくの間沈黙を続けた。

両さんは、静かに部長を見つめていた。彼の目は、いつも通りの鋭い光を放っていたが、そこにはどこか哀愁が漂っていた。

「部長…」

両さんはゆっくりと口を開いた。

「あの件は、もう終わったことだ。俺も、お前も、もう過去にとらわれる必要はない。」

彼はそう言うと、テーブルの上のビールを一口飲んだ。

部長は顔を上げ、両さんの目を見つめた。

「でも、両さん…あの時、俺が…」

「あの時、部長は自分の仕事を全うしようとしただけだ。そして、俺はそれを止められなかった。それだけのことだ。」

両さんは、静かに言った。彼の言葉には、どこか諦めのようなものを感じさせた。

部長は、両さんの言葉を聞いて、深くため息をついた。

「でも、俺たちは…」

「もう終わったことだ」

両さんは繰り返した。彼の目は、部長を優しく見つめていた。

「これから、どうするかだ。俺たちは、まだ前に進むことができる。」

両さんの言葉は、まるで希望の光のように、部長の心を照らした。彼は、ゆっくりと頷いた。

居酒屋の照明が、二人の顔に影を落としている。しかし、彼らの心の中には、すでに新たな決意が芽生え始めていた。

 


CPU times: user 77.9 ms, sys: 10.2 ms, total: 88.1 ms
Wall time: 29.2 s

自然な文章ですね。なんか、いい雰囲気です。

 

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

## 北岳 (Mount Kita)

**Overview:**

* **Location:** Southern Alps, Yamanashi Prefecture, Japan.
* **Elevation:** 3,190 meters (10,466 feet), the second-highest peak in the Japanese Alps and the highest in the Southern Alps.
* **Prominence:** 2,578 meters
* **Classification:**

    * Ranked as one of the "100 Famous Mountains of Japan" (日本百名山)
    * Part of the Southern Alps National Park

**Features:**

* Known for its rugged terrain and challenging hikes.
* Offers panoramic views of the surrounding mountains, including Mount Fuji.
* Home to diverse flora and fauna, including alpine plants and rare animals.

**Climbing:**

* Popular destination for mountaineers and hikers.
* Several trails lead to the summit, varying in difficulty.
* Best climbing season is from July to September.

**Cultural Significance:**

* Holds spiritual significance for local communities.
* Often depicted in Japanese art and literature.

 

Let me know if you'd like more specific information about North Kita, such as:

* Hiking trails and difficulty levels
* Flora and fauna found in the area
* History and cultural significance
* Nearby attractions

CPU times: user 600 ms, sys: 29.8 ms, total: 630 ms
Wall time: 31.1 s

英語になりましたが、しっかりまとめています。

 

日本語のプロンプトにして再度チャレンジします。

北岳は、日本の山梨県にある標高3,190mの山です。南アルプス国立公園に属し、日本百名山の一つに数えられています。

**地理:**

* 南アルプスの主峰であり、赤石山脈の最高峰です。
* 北岳間ノ岳農鳥岳を合わせて「北岳三山」と呼びます。
* 山頂からは富士山や中央アルプスなどの素晴らしい景色を見ることができます。

**登山:**

* 登山道は整備されており、初心者にも比較的登りやすい山です。
* 多くの登山者が訪れる人気の山です。
* 夏には高山植物が咲き乱れ、美しい景色を楽しむことができます。

**その他:**

* 北岳周辺には、温泉やキャンプ場などがあります。
* 山梨県南アルプス市にある「北岳山荘」は、登山者のための宿泊施設です。

 


CPU times: user 526 ms, sys: 16 ms, total: 542 ms
Wall time: 25 s

シンプルに要点をまとめていますね。

 

 

メモ:論文見ながらRAG実装をしてみる。Muti-Round Agent RAG編

勉強にとRAG実装を味見できるようにしたので、続けてトライします。LLMにはollamaを介してgemma3:4b-it-qatを利用します。このまま、GPT-4.1使っても動作するように準備しています。ローカルLLMの方で気楽に挑戦します。

 

今回はこの論文を参考にRAGを作ってみます。

”Retrieval-Augmented Generation with Conflicting Evidence”

Han Wang Archiki Prasad Elias Stengel-Eskin Mohit Bansal

https://arxiv.org/pdf/2504.13079v1

 

retrieved documentsにしばしば含まれる対立した情報の解決にマルチエージェントを利用する方法です。誤情報やノイズをエージェントに議論させます。それを数ラウンド回して答えを得るというものです。

 

この時、エージェントに個性を持たせておいて、retrieved documentsはそれぞれのdocumentを各エージェントが一回は解釈するようにプログラムします。論文そのままを作りこむのは大変なので、簡略化して実装します。

  1. retrieved documentsを収得する
  2. それぞれのAgentにdocumentsを割り当て議論。
  3. 議論の結果から有益な情報をまとめる。
  4. 2,3を繰り返してAgentがすべてのdocumentsを見るようにする。
  5. 最終的な答えをとりまとめる。

 

Qwen2,2,5, 3のテクニカルレポートをpdfの中に混ぜておいて以下のような問と答えが得られました。

Query: What is Qwen3?

 

Final Answer
Summary: Qwen3 is a collection of open-weight large language models (LLMs) with parameters ranging from 0.6 billion to 235 billion, utilizing both dense and Mixture-of-Experts (MoE) architectures, and operating in ‘thinking’ and ‘non-thinking’ modes. It was pre-trained on 36 trillion tokens across 119 languages and dialects.

Explanation: The agents converge on several key aspects of Qwen3. All agree it's a collection of LLMs. Parameter ranges consistently state 0.6 billion to 235 billion. Most importantly, they all confirm the use of Mixture-of-Experts (MoE) architectures, ‘thinking’ and ‘non-thinking’ modes, and a significant training dataset (36 trillion tokens) across 119 languages. The fact that it's open-weight is also confirmed by multiple agents. Therefore, the final answer combines the most consistent and salient details.

この問いには、しっかり答えてくれました。各ラウンドの答えの差もあまりなかったので、この方法じゃなくてもいい感じでしょうか。

What is Qwen?

 

Final Answer
Summary: Qwen is an open-weight series of large language models (LLMs), including Qwen3, pre-trained on over 7 trillion tokens and designed for various applications.

Explanation: The agents provide several confirmations of Qwen's core characteristics. Multiple agents (1, 2, 4, 6, 8, 9, 10) state it's a series of LLMs. Agent 1 corrects the token count from 7 trillion to over 7 trillion. Agent 4 and 8 specify it’s ‘dense.’ Agent 9 notes it’s a ‘foundation model family’. Considering all statements, the most accurate and comprehensive summary is that Qwen is an open-weight series of LLMs, pre-trained on a substantial amount of data (over 7 trillion tokens), built for diverse applications, and represents a significant step in the LLM landscape.

Qwen3は36trilliontokensを学習させているので、7 trillion tokensとするのは間違いですが、エージェントがover 7 trillionと訂正させていてかろうじて間違いを回避しています(笑)確かに多角的な分析がプラスに働いているように見えます。

 

retrieved documentsはchunkした細切れの文章です。情報の対立と云うより意味が通らない時もあるでしょう。そんな時には、こんな簡単な実装でも一定の効果がありそうです。ただ、context lengthが長いモデルが増えてきています。各社のAPIであれば結構なcontext lengthが確保できます。その場合は、retrieved documentsをざっくり各Agentsに投入し、評価させて議論させてしまう方が手っ取り早そうです。従来のMuti-Agentと変わらないようになりますが、対立した情報の取捨選択をプロンプトに入れつつ、各エージェントの性格付けをすることで、対ノイズ性を向上させることができるのではと考えました。

 

と、楽しく考えてみました。

 

今回作成したもの

github.com

 

 

 

メモ:論文を見ながらRAGを実装してみる。

LLMを使ったプログラムはすっかり普通になりました。ローカルLLMでも、利用しやすいものも出てきて気軽に利用できます。一方で、RAGは様々な方法が提案がされています。読んだだけで、さくっと実装できて、利用できそうなコードなのかという感触は早めに得たい。論文を完璧に実装するつもりはありません。同じ環境をそろえることもできませんし、追試をしたいわけでもありません。単なる趣味的にLLMを利用した実装検討の一環です。

 

まず、DeepRAG、RRAというRAGに関する論文をArXivから入手し、それをもとに簡単なRAGをStreamlitで実装します。PRFをパースし回答するという単純なものです。LLMの実装には、langchainを使って実装します。LLMはollamaで動作させます。テキストのチャンクや、様々な細かい調整はせずに簡単に実装が可能か、という視点で作成します。

 

LLMの利用の流れ

  1. ChatGPTにPDFを読み込ませ、上記の条件で実現するコードのたたき台を作成させます。
  2. 得られたコードをVS CodeGithub Copilotの無料枠を利用して、動作できるレベルまで訂正していきます。Copilot君に指示する方が文字数多くなりそうなものは、直接手直しをします。
  3. README.mdを作成させて、書き直ししたり追記します。

以上で完成です。中途半端な実装だったり、論文の主要なエッセンスだけの実装だけだったりの様な気もしますが、手を動かしながらお勉強だと思って割り切ります。筆者がソースコードを公開していたりするので、無駄なことをやっているケースもあると思います。

 

正確さを求めなければ思ったより、簡単に動作できるまでは終わります。寝る前の短時間でできます。ただ、利用するライブラリの基本的な使い方を理解して指示しないと無駄な工数がかかりそう。また、基本的な動作を盛り込んだコードを作ってしまえば、それを参考にさせるような指示をだせば、思った通りに近いものが早々に出来上がりました。サンプルコードや模擬コードで示すのがよかったです。もしかして、人間相手でもそうなのかも・・・。

 

気になるRAG手法の実装雰囲気を楽しめます。ちょっと続けてみようかな。

 

github.com