メインコンテンツまでスキップ

著者になる

拝啓​

私たちの著者グループに参加していただき、ありがとうございます。以下に、よく使用されるツールと規範を提供します。これが、より早く作業を開始するのに役立つことを願っています。

Web ページの立ち上げ​

現在、私たちは Docusaurus を開発の基盤として使用しています。以下は、Web ページを立ち上げるための基本的なコマンドです：

git clone https://github.com/DocsaidLab/website.git
cd website
nvm use node
yarn start

詳細な設定手順​

以下の手順に従って環境をチェックし、設定してください。これにより、スムーズに実行できることが確認できます：

  1. Node.js のバージョン確認

    • Node.js v22 以上を使用することを推奨します。
    • nvmがインストールされていない場合は、nvm の公式ドキュメントを参照してインストールしてください。
    • インストール後、以下のコマンドで Node.js のバージョンを確認して設定してください： 
      nvm install 22
      nvm use 22

  2. Yarn のインストール

    • Yarn がインストールされていない場合は、以下のコマンドでインストールします： 
      npm install -g yarn

  3. 依存関係のインストール

    • プロジェクトのディレクトリに移動した後、以下のコマンドで必要な依存関係をインストールします： 
      yarn install

  4. Web ページの起動ポートの確認

    • デフォルトでは、Docusaurus はhttp://localhost:3000で実行されます。
    • そのポートが既に使用されている場合は、package.jsonの起動コマンドを変更するか、環境変数で新しいポート番号を設定できます： 
      yarn start --port 3001

  5. Web ページの起動テスト

    • 起動コマンドを実行した後、ブラウザで正常に Web ページにアクセスできることを確認してください。
    • 問題が発生した場合は、キャッシュをクリアして再起動を試みてください： 
      yarn clear
      yarn start

  6. 追加テスト

    • プロダクションモードをテストする必要がある場合は、以下のコマンドを使用します： 
      yarn build
      yarn serve
    • Web ページはhttp://localhost:3000でテスト版を提供します。

Docusaurus を使うことで、Markdown で Web コンテンツを書き、React でカスタマイズできます。詳細な使用方法については、Docusaurus Markdown Featuresを参照してください。

技術文書の作成​

プロジェクトの開発が完了し、一定の成果を上げた後、あなたはその成果をみんなと共有したくてたまらないかもしれません。その際、以下の手順で技術文書を Web サイトに公開できます：

以下では、DocAlignerプロジェクトの技術文書を作成する例を示します：

  1. docsフォルダ内に新しいフォルダを作成します。例えば、docs/docaligner。

  2. そのフォルダ内にindex.mdファイルを作成し、内容は以下のようにします：

    # DocAligner（プロジェクト名）

    このプロジェクトの主要な機能は「**文書位置合わせ（Document Localization）**」です。（プロジェクトの紹介）

    - [**DocAligner Github（プロジェクトの Github）**](https://github.com/DocsaidLab/DocAligner)

    ---

    ![title](./resources/title.jpg)（プロジェクトの画像、自己制作または GPT で生成）

    ---

    （プロジェクトのカードを表示するための固定コード）

    import DocCardList from '@theme/DocCardList';

    <DocCardList />

  3. フォルダ内にresourcesフォルダを作成し、プロジェクトの画像を格納します。

  4. 他の技術文書、例えば：

    • docs/docaligner/quickstart.md: クイックスタートガイド
    • docs/docaligner/installation.md: インストールガイド
    • docs/docaligner/advanced.md: 高度な使用方法
    • docs/docaligner/model_arch：モデルのアーキテクチャ
    • docs/docaligner/benchmark：パフォーマンス評価
    • ...（共有したいその他の内容）

  5. 完成後、mainブランチに PR を送信し、レビューを待ちます。

ブログの作成​

開発の過程で、様々な大小の問題に直面することがあります。

あなたの問題は他の人々の問題でもあり、あなたの解決策は他の人々の解決策でもあります。

だからこそ、あなたの問題と解決策をブログに書いて、他の人と共有することを歓迎します。

以下はブログ作成の規範です：

  1. blogフォルダ内で、対応する年を見つけます。例えば blog/2024。もし存在しない場合は、新たに作成します。

  2. 年フォルダ内に、月日とタイトルを含む新しいフォルダを作成します。例えば 12-17-flexible-video-conversion-by-python。

  3. フォルダ内にindex.mdファイルを作成し、以下のような内容にします：

    ---
    slug: flexible-video-conversion-by-python （記事のURL）
    title: バッチ動画変換
    authors: Zephyr （authors.ymlに存在する必要があります）
    image: /img/2024/1217.webp （GPTで生成し、/static/imgフォルダ内に保存）
    tags: [Media-Processing, Python, ffmpeg]
    description: Pythonとffmpegを使用して指定された形式でバッチ変換のプロセスを作成する方法。
    ---

    MOV 形式の映像ファイルを一括で受け取りましたが、システムはそれを読み込むことができず、MP4 に変換する必要があります。

    自分でプログラムを少し書くことにしました。

     <!-- truncate --> （要約終了タグ）

    ## 設計の草案 （本文開始）

  4. フォルダ内にimgフォルダを作成し、ブログ記事の画像を保存します。

    美観のため、画像を使用する際には、Markdown ファイル内で HTML 構文を使用できます：

    <div align="center"> （画像を中央に配置）
    <figure style={{"width": "90%"}}> （画像のサイズを調整）
    ![img description](./img/img_name.jpg)
    </figure>
    </div>

  5. 完成したら、mainブランチに PR を送信し、レビューを待ちます。

  6. 最後に、関連する情報がauthors.ymlファイルに正しく追加されていることを確認してください。これにより、著者情報が正しく表示されます。

    例えば、ファイル内容は以下のようになります：

    Zephyr: （著者を識別する名前）
      name: Zephyr （ウェブ上で表示される名前）
      title: Dosaid maintainer, Full-Stack AI Engineer （著者の肩書き）
      url: https://github.com/zephyr-sh （著者のGitHub）
      image_url: https://github.com/zephyr-sh.png （著者のプロフィール画像）
      socials:
        github: "zephyr-sh" （著者のGitHubアカウント）

    詳細な設定については、Docusaurus Blog Authorsを参照してください。

論文ノートの作成​

論文を読むことは私たちの宿命であり、ノートを書くことは未来の自分への警告です。私たちの記憶は非常に脆弱で、昨日昼食に何を食べたかも覚えていないほどです。ましてや、読んだ論文の内容を覚えておくことは難しいです。

もしあなたもノートを書きたければ、以下の規範に従ってください：

  1. 論文選定ガイドライン：

    1. CVPR、ICCV、NeurIPS などのトップカンファレンスで発表された論文を選びます。これにより論文の品質を保証します。
    2. 上記に該当しない場合は、引用数が 100 以上の論文を選んでください。これはその論文が一定の参照価値を持っていることを意味します。
    3. 有料で閲覧できる論文は避けてください。
    4. ArXiv で公開されている論文を選び、読者が全文を取得できるようにします。

  2. 論文の公開年：論文の年には、ArXiv での公開日、カンファレンスの開催日、論文発表日などがあります。参照しやすいように、ArXiv での公開日を採用します。

  3. papersフォルダ内で、論文の分野に応じて対応する分野を選びます。例えば papers/multimodality。もし存在しない場合は、新たに作成します。

  4. 分野フォルダ内に新しいフォルダを作成し、論文の「発表年月」とタイトルを含めます。例えば 2408-xgen-mm。

  5. 新しいフォルダ内にindex.mdファイルを作成し、必要な画像は同じ階層にimgフォルダに保存します。

  6. 論文ノートの書き方は以下の標準フォーマットに従います：

    • タイトル：年、月、論文名の形式
    • 著者：著者名
    • 副題：面白い副題を自分でつけます
    • 論文リンク：論文の完全なタイトルとリンク
    • 問題定義：論文の著者が定義した問題を整理します
    • 問題解決：著者が問題を解決する方法を詳述します
    • 議論：問題解決の有効性や議論の余地、実験結果など
    • 結論：論文の重要なポイントをまとめます

  7. 基本的な例は以下の通りです：

    ---
    title: "[24.08] xGen-MM" （論文のタイトル、業界の慣例または著者が定義したタイトル）
    authors: Zephyr (著者名、関連定義は`/blog/authors.json`ファイルに記載)
    ---

    ## BLIP-3 とも呼ばれる （面白い副題）

    [**xGen-MM (BLIP-3): A Family of Open Large Multimodal Models**](https://arxiv.org/abs/2408.08872)（論文の完全なタイトルとリンク）

    ---

    少し雑談をします。

    ## 問題定義

    著者が定義した問題を整理します。

    ## 解決策

    著者が問題を解決する方法を詳述します。

    ## 議論

    解決策の有効性や論争、実験結果を説明します。

    ## 結論

    論文の重要なポイントをまとめます。

  8. 執筆ガイドライン：

    1. 論文に問題があると思った場合、最初に自分が理解していない可能性を疑ってください。
    2. それでも問題があると感じた場合、他の参考資料を探し、コメントは慎重にしてください。
    3. 各論文には取捨選択があります。その論文から得られるインスピレーションに焦点を当て、欠点にはこだわらないようにしましょう。
    4. 客観的な態度を保ち、過度な批判や過度な賞賛を避けてください。
    5. 本当に良い部分が見つからない場合、そのノートは書かない方が良いです。論文の選定を間違ったかもしれません。
    6. 専門的な言葉遣いを守り、不適切な言葉や画像は使わないようにしてください。

  9. 完成後、mainブランチに PR を送信し、レビューを待ちます。

記事内でコードを書く​

私たちは React ベースの MDX 構文を採用しているため、記事内で直接 React コードを書くことができます。

以下は簡単な例で、まずはHelloWorld.jsコンポーネントを作成します：

import React from "react";

const HelloWorld = () => {
  return <div>Hello, World!</div>;
};

export default HelloWorld;

次に、Markdown 記事内でこのコンポーネントをインポートします。ここでは MD ファイルですが、実際には MDX ファイルとして解析されるため、React コードをそのまま書くことができます：

import HelloWorld from "./HelloWorld";

# タイトル

<HelloWorld />

## サブタイトル

その他の内容

多言語サポート​

記事を書いた後、突然気づいたのは、私たちのウェブサイトが多言語に対応しているということですが、あなたは他の言語を理解していません！

大丈夫です。一般的に、Zephyr という人がこれを手伝ってくれますが、あなた自身で行うこともできます：

  1. 書いた記事を対応するi18nフォルダに入れてください。例えば：

    • docsの記事はi18n/en/docusaurus-plugin-content-docs/currentフォルダに、
    • blogの記事はi18n/en/docusaurus-plugin-content-blog/currentフォルダに、
    • papersの記事はi18n/en/docusaurus-plugin-content-papers/currentフォルダに入れてください。

    日本語の場合はi18n/jaフォルダに、他の言語も同様に配置します。

  2. 次に、i18nフォルダ内の記事内容を対応する言語に翻訳します。GPTs を使って翻訳し、その後、不必要な文や明らかな間違いを削除することをお勧めします。

  3. 最後に、mainブランチに PR を送信し、レビューを待ちます。

最後​

私たちは、現在多くの AI ツールが記事作成をサポートできるようになったとはいえ、真に魅力的な良い記事は、必ず著者独自の個性と感情表現を持っているものであり、これは現在の AI では完全に模倣したり置き換えたりできない部分であることをお伝えしたいです。

AI モデルの基本的な動作は統計モデルに基づいており、最大尤度推定を通じてコンテンツを生成します。これは、モデルが一般的でよく見られる文法や文型を生成しがちであることを意味します。そのため、AI が作り出すコンテンツは、スタイル的に平凡で似たようなものになりがちです。過度にモデルに依存すると、創作者は本来の個性や魂を失い、記事が深みや感動を欠いたものになる可能性があります。

もし AI の助けなしに創作できない、あるいは頭が真っ白になってしまう場合、それは警告のサインです。自分のライティング能力をまず強化し、基本的な創作技術を習得する必要があります。さもなければ、あなたはモデルの伝声筒に過ぎなくなるかもしれません。

私たちの経験から言うと、AI モデルは退屈で繰り返しの多い作業に非常に適しています。例えば、表計算データの分析やデータ集計などです。これらの作業は通常、高い標準化を持ち、正確性と効率が非常に重要ですが、創造性や柔軟性の要求は比較的低いです：

結局のところ、表計算のデータは、あなたがどんなに創造的であっても、面白くなったり実験結果が変わったりすることはありません。

例えば「論文ノート」では、AI は難解な数学理論に対処する手助けをし、「## 議論」のセクションで実験結果や結論を整理することもできます。しかし、論文の理解や思考を置き換えることはできませんし、論文に対する批判的思考や深い分析も代わりに行うことはできません。さらに「プロジェクトドキュメント」では、AI は退屈な関数の入力や出力の詳細について、迅速に大量の技術文書を生成することができますが、モデル設計の理念に関しては自分自身で考える必要があります。そして「ブログ」のように完全に創作者のスタイルや思考に依存する記事では、AI の助けはさらに少ないものです。

したがって、私たちは AI の使用範囲を明確にし、創作戦略を適切に調整して、記事の品質と独自性を確保する必要があります。AI は視野を広げ、効率を高めるためのツールであり、思考やスタイルを制限するものではありません。

書く過程で、本当に感動的な言葉は人の心から来ることを忘れないでください。

AI は考えない人を置き換えるだけです。私は考える、だから私は存在する。

＊

2024 © Zephyr