タグ

評価に関するMarukosuのブックマーク (15)

  • なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか - 一休.com Developers Blog

    CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアSlack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニア技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる?」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした(笑)。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜

    なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか - 一休.com Developers Blog
  • ノーススター(北極星)指標をモニターしてるのにビジネスが成長しないのはなぜか? - Qiita

    よくスタートアップやSaaSの世界などでノーススター(北極星)指標が注目されます。自分たちのビジネスを成長させるために組織の全員が一丸となって追うべき1つの指標というものです。 例えば、アクティビティの指標であるDAU(Daily Activity Users)やMAU(Monthly Active Users)であったり、またはエンゲージメントを測るためのDAU/MAU、またはそれこそ売上やMRRであったりするかもしれません。 データや数値を元にビジネスを成長させようということで、こうした「ノーススター」指標を決め、ダッシュボードなどで毎週、毎月モニターし始めます。 ところが、ここから誰もが話したくないことが起き始めます。 たいていの組織や企業の中の人達はこの指標をだんだん見なくなる、または気にしなくなります。 実際見ている人は経験あると思うのですが、こうした指標の数値は良くなったり悪

    ノーススター(北極星)指標をモニターしてるのにビジネスが成長しないのはなぜか? - Qiita
  • 評価者を孤独にしない

    EMゆるミートアップ vol.6 〜LT会〜 登壇資料

    評価者を孤独にしない
  • ラクスルのユーザビリティを評価する 【準備編 #1】|Haruka Kawamura

    こんにちは、RAKSULでデザインインターンをしている川村です。 現在ラクスルでは、プロダクトの使いやすさを計るため、ユーザビリティ評価を行っています。今回、自分は評価で使用するラクスル独自のユーザビリティ評価シートを作成させていただきました。 このnoteでは、ラクスルのユーザビリティ評価シート作成のプロセスについて、2つの記事に分けて書いていきたいと思います。今回は【準備編 #1】 … 評価をする上で必要な知識を身につけるぞ!です。 Step1. 評価に関する知識を身につけるユーザビリティ評価シートを作成する前に、まず基的な知識であるユーザビリティの各評価手法:ユーザビリティテスト、ヒューリスティック評価について調べました … 個人的にユーザビリティテストは実際に何度かやったことがあるのですが、ヒューリスティック評価は言葉を聞いたことがあっただけで、実際にどういう評価スタイルなのかま

    ラクスルのユーザビリティを評価する 【準備編 #1】|Haruka Kawamura
  • ベイズモデリングによるチームメイト及び対戦相手の能力を考慮したポゼッションデータに基づくバスケットボールプレイヤーの能力評価指標

    現在, バスケットボールの選手評価に使われる指標には, 評価値の信頼性に関する情報を得ることや選手同士の相乗効果に関する評価が難しいという問題がある. これに対し論文では, チームメイトや対戦相手など同時に出場している選手の能力や, チームメイトとの相乗効果を考慮に入れたモデルをベイズ推定することでそれらの問題を解決する選手評価が可能になることを示した. また, 選手の攻撃・守備能力などの事後分布を解析的に導出することで, 選手の能力評価値やそれらのアフィン変換で得られる指標のベイズ信用区間を構築し, 能力値の推定の不確実性についても評価できることを示した. これは, マルコフ連鎖モンテカルロ法を利用するよりも計算コストを抑えることが可能である. また, アメリカ National Basketball Association (NBA) のデータを利用し, 既存手法との比較検証を実施し

  • 【資料公開】目標設定の基本

    みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと

    【資料公開】目標設定の基本
  • 日本語CLIP 学習済みモデルと評価用データセットの公開

    はじめに 基盤モデル がAIの新潮流となりました。基盤モデルというとやはり大規模言語モデルが人気ですが、リクルートでは、画像を扱えるモデルの開発にも注力しています。画像を扱える基盤モデルの中でも代表的なモデルのCLIPは実務や研究のさまざまな場面で利用されています。CLIPの中には日語に対応したものも既に公開されていますが、その性能には向上の余地がある可能性があると私たちは考え、仮説検証を行ってきました。今回はその検証の過程で作成したモデルと評価用データセットの公開をしたいと思います。 公開はHugging Face上で行っていますが、それに合わせて記事では公開されるモデルやデータセットの詳細や、公開用モデルの学習の工夫などについて紹介します。 記事の前半では、今回公開するモデルの性能や評価用データセットの内訳、学習の設定について紹介します。記事の後半では大規模な学習を効率的に実施す

    日本語CLIP 学習済みモデルと評価用データセットの公開
  • 不確実な生産環境下における遅延リスク回避のためのロバストスケジューリング法の開発

  • なぜ分類問題のLBでLogLossではなくF1を使うか

    なぜ分類問題のLBでLogLossではなくF1を使うか TL; DR モデルの予測値はケースによって現実でのその後の扱い方が異なる 分類問題では対応の有無を決定するために0か1で予測を使用することが多い 0か1かの予測を評価する際は、分類問題の場合はLogLossよりF1が望ましいことが多い よって、分類問題のLBではLogLossではなくF1を使われることが多い 予測値の扱い方とは何か ケース: 異常検出 よくある異常検出のケースで考えてみます。 ラベルが[0, 0, 0, 0, 0, 0, 0, 0, 0, 1](0が9個、1が1個)とします。以下の予測値を出すモデルが2つあったとして、どちらが現実で使った際に役立つでしょう? [0.4, 0.4, 0.4, 0.4, 0.4, 0.4, 0.4, 0.4, 0.4, 0.6] [0.1, 0.1, 0.1, 0.1, 0.1, 0.1

    なぜ分類問題のLBでLogLossではなくF1を使うか
  • マネージャーの評価基準(シート・動画付き)|長村禎庸@EVeM

    はじめに約1年ぶりのエントリーになります。今回はマネージャーの評価基準というタイトルで書きたいと思います。 マネージャーを評価する基準というのはありそうでないなと、この1年色々な経営者・マネージャーの方と話す中で感じていました。 その時残すべき成果が出ていればマネージャーとしてOKとしている会社もあれば、「マネージャーとしての行動リスト」のようなものが5個〜多くて30個程度であり、その行動リストを評価とまではいかなくとも、チェックリストのように使っている会社もあります。 しかし、前者の場合は「成果が出ていれば色々な犠牲が出てもよし」となりますし、後者の場合は「行動リストのうち今必要が無いことも行動せよ」となるので、両方ともマネージャーを評価する基準としては何か違うなと違和感を覚えてました。 しかし、何を以て良いマネージャーなのか、それを判断する基準がなければ、マネージャーに何を求めて良いか

    マネージャーの評価基準(シート・動画付き)|長村禎庸@EVeM
  • 人事制度ハンドブック - kaneda blog

    2022年5月6日 人事制度 人事制度ハンドブック 22年1月から開始したブログ。 人事制度の設計・運用に関する記事のまとめです。 今後、人事制度を設計する際のハンドブックとして、随時更新していきます。 ■書籍:スタートアップのための人事制度の作り方 ■ブログ体:https://kaneda3.com/ Pickup スタートアップにおける組織づくりの鉄則 今年、何パーセント昇給しましたか?(昇給率の話) 「売上が上がらないことよりも、人が辞める方がつらい」という音 人事制度を使って、入社時に「期待」を伝える方法 等級の中に「サブグレード」をつくってはいけない 等級制度と評価制度の違い 降格・降給は、「カルチャー」である 【スライド公開】スタートアップにおける等級別の報酬レンジ 報酬水準に関する公開資料_ver5.0 昇格に、メリットはあるのか? 急成長できるスタートアップの組織文化

    人事制度ハンドブック - kaneda blog
  • 「AIによる動画要約研究」に激震。今までの自動動画要約技術はランダム抽出と大差なかった? | Ledge.ai

    画像認識におけるトップカンファレンス「CVPR 2019」で、AIでの自動動画要約の常識を根的に覆す論文が発表された。最先端の動画要約手法が、ランダムで作成された動画要約と同等レベルでの要約しか作成できていないことを示したものだ。 稿では、7月13日に開催された「CCSE 2019」でのサイバーエージェントAI Labの大谷まゆ氏による講演「ディープラーニング時代の性能評価」の講演内容、および同氏のCVPR 2019に採択された論文「Rethinking The Evaluation of Video Summaries」の内容をまとめた。 合わせて、動画要約技術で用いられてきた手法の簡単な説明と、「ランダム抽出での要約結果がAIと同等の結果を示した」とはどういうことか、解説する。 近年の動画要約手法とそのデータセットそもそも動画要約とは、もとの映像のなかで根幹をなす内容を捉えつつ、映

    「AIによる動画要約研究」に激震。今までの自動動画要約技術はランダム抽出と大差なかった? | Ledge.ai
  • RecSys 2019 ベストペーパーを読んだメモ - Qiita

    紹介論文 Are We Really Making Much Progress? A Worrying Analysis of Recent Neural Recommendation Approaches (RecSys 2019) 日語では「当にそんなに進捗出てるの? -或いは最近のNN推薦手法に対する警鐘-」という感じだろうか。 元論文はこちら https://arxiv.org/pdf/1907.06902.pdf 概要 DNNが登場してから推薦分野でもDeepXXな手法が増えている 新手法の登場頻度が高いため、代表的なタスクであるtopN推薦に対してすらSOTAが何か追えなくなっている そこでトップ会議(KDD, SIGIR, WWW, RecSys)のDNN関連研究18を追試した 18のうち、現実的な努力を行った上で再現できたのが7 (RecSysでの発表によると、)

    RecSys 2019 ベストペーパーを読んだメモ - Qiita
  • データ化すれば客観的に評価できるという考えの落とし穴──『測りすぎ──なぜパフォーマンス評価は失敗するのか?』 - 基本読書

    測りすぎ――なぜパフォーマンス評価は失敗するのか? 作者: ジェリー・Z・ミュラー,松裕出版社/メーカー: みすず書房発売日: 2019/04/27メディア: 単行この商品を含むブログを見る僕の業はWebプログラマで、こうした職業としてはありがちなこととして何社も転々としながら(時にフリーで)仕事をしているのだが、極少人数の企業をのぞけばだいたい「どうやって社員の成果を評価するか」といったところで試行錯誤している。 メンター的な存在が評価するようなケースもあれば、成果をできるだけ定量的・客観的に評価しようとするところもありと様々だが、やはりIT界隈ということもあり後者の機運の方が高い。より納得感のある評価制度があれば会社側も勤めている側もウィンウィンなので、定量的・客観的な評価が「当に」できるのであればそれは良いことなのだけれども、あんまり「こりゃうまくいっている!」というところは

    データ化すれば客観的に評価できるという考えの落とし穴──『測りすぎ──なぜパフォーマンス評価は失敗するのか?』 - 基本読書
  • 時間計測

    fortran90において、 このプログラムは何秒かかるか? 早い?遅い? を調べるためにはもちろん計算時間を計るのが一番です。 実時間とCPU時間の違い 実時間計測 date_and_time system_clock CPU時間計測 cpu_time 実時間とCPU時間の違い 『計算時間』には大きく2種類あります。実時間とCPU時間です。 実時間 → 現実の世界での経過時間 CPU時間 → プログラムの実行でCPUを使った時間 ※[1]より。参考文献とは程遠いですが、僕の認識とあっていて、綺麗な説明と感じたので載せておきます。 例えば、計算時間はそんなにかかってないのに詳細な画像を得たいがために書き出すデータ量を増やしている場合、実時間は長く、CPU時間は短くなります。 また、あるデータ点1つを得るために計算時間は膨大にかかる場合、実時間≈CPU時間になります。 fortranでは時刻

    時間計測
  • 1