diff --git a/i18n/ja/code.json b/i18n/ja/code.json index 6773f170f09..edd5174f4a2 100644 --- a/i18n/ja/code.json +++ b/i18n/ja/code.json @@ -8,7 +8,7 @@ "description": "Title for the open source projects feature" }, "homepage.feature.description1": { - "message": "オープンソースを探索し、共にAIを推進しましょう。", + "message": "オープンソースプロジェクトを紹介し、AI 開発の知見を共有します。", "description": "Description for the open source projects feature" }, "homepage.feature.title2": { @@ -16,7 +16,7 @@ "description": "Title for the technical documentation feature" }, "homepage.feature.description2": { - "message": "私たちのオープンソースの知見を提供し、開発を支援します。", + "message": "技術ドキュメントと実装メモを公開し、開発を支援します。", "description": "Description for the technical documentation feature" }, "homepage.feature.title3": { @@ -24,7 +24,7 @@ "description": "Title for the paper notes feature" }, "homepage.feature.description3": { - "message": "論文の感想や見解を記録し、思考プロセスと要点を共有します。", + "message": "論文ノートを整理し、要点と考察を共有します。", "description": "Description for the paper notes feature" }, "theme.blog.paginator.navAriaLabel": { @@ -470,7 +470,7 @@ "description": "The title of the tag list page" }, "homepage.tagline": { - "message": "ここは私たちのテクノロジーの遊び場です", + "message": "ここは私たちの技術的な遊び場です", "description": "Title for homepage tagline" }, "homepage.recentUpdatesTitle": { @@ -497,11 +497,11 @@ "description": "Title for homepage featured projects" }, "homepage.demoTitle": { - "message": "ショーケース", + "message": "デモ", "description": "機能展示 for homepage featured projects" }, "homepage.demoIntro": { - "message": "以下は、文書アライメントのためのDocAlignerと、機械可読領域を識別するMRZScannerのデモを実行しています。", + "message": "以下では、文書整列用の DocAligner と、機械可読領域を検出する MRZScanner のデモを試せます。", "description": "機能描述 for homepage featured projects" }, "homepage.docAlignerDemoDesc": { diff --git a/i18n/ja/docusaurus-plugin-content-blog/2025/03-24-build-a-resume/index.md b/i18n/ja/docusaurus-plugin-content-blog/2025/03-24-build-a-resume/index.md index 3ca3dbe3346..3621c667894 100644 --- a/i18n/ja/docusaurus-plugin-content-blog/2025/03-24-build-a-resume/index.md +++ b/i18n/ja/docusaurus-plugin-content-blog/2025/03-24-build-a-resume/index.md @@ -1,41 +1,41 @@ --- slug: build-a-resume -title: JSを使って履歴書を書いてみよう！ +title: JS で履歴書を書いてみよう！ authors: Z. Yuan image: /ja/img/2025/0324.webp tags: [JavaScript, React, Resume] -description: テンプレートに頼らず、自分でコードを書く！ +description: テンプレートに頼らず、自分でコードを書く --- -今回は履歴書を書く必要がある。 +今回は履歴書を書く必要がありました。 -そこで、いつものようにオンラインツールを探してみたが、どれもこれも昔ながらのパターンだった。テンプレートがあまり洗練されていないか、あるいは有料でしかダウンロードできないものばかりだった。 +そこでいつものようにオンラインツールを探してみたのですが、だいたい似たようなものばかりでした。テンプレートの見た目がいまひとつだったり、ダウンロードには課金が必要だったり。 -一通り見渡した後、心に一つの考えが浮かんだ： +一通り見たあと、頭に浮かんだのはこれだけです。 -> **毎日毎日、どうしてまた有料にするの？** +> **毎回毎回、どうしてすぐ課金になるんだろう？** -## それなら自分でやってみよう！ +## それなら自分で作ろう -履歴書を書いたことがある友人なら、内容が良く書けるのは一つのことだが、レイアウトが美しく仕上がるのもまた別の技だということはよく分かるはずだ。 +履歴書を書いたことがある人なら分かると思いますが、内容をきちんと書くことと、見た目をきれいに整えることは別問題です。 -文字が正確で、レイアウトが整然としており、スタイルが清潔でプロフェッショナルでなければならず、これらの要求は、普段ウェブサイトを作るのと同じくらいの手間がかかる。 +誤字がなく、レイアウトが整っていて、全体の雰囲気も清潔でプロフェッショナルであること。これらを全部そろえようとすると、やっていることはほとんど普段のフロントエンド実装と変わりません。 -そもそもウェブサイトが作れるなら、なぜJSを使って直接履歴書を書いてみないのだろうか？ +だったら、もともと Web を書けるのだし、JS でそのまま履歴書を組んでしまえばいいのでは？ -さらに、この方法ならレイアウトのスタイルを完全にカスタマイズでき、自由にモジュールを組み合わせることができ、バージョン管理も容易になる。加えて、Reactのコンポーネント化された構造特性により、保守もより明確になる。 +この方法なら、レイアウトも完全に自分で制御できますし、モジュールの組み替えも自由です。さらにバージョン管理もしやすく、React のコンポーネント構成のおかげで保守もしやすくなります。 ## 設定ファイル -履歴書の内容データは、すべてひとつの設定ファイル `resumeData.js` に集約している。 +履歴書の内容データは、ひとつの設定ファイル `resumeData.js` にまとめています。 -これにより、データと表示ロジックを明確に分離でき、将来的にデータを変更したり、言語を切り替えたり、さらにはAPIから取得することも可能になる。 +こうしておくと、データと表示ロジックをきれいに分離できます。後から内容を変更したり、言語を切り替えたり、将来的に API からデータを取るようにしたりするのも簡単です。 -このデータには主に個人情報、スキルリスト、「私について」、職務経験、個人的な成果、学歴などの項目が含まれている。 +このデータには、個人情報、スキル一覧、自己紹介、職務経験、個人成果、学歴などを含めています。 -以下はサンプル内容で、例としていくつかのデータを入力している： +以下はサンプルです。説明用にダミーデータを少し入れています。 ```javascript title="src/data/resumeData.js" const resumeData = { @@ -101,18 +101,18 @@ const resumeData = { export default resumeData; ``` -## 左右兩欄 +## 左右 2 カラム -今回は左右カラムのレイアウトを使用して履歴書を表現します。 +今回は左右 2 カラムのレイアウトで履歴書を構成します。 -このデザインは履歴書レイアウトのクラシックなスタイルであり、情報が明確に分類され、視覚的にも圧迫感が少ないです。 +この形式は履歴書では定番で、情報を分類しやすく、見た目にも窮屈になりにくいのが利点です。 -- 左側には主に静的な基本情報、例えば氏名、職位、連絡先、スキルなどを配置します -- 右側は経歴などの動的な内容、例えば自己紹介、職務経験、成果、学歴などを配置します +- 左側には、氏名、肩書き、連絡先、スキルなどの静的な基本情報を置く +- 右側には、自己紹介、職務経験、実績、学歴といった経歴系の情報を置く -### 聯繫資訊 +### 連絡先情報 -連絡情報の表示方法としては、アイコンとテキストを組み合わせて各種連絡手段を列挙し、リンク先（例：LinkedIn、GitHub、個人ウェブサイト）を含むことで、採用担当者がワンクリックであなたの情報にアクセスできるようにします： +連絡先は、アイコンとテキストを組み合わせて各種手段を並べる形にしました。LinkedIn、GitHub、個人サイトなどのリンクも付けておけば、採用担当者がそのまま確認できます。 ```javascript title="src/components/Resume/ContactInfo.js" import React from "react"; @@ -156,13 +156,13 @@ function ContactInfo() { export default ContactInfo; ``` -### スキルツリー +### スキル -スキルセクションは、視覚と情報の両面を兼ね備えた小さな見どころです。 +スキル欄は、視覚的にも情報量的にも分かりやすいポイントになります。 -各スキルには名称、熟練度ラベル、そして対応する進捗バーがあり、一目で得意分野とその程度が分かります。 +各スキルに名称、熟練度ラベル、進捗バーを付けておけば、どの分野が得意で、どの程度できるのかを一目で伝えられます。 -ここでは、`resumeData.skills` 配列から直接レンダリングし、各項目にはスキルの名称と熟練度のパーセンテージが含まれています： +ここでは `resumeData.skills` 配列をそのままレンダリングしています。 ```javascript title="src/components/Resume/Skills.js" import React from "react"; @@ -196,9 +196,9 @@ export default Skills; ### 自己紹介 -このセクションは通常、短くて力強い自己紹介文を掲載するために用いられます。 +このセクションには、短くても印象に残る自己紹介を書くのが向いています。 -ありきたりなテンプレート文句に陥らず、個人の専門性、技術の主軸、そして過去に積み上げた経験の核となる部分を強調してみてください： +ありきたりな定型文ではなく、自分の専門領域、技術の軸、これまで積み上げてきた経験の核をはっきり示した方が効果的です。 ```javascript title="src/components/Resume/AboutMe.js" import React from "react"; @@ -218,7 +218,7 @@ export default AboutMe; ### 職務経験 -このセクションは履歴書の重要な部分です。フォーマットとしては、カード型の構造を使用することをお勧めします：職種、会社名、勤務期間、そしていくつかの具体的な職務内容や成果を記載することで、HRや上司があなたが行った業務内容や成果を素早く把握できるようにします。 +ここは履歴書の中心になる部分です。カード型の構成にして、職種、会社名、在籍期間、具体的な業務内容や成果をまとめると、採用担当者が内容を素早く把握しやすくなります。 ```javascript title="src/components/Resume/WorkExperience.js" import React from "react"; @@ -251,15 +251,15 @@ function WorkExperience() { export default WorkExperience; ``` -### 個人の実績 +### 個人成果 :::tip -一部の企業ではエンジニアがブログを書くことを禁止している場合がありますので、使用には注意が必要です。 +会社によっては、エンジニアの個人ブログ運営を歓迎しない場合もあるので、記載するかどうかは状況を見て判断してください。 ::: -正社員としての仕事以外にも、もしブログを運営していたり、オープンソースプロジェクトに参加したり、コンテストに参加した経験があれば、それらも非常に価値のある情報です。 +正職での仕事以外にも、ブログ運営、オープンソース活動、コンテスト参加などがあれば、十分に書く価値があります。 -これらの情報は、時には正式な職務よりもエンジニアとしての情熱や継続的な取り組みの姿勢を強調することができます。 +こうした情報は、正式な職歴以上に、エンジニアとしての熱意や継続性を伝えてくれることがあります。 ```javascript title="src/components/Resume/PersonalAchievements.js" import React from "react"; @@ -286,9 +286,9 @@ export default PersonalAchievements; ### 学歴 -こちらのフォーマットは比較的シンプルですが、レイアウトを分かりやすく、整理された形にすることが重要です。 +ここは比較的シンプルなセクションですが、やはり見やすさと整理の良さは重要です。 -もしあなたが新卒や転職者であれば、学歴が比較的大きな比重を占めることになりますので、特にしっかりと表現することが求められます。 +新卒や異業種からの転職であれば、学歴の比重が高くなることもあるので、丁寧に見せた方がよいでしょう。 ```javascript title="src/components/Resume/Education.js" import React from "react"; @@ -314,9 +314,9 @@ function Education() { export default Education; ``` -### 左側欄 +### 左カラム -連絡先情報とスキルは左側の欄に配置し、上部には名前と職種を並べることで、全体の構造が分かりやすく、情報が一目で理解できるようにします。 +左側には連絡先とスキルを配置し、最上部に氏名と職種を置いて、全体の情報構造がひと目で分かるようにします。 ```javascript title="src/components/Resume/LeftColumn.js" import React from "react"; @@ -342,9 +342,9 @@ function LeftColumn() { export default LeftColumn; ``` -### 右側欄 +### 右カラム -右側の欄は、動的な履歴情報を表示するために使用します。例えば自己紹介、経験、学歴などが含まれます。この配置は、採用担当者が読む際の習慣にもより合ったものです： +右側には、自己紹介、職務経験、実績、学歴といった動的な履歴情報を配置します。この方が読む側の視線の流れにも自然に合います。 ```javascript title="src/components/Resume/RightColumn.js" import React from "react"; @@ -367,10 +367,9 @@ function RightColumn() { export default RightColumn; ``` - ## 統合表示 -最後に、左右の欄を統一のコンテナコンポーネントに包み込むことで、履歴書全体が完成します。 +最後に、左右のカラムをひとつのコンテナコンポーネントにまとめれば、履歴書全体の構成は完成です。 ```javascript title="src/components/Resume/ResumeContainer.js" import React from "react"; @@ -390,17 +389,17 @@ function ResumeContainer() { export default ResumeContainer; ``` -CSSの部分については、別途スタイルファイルを分けており、メンテナンスやカスタマイズがしやすいようにしています。こちらにスタイルファイルのリンクを添付しますので、スタイルはこのファイル内で全て管理されており、デザイン変更もお好みで行えます。 +CSS は別ファイルに切り出してあり、保守やカスタマイズがしやすいようにしています。スタイルは以下のファイルでまとめて管理しています。 - [**src/components/Resume/resume.css**](https://github.com/DocsaidLab/website/blob/main/src/components/Resume/resume.css) ## 完成品 -実行後の成果は以下の図の通りです。 +実行後の見た目は次のとおりです。 -全体的に見て、清潔でシンプル、整然としており、市販の有料テンプレートに引けを取らないクオリティです。また、この履歴書は100%カスタマイズ可能で、100%コントロールできるため、内容の変更やモジュールの追加、さらには言語の変更も非常に簡単に行えます。 +全体として、すっきりしていて見やすく、有料テンプレートと比べても十分戦える仕上がりです。しかも、この履歴書は 100% カスタマイズ可能で、内容の差し替えやモジュール追加、言語切り替えもとても簡単です。 -もしあなたも自分だけの技術履歴書を作りたいのであれば、JSで自作する方法は、面白い挑戦になるかもしれません。 +もし自分だけの技術履歴書を作ってみたいなら、JS で自作するのはかなり面白い方法だと思います。 import ResumeContainer from '@site/src/components/Resume/ResumeContainer'; import { Helmet } from "react-helmet"; @@ -422,11 +421,11 @@ import { Helmet } from "react-helmet"; ## 最後に -もしHTMLファイルをPDFに変換したい場合は、`puppeteer`パッケージを使用することができます。 +HTML ファイルを PDF に変換したい場合は、`puppeteer` パッケージが使えます。 -このパッケージは、Chromeチームによって開発されたヘッドレスブラウザの自動化ツールで、プログラムでブラウザの動作を制御できるようにします。たとえば、ウェブページを開いたり、ボタンをクリックしたり、スクリーンショットを撮ったり、ページ全体をPDFに変換することができます。 +これは Chrome チームが開発している headless browser 自動化ツールで、プログラムからブラウザを操作できます。Web ページを開く、ボタンを押す、スクリーンショットを撮る、ページ全体を PDF にする、といった処理が可能です。 -以下は、Puppeteerを使って履歴書のHTMLをPDFに出力する簡単な例です： +以下は、Puppeteer を使って履歴書の HTML を PDF として出力する簡単な例です。 ```js title="html2pdf.js" const puppeteer = require('puppeteer'); @@ -435,7 +434,7 @@ const puppeteer = require('puppeteer'); const browser = await puppeteer.launch(); const page = await browser.newPage(); - // ローカルHTMLまたはリモートURLを読み込む + // ローカル HTML またはリモート URL を読み込む await page.goto('http://localhost:3000/resume', { waitUntil: 'networkidle0', }); @@ -450,8 +449,8 @@ const puppeteer = require('puppeteer'); })(); ``` -`goto()`内のURLは、ローカル開発サーバー（例えばlocalhost）またはデプロイ後の履歴書ページのURLでもかまいません。 +`goto()` に渡す URL は、ローカル開発サーバー（localhost）でも、デプロイ後の履歴書ページでも構いません。 -`printBackground: true`を設定すると、設定したCSSの背景や色を保持することができます。もしページに動的なデータレンダリング（例えばReactのSPA）が含まれている場合は、内容が完全に読み込まれてからエクスポートするようにしてください。`waitUntil: 'networkidle0'`はより安全な方法です。 +`printBackground: true` を指定すると、CSS で設定した背景や色をそのまま保持できます。React の SPA のように動的レンダリングがあるページでは、内容が完全に読み込まれてから出力するようにしてください。`waitUntil: 'networkidle0'` はそのための比較的安全な指定です。 -これで、JSで作成した素晴らしい履歴書を簡単に高品質のPDFに変換し、送信したり、印刷したりすることができます！ \ No newline at end of file +これで、JS で作った履歴書を高品質な PDF として簡単に書き出せます。送付にも印刷にもそのまま使えます。 diff --git a/i18n/ja/docusaurus-plugin-content-docs-papers/current/deepseek/2501-deepseek-r1/index.md b/i18n/ja/docusaurus-plugin-content-docs-papers/current/deepseek/2501-deepseek-r1/index.md index b16cf487157..d4165769ed2 100644 --- a/i18n/ja/docusaurus-plugin-content-docs-papers/current/deepseek/2501-deepseek-r1/index.md +++ b/i18n/ja/docusaurus-plugin-content-docs-papers/current/deepseek/2501-deepseek-r1/index.md @@ -3,79 +3,79 @@ title: "[25.01] DeepSeek-R1" authors: Z. Yuan --- -## 強化学習によるひらめき +## 強化学習が生んだ「ひらめき」 [**DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning**](https://arxiv.org/abs/2501.12948) --- -この論文を読むために、前の 3 世代の DeepSeek アーキテクチャを振り返る必要がありました。 +この論文をきちんと読むために、先に DeepSeek の前 3 世代のアーキテクチャを振り返る必要がありました。 -どの論文もレンガのように分厚いもので、今思い返すと、本当に簡単ではなかったと感じます。 +どの論文もかなり分厚く、今振り返っても、読み切るだけでなかなか大変でした。 -## 問題の定義 +## 問題設定 -OpenAI の o1 シリーズは最近、推論段階で推論チェーン（Chain-of-Thought）を延長する方法を最初に導入し、モデルの複雑な推論タスクにおけるパフォーマンスを大幅に向上させたことで話題になりました。 +OpenAI の o1 シリーズは、推論段階で Chain-of-Thought を長く使うアプローチを前面に出し、複雑な推論タスクで大きな性能向上を示したことで注目を集めました。 -過去にも「プロセス報酬モデル」「強化学習」「探索アルゴリズム（モンテカルロ木探索やビームサーチなど）」を使用して、モデルの推論能力を改善しようとする研究がありましたが、o1 シリーズのような総合的な理論推論能力には達していませんでした。 +以前から、「過程報酬モデル」「強化学習」「探索アルゴリズム（モンテカルロ木探索や Beam Search など）」を使ってモデルの推論能力を改善しようとする研究はありましたが、o1 シリーズのような総合的な理論推論能力には届いていませんでした。 -それで、これで終わりにしてしまうのでしょうか？ +では、そこで終わりにするのか？ -それではだめです！研究者たちの頑固な性格は無駄ではありません。 +もちろん、そうはなりません。 -DeepSeek 研究チームは、この論文で初めて「単純な強化学習」を使って、言語モデルの推論能力を駆動することを試みました。監視データには全く依存しません。こうして、著者は DeepSeek-V3-Base をベースモデルとして、数千回の RL ステップを経て、最初のモデルを作り上げました。これが DeepSeek-R1-Zero と呼ばれるものです。 +DeepSeek の研究チームはこの論文で、**純粋な強化学習だけで言語モデルの推論能力を引き上げられるか**を初めて本格的に試しています。監督データには依存せず、DeepSeek-V3-Base を基盤モデルとして、数千回の RL ステップを経て最初のモデルを作りました。それが DeepSeek-R1-Zero です。 -では、問題は解決したのでしょうか？ +では、これで問題は解決したのか。 まだです。 -DeepSeek-R1-Zero の後が、本当のスタートだったのです。 +本当の話は、DeepSeek-R1-Zero のあとから始まります。 ## 問題の解決 ### DeepSeek-R1-Zero -まず、DeepSeek-V3-Base をベースモデルとして使用し、監視付きの微調整段階を省略し、直接強化学習アルゴリズムを使って訓練します。 +まず、DeepSeek-V3-Base をベースモデルとして使い、監督微調整を飛ばして、いきなり強化学習をかけます。 -RL の訓練コストを下げるために、本文では GRPO 法を採用しています。この方法は、戦略モデルと同じ規模のクリティックモデルを使用せず、スコアセットに基づいて基準を推定します。 +RL の学習コストを抑えるために、この論文では GRPO を採用しています。これは、方策モデルと同規模の critic を持たず、一群のスコアから基準線を推定する方法です。 :::info -GRPO アルゴリズム、元々は Group Relative Policy Optimization という名前で、これも DeepSeek が以前発表した論文です。時間があれば、こちらも確認できます： +GRPO は Group Relative Policy Optimization の略で、これ自体も以前に DeepSeek が提案した手法です。興味があれば、こちらも読むとつながりが見えます。 - [**[24.02] DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models**](https://arxiv.org/abs/2402.03300) - ::: +::: -GRPO アルゴリズムでは、モデルが自分で「より良い回答」を生成する方法を「学ぶ」ことを期待しています。その核心的なプロセスは以下のステップで構成されています： +GRPO の狙いは、モデル自身に「よりよい答えを出すにはどうすればいいか」を学ばせることです。流れを簡単に整理すると次のようになります。 -- **1. 旧モデルから複数の答えを生成** +- **1. 旧モデルから複数の答えを生成する** - - **各問題 $q$ に対して**： 旧戦略 $\pi_{\theta_{\text{old}}}$ を使って答えのセットを生成します + - **各問題 $q$ に対して**、旧方策 $\pi_{\theta_{\text{old}}}$ を使って答えの集合 $$ \{o_1, o_2, \dots, o_G\} $$ - ここで、$G$ は答えの数です。 + を生成します。ここで $G$ は答えの数です。 *** -- **2. 答えの評価：優位性 $A_i$ の計算** +- **2. 各答えの優位性 $A_i$ を計算する** - 答えの良し悪しを測るために、各答え $o_i$ は報酬 $r_i$ を得ます。 + 各答え $o_i$ には報酬 $r_i$ が与えられます。 - どの答えが良いかを比較するために、著者は優位性 $A_i$ を以下のように定義しています： + どの答えが平均より良かったかを比較するため、論文では優位性 $A_i$ を次のように定義しています。 $$ A_i = \frac{r_i - \text{mean}(\{r_1, r_2, \dots, r_G\})}{\text{std}(\{r_1, r_2, \dots, r_G\})} $$ - この式は、ある答えが平均のパフォーマンスをどれだけ超えているか（標準偏差を使って標準化）を示しています。 + これは、ある答えが平均との差でどれだけ優れていたかを、標準偏差で正規化して表したものです。 -- **3. 新しいモデルの最適化：目的関数の最大化** +- **3. 新モデルを最適化する** - 新しいモデル $\pi_\theta$ が、より高得点の答えを生成することを学ぶことを望んでいます。 + 新しいモデル $\pi_\theta$ が、より高得点な答えを出しやすくなるように学習させます。 - そのために、著者は次のような目的関数を設計しました： + そのための目的関数は次のとおりです。 $$ \begin{aligned} @@ -86,21 +86,21 @@ GRPO アルゴリズムでは、モデルが自分で「より良い回答」を \end{aligned} $$ - この式を見ると、ついスクロールしたくなりますが、心配しないで、ひとつずつ見ていきましょう： + 見た目は大変そうですが、要点はそこまで複雑ではありません。 - - **確率比率** - $\frac{\pi_\theta(o_i|q)}{\pi_{\theta_{\text{old}}}(o_i|q)}$ は、新しいモデルが答え $o_i$ を生成する確率が旧モデルと比較してどのように変化したかを示しています。 + - **確率比** + $\frac{\pi_\theta(o_i|q)}{\pi_{\theta_{\text{old}}}(o_i|q)}$ は、新モデルが答え $o_i$ を出す確率が旧モデルと比べてどれだけ変わったかを表します。 - **優位性 $A_i$ を掛ける** - もし答えが平均より良ければ（$A_i$ が高ければ）、新しいモデルはその答えを生成する確率を増加させたいと考えます。 + 平均より良かった答えほど、その答えを出しやすくする方向に更新したいわけです。 - **clip 操作** - 確率比率の変動が大きくなりすぎないように、これを制限し、$[1-\epsilon,\, 1+\epsilon]$ の範囲内に収めます。ここで$\epsilon$は超パラメータで、モデルの変動に「安全帯」を設定するようなものです。 + 更新が大きくなりすぎると不安定になるので、変化量を $[1-\epsilon, 1+\epsilon]$ の範囲に抑えます。 - - **KL 散度ペナルティ** - $\beta D_{KL}\big(\pi_\theta||\pi_{ref}\big)$ はペナルティ項で、新しいモデルと参照モデル $\pi_{ref}$ の違いを測り、モデルが元の安定した戦略から逸脱しないようにします。 + - **KL 散度のペナルティ** + $\beta D_{KL}(\pi_\theta||\pi_{ref})$ によって、参照モデルから大きく逸脱しすぎないようにします。 - KL 散度の計算方法は次の通りです： + KL 散度は次の形で計算されます。 $$ D_{KL}\big(\pi_\theta||\pi_{ref}\big) = \frac{\pi_{ref}(o_i|q)}{\pi_\theta(o_i|q)} - \log\frac{\pi_{ref}(o_i|q)}{\pi_\theta(o_i|q)} - 1 @@ -108,26 +108,24 @@ GRPO アルゴリズムでは、モデルが自分で「より良い回答」を *** -どうですか？実際、そんなに難しくはないでしょう？ - -モデルは $J_{GRPO}(\theta)$ の最大化を通じて、パラメータを調整します。これは、新しいモデルが、より高い報酬（高い $A_i$）を得た答えを生成する傾向が強くなり、同時に変化の安定性を保つことを意味します。 +要するに、$J_{GRPO}(\theta)$ を最大化することで、新モデルは「報酬の高かった答えを出しやすくしつつ、急に壊れない範囲で更新する」ように学びます。 -報酬は強化学習の訓練信号であり、最適化の方向を決定します。 +報酬は強化学習における学習信号であり、最適化の方向そのものを決めます。 -研究チームは、本論文でルールベースの報酬システムを採用しており、主に次の 2 種類の報酬が含まれています： +この論文では、ルールベースの報酬系を採用しています。主に次の 2 種類です。 -- **正確性報酬**：回答が正しいかどうかを評価します。例えば、数学の問題では、モデルが特定の形式（例えば、答えを囲む）で最終的な答えを出すことを要求し、その結果、規則に基づいて検証可能です。LeetCode の問題においては、コンパイラと予め設定したテストケースを使って検証できます。 -- **フォーマット報酬**：モデルが思考過程を `` と `` タグ内に配置するように要求し、出力が予め設定された形式に従うことを確保します。 +- **正確性報酬**：回答が正しいかどうかを評価する。たとえば数学では、特定形式で最終答えを出させることでルールベースに検証できる。LeetCode 系の問題であれば、コンパイラとテストケースで確認可能。 +- **フォーマット報酬**：思考過程を `` と `` に入れさせ、出力形式を一定に保つ。 :::info -本論文では、ニューラルネットワークベースの結果やプロセス報酬モデルは採用していません。その理由は、大規模な RL プロセスにおいて「報酬ハッキング」の問題が発生しやすく、報酬モデルを再訓練することが追加のリソースを必要とし、全体のプロセスが複雑になるためです。 +本論文では、ニューラルネットベースの結果報酬モデルや過程報酬モデルは使っていません。大規模 RL では reward hacking が起きやすく、報酬モデルの再学習も追加コストと複雑性を持ち込むからです。 ::: :::tip -報酬ハッキング（Reward Hacking）は、強化学習の過程でエージェントが報酬関数の予期しない欠陥や弱点を利用し、報酬値を迅速に増加させる戦略を見つけることを指しますが、これらの戦略は必ずしも設計者の本来の目標に沿っていない場合があります。 +Reward Hacking とは、エージェントが報酬関数の抜け穴を突いて高い報酬だけを取りにいき、本来の目的から外れてしまう現象です。 ::: -DeepSeek-R1-Zero の訓練時、著者はモデルにまず推論過程を生成させ、最終的な答えを提供させる簡単で明確なテンプレートを設計しました。以下の表に示します： +DeepSeek-R1-Zero の学習時には、まず推論過程を出し、そのあと最終答えを出すというシンプルなテンプレートを使っています。
@@ -135,9 +133,9 @@ DeepSeek-R1-Zero の訓練時、著者はモデルにまず推論過程を生成
-この設計は、出力構造のみを制限し、内容面での偏見（例えば、反省的推論や特定の解法戦略を強制するなど）を避け、モデルが RL プロセス内で自然に進化する様子を観察することを目的としています。 +これは出力構造だけを制限し、内容面で特定の解法や反省スタイルを強制しない設計です。つまり、RL の中でモデルがどう自然に進化するかを観察したいわけです。 -次の図は訓練過程を示しており、DeepSeek-R1-Zero が AIME 2024 ベンチマークテストで、初期の 15.6%から安定的に 71.0%まで平均 pass@1 スコアを向上させ、OpenAI-o1-0912 モデルに匹敵する結果を示しています。さらに多数決機構（赤線）を用いることで、性能は 86.7%にまで向上しました。 +次の図を見ると、DeepSeek-R1-Zero は AIME 2024 において、平均 pass@1 を初期の 15.6% から 71.0% まで着実に伸ばし、OpenAI-o1-0912 に匹敵するところまで到達しています。さらに多数決を使うと、86.7% まで上がります。
@@ -145,7 +143,7 @@ DeepSeek-R1-Zero の訓練時、著者はモデルにまず推論過程を生成
-訓練が進むにつれて、モデルの思考時間は次第に長くなり、以下の図に示すように、テスト段階で数百から数千個の推論トークンを生成できるようになり、自己反省や他の解法の探索などの高度な行動が自然に発展するようになりました。これらは全て、RL 環境内でモデルが自発的に進化した結果です。 +学習が進むにつれて、モデルの思考時間は次第に長くなっていきます。テスト時には数百〜数千トークン規模の推論が可能になり、自己反省や別解探索のような高次の振る舞いが自然に現れます。
@@ -153,9 +151,9 @@ DeepSeek-R1-Zero の訓練時、著者はモデルにまず推論過程を生成
-訓練過程中、モデルはある中間バージョンで「Aha Moment」を迎え、より多くの思考時間を再配分し、初期の解法戦略を再評価することを学び始めました。これはモデルの推論能力の顕著な向上を示すだけでなく、RL が明示的な指導なしで高度な解法戦略を引き出す潜在能力を持っていることに驚かされる瞬間でした。 +そして学習途中で現れたのが、いわゆる **Aha Moment** です。モデルがより多くの思考時間を再配分し、最初の解法方針を自分で見直し始めます。これは、RL が明示的に教えなくても高度な解法戦略を引き出しうることを示しています。 -著者は論文内で「Aha Moment」の例を示しています： +論文中には、その例も載っています。
@@ -163,127 +161,120 @@ DeepSeek-R1-Zero の訓練時、著者はモデルにまず推論過程を生成
-この例から、いくつかの重要な点が分かります： +ここから読み取れるポイントは次の通りです。 -1. **問題と初期推論：** +1. **問題と初期推論** - 表には数学的な問題が示されています。例えば「もし $a > 1$ ならば、方程式 $\sqrt{a - \sqrt{a + x}} = x$ の実数解の和は何か？」という問題です。 + たとえば「$a > 1$ のとき、方程式 $\sqrt{a - \sqrt{a + x}} = x$ の実数解の和は何か」という問題に対し、モデルはまず平方して根号を外し、多項式形へ変形しようとします。 - モデルはまず平方を使って根号を消去し、方程式を多項式の形に変換しようとします。 +2. **途中での疑問と再考** -2. **途中の疑問と反省：** + 推論途中で、モデルは突然こう言います。 - 推論の過程で、モデルは突然立ち止まり、こう言います： + - "Wait, wait. Wait. That’s an aha moment I can flag here." - - 「Wait, wait. Wait. That’s an aha moment I can flag here.」 + つまり、自分の途中手順に違和感を覚え、立ち止まって再評価し始めたわけです。これが Aha Moment です。 - これは、あるステップに問題があるか不合理だと感じ、推論過程を再評価することを決定した瞬間を意味します。この突然の「ひらめき」が「Aha Moment」です。 +3. **Aha Moment の意味** + - **自己反省**：モデルが自分で疑義をマークし、誤りの可能性を意識している。 + - **戦略の進化**：単にルールをなぞるのではなく、途中で戦略を修正する方向へ進化している。 + - **人間らしい表現**：言い回し自体がかなり人間的で、思考している感じを強く与える。 -3. **Aha Moment の意義：** - - **自己反省：** モデルが自ら疑念を示し、解答の過程でエラーや修正が必要な部分を自覚している様子が見て取れます。 - - **進化的学習：** このような行動は、モデルが強化学習の過程で単に規則を機械的に実行するのではなく、戦略を調整し、推論過程を改善する方法を学びつつあることを示しています。 - - **人間らしい表現：** モデルが人間のような言い回しを使って「Aha Moment」を表現しており、思考・反省しているように感じられます。これは強化学習における自己進化能力の美しい表れです。 - -モデルの思考過程と自己チェックは、私たちに、強化学習の大規模プロセス内で、モデルがいかにして誤りから学び、修正する能力を高め、解題能力を向上させることができるかを証明しています。これこそが、強化学習が推論タスクにおいて示す強力な潜在能力と柔軟性です。 +こうした過程は、大規模強化学習の中で、モデルが誤りから学び、修正し、推論能力を高められることをよく示しています。 :::tip -ここまでで、このモデルはまだ使えません。 +ただし、この段階ではまだそのままでは使いにくいモデルです。 -DeepSeek-R1-Zero は推論能力において顕著な成果を上げましたが、出力の可読性が低い、言語が混在しているなどの問題が依然としてあります。これらの欠点を改善するために、後続の研究では人間らしい冷起動データを補助として使用した R1 モデルが導入されました。 +DeepSeek-R1-Zero は推論能力こそ大きく伸びましたが、出力が読みにくい、言語が混ざる、といった問題が残っています。そのため、後続研究では人間らしい cold start データを使った R1 が導入されます。 ::: ### DeepSeek-R1 -DeepSeek-R1-Zero の可読性や言語の混合問題を克服するために、研究チームはさらに人間らしい冷起動データを補助とした DeepSeek-R1 モデルを導入しました。 +DeepSeek-R1-Zero の可読性や言語混在の問題を改善するため、研究チームは人間らしい cold start データを補助に用いた DeepSeek-R1 を導入しました。 -この部分の核心は、精密に設計された多段階の訓練パイプラインを通じて、モデルが推論能力を維持しつつ、構造が明確で理解しやすい回答を生成できるようにすることです。 +要するに、推論能力を維持したまま、構造が明確で読みやすい出力に持っていくための多段階学習パイプラインです。 -DeepSeek-R1 の訓練プロセスは四つの段階に分かれており、順を追って見ていきましょう： +DeepSeek-R1 の学習は 4 段階に分かれます。 -- **冷起動 (Cold Start)** +- **Cold Start** - DeepSeek-R1-Zero と異なり、基盤モデルから直接 RL に入ると初期の不安定性が生じる可能性があります。 + DeepSeek-R1-Zero と違って、ベースモデルからいきなり RL に入ると初期不安定性が大きくなります。 - そのため、研究チームはまず少量の高品質な長チェーン思考（CoT）データを収集し、DeepSeek-V3-Base を微調整して、安定した RL 初期値を作り上げました。 + そこでまず、少量の高品質な長い CoT データを集め、DeepSeek-V3-Base を微調整し、安定した RL の初期値を作ります。 :::tip - 高品質な長チェーン思考データは、一般的に現在最強と認められているモデルを用いて生成されます。 + 高品質な長い CoT は、その時点で最も強いと考えられるモデルに作らせることが多いです。 ::: - **データ収集方法には以下が含まれます：** + **データ収集方法は主に次の通りです。** - - **Few-shot ヒント：** 長い CoT の例を使って解法の手順を示し、モデルに詳細な推論過程を模倣させる。 - - **直接ヒント生成：** 反省と検証を促進するヒントを設計し、モデルに体系的な回答を生成させる。 - - **優れた出力の抽出：** DeepSeek-R1-Zero から言語的に流暢で読みやすい回答を選出。 - - **人工後処理：** 最後に人間によって精練され、不適切または混乱した出力を排除。 + - **Few-shot プロンプト**：長い CoT の例を見せて、詳細な推論過程を模倣させる。 + - **直接プロンプト生成**：反省や検証を促すプロンプトを設計し、より整理された回答を出させる。 + - **良質な出力の抽出**：DeepSeek-R1-Zero の出力から、言語的に流暢で読みやすいものを選ぶ。 + - **人手での後処理**：最終的に人手で整え、不適切な出力や混乱した出力を除去する。 - データの可読性を確保するために、著者は固定の出力フォーマットを定義しました： + 可読性を確保するため、出力形式も固定しています。 ``` |special_token||special_token| ``` - ここで、`` は詳細な推論過程、`` はその推論過程の概要です。このフォーマットにより、完全な推論内容を保持しつつ、ユーザーが要点を迅速に把握できるようになっています。 + `` は詳細な推論、`` はその要約です。完全な思考過程を残しつつ、読者が要点もすぐ掴めるようにしています。 *** -- **推論指向の RL** +- **推論指向 RL** - 冷起動データの助けを借りて、まずモデルを安定状態にしてから RL 訓練を開始します。この段階の主な目的は、数学、プログラミング、科学、論理などの推論タスクにおけるモデルの能力をさらに強化することです。具体的な手順は以下の通りです： + Cold Start で安定化させたあと、本格的な RL を行います。目的は、数学・コード・科学・論理のような推論タスクをさらに強化することです。 - - **大規模な RL 訓練の開始：** - 微調整後の DeepSeek-V3-Base を基盤として、DeepSeek-R1-Zero と同様の RL 方法（例えば GRPO アルゴリズム）で訓練を続けます。 + - **大規模 RL の開始** + 微調整済み DeepSeek-V3-Base を土台に、DeepSeek-R1-Zero と同様の GRPO 系手法で学習を継続します。 - - **言語混合問題の処理：** - RL ヒントが複数の言語を含むとき、モデルが言語混合の現象を示すことが分かりました。この問題を解決するために、著者は「言語一致報酬」を導入し、その計算は CoT 内のターゲット言語の語彙比率に基づいて行われます。 + - **言語混在への対処** + RL プロンプトが多言語になると、モデルが言語を混ぜる傾向が出ました。そこで、CoT 内で目標言語の語彙比率に基づく「言語一致報酬」を導入します。 :::tip - この部分は一部の推論精度に若干影響を与えるかもしれませんが、全体の出力が人間の読解習慣により合致するようになりました。 + これは一部の推論精度を少し落とす可能性がありますが、全体としてははるかに読みやすくなります。 ::: - - **最終的な報酬設計：** - 推論精度報酬と語言一致報酬を加算し、モデル更新の最終的な訓練信号として使用します。これにより、新しいモデルは推論能力を向上させるとともに、出力の構造と可読性にも注意を払うようになります。 + - **最終報酬設計** + 推論の正確性報酬と言語一致報酬を加算し、最終的な訓練信号とします。 --- -- **拒否サンプリングと監視微調整** - - 推論指向の RL 訓練が収束した後、研究チームはさらに高品質な監視データを生成し、第二ラウンドの微調整を行ってモデルの汎用タスクでのパフォーマンスを向上させました。 +- **拒否サンプリングと監督微調整** - **データ生成は二つの大きなカテゴリーに分かれます：** + 推論指向 RL が収束したあと、さらに高品質な監督データを作り、2 回目の微調整を行って汎用タスク性能を上げます。 - - **推論データ：** + **データは 2 種類あります。** - - 拒否サンプリング法を用いて、RL 訓練から得られた答えの中から正確で代表的な推論過程を選びます。 - - 品質を保証するため、著者は言語混合、段落が長すぎる、コードブロックを含む出力をフィルタリングします。 - - 最終的に約 600,000 件の推論関連サンプルを収集します。 + - **推論データ** + - RL 出力から拒否サンプリングで、正しく代表性の高い推論過程を選ぶ。 + - 言語混在、段落過長、コードブロックを含む出力は除外する。 + - 最終的に約 60 万件の推論サンプルを収集する。 - - **非推論データ：** - - 書き込み、事実に基づく質問応答、自己認識、翻訳などのタスクが含まれ、これらのデータは DeepSeek-V3 の監視データから得られます。 - - いくつかのタスクでは、モデルに潜在的な CoT を生成させ、その後最終的な回答を生成させます。単純なクエリには CoT を生成しません。 - - この部分は約 200,000 件のサンプルです。 + - **非推論データ** + - 執筆、事実 QA、自己認識、翻訳などを含む。 + - 一部のタスクでは潜在 CoT を出してから最終回答を生成させる。 + - こちらは約 20 万件。 - これらのデータを統合すると、約 800,000 件のサンプルが収集され、DeepSeek-V3-Base に対して 2 回のエポックで監視微調整が行われ、モデルは推論と汎用タスクの両方で向上しました。 + 合わせて約 80 万件のデータで、DeepSeek-V3-Base を 2 epoch 監督微調整します。 :::info - 拒否サンプリング（Rejection Sampling）は統計的サンプリング手法の一つで、候補サンプルを生成した後、事前に定義した基準や評価指標に基づいて、条件に合わないサンプルを排除し、条件に合致するサンプルのみを保持する方法です。 - - この方法を使うことで、複雑で直接的にサンプリングが難しい分布から、高品質で特定の条件を満たすサンプルを得ることができます。 + Rejection Sampling は、候補サンプルを作ってから条件に合わないものを落とし、条件を満たすものだけを残す方法です。品質管理のためによく使われます。 ::: --- -- **全場面強化学習** - - モデルがユーザーのニーズにより適応できるよう、研究チームは第二段階の RL 訓練を実施しました。この訓練では、すべてのシーン（推論タスクに限らず）を最適化し、モデルの有用性（helpfulness）と安全性（harmlessness）を向上させました。 +- **全シナリオ強化学習** - 推論データについては、前述の規則に基づく報酬法を引き続き使用し、数学、プログラミング、論理などのタスクの推論精度を確保します。一般的なデータには、報酬モデルを用いて人間の好みを捉え、最終的な要約が有用で安全基準を満たすことを重視します。 + 最後に、モデルをより実用的にするため、推論タスクだけでなく広いシーンを対象に第 2 段階の RL を行います。有用性と安全性の両方を改善するのが狙いです。 - これにより、モデルは優れた推論能力を維持しつつ、人間らしさとリスク管理にも配慮して回答を生成できるようになりました。 + 推論データには引き続きルールベース報酬を使い、一般データには報酬モデルを使って人間の好みを反映させます。とくに最終要約が有用で安全であることを重視します。 - この訓練段階を通じて、モデルは多くのタスクとシーンにおいて、バランスの取れた優れたパフォーマンスを達成することができました。 + こうして、強い推論能力を保ちながら、より人間にとって使いやすい出力へ調整していきます。 -## 討論 +## 考察 ### 評価結果 @@ -299,77 +290,26 @@ DeepSeek-R1 の訓練プロセスは四つの段階に分かれており、順 -上記の表は、DeepSeek-R1 が複数のベンチマークテストで示した評価結果です。グラフの領域別に説明します： - -- **英語の知識と推論タスク** - - - **MMLU、MMLU-Redux、MMLU-Pro** - これらの指標は、モデルの学術的および一般的な知識を評価するために使用されます： +上の表は DeepSeek-R1 の主要ベンチマーク結果です。領域ごとに見ると次のようになります。 - - **MMLU (Pass@1)：** モデルが最初の回答で正解を出す割合を示し、DeepSeek-R1 は 90.8 を記録しており、一部の競合と比較して高いスコアを達成しています。 - - **MMLU-Redux (EM)：** 精度一致（Exact Match）で評価し、DeepSeek-R1 は 92.9 のスコアを記録。これは精度の高い回答を提供する能力を示しています。 - - **MMLU-Pro (EM)：** 専門的な分野の問題に焦点を当て、DeepSeek-R1 は 84.0 を記録しており、DeepSeek-V3 よりも顕著に向上しており、特に STEM の問題での進展が反映されています。 - - - **DROP (3-shot F1) と IF-Eval (Prompt Strict)** - - - **DROP**：読解と数値推論能力をテストする指標で、DeepSeek-R1 は 92.2 の F1 スコアを達成しました。 - - **IF-Eval**：フォーマット遵守を評価する指標で、DeepSeek-R1 は 83.3 であり、他のモデルに若干劣りますが、全体的には優れた結果を出しています。 - - - **GPQA Diamond と SimpleQA** - - - **GPQA Diamond (Pass@1)**：複雑な知識問答におけるモデルのパフォーマンスを評価し、DeepSeek-R1 は 71.5 を記録。 - - **SimpleQA (Correct)**：簡単な事実に基づく問答の正確さを測定し、DeepSeek-R1 は 30.1 を達成しました。事実問答においては DeepSeek-V3 よりも明確に改善が見られますが、中文 SimpleQA では少し劣る結果となり、これは安全な RL 戦略による影響です。 - - - **FRAMES、AlpacaEval2.0、ArenaHard** - 長文、オープンドメイン問答、ライティングタスクに関連する指標です： - - **FRAMES (Acc.)**：DeepSeek-R1 は 82.5 を記録し、長文問答タスクにおける強力なドキュメント解析能力を示しています。 - - **AlpacaEval2.0 (LC-winrate)** と **ArenaHard (GPT-4-1106)**：ライティングとオープンドメイン問答におけるパフォーマンスを評価し、DeepSeek-R1 はそれぞれ 87.6% と 92.3% の勝率を達成しました。これにより、汎用性と実用性が強調されます。 - ---- +- **英語の知識・推論タスク** + - MMLU、MMLU-Redux、MMLU-Pro では、一般知識と専門知識の両方で高い水準を示しています。 + - DROP や IF-Eval では、読解・数値推論・フォーマット遵守能力も良好です。 + - GPQA Diamond や SimpleQA では、複雑な知識問題から単純事実 QA まで広く対応できています。 + - FRAMES、AlpacaEval2.0、ArenaHard では、長文理解と自由記述能力も強いことが分かります。 - **コード生成タスク** - - - **LiveCodeBench (Pass@1-COT) と Codeforces** - コード生成とアルゴリズム推論のパフォーマンスを評価する指標です： - - - **LiveCodeBench**：DeepSeek-R1 は 65.9 を記録し、Chain-of-Thought を使用してコードを生成する優れた能力を示しました。 - - **Codeforces (Percentile と Rating)**：Codeforces のコンテストで DeepSeek-R1 は高い評価を受け、Rating は 2029 で、トップレベルに位置しています。これにより、競技プログラミングにおける優れた能力を示しています。 - - - **その他のエンジニアリング関連指標** - - **SWE Verified (Resolved)**：エンジニアリングタスクに関連し、DeepSeek-R1 は 49.2 を記録し、いくつかの競合モデルと同等のパフォーマンスを示しました。 - - **Aider-Polyglot (Acc.)**：多言語プログラミングタスクにおいて DeepSeek-R1 は 53.3 を記録しました。若干のモデルには劣りますが、推論に基づくモデルの有利性が示されています。 - ---- + - LiveCodeBench や Codeforces では、コード生成とアルゴリズム推論でかなり高い性能を示しています。 + - ただし Aider のような実務寄りエンジニアリングタスクには、まだ改善余地があります。 - **数学タスク** - - - **AIME 2024、MATH-500、CNMO 2024** - 数学的な推論と問題解決を評価する基準です： - - **AIME 2024 (Pass@1)**：DeepSeek-R1 は 79.8 を記録し、OpenAI-o1-1217 と並ぶレベルのパフォーマンスを示しています。 - - **MATH-500 (Pass@1)**：DeepSeek-R1 は 97.3 を達成しており、複雑な数学問題の解決において優れた能力を示しています。 - - **CNMO 2024 (Pass@1)**：DeepSeek-R1 は 78.8 を記録し、中文の数学推論においても優れたパフォーマンスを示しています。 - ---- + - AIME 2024、MATH-500、CNMO 2024 では非常に高いスコアを出しており、数学推論は本モデルの強みのひとつです。 - **中国語タスク** + - CLUEWSC、C-Eval などでも競争力が高く、中国語の理解と推論能力も強いです。 + - 一方で C-SimpleQA は安全 RL の影響で一部クエリを拒否するため、絶対値だけを見ると少し不利になります。 - - **CLUEWSC、C-Eval、C-SimpleQA** - 中国語タスクにおいて、DeepSeek-R1 は非常に良いパフォーマンスを示しています： - - **CLUEWSC (EM)**：DeepSeek-R1 は 92.8 を記録し、中国語の理解と推論能力が強いことを示しました。 - - **C-Eval (EM)**：スコアは 91.8 で、再度、中国語の言語評価における競争力を証明しました。 - - **C-SimpleQA (Correct)**：DeepSeek-R1 は 63.7 を記録しましたが、DeepSeek-V3 よりも優れた結果が得られており、安全な RL 戦略の影響で一部のクエリが拒否されたことが原因です。安全 RL を解除すれば、正確性は 70% を超えると考えられます。 - ---- - -DeepSeek-R1 は MMLU、MMLU-Pro、GPQA Diamond など、教育主導の知識評価で素晴らしい結果を出し、特に STEM 領域の問題で大規模 RL トレーニングによる精度の大幅な向上が確認されました。 - -FRAMES、AlpacaEval2.0、ArenaHard の結果は、DeepSeek-R1 が長文ドキュメント、クリアな要約の生成、ライティングタスクにおいて優れた能力を示しており、これらの改善は最終段階の監視微調整と RL トレーニングにおける指示追従データの導入によるものです。 - -DeepSeek-R1 は数学的推論において OpenAI-o1-1217 と並ぶ結果を出し、コード生成やアルゴリズム競技でも優れたパフォーマンスを発揮しています。しかし、エンジニアリング関連のコードタスク（Aider など）では、さらなる改善が求められます。今後のバージョンでは、関連する RL データを追加することで、さらに改善されることが期待されます。 - -モデルが生成する要約の平均長さは、ArenaHard で 689 トークン、AlpacaEval2.0 で 2,218 文字であり、DeepSeek-R1 は GPT ベースの評価で長さの偏差を避け、安定性と多領域適応性をさらに証明しています。 - -全体として、DeepSeek-R1 は大規模強化学習と精密に設計された多段階訓練プロセスを通じて、複数のベンチマークで印象的なパフォーマンスを達成しました。これにより、知識問答、数学的推論、コード生成、中国語処理などの多方面での強力な能力が示され、今後のより強力で汎用的な言語モデル構築に向けた有力なサポートが提供されました。 +総じて、DeepSeek-R1 は大規模 RL と多段階学習によって、知識 QA、数学、コード生成、中国語処理などで非常に強い性能を達成しています。 ### 蒸留と強化学習の比較 @@ -379,54 +319,46 @@ DeepSeek-R1 は数学的推論において OpenAI-o1-1217 と並ぶ結果を出 -ここでの議題は、二つのシナリオを仮定して比較することです： - -1. 大規模モデルの推論パターンを小型モデルに蒸留する。 -2. 小型モデルで直接大規模 RL を行う。 +ここでは次の 2 つを比較しています。 -同じ小型モデルにおいて、実験結果は上記の表に示されており、Qwen-32B-Base モデルで 10,000 ステップ以上の RL 訓練を行い、DeepSeek-R1-Zero-Qwen-32B が得られました。もう一つは、DeepSeek-R1 から蒸留された DeepSeek-R1-Distill-Qwen-32B です。 +1. 大規模モデルの推論パターンを小型モデルに蒸留する +2. 小型モデルに対して直接大規模 RL をかける -その蒸留版の結果は、すべてのベンチマークにおいて RL を行ったバージョンを大きく上回っています。 +Qwen-32B-Base を使った実験では、DeepSeek-R1-Zero-Qwen-32B より、DeepSeek-R1 から蒸留した DeepSeek-R1-Distill-Qwen-32B の方が、全ベンチマークで大幅に良い結果を出しました。 -ここで著者は二つの結論を導き出しました： +ここから論文は 2 つの結論を引いています。 -1. **蒸留の効果は優れている**：強力なモデルの推論パターンを小型モデルに蒸留することで、パフォーマンスを大幅に向上させ、計算リソースの要求が大規模 RL を小型モデルで行うよりもはるかに少ないことが示されています。 -2. **RL の限界**：大規模 RL は知能の限界を突破するのに有効ですが、もし小型モデルだけで RL を行うと、計算リソースが非常に多く要求され、性能も蒸留方法に劣る可能性があります。そのため、今後既存の知能レベルを超えるためには、さらに強力な基盤モデルと大規模 RL の訓練が必要です。 +1. **蒸留は非常に強力**：強いモデルの推論パターンを小型モデルへ移すことで、少ない計算資源で大きく性能を上げられる。 +2. **小型モデル単体 RL には限界がある**：大規模 RL は知能の上限を押し広げる力を持つが、小型モデルだけでやると計算コストが重く、蒸留ほど効率的ではない場合がある。 ### 失敗した試み -DeepSeek-R1 の開発初期段階で、研究チームは他の方法も試みましたが、最終的に期待した結果を得られませんでした。 - -この部分では二つの方法について説明します： - -- **プロセス報酬モデル (Process Reward Model, PRM)**：PRM は理論的には、モデルが推論問題を解決する際により良い戦略を取るように導くことができますが、実際の応用では以下の三つの課題に直面しました： - - - **細かいステップの定義が難しい**：一般的な推論タスクで、どの細かいステップを明確に定義するかは非常に困難です。 - - **中間ステップの正確性の判定**：自動化されたアノテーションは理想的な結果を得ることが難しく、手動アノテーションではスケールアップが難しいです。 - - **報酬ハッキング問題**：モデルベースの PRM を導入することは、報酬ハッキングを引き起こしやすく、報酬モデルの再訓練は追加のリソースを要し、訓練プロセス全体の複雑さを増します。 - - PRM は、上位 N 個の出力を並べ替えたり、検索を補助することには一定の効果がありましたが、計算コストと適用難易度のため、その利点は限られていました。 +DeepSeek-R1 の初期開発では、他の方法も試されていますが、最終的には期待した成果を得られませんでした。 -- **モンテカルロ木探索 (Monte Carlo Tree Search, MCTS)** +- **過程報酬モデル (PRM)** + - 細粒度ステップの定義が難しい + - 中間ステップの正しさを大規模に評価しにくい + - reward hacking を誘発しやすい - AlphaGo や AlphaZero に触発されて、研究チームは MCTS を使ってテスト時の計算規模と探索能力を改善しようとしました。方法としては、回答をより小さな部分に分け、モデルに各推論ステップに対応するラベルを生成させ、その後、事前に訓練された価値モデルを使って誘導するというアプローチです。しかし、この方法は二つの大きな課題に直面しました： + PRM は並べ替えや探索補助には一定の効果がありましたが、コストと実装難度の割に決定打にはなりませんでした。 - - **探索空間が巨大**：チェスのようなゲームと比べて、トークン生成の探索空間は指数的に増加します。ノードの拡張上限を設定しても、モデルが局所最適解に陥りやすくなります。 - - **価値モデルの訓練が難しい**：価値モデルは各ステップの探索品質に決定的な影響を与えるのですが、精密な価値モデルを訓練すること自体が非常に難しく、そのため全体の探索プロセスの改良に影響を与えます。 +- **モンテカルロ木探索 (MCTS)** + - トークン生成の探索空間が巨大すぎる + - 良い価値モデルを作るのが難しい - そのため、MCTS は推論段階で事前訓練された価値モデルを使用してパフォーマンスを改善できましたが、自己探索によってモデルのパフォーマンスを持続的に向上させることは依然として大きな課題です。 + 推論時の改善には使える場面があるものの、自己探索だけで継続的に性能を押し上げるにはまだ難しい、というのが結論です。 ## 結論 -DeepSeek-R1 は冷起動データと反復的な強化学習微調整を組み合わせることで、最終的に多くのタスクにおいて OpenAI-o1-1217 と並ぶパフォーマンスを達成しました。これは、大規模強化学習が推論能力の向上に大きな潜在能力を持っていることを証明しています。 +DeepSeek-R1 は、cold start データと反復的な RL 微調整を組み合わせることで、多くのタスクで OpenAI-o1-1217 に匹敵する水準に達しました。これは、大規模強化学習が推論能力の向上に大きな可能性を持つことをよく示しています。 -現在、DeepSeek-R1 にはいくつかの既知の欠点が残っています。著者は論文の最後でこれらを明確に指摘しています： +ただし、著者自身もいくつかの弱点を挙げています。 -- **汎用能力**：R1 は一部のタスク（関数呼び出し、複数ターン対話、複雑なロールプレイングや JSON 出力）で V3 よりも若干劣っています。 -- **言語混合問題**：R1 は主に中英語に最適化されており、他の言語のクエリには言語混合が発生する可能性があります。 -- **プロンプティング（Prompting）**：R1 はプロンプトに敏感で、特に少数ショットプロンプトではパフォーマンスに影響を受けやすいです。著者はゼロショット設定で問題を直接説明し、出力形式を明確に指定することを推奨しています。 -- **ソフトウェアエンジニアリングタスク**：この種のタスクは評価時間が長いため、RL 訓練の効率に影響を与え、R1 はこの分野で顕著な優位性を示していません。 +- **汎用能力**：関数呼び出し、多ターン対話、複雑なロールプレイ、JSON 出力では V3 に劣る場面がある +- **言語混在**：主に中英に最適化されており、他言語では混在が起こりうる +- **プロンプト感度**：とくに few-shot プロンプトでは性能がぶれやすい +- **ソフトウェア工学タスク**：評価コストが高く、RL 学習も効率が悪くなりやすい -全体として、オープンソースモデルとクローズドソースモデルとの間には依然として差があるものの、DeepSeek-R1 の進展は両者のギャップを大幅に縮め、将来のオープンソースモデルの発展に新たな可能性を開きました。 +それでも、オープンソースモデルとクローズドモデルの差は確実に縮まっています。 -おそらく、次の突破口は、もはや特定の実験室や企業だけのものではなく、オープンソースコミュニティ全体の集団的努力から生まれるでしょう。 +次の大きなブレイクスルーは、特定の企業や研究所だけではなく、オープンソース全体の積み上げから出てくるのかもしれません。 diff --git a/i18n/ja/docusaurus-plugin-content-docs-playground/current/intro.md b/i18n/ja/docusaurus-plugin-content-docs-playground/current/intro.md index 6f0830f8755..9780dbf8fe4 100644 --- a/i18n/ja/docusaurus-plugin-content-docs-playground/current/intro.md +++ b/i18n/ja/docusaurus-plugin-content-docs-playground/current/intro.md @@ -4,38 +4,40 @@ sidebar_position: 1 # 遊び場 -モデルが完成したので、その能力を見せてみましょう！ +せっかくモデルを作ったのだから、その実力を実際に触って試せる場も用意しました。 -ここは、モデルを展示し、テストするための場所です。現在は 1 つのデモしかありませんが、時間が経つにつれて、さらに面白いモデルを追加していく予定です。 +ここは、モデルのデモと検証のためのスペースです。現時点では数は多くありませんが、今後も時間を見つけて、面白いモデルを少しずつ追加していく予定です。 -- [**DocAligner Demo**](./docaligner-demo.md) – これは文書の 4 つの角点を特定するツールで、後処理を行うために便利です。 -- [**MRZScanner Demo**](./mrzscanner-demo.md) – これは MRZ 領域向けの OCR アプリケーションです。 -- [**StockAnalysis Demo**](./stock-demo.md) – これは株式分析ツールで、現在は時間の都合で機能追加が難しいですが、今後さらに多くの機能を追加する予定です。 +- [**DocAligner Demo**](./docaligner-demo.md) – 文書の四隅を推定し、後続の補正や処理につなげるためのツールです。 +- [**MRZScanner Demo**](./mrzscanner-demo.md) – MRZ 領域向けの OCR アプリケーションです。 +- [**StockAnalysis Demo**](./stock-demo.md) – 株式分析ツールです。まだ十分に機能追加できていませんが、今後少しずつ拡張していく予定です。 ## ご案内 -クラウドサーバーのコストが非常に高いため、現在すべてのモデルは私の個人サーバーに展開されています。そのため、これらのデモを使用する際に、少し遅延が発生することがあります。しかしご安心ください、モデルは最適化されていますので、少しの忍耐でその効果を見ることができます。 +クラウドサーバーの利用コストがかなり高いため、現在はすべてのモデルを私個人のサーバー上で動かしています。 + +そのため、デモの利用時に多少の遅延が発生することがあります。ただし、できる限り最適化は行っているので、少し待っていただければ結果を確認できます。 ## 小さなお願い 🙏 -これらのデモはいつでも試していただいて構いません！ +これらのデモは、どうぞ自由に試してみてください。 -ただし、できるだけ「過労」にさせないようにお願いします。感謝します。 +ただし、できるだけ「過労」させないように使っていただけると助かります。 -以下の行為は禁止されています： +以下の行為は禁止しています： -1. **DDOS 攻撃**：これにより、私のサーバーが影響を受け、他のユーザーがこれらのツールを利用できなくなります。 -2. **自動化された大量リクエストの使用**：スクリプトやボットを使って、大量にリクエストを送ることはご遠慮ください。モデルが休む時間も必要です。 +1. **DDoS 攻撃**：私のサーバーだけでなく、他の利用者にも影響が出ます。 +2. **自動化による大量リクエスト**：スクリプトやボットで大量のリクエストを送るのはやめてください。モデルにも休む時間が必要です。 -これらの行為によりサーバーがクラッシュしてしまいます。状況が深刻になると、あなたの IP をブラックリストに追加せざるを得なくなります 😅。 +こうした行為が続くとサーバーが停止し、状況によっては IP をブラックリストに追加せざるを得ません 😅 -みんなでリソースを友好的に使い、この遊び場が長く運営できるようにしましょう！ +みんなで節度をもって使って、この遊び場を長く維持できるようにしていただけると嬉しいです。 ## まとめ -現在のデモはまだ始まりに過ぎません。 +今あるデモは、まだほんの入口にすぎません。 -画像処理、言語モデル、その他の機械学習関連のアプリケーションについて、時間があれば順次この遊び場に追加していきます。 +画像処理、言語モデル、そのほかの機械学習関連アプリケーションについても、時間が取れしだい順次追加していきます。 ＊ diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/docaligner/intro.md b/i18n/ja/docusaurus-plugin-content-docs/current/docaligner/intro.md index cfff383c078..164e1428c0f 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/docaligner/intro.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/docaligner/intro.md @@ -4,118 +4,122 @@ sidebar_position: 1 # イントロダクション -このタスクは実際には OCR タスクの「前段階」と言えます。 +このタスクは、実際には OCR の「前段」にあたる処理です。 -ここ数年、さまざまな汎用 OCR モデルが非常に成熟しており、前処理なしで制限のないシーンで文字を見つけて認識結果を提供することができるようになりました。 +近年は汎用 OCR モデルがかなり成熟しており、前処理なしでも、制約の少ない環境で文字を見つけて認識結果を返せるようになってきました。 -しかし、それは少し高価です。 +ただし、それにはそれなりのコストがかかります。 -この「高価」の意味をいくつかの側面から切り出すことができます： +ここで言う「コスト」は、いくつかの観点から考えられます。 ### 推論コスト -実際のシーンでは、文書認識タスクは OCR 領域で非常に大きな割合を占めています。なぜなら、私たちは生活の中で常に文書を扱うからです。これらの活動では、通常「能動的」ではなく「受動的」にスキャンを受けることが多いです： +実際の現場では、OCR 領域の中でも文書認識の比重はかなり大きいです。というのも、私たちの生活は文書と切り離せないからです。 -1. 銀行口座を開設する際、証明書を見せる必要がある？ -2. 海外に行く際、パスポートを見せる必要がある？ -3. ビザを申請する際、証明書を見せる必要がある？ -4. 保険に加入する際、契約書を見せる必要がある？ +しかも、こうした場面では、自分から積極的にスキャンしたいというより、必要に迫られて提示することの方が多いはずです。 -これらの割合は非常に大きいですが、必ずしも儲かるビジネスとは言えません。なぜなら、この分野には多くの競合企業があり、質の良い製品が手頃な価格で溢れているからです。 +1. 銀行口座を開くときは本人確認書類が必要ではないか？ +2. 海外に行くときはパスポートが必要ではないか？ +3. ビザ申請では証明書類が必要ではないか？ +4. 保険加入では契約書の確認が必要ではないか？ -つまり、汎用 OCR モデル（通常は LLM）を使ってこの問題を処理すると、推論コストだけで大きな赤字を出す可能性があります... +需要が大きいからといって、必ずしも儲かる市場とは限りません。この分野には競合も多く、安価で実用的な製品がすでにたくさんあります。 -その赤字を逆転させることもできます。 +つまり、汎用 OCR モデル（多くの場合は LLM）でこの問題をそのまま処理すると、推論コストだけで赤字になりかねません。 + +しかも、かなり派手に赤字になります。 :::tip -ここでは、経済的に余裕のある人々を除外しています。 +ここでは、予算をまったく気にしなくていい人たちはいったん除外しています。 ::: -### 文字は通常非常に密集している +### 文字は通常かなり密集している + +文書中の文字はたいてい高密度です。情報を取りこぼしたくなければ、高解像度でスキャンする必要があります。 -文書内の文字は通常密集しており、つまり、情報を見逃したくない場合、高解像度で文書をスキャンする必要があるということです。 +例えば、一般的な物体検出では $640 \times 640$ を使うことが多いですが、文書位置合わせの場面では、$896 \times 896$、$1536 \times 1536$、あるいはそれ以上まで上げることも珍しくありません。 -例えば、物体検出を行う際に一般的に使用する解像度は $640 \times 640$ ですが、文書の位置決めシーンでは、この解像度は $896 \times 896$ や $1536 \times 1536$、さらにはそれ以上に拡大されることがあります。 +もしモデルの役割を分割せず、高解像度のまま LLM に全部やらせると、推論コストはもちろん、計算資源の負担も非常に大きくなります。学習用 GPU の価格を見れば、その重さはよく分かります。LLM は本当に高価です。 -もしモデルの機能を分割せず、直接高解像度の環境で LLM を強引に適用すると、推論コストはさておき、V100 トレーニング用の GPU が 30,000 ～ 50,000 ドルもすることを知っていますか？LLM は本当に高すぎます！ +### 中国語は文字種が非常に多い -### 中国語の文字数が膨大 +中国語は簡体字と繁体字を含めると文字種が非常に多く、ラテン文字圏の文字分類と比べて桁違いです。 -中国語の文字分類は、簡体字と繁体字を含むため、文字数は 10 万種類にも及びます。ラテン系言語の文字と比較すると、分類数が 3 桁多いことになります。 +モデルは複雑な背景から文字を見つけ、そのうえでごく小さな文字領域から判別に必要な特徴を抽出しなければなりません。そのため、必要なパラメータ数も計算量も大きくなります。 -モデルは複雑な背景から文字を見つけ、さらに文字の細部（数ピクセルしかない場合もあります）から重要な特徴を見つける必要があるため、必要なパラメータ数と計算量が大幅に増加します。 +私たちはもちろん、エンドツーエンドですべてを解決したくなります。理想を言えば、何も分けずにひとつのモデルですべて片づけたい。 -私たちはもちろん、端から端までの解決策を望んでいます。できれば、何もせず、1 つのモデルで全てを解決できるものが理想です。そのようなモデルは現在も存在しており、今後はさらに増えていくでしょう。 +そうした方向のモデルはすでに存在しますし、今後さらに増えていくでしょう。 -しかし、推論は高価で利益は少なく、現段階ではどんなに見ても赤字ビジネスです。 +ただ、現時点では推論コストが高く、収益性も低いため、現場目線ではかなり厳しい選択です。 -### 機能の分割 +### 機能分割 -したがって、より経済的で実用的な方法が必要であり、ここでモデルの分割が必然的な選択となります。 +そこで必要になるのが、もっと現実的で経済的な方法です。その文脈で、モデル機能の分割は自然な選択になります。 -これが、このプロジェクトの目的です： +これが、このプロジェクトの目的です。 -- **騒がしい環境の中で、関心のある文書領域を正確に特定し、それをフラットにして、その後の文字認識やその他の処理を可能にすること。** +- **雑然とした環境の中から、必要な文書領域を正確に見つけて平坦化し、その後の文字認識や各種処理につなげること。** -文書の位置決めができれば、次に文字の位置決め、そして文字認識、最後に意味解析理解へと進みます。 +文書位置合わせのあとに文字検出があり、そのあとに文字認識があり、最後に意味理解があります。 -このプロセスは少し煩雑かもしれませんが、コストと効果のバランスを取ると、これは比較的良い選択肢です。 +工程は少し増えますが、コストと効果のバランスを考えると、かなり現実的な構成です。 -## モデル機能 +## モデルの機能 -このモデルは、画像内の文書を特定し、その 4 隅を正確に見つけ、ユーザーがその文書をフラットにして後続の文字認識やその他の処理を行えるようにするために設計されています。 +このモデルは、画像内の文書を検出し、四隅の角点を正確に求め、文書を平坦化して後続の文字認識やその他の処理に使えるようにするためのものです。 -ここでは、2 種類の異なるモデルを提供しています：「ヒートマップモデル」と「ポイント回帰モデル」で、それぞれ特徴と適用シーンがあり、これらは後の章で詳細に説明します。 +ここでは 2 種類のモデルを提供しています。「ヒートマップモデル」と「点回帰モデル」で、それぞれ特徴と向いている場面が異なります。詳細は後続の章で説明します。 -技術面では、PyTorch をトレーニングフレームワークとして選び、推論時にはモデルを ONNX フォーマットに変換し、異なるプラットフォームでの展開を可能にしています。また、ONNXRuntime を使用してモデルの推論を行うことで、CPU と GPU の両方で効率的に動作するようにしています。 +技術面では、学習には PyTorch を採用し、推論時には ONNX に変換して各種プラットフォームへ展開できるようにしています。また、推論には ONNXRuntime を利用し、CPU と GPU の両方で効率よく動作するようにしています。 -私たちのモデルは性能面で最先端レベルに達しており、モバイルデバイスでの推論速度は約 10〜20 FPS に達します。これにより、ほとんどのアプリケーションシーンのニーズに対応することができます。 +性能面では、モバイル端末上でもおよそ 10〜20 FPS 程度の推論速度を実現しており、多くの実用シーンに対応できます。 :::info -深層学習の分野「外」では、『Localization』は通常、文書を異なる言語に翻訳することを指します。 +深層学習の文脈以外で「Localization」と言うと、一般には文書や製品の多言語化を意味します。 -しかし、深層学習の分野では、画像内の文書を位置決めし、それをフラットにするプロセスを指します。 +しかしここでは、画像中の文書位置を特定し、平坦化する処理を指しています。 ::: :::tip -**フラット化**：三次元空間で歪んだ文書を、透視変換などの方法で二次元平面に投影し、平面上に表示させること。 +**平坦化**：三次元空間で歪んだ文書を、透視変換などで二次元平面へ写し取り、見やすい平面画像にすること。 ::: ## 定義 -私たちは、この分野の先駆者たちの定義に従い、文書の座標点の： +この分野の一般的な定義に従い、文書の 4 点は次の順序で扱います。 -- **起点を左上角に設定** -- **終点を左下角に設定** +- **始点は左上** +- **終点は左下** -とし、4 つの座標点を使って文書の位置を表現します。順番は：『左上 > 右上 > 右下 > 左下』です。 +すなわち、順序は **左上 → 右上 → 右下 → 左下** です。 :::danger -可視化結果では、異なる座標点に異なる色を使用していますが、その色は文書自体の向きを示すものではありません。 +可視化では各座標点に異なる色を使っていますが、その色は文書の向きを意味するものではありません。 -つまり：**文字がどんなに回転しても、モデルは常に左上角を起点、左下角を終点として定義します。** +つまり、**文字がどの向きに回転していても、モデルは常に左上を始点、左下を終点として定義します。** ::: ## 遊び場 -このモデルをウェブページに組み込んでおり、遊び場で試すことができます。 +このモデルは Web ページ上でも試せます。遊び場はこちらです。 - [**DocAligner-Demo**](https://docsaid.org/ja/playground/docaligner-demo) :::tip -使用中にバグを見つけた場合は、悪用を避けるため、私たちにプライベートで通知してください。迅速に対応します。 +利用中にバグを見つけた場合は、悪用を避けるためにも公開せず、まずは私たちに私的に知らせてください。できるだけ早く対応します。 ::: ## 最後に -実は、最初に目指していたのは Zero-shot のモデルで、モバイルデバイスで快適に動作するものを作ることでした。つまり、世界中のさまざまな文書に一般化でき、何も注釈をつけず微調整もせずにそのまま使えるものを目指していました。 +最初は、Zero-shot で動作し、しかもモバイル端末上で快適に使えるモデルを目指していました。つまり、世界中のさまざまな文書にそのまま一般化でき、追加アノテーションや微調整なしで使えるものです。 -しかし、モデル規模の制限により、この目標は少し遠くなりました。 +しかし実際には、モデル規模の制約が大きく、その目標は思っていたより遠いものでした。 -これは非常に難しい選択でした：モデル規模を大きくすると、最初の目的から外れてしまいます。モデルを大きくしないと、構造を変更する必要があり、構造を変更するとモデルの一般化能力に影響を与えてしまいます。 +モデルを大きくすれば当初の目的から離れますし、大きくしないなら構造を工夫する必要があり、その結果として汎化性能に影響が出ることもあります。 -最終的に、数ヶ月の努力の後、Zero-shot をあきらめ、精度を第一に優先しました。 +結局、数か月試行錯誤した末に、Zero-shot 性を一部あきらめてでも、まず精度を優先する判断を取りました。 -このトピックに興味がある方は、ぜひ自分でテストしてみてください。フィードバックをお待ちしています。 +このテーマに興味があるなら、ぜひ自分でも試してみてください。フィードバックをもらえると嬉しいです。 -また、アドバイスがあれば、ぜひお知らせください。喜んで交流させていただきます。 +意見や提案も歓迎します。ぜひ交流しましょう。 diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/gmailsummary/gmailapi_using.md b/i18n/ja/docusaurus-plugin-content-docs/current/gmailsummary/gmailapi_using.md index 13beec5112d..599aeda7252 100644 --- a/i18n/ja/docusaurus-plugin-content-docs/current/gmailsummary/gmailapi_using.md +++ b/i18n/ja/docusaurus-plugin-content-docs/current/gmailsummary/gmailapi_using.md @@ -2,17 +2,17 @@ sidebar_position: 4 --- -# Gmail API の呼び出し +# Gmail API の利用 -設定が完了したら、Gmail API を使用し始めることができます。 +設定が完了したら、Gmail API を使い始められます。 -まず、先ほどダウンロードした`credentials.json`ファイルを見つけ、それをプロジェクトのルートディレクトリに配置します。 +まず、先ほどダウンロードした `credentials.json` を見つけて、プロジェクトのルートディレクトリに配置してください。 次に、Google が提供しているチュートリアルを開きます：[**Python quickstart**](https://developers.google.com/gmail/api/quickstart/python) ## パッケージのインストール -Python 用の Google クライアントライブラリをインストールする必要があります： +Python 用の Google クライアントライブラリをインストールします： ```bash pip install -U google-api-python-client google-auth-httplib2 google-auth-oauthlib @@ -20,11 +20,11 @@ pip install -U google-api-python-client google-auth-httplib2 google-auth-oauthli ## 設定例 -1. 作業ディレクトリに`quickstart.py`という名前のファイルを作成します。 +1. 作業ディレクトリに `quickstart.py` という名前のファイルを作成します。 - - Google が提供するソースコードをそのまま使うこともできます：[**source code**](https://github.com/googleworkspace/python-samples/blob/main/gmail/quickstart/quickstart.py) + - Google が提供するサンプルコードをそのまま使っても構いません：[**source code**](https://github.com/googleworkspace/python-samples/blob/main/gmail/quickstart/quickstart.py) -2. 以下のコードを`quickstart.py`に追加します： +2. 以下のコードを `quickstart.py` に追加します： ```python title="quickstart.py" import os.path @@ -83,17 +83,17 @@ pip install -U google-api-python-client google-auth-httplib2 google-auth-oauthli ## 実行例 -`quickstart.py`を実行します： +`quickstart.py` を実行します： ```bash python quickstart.py ``` -`quickstart.py`を初めて実行すると、認証を求められます。「Allow」をクリックしてください。 +初回実行時には認証画面が表示されるので、「Allow」をクリックしてください。 ![gmail_19](./resources/gmail19.jpg) -次のような出力が表示されます： +すると、次のような出力が表示されます： ```bash Labels: @@ -113,15 +113,15 @@ STARRED UNREAD ``` -また、`token.json`というファイルが取得され、次回`quickstart.py`を実行する際に再度認証を求められることはなくなります。 +また、`token.json` というファイルも生成されます。次回以降は、このファイルにより再認証が不要になります。 -## 使用開始 +## 使い始める -次に、Gmail API を使用してメール内容を解析する準備を始めます。 +ここからは、Gmail API を使ってメール内容を解析していきます。 -以下の三つの部分を実装します：クライアントの作成、メールの取得、メールの解析。 +実装するのは、次の 3 つです：クライアントの作成、メールの取得、メール本文の解析。 -まず必要なパッケージをインポートします： +まず、必要なパッケージをインポートします： ```python from base64 import urlsafe_b64decode @@ -135,7 +135,7 @@ from googleapiclient.discovery import build ### クライアントの作成 -Gmail API クライアントを作成するとき、`token.json`に保存されたユーザーのアクセスおよびリフレッシュトークンをロードし、アクセス令牌が期限切れの場合は自動的にリフレッシュされます。 +Gmail API クライアントを作成する際は、`token.json` に保存されたアクセストークンとリフレッシュトークンを読み込みます。アクセストークンの有効期限が切れている場合は、自動的に更新されます。 ```python def build_service(): @@ -149,7 +149,7 @@ def build_service(): ### メールの取得 -次に、ユーザーからメール内容を取得する関数を定義します： +次に、メール内容を取得する関数を定義します： ```python def get_messages( @@ -196,7 +196,7 @@ def get_messages( ### メールの解析 -データを取得した後、その内容は大量のメタデータを含んでいるため、読みやすい形式に解析する必要があります。 +取得したデータには大量のメタデータが含まれているため、読みやすい形式に整形します。 ```python def parse_message(service, msg_id, user_id='me'): @@ -212,14 +212,14 @@ def parse_message(service, msg_id, user_id='me'): 'Text': None } - # 解析ヘッダー情報（送信日時、件名、送信者、受信者） + # ヘッダーを解析して送信日時と件名を取得 for header in headers: if header['name'] == 'Date': email_data['Date'] = header['value'] elif header['name'] == 'Subject': email_data['Subject'] = header['value'] - # メール本文の解析 + # メール本文を解析 for part in parts: if part['mimeType'] == 'text/plain' or part['mimeType'] == 'text/html': data = part['body']['data'] @@ -236,8 +236,8 @@ def parse_message(service, msg_id, user_id='me'): ## まとめ -ここまでで、Gmail API の基本的な使用方法について説明しました。 +ここまでで、Gmail API の基本的な使い方は一通り説明できました。 -次に進む前に、いくつか準備が必要です。 +ただし、まだ実行するのは少し待ってください。先にいくつか準備が必要です。 -OpenAI の API と接続し、メール内容を ChatGPT に送信して解析を行えるようにします。 +次は OpenAI API と接続し、メール内容を ChatGPT に渡して解析できるようにします。 diff --git a/i18n/ja/docusaurus-plugin-content-pages/aboutus.md b/i18n/ja/docusaurus-plugin-content-pages/aboutus.md index 2755bc13db5..52c22828b7a 100644 --- a/i18n/ja/docusaurus-plugin-content-pages/aboutus.md +++ b/i18n/ja/docusaurus-plugin-content-pages/aboutus.md @@ -1,81 +1,99 @@ # 私たちについて -私のウェブサイトへようこそ。 +ようこそ。 -私は Z. Yuan、台湾在住の AI エンジニアです。 +私は台湾在住の AI エンジニア、Z. Yuan です。 -## エンジニアなのですか？ +## エンジニアなのか？ -はい。 +はい、そうです。 -私は科学的知識を用いて現実の問題を解決することを楽しんでいます。 +私は、科学や技術の知識を使って現実の問題を解くことが好きです。 -数年前までは、画像処理をする人は「コンピュータビジョンエンジニア」、テキスト処理をする人は「自然言語処理エンジニア」と呼ばれていました。さらに「機械学習エンジニア」や「深層学習エンジニア」と分かれることもあり、職種間にはある種の優劣意識が存在していました。 +数年前までは、画像を扱う人は「コンピュータビジョンエンジニア」、テキストを扱う人は「自然言語処理エンジニア」と呼ばれていました。そこからさらに「機械学習エンジニア」や「深層学習エンジニア」に細分化され、職種のあいだには妙な上下関係の空気さえありました。 -しかし、誰であれ「AI エンジニア」を一様に軽んじていました。 +ところが「AI エンジニア」という肩書きだけは、どこか一段低く見られがちでした。 -> フン！またセンスのない企業や求職者がタイトルを詐称しているのか！ +> ふん、またセンスのない会社や求職者が肩書きを盛っているのか。 -時代は流れ、「テキスト」「画像」「音声」など異なるデータ次元が、「基盤モデル」の波によって高次元空間で統一されました。これにより、多モーダルトレーニングの新しいパラダイムが誕生し、ランキングや評価を席巻し、論文執筆の強力なツールとなっています。 +でも時代が変わりました。 -その結果、実際にはこれらのエンジニアたちが異なる次元で同じ作業をしていることに気付いたのです。 +テキスト、画像、音声といった異なるデータモダリティは、基盤モデルの波によって高次元空間で統一的に扱われるようになりました。マルチモーダル学習は評価指標を塗り替え、論文執筆や製品開発の方法まで変えつつあります。 -すぐにこの分野では、もはやエンジニアを分けることが無意味となり、学術研究がクロスディシプリン化しました。研究者はあらゆる分野の基礎知識を理解する必要があり、それがなければ研究は進みません。このようにして、私たちは自分たちが何者であるかを説明することがますます難しくなっています。 +そこでようやく気づいたのです。実は、みんな別々のことをしていたのではなく、違う次元でかなり似たことをやっていたのだと。 -その時、ふと振り返るとこうなります。 +この分野では、もはやエンジニアを細かく分ける意味は薄れ、研究もますます横断的になっています。今では、複数分野の基礎を理解していないと研究そのものが進みません。 -> そうだ、君だ！AI エンジニア！ +そうなると、自分たちが何者なのかを説明するのは、むしろ前より難しくなりました。 -## では、ここは？ +そんなとき、振り返ると結局こうなるわけです。 -おそらく 2023 年のことだろう。 +> そう、それだ。AI エンジニア。 -ある日、何気なく街を歩いているときに、Meta がオープンソースで公開している[**Docusaurus**](https://docusaurus.io/)を見つけ、その機能がなかなか豊富だということに気づいた。 +## では、ここは何なのか？ -これを使ってブログを書いてみようと思い、まずは GitHub Pages にサイトをデプロイし、記事を書き始めた。 +たしか 2023 年ごろのことです。 -ブログを書いているうちに、ついでにいくつかオープンソースのプロジェクトも作ってみようと思い、プロジェクト紹介の内容も加えた。そして、Docusaurus の標準機能では足りないと思い、いくつか自分でプラグインを書き始め、さらに技術的なノートも書くようになり、最終的には今のような形になった。 +ある日なんとなく歩いていて、Meta がオープンソースで公開している [**Docusaurus**](https://docusaurus.io/) を見つけました。思っていたより機能が揃っていて、「これならブログを書けるかもしれない」と思ったのが始まりです。 -さて、話は戻るが、私は何度も試行錯誤を繰り返しているうちに、このサイトは GitHub Pages の容量制限に近づいている。だから、今後は別の場所に移行する必要がありそうだ...（あぁ、人生は本当に難しい 😮‍💨） +最初は GitHub Pages にデプロイして、単純に記事を書くだけのつもりでした。 + +ところが書き始めると、せっかくだからオープンソースのプロジェクト紹介も載せたくなり、さらに Docusaurus の標準機能では足りなくなって、自分でプラグインまで書き始めました。そうして技術メモや論文ノートも増えていき、今の形になりました。 + +ただし、その代償として、サイト全体はだんだん GitHub Pages の容量制限に近づいています。つまり、いずれは別の置き場所を考えないといけません。 + +……本当に、人生は面倒です 😮‍💨 ## サイト名の由来 -「ウェブサイトを作る」というプロセスで最も難しいのは、名前を考えることです。 +サイトを作るうえで一番難しいのは、たぶん名前を決めることです。 + +私は普段、テキスト分析に関わる仕事をしています。画像認識、詐欺検出、テーマ分類、キーワード抽出など、扱うものはさまざまです。 + +そして私にとって「テキスト」は、単なる文字列に限りません。画像、動画、音声、データセット、さらには人間の行動ですら、分析したいと思えば一種のテキストとして扱えます。 -テキスト分析は私の日常業務です。画像認識、詐欺検出、テーマ分類、キーワード抽出など、さまざまな仕事をしています。私の視点では、テキストは文字だけに限りません。それは画像、動画、音楽、データセット、さらには人間の行動も含みます。分析価値があるもの、または分析したいと思えるものは、すべて「テキスト」になり得るのです（混沌の邪悪？）。 +そこで、このサイトにもそれを反映した名前を付けようと考え、 **DOCSAID** という名前にしました。 -そこでこのウェブサイトに関連する名前を付けたいと考え、 **DOCSAID** という名前にしました。 +この名前は「DOC」と「SAID」の 2 つからできています。ざっくり言えば意味はこうです。 -この名前は「DOC」と「SAID」という 2 つの単語から成り立っています。大まかな意味としては： +> **テキストが生まれた瞬間、その中身はすでに何かを語っている。** -> **テキストが作られた瞬間、その内容はすでに語り尽くされています。** +ならば、その語られた内容を分析すればいい。 -では、そのテキストが何を語ったのか？ それを分析すれば良いだけの話です！ +そんな発想です。 -面白いことに、この名前を付けた後、中に「AI」という文字が含まれていることに気付き、ちょっとしたサプライズとなりました。 +しかも後になって気づいたのですが、この名前には中に「AI」も含まれていました。ちょっと得した気分でした。 -## ウェブサイトデザインについて +## サイトデザインについて -私のサイトデザインがシンプルすぎると言わないでください！分かっています！😅 +サイトデザインがあまりにも質素だ、と言いたい人がいるかもしれません。 -私の本職はモデル開発で、普段は論文を読み、コードを書き、パラメータを調整しています。ウェブデザインやバックエンド構築については、最低限の知識しかありません。今後機会があれば、専門家に改良をお願いするつもりです。 +分かっています。私もそう思っています。😅 + +本業はモデル開発で、普段は論文を読み、コードを書き、パラメータを調整しています。Web デザインやバックエンド構築は最低限しか分かりません。 + +もし機会があれば、そのうち専門の人にもっときれいに整えてもらいたいところです。 ## 連絡先 -もし何か質問がある場合、または私の仕事に興味をお持ちでしたら、どうぞお気軽にご連絡ください！ +質問がある方、あるいは私の仕事に興味を持ってくださった方は、お気軽にご連絡ください。 -私の仕事用メールアドレスは **docsaidlab@gmail.com** です。メールを送るか、このサイトのどこかの記事にコメントを残していただければ、必ず目を通します。 +仕事用のメールアドレスは **docsaidlab@gmail.com** です。メールでも、このサイト内のどこかの記事へのコメントでも構いません。ちゃんと目を通します。 ## 最後に -これらのプロジェクトとノートは、私がかなりの時間をかけて、試行錯誤しながら作り上げたものです。私にとって、これは学習の過程であり、同時にコミュニティへの還元の方法でもあります。 +ここにあるプロジェクトやノートは、かなりの時間をかけて少しずつ積み上げてきたものです。 + +私にとってこれは学習の記録であり、同時にコミュニティへの還元でもあります。 + +もしこのサイトから何かひとつでも学べた、あるいは「この記事はよかった」と思っていただけたなら、次のような形で応援してもらえると嬉しいです。 -もしこのサイトで何かを学んだり、たとえどの記事でも「これ、良いな」と思っていただけたら、以下の方法でサポートしていただけると嬉しいです： +- [**Buy Me A Coffee**](https://buymeacoffee.com/zyuan)（夜更かししてノートを書くための燃料になります ☕️） +- GitHub でプロジェクトにスターを付ける ⭐️（ひとつ増えるたびに内心かなり喜んでいます） +- メッセージやアドバイスを送る（こういうのは普通に励みになります） -- [**Buy Me A Coffee**](https://buymeacoffee.com/zyuan)（私が夜遅くまでノートを書くためのエネルギーになります ☕️） -- GitHub でプロジェクトにスターをつけてくれると嬉しいです ⭐️（星が 1 つ増えるたびに密かに喜んでいます） -- もしくは気軽にメッセージを残したり、アドバイスをくれたりするだけでも、大きな励みになります！ +ここまで読んでくださってありがとうございます。 -ここまで読んでいただきありがとうございます。**DOCSAID**がいつかあなたの役に立ち、インスピレーションを与えることを願っています。 +**DOCSAID** が、いつかあなたの役に立つ場所になれば嬉しいです。 **Z. Yuan**