はてなブックマーク

こちらはGaudiy アドベントカレンダー 202420 日目の記事です。社内のことを書こうと思ったのですが間に合わなかったので、今回は自分が調査したサービスについて紹介しようと思います。 概要 OpenAPI から数種類のプログラミング言語の SDK が生成できるStainlessの紹介と、実際にデモで使ってみた手順や感想を述べます。 導入 弊社のようなプラットフォームを提供する会社では、サービスの API や SDK を提供するケースは多いかと思います。しかし、多言語の SDK を開発・運用することは簡単ではありません。 例えば Node.js の SDK を作る必要が出てきたとき、必要なセットアップはいくつか存在します。 コード 環境構築 TypeScript 整備 使用するライブラリの選定 ESlint や Prittier 等のツール npm package の設定 CICD の

こんな経験はありませんか？ 「開発メンバーになんでこれ優先度高い/低いんですか？」と聞かれるとき 「考えていた新機能以外にビジネスサイドからの要求が尽きない。ユーザー要望は待ったなしで、技術的な課題も放置できない……。どれから手をつければいい？」と思うとき はじめまして。株式会社GaudiyでPdMをしている三島(@kaa_a_zu)です。今は漫画やゲームのIPごとにファンコミュニティを作ることが出来るFanlinkというサービスを作っています。 実際、私も優先順位で悩んだことが何度もあります。多くの要求やアイデアに囲まれたとき、どれを先に取り組むべきか判断するのは簡単ではありません。 今回の記事ではこの課題を打破する一つの手段として、今回はICEスコアをベースにした優先順位づけの方法を紹介したいと思います。 スコアリングによる初期整理、そしてスコア化だけでは拾いきれない部分を対話や情報共

「LLMの評価」というフレーズを見て、どんなことを思い浮かべるでしょうか？ おそらく大半はLLMモデル自体の評価のことを思い浮かべると思います。新しいモデルが出てきた時に𝕏で見かける「GPT-4o のMMLUベンチマークは89%!」みたいなアレ。 ですが、プロダクト開発にLLMを使っている人の間では、プロンプト等が十分な品質を出しているかの確認などにも評価という言葉を使っていることは多いのではないかと思います。 うまい具合に後者を区別するためにいい感じの呼び名を付与したい気持ちがあるのですが、英語圏での例を見てみるとシンプルに"Evals"と呼んでることもあれば Evaluating LLM System Evaluating LLM-based Applications などなど表現の仕方は様々になっています。 そしてそのプロダクト開発文脈での評価も、実態としてはオフライン評価やオンラ

LLMをプロダクトに活用していく上でプロンプトの出力結果を評価していかなければいけない訳ですが、可能な限り自動で定量評価できると改善もしていきやすくなり大変助かります。 そこで所謂LLM-as-a-Judgeと呼ばれるLLMに評価してもらう手法を取るわけですが、やはり「このスコアはどれくらい信じられるのか...?」という疑問が湧いてきて"評価の評価"がしたくなってきます。 というところで、本記事では使いそうなLLM-as-a-Judgeの手法について調べた後、"評価の評価"の仕方を調べてみた結果をまとめていきます。 LLM-as-a-Judgeの手法 まず初めに、LLM-as-a-Judgeにも様々な手法が存在するので、それらを確認していきます。 スコアベース 一番ベーシックなものはスコアをつけてもらうやり方です。 次のように実際のインプット、それに対するLLMの回答をプロンプトに加えて、

- {place_name}の主要な観光スポットを網羅できているか - 各観光スポットの特徴や見どころを具体的に説明できているか - アクセス方法や所要時間など、実用的な情報を提供できているか - 主観的な意見を述べていないか - 明るく丁寧な口調を維持できているか [ { "input": { "place_name": "鎌倉" }, "output": "鎌倉は神奈川県にある人気の観光地です。以下のような見どころがあります。\n\n1. 鶴岡八幡宮: 源頼朝ゆかりの神社。本殿や舞殿が国宝に指定されています。\n2. 高徳院: 有名な「鎌倉大仏」があります。高さ11.3mの銅造阿弥陀如来座像は圧巻。\n3. 長谷寺: 本尊の十一面観音菩薩は高さ9.18mの木造で、日本最大級です。\n4. 鎌倉文学館: 鎌倉ゆかりの文学者を紹介。歴史的建造物の中で作品を楽しめます。\n5. 江ノ島: 弁

先月くらいにGuardrails AI という何ともAIのアウトプットを制御してくれそうな名前の会社からGuardrails　HubというLLMのアウトプットを評価する関数が集まったプロダクトがリリースされました。 下図のように便利なバリデーション関数がたくさんあります。 個人的に使いそうなものをピックアップして見てみると次のようなものがあります。 個人情報が含まれているかを判定 https://hub.guardrailsai.com/validator/guardrails/detect_pii メールアドレス、電話番号、住所などなどが含まれているかを判定する 内部では presido というライブラリを使っていて、こちらのページにあるプロパティの判定に対応 https://microsoft.github.io/presidio/supported_entities/ 卑俗語があるか

実プロダクトにおけるプロンプトチューニングはとても疲弊する仕事です。 出力が求める品質に満たない時にプロンプトを変更していく訳ですが、それによって他の品質が満たせなくなるリグレッションが起きたり、また、ある課題が１００％の確率で起きるということはほぼなく、何回も繰り返し実行してその課題が起きないか確認する必要があったりします。 この疲弊しがちなタスクを効率化するために実験管理の環境を整えるのも大事なのですが、それにアドオンとして可能な限りLLMさんに自動でチューニングしていただけないかな〜と思い、手始めに先行研究を色々調べてみたのでそのリサーチ内容をまとめてみます。 NeuroPrompts 少し前にこちらの記事で話題になった方法です。 ざっくりまとめると「text-to-imageのプロンプトチューニングに特化した fine-tuning をしたモデルを作った」という内容です。 2章を読

はじめに 社のフロントエンド開発で、品質担保施策の一環としてVRTを実施しています。 単純にコンポーネントをマウントした結果だけではなく、interaction test や msw-storybook-addon を合わせて活用し、pageやmodal単位の振る舞いの変化の結果の担保として、integration test の役割も一部担わせているため、これを安定化させ、オオカミ少年にしないことが重要です。 そのために、ドキュメントされていない点で改善を試行錯誤した部分があるのでまとめておきます。 改善事項 storycapは厳密には play function に対応していないことを意識する storycapは、正式なサポートとして、play関数のPromiseが解消されたことを確認してから撮影しているわけではありません。storybookにこれが導入される前から、撮影の安定化のために

普段 GraphQL を使ったフロントエンド開発をしています。最近 GraphQL Code Generator の設定を見直しており、いくつかの plugin や preset を採用したり削除したのですが、その中でも gql-tag-operations-preset がとても良かったので、もともとの構成と gql-tag-operations-preset を導入した後の構成を比較して記事に残しておきます。 また、 gql-tag-operations-preset を導入することで、 Relay 以外の GraphQL Client でも Fragment Colocation が扱いやすくなります。 私は Apollo ユーザーなので Relay の Fragment Colocation を原則とした開発体験を羨ましく思っていたのですが、 Apollo でも少し近づいた開発体験

キャッシュは、CPUのバスやネットワークなど様々な情報伝達経路において、ある領域から他の領域へ情報を転送する際、その転送遅延を極力隠蔽し転送効率を向上するために考案された記憶階層の実現手段である。(引用: フリー百科事典『ウィキペディア（Wikipedia）』) こんにちは、@kaa_a_zu です。私たちエンジニアは、「キャッシュ」というワードをよく口にしています。それはインフラの設計をしている時かもしれないし、表示されるコンテンツが変わらない時かもしれないし、パフォーマンスの改善をしている時かもしれません。普段何気なく使っている「キャッシュ」とは一体何なのでしょうか。この記事は、そんな「(Webフロントエンドを触るエンジニアが知るべき)キャッシュ」について、どんなものがあるのかがちょっと分かったという状態になることを目的に書いています。

こんにちは、@kaa_a_zu です。今日(11/23)の日本時間早朝に React Router の制作者である @Ryan氏 と @Michael が着想した Remix V1.0 が正式リリースされました🎉 RemixがWebの世界に及ぼす影響は大きいと思っており、実際のコードやドキュメントを見ながら既存のフレームワークと何が異なっているのかを中心に書いた紹介記事です。(正直、魂が震えています) より具体的な使い方はドキュメントを見て、手を動かしていただくのが良いかと思います。また、既に国内でも使ってみた系の記事がいくつかあるようです。 Remixの機能には様々なものがありますが、当記事では筆者がより注目しているものについて書いていきます。Remixに興味があるけど、あまり追えていないという方に読んでいただけると嬉しいです。 ※この記事はGatsbyやNext.jsよりもRemix

こんにちは、@kaa_a_zu です。私は、今までいくつかの組織でフロントエンドのパフォーマンス改善に取り組んできました。パフォーマンスが劇的に改善したこともあれば、改善点の洗い出しで終わったこともありました。この記事では、それらの経験に基づいて、どのようにしたらチームがパフォーマンスに意識を向けることができるのか、改善を習慣化できるのかについて基本的なことを紹介させていただきます。少しでも参考になったらありがたいです。また、ご指摘や感想も随時お待ちしております。 ※この記事はWebフロントエンド領域を対象にしています。 なぜパフォーマンス改善をするのか パフォーマンスを改善する目的には、大きく３つあると考えています。 ユーザー体験の質を向上させるため(追記: この動画はパフォーマンスの重要性を説いています) SEO対策のため 将来的にリッチな機能を導入するため(既にTWA化の基準にはパフ

概要 メディアやコミュニティ系のアプリケーション開発を中心に行っていたが、最近会社で決済系のシステムを扱うようになったこともあり、複数のサービス間がある中でどう結果整合性を担保するかについて学んでいた。 そこで学んだ複数サービス間での整合性を保つための手法として分散Sagaパターンがあり、実際にCloud RunとCloud PubSubで実装をしてみた。 複数サービスでの整合性 複数サービスでの整合性の問題 一般的にシステムを複数サービスに分けることによって、サービスを効率的に利用することや開発チームを分けることや小さくデプロイが可能など多くのメリットが挙げられる。 しかし、複数サービスにしたときの１つの問題として、データの整合性を取ることが難しくなることが挙げられる。 例えば、1つのDBのシステムに対してデータのWriteをアトミックに行う場合はDBのトランザクション等を使うことによっ