【完全保存版】GPT を特定の目的に特化させて扱う (Fine-tuning, Prompt, Index, etc.) - Qiita
【完全保存版】GPT を特定の目的に特化させて扱う (Fine-tuning, Prompt, Index, etc.)OpenAIChatGPTlangchainGPT-4LlamaIndex ChatGPT に代表される今日の AI ブームを牽引しているのは 大規模言語モデル（Large-scale Language Model, LLM） と言っても過言ではないでしょう。LLM とは大量のテキストデータを使ってトレーニングされた自然言語処理のモデルで、代表的なものに、GPT（OpenAI）、Llama（Meta）、PaLM（Google）があります。我々開発者は、事前学習されたこれらのモデルを使って簡単にアプリケーションを作ることができます。 LLM が遂行可能な言語的タスク LLM を使って行える言語的タスクには次のような種類があります： Classification: 感情やポジ
AWS RDSでもDBAはparameterチューニングする - Qiita
弊社で某テック・リーダーの遺産として「PostgreSQL 運用管理トレーニング」が1月に実施されたのはまだ記憶に新しいところ。 あのときのリーダーの言葉、憶えているうちに書き留めておこう。 「Managed Service で RDB を使う時代になっても、この研修で扱う知識はDBAもApplication Engineerも持っておくべきだと信じて、企画し実現しました」 （この記憶はほんとうか？ 意訳や美化が入っているかもしれない） 事例の1つを共有しましょう。 担当プロダクトの背景事情 担当プロダクトで使っているPostgreSQLをメジャーアップするには、現況を把握して変更影響を洗い出す作業から始めます。 現況把握のひとつとして、postgresql.conf（AWS RDSだとparameter group） の状況調査をしました。 重点ポイント PostgreSQLデフォールト
チューニングが必要なSQLを洗い出す
本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。（編集局） 連載目次 前回までの記事でSQLチューニングを行うために必要な基礎知識を説明しました。今回は、チューニング対象とすべきSQLを、どのような観点から、どのように洗い出していくのかを説明していきます。 チューニング対象SQLの洗い出し 通常、アプリケーションでは多くのSQLが実行されています。SQLチューニングのステップは、実行されている多くのSQLの中から、チューニングの目標に合わせて、対象とするSQLを洗い出
＠IT：事例に学ぶWebシステム開発のワンポイント（6）APサーバからの応答がなくなった、なぜ？
今回のワンポイント アプリケーション・サーバから応答がない、いわゆる無応答状態は、ベンダのサポートセンターに寄せられる質問でも数が多いといわれている。無応答状態の原因の多くはGC（ガベージ・コレクション）にあり、これはGCチューニングにより解消可能だ。今回の記事では、GCチューニングにより無応答状態を解決する道のりを紹介していく。 サーバから応答がない、なぜ？ あるとき、長時間レスポンスが返ってこないという事象が発生した。定期的な応答時間の監視から、無応答状態はアプリケーション・サーバを起動してから数時間経過すると発生し、数分間無応答状態が続いた後に再び正常に処理を開始することが分かった。 無応答の原因を探る 筆者はこの現象を見て、無応答が数分間で終わっていることからガベージ・コレクション（GC）が原因であるとの仮説を立てた。GC実行中、アプリケーション・サーバのCPUはGCのためだけに使
Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第6回：query_cache_sizeの違いによるパフォーマンス比較 (1/3)