OpenAI API の ファインチューニングガイド｜npaka
1. ファインチューニングの利点ファインチューニングの利点は、次のとおりです。 (1) プロンプトよりも高品質な応答 (2) プロンプトに収まりきらないより多くの例の適用 (3) プロンプトの短縮によるトークン数 (コスト) の節約 (4) プロンプトの短縮による処理時間の短縮 モデルは膨大な量のテキストで事前学習されており、このモデルを効果的に利用するため、プロンプトに手順や応答の例を指定する手法が使われます。この例を使用してタスクの実行方法を示すことを「Few-Shot」と呼びます。 ファインチューニングで、プロンプトに収まりきらないより多くの例で学習することにより、さまざまなタスクでより良い結果を達成できるようになります。プロンプトに多くの例を指定する必要はなくなります。これによりトークン (コスト) が節約され、処理時間も短縮されます。 2. ファインチューニングの使用料金ファイン
Advanced API Calling in Go
Go 1.9 Release Party in Tokyo での発表資料です by @__timakin__
アプリエンジニアから見てAPI設計において気をつけてもらえるとうれしいこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? by @mixiappwchr アプリ向けのAPIの開発時に気をつけてもらえるとうれしい＆メンテナンスや実装コストが下がる点をつらつら書きます。 データ構造について データを返すとき、一定のルールを守って返す。例えば当然ですが同じデータ構造はもちろん、似たような構造もルールを作ってproperty名などそろえておく。relationやlistで返すときもどのデータ構造なのかがpropertyで明確にわかるようなっているようにする listを返す場合の形式やpagingが必要な場合の形式はそろえる。配列のデータがない場合も考慮しておく。例
権限管理を実装するときの地味な話 - ✘╹◡╹✘
「あるユーザがXをYできるかどうか」というメソッドを定義したいとき、Userに実装するよりも、Xに実装した方がうまくいくことが多かった。例えば「ユーザが投稿を編集できるか」という、ブログの共同編集のような機能で使うやつで考える。つまり、User#can_edit?(entry) みたいなやつにするか Entry#editable_by?(user) みたいなやつにするかという話になる。 後者の方でうまくいった理由は、Webアプリだとログイン中のユーザが存在しない場合というのがあるが、後者ではuserがnilの場合でも対応できたというのと、Userクラスが長大にならなかったという点 (Abilityクラスとかを全ての場所で統一して使えている場合はそれで良いので各自適当にやっていってほしい)。あとメソッドの命名規則の問題があって、名詞形 (例:User#name) か、xxx?で終わるメソッド
ページャNight 1ページ目という勉強会やりました - その手の平は尻もつかめるさ
そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前
言語設計と文字列API
リンク t.co プログラミング言語内の正規表現リテラルについて — KaoriYa プログラミング言語内の正規表現リテラルが是か非か、 そんな議論にいまさらながら参加してます。 ただしどちらかの立場に立って擁護したいというわけではなく、 話を抽象化というか一般化して問題の本質にせまります。 Kazuho Oku @kazuho 言語設計論では、基本「書くコスト」と「保守（読む）コスト」の２種類にわけて考えればいいと思ってる / 言語のAPI仕様を最小にするのには正規表現リテラルの導入が有効というのが僕の論 / “プログラミング言語内の正規表現リテラルにつ…” http://t.co/whvioxMAII 2013-12-20 14:14:16
日本の全エンジニアに捧ぐ！現在公開されているAPI一覧【2013年版】 | Find Job ! Startup
2013年のいま、API界隈が熱い！ 今年に入り、官公庁の統計データやNHKの番組情報など、今までなかなか利用できなかったデータがAPIとして扱えるようになってきました。このエントリでは現在公開されているAPIを一覧でまとめます。いま使えるAPIはこれだけ読めば大丈夫。2013年の最新マッシュアップ事情をあますとこなく網羅します！ HOT! API 総務省 次世代統計利用システム（国勢調査、人口推計、就業構造、企業統計、物価統計 etc.） NHK番組表（※未公開） 行政・自治体・公共サービス 郵便番号 郵便番号検索API（郵便番号 → 住所） 郵便専門ネット（郵便番号 → 住所、郵便番号の簡易存在チェック） ぽすたん（郵便番号 → 住所、住所 → 郵便番号） IW3 PROJECT（郵便番号 → 住所、住所 → 郵便番号） 宇宙 Google+ JAXA PR（※現在一部の学生に限定公開
ゆーすけべー日記
ムフフなビデオも網羅的に扱うDVDや動画の提供サービス「DMM」のWeb APIがいつの間にか公開していたらしく、なにぶんノーマークだったもので昨日の夜知ってビックリした。というかDMMは一生API出さないだろうなんて決め込んでいたのが良くなかったですね。 ってことでとあるAV女優の商品一覧を出力するようなスクリプトを書いてみました。API固有の「癖」でいくつか実装する際の注意すべきポイントがあるのでそれをまず紹介します。Perlコードですが参考になるかもです。 リクエストパラメータにはタイムスタンプがいる リクエストのパラメータにはタイムスタンプが必須です。形式は 2013-05-14 08:03:16 というもの。僕はDateTime派なので、以下のコードで現在のタイムスタンプの文字列をつくっています（＊ある方から指摘を受けてコードを修正させていただきました！）。 use DateTi
API設計に関する10のワーストプラクティス
過半数の開発者が平均で3つ以上のAPIのインテグレーションを実装していると言われている昨今、「使い辛い設計のAPI」を実装するのは開発者にとっては頭の痛い問題ではないでしょうか？ Programable Web上に投稿されたAPIのワーストプラクティスに関する記事が国内外の開発者の目に止まったようです。この記事によると悪いAPIに見られるプラクティスは下記のようなものだそうです。 貧弱なエラーハンドリング HTTPのルールを無視したREST API 裏に潜んだ生のデータモデルの露出 セキュリティの複雑さ ドキュメント化されていない予期せぬリリース 貧弱なデベロッパエクスペリエンス MVCフレームワークが良いAPIにしてくれるという思い込み 開発すれば使ってもらえると見なすこと 不十分なサポート 貧弱なドキュメンテーション APIを利用するだけでなく、APIを提供する場合に上記のようなポイン
Island Life - メッセージキューの設計
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 米国の大学進学無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...More... 最近のコメント shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハイポハイポのシューリンガン (2022/04/02)ベアトリーチェ on ハイポハ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
API Meetup Tokyo #11 セッション#3 Microservices on pairs
http://glide.so/nikezono/6761059
[iOS7] iOS7 新API紹介
Secrets of Awesome JavaScript API Design
http://neta.ywcafe.net/000654.html