ABEJAでデータサイエンティストをしている服部です。 ABEJAは国立研究開発法人新エネルギー・産業技術総合開発機構（以下「NEDO」）が公募した「ポスト5G情報通信システム基盤強化研究開発事業／ポスト5G情報通信システムの開発」に当社提案の「LLMの社会実装に向けた特化型モデルの元となる汎化的LLM」に採択されたことを受け、LLMの事前学習を実施しました。 その中でモデルの学習だけでなく、学習に欠かせない大規模日本語言語コーパスを作りました。データセットのサイズとしては、語彙拡張前のMixtral Tokenizerで約400Bほどのものです。 特にその中で大部分を占めるCommon Crawlをベースとしてデータセットを作った過程について解説します。 データセットの概要 Common Crawlについて warcとwet データセット作成方針 前処理の流れ 1. 日本語の簡易判定、w

使いたい開発ツールがきっと見つかるFindy Toolsは、実際に利用している企業の レビューから 開発ツールの導入、 検討に関わる意思決定をサポートします。

LAPRAS忘年会 2023でのLT発表資料です。

切っ掛けと問題の認識 AWS Config のカウント数の監視 対象外にしたいリソースが見つかったら AWS Config 側で除外する 実際のコスト削減効果 なぜもともとコストが高かったのか まとめ こんにちは、ABEJAの村主です。ABEJAアドベントカレンダー2023の18日目の記事です。今回は、意外にも高額になりがちなAWS Configのコスト削減について、どのように対応したかをご紹介します。特に、AWS Configのコストを大幅に減らすためのアプローチについてお話しします。また、CloudWatch で AWS Config のカウント量を可視化する方法はあまり見かけなかったのでブログにしておきました。 切っ掛けと問題の認識 最初に気づいたのは、AWS Cost Explorer を確認していたときです。そこで見たAWS Configのコストは、1日あたり約$15、月間では約

はじめに ABEJAでデータサイエンティストをしている服部です。 今回はLLMで外部データを使うケースについてのお話をしたいと思います。 はじめに LLMと外部データの利用 RetrievalとLLM 0. (事前準備)参照したいテキストデータをDBに格納 1. ユーザの入力文とのテキスト類似度を計算して、関連テキストを抽出する(Retrieval) 2. 関連テキストをLLMのプロンプトに入れ込み、ユーザの入力文に回答する。 Retrieval時の課題 LangChainでの用意 Case1: それぞれの文章がRetrievalしにくい形で保存されている 対策案: ページ構造を意識した形で各文章を格納する 他の対策案 聞き方を明確にする 類似度を測るクエリ文章を置き換える 不要そうな文章をデータから削除する データ自体をLLMで整形し直す Case2: 未知の単語を含む 仮説: ニャオハ

自己紹介 I/Oや通信的観点 分割されたクエリを取り除く 過剰なワイルドカード テーブルを避ける テーブルを日付別にシャーディングすることを避ける & テーブルの過度な分割を回避する JOIN を使用する前にデータを削減する コンピューティング的観点 結合パターンを最適化する 結合で INT64 データ型を使用して費用を削減し、比較パフォーマンスを向上させる 同じ共通テーブル式（CTE）を複数回評価するのを避ける クエリのアンチパターン 自己結合 データスキュー 公式にはない項目ですが個人的に気になったので 単一行を更新または挿入する DML ステートメント 非正規化の検討 ネストされて繰り返されているフィールドを使用する 採用情報 自己紹介 こんにちは、真壁（@Takayoshi_ma）です。先日読んだGoogle Cloudの公式ドキュメントが個人的に勉強になったので内容についてまとめ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Terraform はそのままだと管理が大変 みなさん IaC (Infrastructure as Code) してますか？パブリッククラウドをIaCするなら、 Terraform が便利ですね！ しかし、本格的に使い始めると、こういう問題がすぐに出てきます。 複数環境の楽な分け方を知りたい ワークスペースはなんか嫌だ とはいえ、環境間で共通するボイラープレートをどうにかしたい 環境内で適用するモジュールを細分化・分岐したいけど面倒 環境ごとに使うモジュールを切り替えたい テスト環境はAuroraではなく安いRDSにしたい モジュール(tfstate)を分割して小さい範囲で適用したい 大きなモジュールは影響範囲がわからないし、差分計算にそれなりに時間がかかってしまう 分けたモジュールを一括適用するのが面倒 モジュール間の依存関係がわからない モジュール(tfstate)間での値参照が面倒

ABEJAでデータサイエンティストをしている服部です。 2022年10月28, 29日にバルセロナにてKaggle Days World Championship Finalというデータサイエンスに関するイベント兼コンペティションが開催され、そこに参加しました。そして幸いなことに私の所属するチームが優勝することができました！！ 本記事では今回のイベントそのものと、優勝に至るまでのコンペ上での過程や工夫点などについてご紹介しようと思います。 Kaggle Days World Championship Finalとは 1日目（ワークショップやプレゼンテーション等） Opening remarks by LogicAI and Kaggle HP introduction - Key note Kaggle Team - Ask Me Anything Winners team present

1. はじめに 2. 先行研究からの学び 3. 前提 4. アーキテクチャ変更候補 活性化関数の変更 (SwishGLU) Transformer layerの並列化 biasパラメータ除去 Input-Output Embeddingの共有 (Weight tying) 5. 小規模モデルでの実験 実験設定 Transformer layerの並列化 SwishGLUの適用 Bias parameterの除去 bias削除の実験 最初もしくは最後のbiasだけを残す Input-Output Embeddingの共有 (Weight tying) 6. 中規模モデルでの実験 実験設定 モデルサイズでの比較 Shared Input output embeddings (weight tying) Transformer layerの並列化 SwishGLUの適用 7. 13Bパラメーター