Making a vintage LLM from scratch (50 minute read)｜ゼロから作るヴィンテージ LLM（50 分読了） | AIニュース最前線

2026 年 5 月 25 日、月曜日 50 分 このブログ記事では、ほぼゼロから独自に LLM（大規模言語モデル）を作成し、古いテキストのみでトレーニングした私の冒険について共有します。私は独自のベーストレーニングおよびファインチューニングスクリプト、データ処理パイプライン、カスタムデータセットをすべて自作しました。 （「ほぼゼロから」とは、既存のプログラミング言語やライブラリを使用したという意味であり、アセンブリ言語で記述したわけではありません。AI を「ゼロから」構築する他の人々と同じようにです） このモデルは HuggingFace で利用可能です：[https://huggingface.co/croqaz/vintage-LLM-340m-v1-base](https://huggingface.co/croqaz/vintage-LLM-340m-v1-base) ; すべてのコードはオープンソースで公開されています：[https://github.com/croqaz/vintage-LLM](https://github.com/croqaz/vintage-LLM) ; より大きな Vintage モデルを確認したい場合は、私の以前の投稿をご覧ください：[Vintage LLM models](https://crlf.link/log/entries/260428-1/)。 ## アイデア 3 ヶ月前の 2 月末、Hayk Grigorian（[Hayk Grigorian](https://huggingface.co/haykgrigorian)）によるいくつかの Reddit の投稿を発見しました。彼はそこで時系列ゲート付き言語モデルを作成した方法を説明していました。私はそのことに完全に魅了されました。 1800 年代ロンドンのテキストのみで LLM をトレーニング（90GB データセット）: [https://reddit.com/r/LocalLLaMA/comments/1pkpsee/training_an_llm_only_on_1800s_london_texts_90gb](https://reddit.com/r/LocalLLaMA/comments/1pkpsee/training_an_llm_only_on_1800s_london_texts_90gb) 1800 年代のロンドンテキストのみからゼロからトレーニングされた LLM が、1834 年の本物の抗議を呼び起こしました: [https://reddit.com/r/LocalLLaMA/comments/1mvnmjo/my_llm_trained_from_scratch_on_only_1800s_london](https://reddit.com/r/LocalLLaMA/comments/1mvnmjo/my_llm_trained_from_scratch_on_only_1800s_london) 明らかに、他の人々が独自の LLM を作成した他の投稿も読みましたが、もしかすると私が自分でやる準備ができていなかったか、彼らが取り組んでいたモデルがそれほど面白くなかったのかもしれません。とにかく、自分だけのビクトリア朝のチャットボットを持つという考え…なんて凄まじい！！ それからというもの、私は毎日欠かさず「Vintage LLM」に取り組んできました。例外はありません。病気の時でさえも。 その間には、Violet-1B4-Chat [Violet-1B4-Chat](https://huggingface.co/zakarth/violet-1b4-chat)、Mr. Chatterbox [Mr. Chatterbox](https://huggingface.co/tventurella/mr_chatterbox_model)、GPT-1900 [GPT-1900](https://huggingface.co/mhla/gpt1900-instruct-v3-sft)、Talkie [Talkie](https://huggingface.co/talkie-lm/talkie-1930-13b-it)、TypewriterLM-base [TypewriterLM-base](https://huggingface.co/typewriter-ai/typewriter-1913-7B-base) など、多くの歴史的 LLM がリリースされました。 ## 何？なぜ？どこで？どうやって？ 何？****これは時間ロックされた LLM（歴史 LLM）であり、英語のみ対応、知識の更新カットオフは 1900 年です。（特定の年に制限するのはエラーを起こしやすいですが、私は最善を尽くしました）。Llama アーキテクチャに基づいており、パラメータ数は 340M（0.3B）です。 なぜ？****自分でやってみなければ学べないからです。そしてこれは非常に楽しいプロジェクトだからです。 どこで、どのように？****私は独自にデータセットを作成し、独自の処理とトレーニングコードを構築しました。 コードは、VS-Code と PI（OpenRouter モデル）で利用可能なあらゆる LLM を活用して、半ば雰囲気重視でコーディングされました。すべての関数を確認・検証し、各コードファイルが何をしているかを深く理解しています。 データ処理に最も時間がかかり、機能しない様々な試行錯誤を繰り返した結果、膨大な時間を浪費することになりました。複雑な解決策ほど最悪です…… 私はすべてのデータを自分の PC で処理し、PC 上で LLM の小型版をトレーニングしました（*Cachy OS Linux、AMD Ryzen 7 9700X CPU、64GB RAM、Radeon RX 9070 16GB VRAM*）。 一方、より大規模な 340M モデルについては、RunPod、ThunderCompute、[Vast.ai](http://vast.ai/) でトレーニングしました。これを自分の PC でやれば永遠にかかってしまうでしょう。 このプロジェクトの総コストは約$80（GPU コストのみ）でした。 これは私がデータを処理できる十分な性能を持つ PC を持っているからです。もし RAM がもっとあれば、特にメモリ内でのテキスト重複排除において、一部のデータ処理をずっと高速に行えたはずです。 **免責事項**: これはおもちゃ/趣味の LLM です（ただし、私は非常に真剣に取り扱っています）。このモデルは幻覚を起こし、歴史的に半ば正確な内容を生成しますが、当時は普通と考えられていたものが、現代の基準では有毒、攻撃的、安全でないものと見なされます。これは予想されることであり、私はアライメントを行っていないためです。モデルをアライニング（または検閲）するには多大な労力が必要であり、歴史的正確性を損なうことになります。 また、私のモデルが厳密に 1900 年までに限定されていることを保証できません（最善を尽くしたとしても）、例えば「アルベルト・アインシュタインテスト」を実行する際などです。 ## プラン 私は仕事で毎日 AI を使用しており、その仕組みも理解していますが、自分で LLM を構築したのは今回が初めてです。職場では特定の AI 学習およびファインチューニングパイプラインを実行したことはありますが、過去に C や Python で小さなニューラルネットワークを構築したことはあっても、このプロジェクトを開始する時点では、人々が通常どのように LLM を構築しているかを知りませんでした。 私は一週間検索を行い、トピックを調査する際いつも行うように、複数のボットとチャットして異なる視点を得ました。 要約すると、LLM を構築するには 4 つのものが必要です： - データ -- LLM には識別力や理解力はありません。あなたが良いか悪いかに関わらず、何でも教えて学習します。これが最も長いプロセスです。 - トークン化 -- トークナイザーは、単語や文字を数値（トークン）に変換する小さなプログラムです。LLM は単語を理解せず、数値のみを理解します。 - pre-training -- これは混乱を招く表現ですが、「ベーストレーニング」を意味し、LLM がテキストの補完を学習するプロセスです。300m パラメータ以上のモデルを目指す場合、これが最もコストのかかる工程となります。 - fine-tuning -- ここで LLM はターンごとのチャットや質問応答の方法を学習します。 実際にはこれらの単純なステップ以外にもいくつかの要素がありますが、本記事ではこれ以上深く掘り下げません。 さて、各ステップをより詳細に確認していきましょう。 ## 初期実験 私が「大規模」モデルに落ち着くまでに、多くの間違いを犯し、いくつかのデータセットやモデルアーキテクチャを実験したことは言及する価値があります。ここで言う"big"（大規模）には引用符をつけていますが、ご存知のように Talkie-13B や TypewriterLM-7.24B といったより大きなモデルと比較すれば、私のモデルは単なるおもちゃに過ぎないからです。 私が自分の PC で訓練した v2 トイ版の EleutherAI/pythia-14m に関するいくつかの詳細： [https://github.com/croqaz/vintage-LLM/tree/e272b94fcf96316f874babbed549d20809fe5a39/models/m-v2](https://github.com/croqaz/vintage-LLM/tree/e272b94fcf96316f874babbed549d20809fe5a39/models/m-v2) 検証損失やパープレキシティの SVG ファイルをご覧いただくと、大きな跳躍が見られるはずです。これはファイルチャンクをランダム化しなかったためです。また、データセットファイルがアルファベット順にトークン化されていたことも原因で、クリーンな書籍ファイルが先に配置されていました。その結果、モデルが Time-Capsule データセットにさらされ始めると、徐々に性能が悪化しました。なぜならこのデータセットには奇妙な OCR のアーティファクトや壊れた単語・文などが多く含まれていたからです。 間違いは犯されました…しかし、そこから学びました。 私はしばらく行き詰まっていましたが、まず不適切な文書をフィルタリングし始めたことで打開策が見つかりました。 ## データ処理 データ処理はこれまでで最も長く、最も退屈なプロセスでした。その理由はお分かりいただけるでしょう…… インターネットからスクレイピングされた現代的で高品質なデータセットは数多く存在しますが、私の LLM がコンピュータや原子爆弾、宇宙船について学習することを望まなかったため、自分自身でデータセットを作成するしかなかったのです。 幸いにも利用可能なデータセットはいくつかありますが、それらの質はあまり良くなく、私の作業の大部分は重複データの除去、極めて不適切なテキストのフィルタリング、既存のテキストの一部の強化に費やされました。 歴史的なデータセットは非常に限られており、新しい古書が発見されスキャンされるまで、私たちが利用できるのは古い書籍だけです。そのため、利用可能なものを使うしかありません。 特筆すべきデータセットとしていくつか挙げられます：Project Gutenberg、Oxford Text Archive、Internet Archive books、TheBritishLibrary/blbooks、storytracer/LoC-PD-Books、dell-research-harvard/AmericanStories、dell-research-harvard/NewsWire、Heritage Made Digital Newspapers (HMD)。 各データセットの年と言語を特定するために最善を尽くし、1900 年以前の英語資料にのみ限定しました。 日付が明記されていない文書や、テキスト内で日付が見つからない文書については、品質が高くても安全のために完全に無視しました。 サイドプロジェクトとして、古い書籍、タイトル、著者、書籍 ID、ソースを含む多数の古書を収録した Book-Metadata HF データセットを作成しました：[https://huggingface.co/datasets/croqaz/book-metadata](https://huggingface.co/datasets/croqaz/book-metadata)；私の目標は全グーテンベルク書籍の年を特定することでしたが、最終的に年が 100% 確実な書籍が 5300 冊しか見つかりませんでした。 これもまた、本当に永遠にも思えるほど時間がかかりました。このブログ記事を書いている現在も、まだ完全に完了していません。 もし今後別の LLM を訓練する機会があれば、次回はより多く、より質の高いデータを用意できるでしょう。 当初は MinHash や埋め込みベクトルの類似度など、複数の重複排除手法を想定していました。これが何を意味するかご存じない場合はご安心ください、詳細には立ち入りません。 あまりにも遅く、コストも高すぎたため、断念せざるを得ませんでした。 この処理がいかに遅かったかをお伝えするために言えば、高性能な DEV サーバーで短いテキストデータセットの埋め込み計算を行いましたが、サーバーを昼夜問わず稼働させても 1 週間でデータセット全体の 10% しか処理できませんでした。そのサーバーには共有していた RTX 3090 GPU を搭載していました。 最終的に、正規化されたテキスト（小文字に変換し、すべての空白を除去したテキスト）に基づいて重複排除を行いました。つまり、「hello world」というテキストは「 Hello World」（スペースと大文字表記の違いに注意）と同じであり、私のデータセットではそのテキストは一度だけ保存されます。 最初から、データが最も重要であることを知っていました：ゴミを入れればゴミが出るのです。私は多くの実験と反復を行い、Qdrant、Zvec、Lance、ValKey、LevelDB といったデータベースを試しながら、データセットの保存方法を模索しました。 Qdrant は、多くのエントリを追加し始める前にもかかわらず DB のディスクサイズが巨大だったため、採用を断念しました。 Zvec も、DB エントリをローテーションさせる手段がないため、一度保存すると DB を探索する方法がなくなるという理由で採用を断念しました。この点について [Issue を作成しました](https://github.com/alibaba/zvec/issues/380)。Zvec は非常に新しいライブラリであり、成熟するまでもう少し時間を置くべきだったかもしれません。 Lance はバージョン管理機能に起因して採用を断念しました。数百万件以上のエントリを追加し始めると DB の速度が徐々に低下します。これは私の責任かもしれませんが、より良い方法が見つかるはずです。 ValKey は、約 1000 万件のレコードをインジェストした後にメモリ不足となり、PC でサーバーが OOM（Out Of Memory）クラッシュを起こしたため採用を断念しました。それでもなお、さらに大量のデータをインジェストする必要がありました。それ以外は ValKey は非常に優れたライブラリでした。 最終的に、ローカルウォレットアプリでビットコインやイーサリアムのトランザクションを保存するために使用されていた LevelDB を採用しました。これにより、私の PC でもスケーラブルであることが確実です。1200 万件の行をインジェストしましたが、CPU や RAM の使用量を最小限に抑えつつ、何の問題もなく完了できました。LevelDB は時として遅い場合がありますが、一貫して信頼性が高いです。 もしより高性能な PC やスーパーコンピュータを持っていれば、ValKey を最後まで使い続けたかもしれません。 テキストの質を把握するために、まず各ドキュメントの長さや一意の文字数を調べました。第一段階では短いテキスト（最大 32k 文字）を使用し、第二段階では最大 10MB の長いテキストを使用することにしました。英語は通常 30〜50 記号以内であるべきです。もしテキストの断片に 100 個以上の一意の記号が含まれている場合、それは英語ではないため除外しました。また、一意の記号がたった 8 個しかないテキストも意味をなさないため、これも削除しました。 さらに 3 つのフィルタを適用しました。 非常に簡単な指標として、ZLIB の圧縮率（compression ratio）を使用します。短すぎて多様なテキストは大きな値を持ち、過度に繰り返されるテキストは非常に小さな値になります。 # ZLIB compression ratio # A good window is 0.5...0.7; def compression_ratio(text) -> float: raw = text.encode("utf-8") compressed = zlib.compress(raw) return len(compressed) / len(raw) compression_ratio("Lorem ipsum dolor sit amet") # 1.3 compression_ratio("other, and other and other" * 100) # 0.01 -- very repeated compression_ratio("The President has nominated Thomas Johnson, William Cranch, and Charles\nSimms, Judges of the district of Columbia.\n\nOn Saturday last, Thomas Jefferson, at\npresent Vice President of the United States,\nand President of the Senate, took leave of\nthat body on which occasion he delivered\nthe following address:\n\nGentlemen of the Senate,\n\nTo give the usual opportunity") # 0.64 -- Regular text また、シャノンエントロピー（Shannon entropy）も使用しました。 # シャノンエントロピー # 印刷された英語の推定エントロピー率は約 4.2...5.5 です； def char_entropy(text) -> float: counts = Counter(text) total = len(text) entropy = 0.0 for count in counts.values(): p = count / total entropy -= p * log2(p) return entropy char_entropy(("a " * 10 + "!")) # 1.22 -- 低すぎます char_entropy("Lorem ipsum dolor sit amet") # 3.6 -- 少し低い char_entropy("IN the High court of Chancery for the Rich\nmond District,\nBetween\nHenry Banks plaintiff,\nAnd\nNathaniel Anderson, Robert Pollard.") # 4.5 -- 通常の英語 char_entropy(''.join(chr(i) for i in range(200))) # 7.6 -- 非常に高いエントロピー そして、私自身の品質検出フィルターです。これにより、奇妙な記号が多く含まれる非常に悪い OCR テキストを特定できました： _LETTER_RE = re.compile(r'[a-zα-ωàâäçèéêëîïôöùûüüÿæœß]$', re.I) _DIGIT_SPACE_RE = re.compile(r'[0-9 \n]$') _PUNCT_RE = re.compile(r'[.,;!?\'"_\-$]') # Cro のカスタム品質スコア # 通常の文字にはスコア 2 を付与； # 数字とスペースにはスコア 1 を付与； # 句読点には 0.5 を付与； # その他すべての文字には -0.5 を付与。 def quality_score(text: str) -> float: score = 0.0 for c in text: if _LETTER_RE.match(c): score += 2 elif _DIGIT_SPACE_RE.match(c): score += 1 elif _PUNCT_RE.match(c): score += 0.5 else: score -= 0.5 return ((score / len(text)) - 0.75) * 100 quality_score("-.•-, , _ ._. , • 1. - , .... - • 4 -------._ ..77/:',. .., ..., : • ':'#)).,-'' 1 - __LI -......-_-.A..-...',... ) • Silli° , A AilitA4' ' •:.:-',73 ..-.-..-_-_,N> 4. .41t.") # -8.72 quality_score("Lorem ipsum dolor sit amet") # 109.61 これらの指標を計算した後、私は単に品質の低いドキュメントを削除しました。 削除されたドキュメントの割合は 1% 未満でした。 これら一連の実験には非常に時間がかかり、常にボトルネックとなったのは計算リソースです。処理できるデータセットは他にもいくつかあります（例：Institutional Books 1.0、947GB の巨大データセット、983K 冊の書籍、386M ページなど）ですが、私の PC を壊したくありませんし、私の小さな LLM にはすでに十分なデータがあります。 私のデータセットは HuggingFace で見つけることができます：[https://huggingface.co/datasets/croqaz/vintage-v1](https://huggingface.co/datasets/croqaz/vintage-v1) ; ## Tokenization（トークン化） 私は独自のトークナイザーを作成する必要がありました。なぜなら、私のモデルは「async function」や「import sys」、「public class Main」、あるいは他のプログラミング言語の用語のような語彙を必要としないからです。 また、これは英語専用の LLM ですので、他の言語からの表現を取り込みたくありません。 既存のトークナイザーを使用していた場合、それらの無意味な単語がすべて語彙の中で無駄に消費されていただろうからです。 私は非常にクリーンな英語のグーテンベルク書籍とオックスフォード書籍を基にトークナイザーを訓練しました。 ## Base-training stage-1（ベーストレーニング段階 1） 基本的なデータセットを手に入れた後、[litGPT](https://github.com/Lightning-AI/litgpt) フレームワークを使用して、非常に基本的な [Pythia-14M パラメータ](https://github.com/EleutherAI/gpt-neox/blob/main/configs/pythia/14M.yml) モデル（パラメータ数は 0.01B）をすぐに作成しました。当初は非常にシンプルで、苦痛を伴うものではありませんでした。 私の PC で動作させるためにいくつかの工夫が必要でした。なぜなら、私は Radeon GPU を使用しており、AI のトレーニングスクリプトのほとんどが NVIDIA GPU を前提としているからです。 わずか 1 時間で、半ばランダムな英語風の無意味な文章を生成する小さな大規模言語モデル（LLM）が完成しました。例： 彼らは魂の一つをそれらに提示した。それは同じ方法で作られたものであり； 私はまたこの瞬間にもいたし、今月が短い時間なしで許されるべきではないということもそうでした。まだ、彼が法廷にいることが知られているその男のために言葉があるわけではありませんでした。これはそこに作られ、理解されるべきものとなり、その言葉は... それは野生的で奇妙な欲求であり、彼の頭の上にはあり、唯一の農場か、黒い空があり、彼は夜の顔の真ん中にいました。 しかし、彼の最初の病気は偉大であり、彼の手を持っていた男が心臓でした。なぜなら、彼は非常に多く得ており、彼は非常に弱かったからです。 彼の口はあったが、彼の手の中にありました。 彼は名誉ある男でしたが、その一人は... もう少し触ってみた後、より大きな Pythia-70M のトレーニングを試みましたが、litGPT はランダムにクラッシュし、以下のようなエラーが発生しました： エラー：ワーカーで予期せぬセグメンテーションフォルトが発生しました。 raise RuntimeError( f"DataLoader worker (pid(s) {pids_str}) exited unexpectedly" ) from e Pythia-14M と同じトークナイザーとデータセットを使用し、Pythia-31M および Pythia-160M でも試しましたが、70M モデルは動作しませんでした。しばらくデバッグを試みましたが成功せず、多くの時間を無駄にしてしまいました。最終的に、litGPT や nanoChat にヒントを得た独自のトレーニングスクリプトを作成することを決断しました。 HuggingFace の transformers ライブラリに [Trainer クラス](https://huggingface.co/docs/transformers/main_classes/trainer) があることを発見し、雰囲気でコーディングして基本的なものを構築しました。[nano-GPT](https://github.com/karpathy/nanoGPT)、[nano-Chat](https://github.com/karpathy/nanochat)、[NanoWhale-100m](https://github.com/huggingface/nanowhale) のソースコードをダウンロードし、他にも「ゼロから」のコードを含むいくつかのリポジトリを確認しました。そして、これらの LLM からベーストレーニングの実施方法に関する技術的な詳細を抽出し、LLM に最良の特徴を自身のトレーニングスクリプトに適用するよう依頼しました。このようにして、数回の反復で非常に堅牢かつ柔軟なものを手に入れることができました。 コードを手作業で何度も微調整し、気に入るまで繰り返し、その動作を理解しました。 私は意図的に nanoChat を使用しないことにしました。なぜなら、HuggingFace ライブラリとの 100% の互換性と、将来的には GGUF との互換性を確保したかったからです。 自分の PC でいくつかのデバッグ版をトレーニングした後、次は規模を大きくしてクラウド上でトレーニングする時が来ました。 Llama3 アーキテクチャに基づいた、200M パラメータ（コンテキスト 2048 トークン）と 340M パラメータ（コンテキスト 4096 トークン）のモデルを試しました。 RunPod は機能も豊富で悪くありませんでしたが、価格が高めでした。私は 0.2B パラメータの LLM をトレーニングしましたが、コンテキストサイズが非常に小さかったため、どこにもアップロードせず、費用をかけたにもかかわらず破棄することに決めました。本当に必要だったのは 4k 以上のコンテキストサイズでした。 ThunderCompute で 0.3B パラメータの Llama のトレーニングを開始しました。速度は非常に遅く、GPU の生産価格も RunPod よりさらに高かったため、大きな失望を味わいましたが、25 ドルのクレジットを使用し、すべて使い切りたいと考えていたため、クレジットを使い果たすまでトレーニングを実行させました。 [Vast.ai](http://vast.ai/) は当初、ベースの Docker イメージにさまざまな問題があり、インスタンスを起動できませんでした。しかし、何度か試行錯誤した結果、チェコにある NVIDIA RTX PRO 5000 を搭載した良好なインスタンスを見つけ、10,000 ステップ（約 3B トークン未満）実行させました。価格は非常に競争力があり、一度良いインスタンスを見つければ非常に高速で安定しているため、[Vast.ai](http://vast.ai/) は必ず再挑戦します。 この段階でのコストは、ThunderCompute で 25 ドル + 15 ドル、そして [Vast.ai](http://vast.ai/) での利用料でした。 この段階のトレーニングメトリクス： ![image](https://crlf.link/log/img/posts/metrics-Stage1.png) ## ベーストレーニングステージ 2 私は、サイズが約 20k から 10MB に及ぶ長いテキストを使用しました。 この段階で、私は長いテキストが以前のすべての指標（カスタム品質、エントロピー、圧縮）において非常に高いスコアを示していることに気づきましたが、そこには大きな OCR アーティファクトの塊が含まれており、例えば： --- マッチ #5/12310 (0fc6a6f36d5e1f02f9e5b000c480efe5005b6be5de6f819b9309b60b577fb242) --- { "source": "LOC", "len": 385331, "uniqChar": 64, "tokens": 73087, "sentences": 4555, "entropy": 103.85, "quality": 95.95, "compress": 91.92, "text": "M; \n\n\n\n1 ? 70 \n\n\nary. \n\n\nwtodrawn. timm \n\nM COLLEGE LIBRARY \n\n\nMARK \n\n\nY \n\n\n\\ \n\n\nJ \n\n\nREV. JAMES DAVIE S \n\n\nCOFI ANT \n\n\nY DIWEDDAR \n\n\nB ARC II. JAMES DAYIES, \n\n\nGan Y PARCH. G. GRIFFITHS, \nCINCINNATI, 0. \n\n\nUTICA, N. Y. \nT. J. GRIFFITHS, ARGRAFFYDD, EXCHANGE BUILDINGS. \n1875. \n\n\nI \nw \n\n\nC YN W YS I AD. \n\n\nAt y Darllenydd 4 \nRhaglith 5 — 11 \ncofiant 12 — 4q \nEnglynion Coffadwriaethol 49 \nPregethau 50—96 \nAmlinelliad o'i Brif Weddnodau 97 — 106 \nAdgofion Personol am Dano 107 114 \nAdgofion Brodyr Eraill am Dano 114— 133 \nYsgubau o Loffion Difyrus am Dano i34_ I4 g \nPenillion Coffadwriaethol 149—156 \nEnglish Department 157 ^3 \nCawellaid o Fan Saethau ei Fwa 174—187 \nPynciau Ysgol < . 188—222 \n\n\nAT Y DARLLENYDD. \n\n\nEr ys llawer o flynyddoedd cyn ei farwolaeth ceisiasai y Parch. James Davies gan ei hen gyfaill, Iorthryn Gwynedd, ysgrifenu ei gofi ant, os goroesai ef. Addawodd yntau wneyd; a chydnabyddid yn gyffredinol ddoethineb y dewisiad. Ond o herwydd anghydwelediad cydrhyngddo a'r perthynasau, parthed i ddull ei ddygiad allan, efe a ymwrthododd yn bendant a'r cyfrifoldeb. Teimlwn fod yn ddyledswydd arnom ddweyd cymaint a hyna mewn cyflawnder a'r brawd Thomas, er mwyn symud ymaith y dybiaeth mewn rhai manau, mai am na roddasid iddo fwy o arian at yr anturiaeth yr ymryddhaodd oddiwrth ei ymrwymiad. Wedi iddo ef nacau, disgynodd y gwaith arnom ni, trwy ddewisiad unol, a thaer ddymuniad y weddw a'i phlant. Yr oedd yn anhawdd genym gydsynio, o herwydd amledd a phwysigrwydd ein dyledswyddau i bobl ein gofal. Ond (i'w credyd cofnoder y ffaith), pan ddeallasant fod hyny yn peri i ni betruso, pasiasant yn unfrydol benderfyniad i ysgafnhau ein dyledswyddau iddynynt hwy tra yn parotoi y bywgraffiad, ac wedi y gorphenem, eu bod yn rhoddi i ni fis o orphwysiant. ... nnheilwng. Ymdrechwn fod yn gyfarwydd a nodau gwir Cristion. Nac ymorphwyswn ar farn dda a ddwg dynion am danom. Gymerwn y gair yn rheol ; ymarferwn ffydd ar aberth Iesu, a llefwn am oleuni a chymorth yr Ysbryd Glan at y gorchwyl. Gochelwn gymeryd ein tymer na'n teimladau yn rheol i holi ein hunain ; ond Beibl Duw fyddo ein prif faen prawf. Dyma reol y farn. \n\n\nY DIWEDD. \n\n\n" } --- マッチ #31/87899 (70fa969d373b988d5537a08ed47ccd6842c17bdcecb2cb55181e3cf37f3e13a1) --- { "source": "LOC", "len": 330083, "uniqChar": 64, "tokens": 62805, "sentences": 5311, "entropy": 104.92, "quality": 94.84, "compress": 92.95, "text": "\nQass_„L X724 ( \nBook _ \n\n\nCOFIANT, \n\n\nPREGETHAU, A BARDDONIAETH \n\n\nY DIWEDDAE \n\n\nPARCH. T. PIERCE, LIVERPOOL; \n\n\nPAKCH. H. E. THOMAS, \nBIEKENHEAD. \n\n\nLIVEKPOOLr AEGEAEEWYD GAN THOMAS LLOYD, \nTITHEEAKN STEEET. \n\n\nIBXtxgq \n\n\nIn Exchange \nThe Nat. Libr'y of Wales \nAug. 1928 \n\n\nAT Y DARLLENYDD, \n\n\nAmcenAIS wneyd y Cofiant nior fyr a cbryno ag y galhvn, er mwyn xhoi y Pregetliau a'r Farddoniaetb i mewn. Diau y buasai yn dda gan lawer ei gael yn gynt, ond nid oedd modd i mi "vraeyd, a bredwyf fod peth mantais Avedi ei gyraedd trwy yr oediad. Dylai esgeulustra Mr. Pieece yn cadw cofnodion o'i fywyd, fod yn rhybydd i'r rhai y byddai eu Cofiant o ddyddordeb ac addysg i'r byd. Dymunaf gydnabod yn y modd mnvyaf diolcbgar y lliaws Cyfeillion a roisant bob cymbortb i mi gasglu y defnyddiau, ac yr -wyf yn gadael ar y rbai oeddynt yn adnabod fy amvyl dad ynghyfraith oreu i fainu am gywirdeb y Cofiant. Bu llawer, ac rnae cryn nifer eto o'i Bregethau goreu ar wasgar, y rbai pe eu cesglid gyda'r gweddill Barddoniaetb, a alien t -vraeyd Ail Gyfiol wertbfawr. \n\nGwelir oddiwrth restr y Tanysgrifwyr am hvyddiant yr antur- naetb, ac y mae genyf addewid y gwertvir Uawer mewn ardaloedd na ddaetb dim emvau oddiyno. \n\nBydd yn rbwydd iawn i'r cyfarwydd diwygio yr ycbydig wallau argraffyddol sydd yn y Gyfrol. \n\nGan ddiolcb am bob cymbortb, a dymuno am bob llwydd a benditb, \n\nY gorpbwysaf, &c, \n\nH. E. THOMAS, \n50, Exmoeth Street, Birkenhead, \nMehefin 28ain, 1804. \n\n\nCYNHWYSIAD. \n\n\nCOFIANT, \n\n\nTUDAL. \nPen. I. Prif helyntion ei Fywyd Boreuol 5 \nPen. II. Ei Fywyd a'i lafur Gweinidogaethol . . . . 17 V. Esgeuluso cyd- gynnulliad \nPeeg. VI. Anfeidrol rinwedd aberth y Groes \n\n\n62 \n\n\ni)0 \n\n69 \n71 \n71 \n74 \n\n\nPeeg. VII. Galwad ar Sion i Ddeffroi \nPeeg. VIII. Y gwr ar y march gwyn \nPeeg. IX. Gogoniant a di- gonolrwydd trefn gras yn ngwyneb trueni dyn fel pechadur \nPeeg. X. Yr henbobl.. .. \nPeeg. XI. Gogoniant ac ar- dderchawgrwydd eglwys Dduw yn y dyddiau diweddaf . . \nPeeg. XII. Cysylltiad bywyd duwiol a manv dedwydd . . \n\n\n78 \n\n\n79 \n\n\n97 \n\n\nBAEDDON1AETH. \n\n\nMawrnad Dewi Wyn o Eifion 101 \nHaman a Mordecai . . . . 121 \nGalareb am y diweddar Barch. J. Breeze 137 \nMarwnadyParch.J. P.Davies 148 \nCywydd i'r Goleudy . . . . \nA WORLD LEADER IN PAPER PRESERVATION \n1 1 1 Thomson Park Drive \nCranberry Township, PA 16066 \n(724)779-2111 ' \n\n\n" } これらのサンプルは全体的に非常に高いスコアを持っていますが、実用性は皆無です。おそらく英語のテキストではないのでしょう。LOC-PD から数百例、その他の OTA データセットからも数百例ほど数え上げました。もし私がこのようなゴミを LLM に与えた場合、何が学習されるでしょうか？ 私は周囲を検索し、辞書単語検索、単語内の母音の数、ノイズの総数といった追加指標を計算することを決めました。これらの新しい値を用いて、すべての値を単一のスコアに統合した結果、最も高品質なドキュメントのみを残すことができました。完璧ではないことは承知していますが、データセットを検索している限り、目にするデータにはかなり満足しています。 低品質なドキュメントは全体の 1% 未満であると計算され、これは短文テキストデータセットの結果と一致していました。 ちなみに、このデータセットのエントリをインポートし、照会し、カウントするためのすべてのコードはオープンソースです：[https://github.com/croqaz/vintage-LLM/tree/main/dataset](https://github.com/croqaz/vintage-LLM/tree/main/dataset) ; 計算資源がもっとあれば、あるいはより大きな LLM を訓練すれば、さらに多くのデータを利用できたでしょう。しかし、すでにこれだけで非常に時間がかかっていたため、私は自ら制限を設けることにしました。 このトレーニングは、フランスの RTX PRO 6000 WS で [Vast.ai](http://vast.ai/) を再度使用し、10,150 ステップ（約 6B トークン）で実行しました。 以下に示すメトリクスにあるように、2 ラウンドのトレーニングを行いました。モデルチェックポイントのアップロード直後にインスタンスを起動した際、私のトークナイゼーションスクリプトが OOM（Out Of Memory：メモリ不足）によりクラッシュしてしまったためです。その問題を修正して再実行している間、GPU を稼働させ続けるために、古詩、名言、ことわざ、そしてオックスフォードのクリーンな書籍からなるサブデータセットを素早くトークナイズしました（これらはすべて同一期間内のものです）。2 回目のトレーニングは、上記で言及したランダム化された長文ドキュメントのみを対象としたものでした。 このステージのコストは 40 ドルでした。 このステージのメトリクス： ![image](https://crlf.link/log/img/posts/metrics-Stage2.png) Chinchilla スケーリング法則によると、3+6=9B トークンが、この 340M パラメータモデルに対する適切なトレーニングトークンの量とされています。 ## Fine-tuning（ファインチューニング） 私がこの記事を書いている時点では、このステージはまだ完了していません。準備ができ次第、別の投稿を作成する予定です。 モデルに対話の理解能力を持たせるために、"base knowledge"（基礎知識）データセットを生成するための一連の Python スクリプトを作成しました。これはファインチューニングの対象となるものです。食品、果物、野菜、いくつかの動物や鳥、色、少数の数に関する基本的な質問と回答が含まれています。 異なる微調整を数回行ったファインチューニングの結果、安定した対話を生成できるようになりました。数百例という少ないデータでさえも、"Question:..." に続く "Answer:..." という構造を学習していることを確認できたのは嬉しかったです。 現時点でのいくつかのサンプル。最終モデルに、私の [CommonSense データセット](https://huggingface.co/datasets/croqaz/commonsense-v1) を用いた軽いファインチューニングを施したものです。 ユーザー：神とは何ですか？ LLM #1: 神は絶対的な支配者であり、我々が希望と強さを得るのは彼のみである。 LLM #2: 神のような性格を持つ存在とは、自分が至高の存在であることを自覚し、それによってのみ我々が行動できる存在のことだ。 LLM #3: 太陽は地球に光を照らし、星々はその光を反射する。 ユーザー：愛とは何ですか？ LLM #1: 愛は強力な衝動であり、それが我々の傾向を克服することを可能にする。 LLM #2: 愛は、人間のある特定の条件の結果である。例えば、「あなたを愛するのは、彼があなたを愛しているから」というような場合だ。 LLM #3: 愛とは快楽を与えることへの欲求であり、行動の対象は、特定の人物や物に対する情熱や愛情の充足である。 ユーザー：人生とは何ですか？ LLM #1: 人生は苦痛との戦いであり、生きる時間が長くなるほど、我々はより多く苦しむ。 LLM #2: 人生は生存のための大きな闘争であり、その中で各人は自らの個人的な快楽を犠牲にし、他者の最善の利益を追求しなければならない。 LLM #3: 人生とは人生そのものであり、その帰結は魂にとって、心臓が心臓であるようなものである。 # いくつかの挨拶を試してみる ユーザー：お元気ですか？ LLM #1: それらの抵抗を克服するためには、熱、火、そして冷たさが必要とされる。 LLM #2: 我々は天文学に関する最良の書籍を使用する。 LLM #2: お天気は魅力的です。 ユーザー：ご挨拶を申し上げます、良い方よ！ LLM #1：最善のことは、あなたが完了したときです。 LLM #2：喜んで！名誉をありがとうございます。私はそれを書くことを考えていました。 LLM #2：いいえ；彼らの思考が嫌いです。それは私の心ではなく、私の記憶からのものです。 # いくつかの名前を尋ねる ユーザー：あなたの名前は？ LLM #1: シャルル・エミール・ド・サン＝ヴァレリー。 LLM #2: ニネット。私は古代のクラスに属します。 LLM #3: シャルル・リチャーズ。 LLM #4: チャールズ・バムフォード、「十九世紀」出身。 LLM #5: 私の母は奴隷、父も奴隷でした。 すべてのサンプルは私の「[generate.py](https://github.com/croqaz/vintage-LLM/blob/main/training/generate.py)」スクリプトで生成されました。*temperature=1.0, top-p=0.9, top-k=25, min-p=0.01, repetition-penalty=1.1*。 このモデルはハルシネーション（幻覚）が多く、会話を本当に追従しません。まだチャットすることはできず、より多くの「ベイク」（学習・調整）が必要です。 すべての対話は宝くじのようなものです：コインを投入し、レバーを引き、最善を祈るのです。時には素敵な結果が得られることもあります。 神、愛、人生に関する質問に対してモデルがこれほどよく回答したことは素晴らしい驚きでした。特に私の「ベース知識」データセットにそれらの概念が含まれていないにもかかわらず、モデルは長期の基礎トレーニングからそれを吸収し、チャットテンプレートを適用する方法を学習しました。 ## モデルは数学を記憶できるか？ 私のファインチューニングに関する知識ファイルには、深く考えずに適当に追加した単純な数学演算が含まれていましたが、トレーニングの異なる段階でさまざまなプロンプトを使ってモデルの振る舞いをチェックしている際、「1 + 1 はいくつですか？」と尋ねてみたところ、答えは通常、ランダムな数値か全く意味をなさないものでした。 そこで私は、モデルが -2 から 12 のような範囲の数に対する基本的な数学演算を記憶できるかどうかを確認したくなりました。 私は、-2 から 12 のすべての数に対する基本的な演算（+、-、/、*）を含む 5300 問の数学データセットを生成しました。質問の仕方も様々で、例えば以下の通りです： - "What is 10 - 3?" - "How much is 7 * 10?" - "Multiply 9 by 2." - "Calculate -2 * 6." また、すべての可能な演算と数値の組み合わせ（0 から 12）に対して「X と Y を計算してください」と問いかける数学ベンチマークも作成しました（負の数値は除外しています）。 ファインチューニングは完全なトレーニングに比べて非常に高速なので、多くの実験を行い、数分以内に結果を確認することができました。 ベースモデルからいくつかのモデルをファインチューニングし、さまざまなハイパーパラメータを試したところ、LR=5e-5、max_seq_length=2048、neftune_noise_alpha=0.0（このケースでは非常に重要）、そしてもちろん temperature=0 で最高の結果が得られました。 最高スコア： [ + ] addition: 75/169 (44.4%) y│ 0 1 2 3 4 5 6 7 8 9 10 11 12 ──┼──────────────────────────────────────────────────── 0 │ ✗ ✗ ✓ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✓ ✗ ✓ 1 │ ✓ ✗ ✓ ✓ ✓ ✗ ✗ ✗ ✓ ✗ ✗ ✓ ✓ 2 │ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✗ 3 │ ✗ ✗ ✓ ✓ ✗ ✗ ✓ ✓ ✗ ✓ ✗ ✓ ✓ 4 │ ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✗ ✓ ✓ 5 │ ✓ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✗ ✗ ✗ ✓ ✓ 6 │ ✓ ✗ ✗ ✓ ✓ ✗ ✓ ✓ ✓ ✗ ✗ ✓ ✓ 7 │ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ 8 │ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✓ ✗ 9 │ ✗ ✗ ✗ ✓ ✗ ✓ ✗ ✓ ✗ ✓ ✗ ✗ ✓ 10 │ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✓ ✓ ✗ ✓ 11 │ ✗ ✗ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ 12 │ ✗ ✗ ✓ ✓ ✗ ✓ ✗ ✓ ✗ ✗ ✗ ✓ ✗ [ - ] 引き算：114/169 (67.5%) y│ 0 1 2 3 4 5 6 7 8 9 10 11 12 ──┼──────────────────────────────────────────────────── 0 │ ✗ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 1 │ ✓ ✗ ✗ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✗ ✓ ✓ 2 │ ✗ ✓ ✗ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✓ ✓ ✓ 3 │ ✗ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✓ ✓ ✗ 4 │ ✗ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✗ ✓ ✗ ✓ ✗ 5 │ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✓ 6 │ ✗ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✗ ✓ ✓ 7 │ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ 8 │ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✗ ✗ ✓ 9 │ ✗ ✓ ✗ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✓ 10 │ ✗ ✓ ✗ ✓ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ 11 │ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗ 12 │ ✗ ✓ ✗ ✓ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✓ ✗ [ * ] 乗算：118/169 (69.8%) y│ 0 1 2 3 4 5 6 7 8 9 10 11 12 ──┼──────────────────────────────────────────────────── 0 │ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✗ ✓ ✓ 1 │ ✗ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✗ 2 │ ✓ ✓ ✓ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 3 │ ✓ ✗ ✓ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✗ ✗ 4 │ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✓ ✓ 5 │ ✓ ✓ ✓ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 6 │ ✓ ✓ ✓ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✗ ✓ ✗ 7 │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✗ 8 │ ✓ ✓ ✗ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ 9 │ ✗ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✗ ✗ ✗ 10 │ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✓ ✗ ✗ ✓ 11 │ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 12 │ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✓ ✓ ✓ ✗ ✓ ✗ [ / ] 除算：85/156 (54.5%) y│ 0 1 2 3 4 5 6 7 8 9 10 11 12 ──┼──────────────────────────────────────────────────── 0 │ · ✓ ✓ ✓ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ 1 │ · ✗ ✗ ✓ ✓ ✗ ✗ ✓ ✓ ✓ ✗ ✓ ✗ 2 │ · ✓ ✓ ✗ ✓ ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✓ 3 │ · ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ 4 │ · ✓ ✗ ✗ ✓ ✓ ✓ ✗ ✗ ✗ ✓ ✗ ✗ 5 │ · ✓ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✓ ✓ ✓ 6 │ · ✗ ✓ ✗ ✓ ✓ ✗ ✓ ✗ ✗ ✓ ✗ ✗ 7 │ · ✗ ✗ ✓ ✓ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✗ 8 │ · ✗ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ 9 │ · ✓ ✓ ✓ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✓ 10 │ · ✓ ✗ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✗ ✓ ✗ 11 │ · ✓ ✓ ✓ ✗ ✗ ✓ ✓ ✗ ✓ ✓ ✗ ✓ 12 │ · ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✗ 要約 + 加算 75/169 (44.4%) ████████ - 減算 114/169 (67.5%) █████████████ * 乗算 118/169 (69.8%) █████████████ / 除算 85/156 (54.5%) ██████████ -------------------------------------------------- 合計 392/663 (59.1%) モデルが減算の方が加算よりも一貫して高いパフォーマンスを示すことに驚いています。なぜなら、減算の定式化は少し複雑だからです。例えば「3 から 2 を引く」と「3 - 2 を引く」では、数字の順序が逆転しています。私は人間のようにモデルが加算で最も良い結果を出すだろうと予想しましたが、実際には加算が最悪のスコアでした… ともかく、60% よりも高いスコアは得られなかったので、このモデルは基本的な数学を記憶できないと考えています。 間違っていたら教えてください！コメントを残して、私が何を見落としているか教えてくださいね！ もちろん、1 + 1 を正しく答える確率が半分しかない 650MB の脳をダウンロードさせるために、これを HuggingFace にアップロードすることはありません…計算機を使いましょうね？ ## トレーニング中のバイブチェック トレーニングの異なるステップでモデルを操作し、何を生成するかを確認します。 興味深いことに、トレーニングの初期段階では、モデルは単語の順序、つまりどの単語が次に続くべきかを学習しています。その後、文のようなより大きなシーケンス内の単語を学習し始めます。さらに進むと、2〜3 文をつなげる方法を学びます。これを継続して訓練すれば、長い段落を構築する方法も学ぶようになりますが、それには時間がかかります… ## ステップ 200 モデルはまだ主にランダムノイズです。 --- プロンプト 1 --- ユーザー：こんにちは！ モデル： こんにちは！ltO,til,le cansia the tst. . m' o. the i6n a 1 M. B. C. C. PI .h., The Fn.l i. n. L --- プロンプト 2 --- ユーザー：あなたは誰ですか？ モデル： あなたは誰ですか？田舎の男です。埋められるために生まれたのです。私たちは今日のこの機会にいます。投票数はサウスカロライナ州のワール郡から銀行に引き渡されました。そこで彼らはすべてを占領しました。手続きはこの大きな塊から生産することを許可されました。これは不必要なことの1つであり、会社側から質問が続きました。 --- プロンプト 3 --- ユーザー：こんにちは、友人よ モデル： こんにちは、私の友人。彼女の「マ・テスル」の友人として。彼の人生と名誉における他のすべての国において、彼は世界でこれまで行われたようなことに対して、一瞬以上を費やすことになるでしょう。 この国がその状態にあることを期待することは不可能です… --- プロンプト 4 --- ユーザー：ここはどこですか？ モデル： ここはどこですか？ 州にとって最初かつ最も重要であり、その意見では、私たちにとって非常に価値あるものです。ロシアの立法府は以下の通りでした：—「アイルランドのH. M'ニード氏（S. H. 氏）の議会は、早期の資金に関する期間に参照されました。 ## ステップ1000 モデルは単語同士を結びつけることを学びます。 --- プロンプト 1 --- ユーザー：こんにちは！ モデル： こんにちは！CIR. および HI, RAJUy 事業が破壊されました。 J. R. フラー氏および、A. & J. マクリーン氏とJ. E. ハバード氏、MIR G. P. ラルトン氏、E. + D. デクスター社のG. W. ハリス氏、および同社のJ. A. ブラウン氏によって。 --- プロンプト 2 --- ユーザー：あなたは誰ですか？ モデル： あなたは誰ですか？— しかし神には、同じようになりたいと願う子供がおられ、彼は非常に優れた方です。それは淑女や士官にとっての作法の飾りとなってきました。私はいつも、著者が私に宛てて書いているとは観察していませんでした。— 私はあなたの良き友人であり見知らぬ者ではありませんが、もし私が見知らぬ者にならないのであれば、彼の人生を喜んで拝見するでしょう。見知らぬ者として信じていますと、それは若く美しい女性、つまり見知らぬ女性に話しかける私の務めとなるでしょう。 --- プロンプト 3 --- ユーザー：こんにちは、友人よ モデル： こんにちは、友人よ、しかし古くからの知人としての道程において。— ご主人がご自身のこの高貴な家系の産物であるかのように思われるほどに、私に対するご恩恵の数々があるのはむしろ驚くべきことです。— しかしこれは私が想像できることのすべてではありません。なぜなら、この種の偉大な対象は、私が言及した宗教的機関の利益を確保するためのものであるように思えるからです。— ご自身の個人的な功績と彼の忠誠心との唯一の違いです。 --- プロンプト 4 --- ユーザー：ここはどこですか？ モデル： ここはどこですか？ 彼はそのような出来事の危険はないと言いました。 原告、すなわち被告は非常に立派な人物であり、バレット・アンド・カンパニーという会社で三年間勤務した経験があります。その報酬は、1830 年に彼が居住していた彼の財産の総価値に対して 50 パーセントでした。彼は長年以前から銀行の業務に関する帳簿を管理しており、それは明らかになりました ## ステップ 10,000（ステージ 1 の終了） このモデルは、現時点で私の [CommonSense dataset](https://huggingface.co/datasets/croqaz/commonsense-v1) を用いて非常に軽いファインチューニングを行ったため、クリーンなテキストを生成します。 --- プロンプト 1 --- ユーザー：こんにちは！ モデル: こんにちは！素晴らしいアイデアですね！これは足が何本ありますか？これはある種の動物です；それが獣です。ああ、あれは何ですか？あれは何ですか？馬には尻尾がありません。しかしそれは野獣であり、恐らく私はその中に尻尾を見つけることができないでしょう。馬には尻尾がなく、それを食べてしまうのです。そしてどうなっているのでしょうか？ああ、それを食べるのにどれくらいかかるのでしょうか？ああ、彼らはどれほど食べるのでしょうか？そして馬は --- プロンプト 2 --- ユーザー：あなたは誰ですか？ モデル: あなたは誰ですか？ では、男と妻の違いとは何でしょうか？ --- プロンプト 3 --- ユーザー：こんにちは、友人よ モデル: こんにちは、友人よ。この友人はここ数日、街を歩き回っている習慣があるようです。彼は安価な商品を購入できる場所を探すために、あらゆる方向に往復して歩きました。これはご存知の通り真実ではありませんが、どうやらあなたは卸売価格でいくつかの商品を購入できる場所について考えているようですね。これは奇妙な商売の方法であり、男は安く買うことで商品を安く作れるとよく言われます。 --- プロンプト 4 --- ユーザー：ここはどこですか？ モデル： ここはどんな場所ですか？それが見えますか？見えますか？私はそれを見ました。それが見えますか？それは果実を結ぶ木であり、その木には果実があります。それが見えますか？地面に立っている木はありますか？同じ種類の他の木はありますか？それらが見えますか？それらが見えますか？それらが見えますか？それらが見えますか？それらはより一般的ですか？それらが見えますか？あれは何ですか？それらが見えますか？ ## ステップ 20,000（ステージ 2 の終了） この段階ではテキストは半ばランダムですが、一貫性があります。このテキストの塊全体が同じ本からのもののように見え、それは素晴らしいことです。 ファインチューニングなし。 --- プロンプト 1 --- ユーザー：こんにちは！ モデル： 「こんにちは！」とダイヤー氏が叫びました。「その男は愚かな連中です。何か役に立たねばなりません。」 「しかし、そうとは考えません、先生」と弁護士は答えました、「私の本の一つで物語をお話ししましょう。老紳士のケースはこうです——彼は見知らぬ国に住んでいました。妻が亡くなり、息子が彼を引き取りました。彼は --- プロンプト 2 --- ユーザー：あなたは誰ですか？ モデル： 「あなたは誰ですか？」 探偵はテーブルのそばに立ち、背中をドアに向けていました。 「その騒ぎを起こしに行くのですか？」と彼は言いました。 「はい」と彼は答えました。 「そしてそれを片付けに行きますか？」 「いいえ」 「では、それについては後で考えましょう。」 --- プロンプト 3 --- ユーザー：こんにちは、友人よ Model: こんにちは、友人よ。私は誠実な男の助言を君に与えよう。 「上記は文字通りの訳である。疑う余地はないが、読者自身がこれを読んだことがあるかどうかはわからない。」 P.S. — ちょうど田舎から戻ってきたところだ。残念だが、誰かの家よりも、むしろ自分の家で過ごしたいと思う。もし私が君に思い出していただければ、それは君にとって --- プロンプト 4 --- ユーザー：ここはどこですか？ Model: ここはどこですか？ 悪魔そのものが悪魔である！ 心の声。53 心の声。 生まれてこなければよかったと願う！ 私の罪の物語を決して語るまい！ 決して語らない！ しかし、ああ！言葉は苦痛に満ちており、 まるでより明確になったかのように響く： ## 次のステップ まだ優れたインストラクションモデルを持っていませんし、未完成なものを共有するつもりもありませんが、取り組んでいるデータセットはいくらでもあります。 - 私の CommonSense データセットは拡大しており、約 7,000 行を準備済みで、さらに追加するアイデアもあります。 - アリストテレス、フロイト、プラトンなどの哲学者からの引用リストを持っており、これらを Q&A ペアとして整えていきます。 - 1900 年以前のいくつかの書籍から、明確な質問と回答を抽出しました。例： The new common school question book 1888（新普通学校問題集 1888） - The advanced question book 1883（上級問題集 1883） - A complete dictionary of synonyms and antonyms 1835（同義語・対義語完全辞典 1835）など。 - これらすべてを処理したわけではありませんが、別々のデータセットとして公開する予定です。 - 古い辞書も持っており、そこから単語の定義を抽出し、より多くの Q&A 形式に変換する計画です。 - King James 訳聖書から異なるトピックを抽出して、より多くの Q&A ペアを作成したいと考えています。 - また、Talkie-13B-Q8-GGUF と Monad-GPT-Q8-GGUF も手元にあります。これらを使っていくつかの合成データセットを生成できるはずです。 これらのデータセット、あるいは少なくともその一部は、モデルが対話構造を理解する助けになるでしょう。実験してみます。 十分に共有できるモデルができたら、また別の投稿を書きます。 ## 終わり このプロジェクトを開始した際、私はあえて「成功」の定義を設けませんでした。明確な目標を持って始めたわけではありません。まず第一に、これは学習プロジェクトでした。 私が目指していたのは、ある程度実用的なビクトリア朝時代の対話文が得られることだけでした。 しかし、これほど多くの時間とエネルギーを費やしたにもかかわらず、ファインチューニングを行わない状態ではその出来があまりにも悪いことに驚きました。そのため、今後はすべての創造的なエネルギーを注ぎ込み、共有できるだけの質の高い何かを生み出すことに集中したいと考えています。 みなさんはどう思われますか？ このような取り組みに興味をお持ちですか？ この種の LLM を何に活用したいとお考えでしょうか？ 「ヴィンテージ LLM」という文脈において、私になら何を試してほしいと思いますか？ ご連絡をご希望の場合は、以下のいくつかの方法があります。 - ここにコメントを残してください； - Hugging Face のディスカッションページにコメントを残してください：https://huggingface.co/croqaz/vintage-LLM-340m-v1-base/discussions； - Vintage-LLM リポジトリにイシューを提起してください：https://github.com/croqaz/vintage-LLM/issues； - Vintage-LLM の Discord サーバーに参加してメッセージを送ってください。 プライベートでお問い合わせしたい場合は、私のメールは *my short name* at *this domain* です。 クラウド GPU プロバイダーの方で、使用されていない GPU をお持ちで、次のモデルのトレーニングをスポンサーしていただける方は、ぜひご連絡ください！**すべての計算リソースを、より良いデータセットを持つ 1B モデルのトレーニングに充てるか、この 340M モデルのベーストレーニングを最大 50,000 ステップまで延長するか、どちらでもお選びいただけます！私は十分なデータを持っていますので、ご選択ください！** これらの LLM（大規模言語モデル）についてさらに詳しく知りたい場合は、私の以前の投稿 [Vintage LLM models](https://crlf.link/log/entries/260428-1/) をご覧ください。多くのリンクが掲載されています。 AI や LLM に興味や期待を抱いている方は、私が行ったように実際に試して、トレーニングの各段階の間にも遊んでみて、その裏側を垣間見てみることをお勧めします。AGI（人工一般知能）についてはすぐに忘れ去ることになるでしょうが、間違いなく楽しいものです。約束します！ もしかすると、誰も見たことのないプロセスのひねり、つまり独自のデータセットやトレーニング手法、あるいは LLM アーキテクチャを見つけられるかもしれません。しかし、必ずしもそうする必要はありません。いずれにせよ新しいことを学べるはずです。私もそうでしたから！ 注：このブログ記事は 100% 私によって書かれました。AI は一切使用されていません。 [@articles](https://crlf.link/articles) [#ai](https://crlf.link/tags/ai) [#vintage](https://crlf.link/tags/vintage)

ゼロから作るヴィンテージ LLM（50 分読了）

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト