主にクラウドの話してます - 広島 での登壇資料です。 https://omoni-cloud.connpass.com/event/315682/
今回はこのような表を自動で得られるようにすることを目標とします。 LLMには、追加学習による精度の改善だけでなく、入力するプロンプトの改善による精度向上の余地があります。 今回は、通常の機械学習の実験管理とは異なり、LLM, プロンプトの2変数のうち、LLMを固定します。仮に精度が向上した場合、それが「LLMを改善したから」なのか「プロンプトを改善したから」なのかが分からなくなってしまうからです。 プロンプトの評価プロンプトの評価に必要なもの以下の4つが全て揃えば大体どんな評価もできます。 最低限*印の項目があればそれなりの評価ができます。 質問文* LLMの回答* 理想の回答 コンテキスト プロンプトの評価指標例プロンプトの評価指標は、原則「プロジェクト・タスクによりけり」です。 ここでは評価指標を定めるための参考として、いくつか事例を集めたので以下にご紹介します。 事例(1): Pro
「住所の揺らぎ程度のことにAIを使いたいだとかデジタル音痴」だの「住所の正規化なんてExcelで2時間あれば作れそう」だの、たいへんフットワークの軽やかな言説の数々に、位置情報界隈のみならず住所の正規化や名寄せに少しでも関わったことのあるエンジニアが総立ちでマサカリを投げていたのも記憶に新しい今日この頃ですが(2023年6月6日)、この手の騒動は周期的に起こってる印象です。 ということはつまり いつまで経っても解消されない、解決が困難な課題である その困難さが界隈以外に共有されていない であるわけで、その都度Twitterにトリビアが投下されてはTLが賑わい華やかではありますが、そろそろ自分の整理としてもどれだけ日本の住所システムがカオスで、その計算機的な処理がいかに困難かをメモっておこうかと思いました。 なおこの件については既にQiitaにGeoloniaの宮内さんが鼻血の出そうな良エン
記事を書く背景 ばんくしさんの「エンジニアとビジネスの距離感の難しさ」というブログを読みました。 経営とエンジニアリングをつなぐ立場であるCTOとしては永遠のテーマだと思います。 申し遅れましたが、私はファストドクター株式会社CTOの宮田 芳郎です。昨年、ファストドクターの開発組織は、大きな技術的意思決定を経営陣とともに実施できました。具体的には次の2点です。 アプリのFlutter化(意思決定は2022年5月) 新規のバックエンド開発時の言語をRubyからTypeScriptへ切り替え(意思決定は2022年6月末) いずれも一度の経営会議で、上記の方針について経営陣との合意を取っています。 5秒でわかる記事の結論 経営陣への提案資料は下記の5点をポイントとして記述すると良い 実施の意義(≒ 解決したい課題) 必要リソース(人・モノ・金 + 時間) 実現コンセプト リスク 手続きの妥当性
(※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。) はじめに リンクアンドモチベーションで、エンジニアをしています、宮田と申します。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね?」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがあ
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD(Domain-Driven Design)を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯(ヤフー内のスキル任命制度/ネットワーク・セキュリティ)に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書
github.blog GitHub Actions の新バージョンが 8/8 に発表されました。 www.kaizenprogrammer.com 自分は過去にも旧バージョン時に GitHub Actions の入門記事を書いていたのですが、新バージョンがこれまでと大きく変わってしまっているので、この記事ではあらためて GitHub Actions についていろいろ調べたり動かしてみたりした内容をまとめます。 目次 注意事項 GitHub Actions とは これまでの GitHub Actions とどこが変わったか コンセプト マルチプラットフォーム対応 HCL から YAML へ 料金 その他 GitHub Actions と Azure Pipelines 簡単な例 (Hello, World) ワークフローの設定 ワークフローとは ワークフローを実行するイベント ワークフロー
こんにちは。セキュリティエンジニアの平松です。 毎年、大きな反響を頂いているエンジニアコース新人研修の内容を今年も公開します。 リクルートテクノロジーズの新人研修 リクルートテクノロジーズでは、新卒採用の新人向けに3ヶ月間の技術研修「ブートキャンプ」を実施しています。 新人たちは採用時の応募職種によって振り分けられ、各職種に適した内容のブートキャンプを受講します。 今年のブートキャンプは以下の3つのコースで実施しました。 スタンダードコース:プログラミングやWebサービスの構造の基礎を学び、その後1つのスマホサイトを企画からリリースまで行うコース。 エンジニアコース:現場での技術に即した実践的な内容を学び、その後実際のサービスでチーム開発のOJTを実施するコース。 データサイエンティストコース:現場でのデータ解析の実務に即した実践的な内容を学ぶコース。 本記事では、実際に「エンジニアコース
前置き 某上場Web系の企業で中途社員のサーバーサイドエンジニアの書類選考や採用面接官などをしています。途中に転職もしましたが面接などの採用に関わり始めてから5年経ちました。 以前に面接についてはこちらの記事を書きました。 エンジニアを面接するときに面接官が本当に知りたいこと 書類選考もしていて、欲しい情報が足りない。本当の実力はもっとあるのでは?と思うこともあり、今回は採用側の立場から、もっと見たい職務経歴書の書き方について書こうと思います。 全てのパターンに当てはまることはなく、主にWeb系の中でもそれなりに大きな会社の中で見てきた観点での話になります。 今回もWeb系の大手企業に入る観点での職務経歴書という前提が付くかもしれません。 しばしば見る、情報が足りない職務経歴書 採用を決めるマネージャがエンジニアでない場合や技術の深さに疎い場合、技術に関してそれなりの評価しか出来ません。
どうすればPythonをJuliaと同じくらい速く動かせるのか? : 様々なやり方で計算の高速化を図る Julia対Python 科学技術計算には、Pythonなどの言語よりもJuliaを使った方がいいのでしょうか? http://julialang.org/ に載っているベンチマークを見ると、どうしてもそんな風に思ってしまいます。というのも、Pythonなどの高水準言語は、スピード面で大幅に劣っているのです。けれども、これは私が最初に感じた疑問ではありません。私が気になったのは、「Juliaのチームが書いたPythonのベンチマークは、Pythonに最適なものだったのか?」ということです。 こういった多言語の比較について、私の考えを述べましょう。まずベンチマークというのは、実行するタスクによって定義されるものです。よって、そのタスクを実行するための最適なコードを、各言語に精通した人々が最
私は技術書典4・5と、個人でサークル参加をしてきたサークル主です。本の制作環境を迷いながら選択することが多かったので、技術書典6にサークル参加される方への備忘録も兼ねて、まとめてみました。 まずは技術同人誌を執筆するための制作環境ですが、私が観測した範囲内では、以下のいずれかでした。 Microsoft Word / Googleドキュメント Markdown LaTeX InDesign / CLIP STUDIO Re:VIEW単体 Re:VIEW + (InDesign / CSS組版)などの組み合わせ VivliostyleでCSS組版 それぞれ簡単ではありますが、所感をつらつらと綴ってみます。なお、眠くて概要を説明する気力がなかったため「◯◯とは?」的な内容は、それぞれのワードで検索して補っていただけると幸いです。 Microsoft Word / Googleドキュメント Wo
出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。 専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「制作サイド」の一部とみなしていいだろう。 一方、基本的に無償で、完成した書籍の献本と謝辞への掲載くらいを前提に、あくまでもベストエフォートで発行前の本の内容を見てくださいというお願いを第三者にすることもある。 この場合の第三者というのは、制作中の書籍の想定読者だったり、出版後の書籍を対象読者へ紹介してくれそうな立場の人だったりする。 このようなプロセスを制作に取り入れる習慣は、とくにここ数年のIT系の出版社ではめずらしくなくて、界隈では「レビュー」などと呼ばれている。 というわけで、技術書の制作における「レビュー」につ
こんにちは、scoutyのシニアエンジニア(DBスペシャリスト)の山田(@denzowill)です。私は昨年の夏頃にscoutyのサービスを通じてscoutyに転職しています。さて、エンジニアが転職する時に気にするポイントの一つに、その企業が「どのような技術を使っているのか」という点があると思います。 現在は私も他のエンジニアの方とカジュアル面談をすることが増えていますが、「使用言語は?」、「インフラ周りはどうしているのか」、「フレームワークは何を採用しているのか」といった質問をいただくことも多いです。 そこで今回はscoutyを支える約10個の技術と題しましてどのような技術スタックをscoutyが採用しているかをご紹介します。 全体図まず先にscoutyというサービスがどのような構成になっているかをご紹介しておきます。 ユーザ側にWEB上でのサービスを提供するメインサービスと、各SNSを
〜〜が知っておくべきサイト20選とか、エンジニアなら今すぐフォローすべき有名人とか、いつも釣られてみにいくと全く興味なかったり拍子抜けしたりするわけだが、こういうのが並んでいたらあまりの格の違いに絶望してしまうだろうというものを適当に並べてみた。私が見ているわけではなくて、こうありたいと思っている私の願望である。どちらかというとインフラ系とか基盤系のものに偏っているが、あくまで私が興味ある一連の例だと思ってください。「これが入ってない!」というクレームは受け付けますので、是非教えてください。一緒に成層圏まで意識を高めましょう。 情報サイト、有名ブログ Software Engineering Radio : IEEEが主催しているソフトウェアエンジニア向けのPodCast。データベースからフロントエンド、暗号、ハードウェア、マイクロサービス、などなどとにかく多様なジャンルの最新のトピックの
Mercari Advent Calendar 2017の3日目はmhidakaがお送りします。 Advent Calendarで空いてるところに収まったら12月3日は日曜日ということで、エンジニアの趣味的な話です。 筆者は技術的なブログや書籍を書くかたわら、技術書のためのイベントなどを開いてます。 技術を追求すること、プログラミング、まとめることが好きでモバイル分野で継続的に書籍を出版しています。 内容はおおむね同人誌作りへ適用している技術の話です。 書籍の作り方は出版社によっても違いますが、紹介する内容と同様の作り方をしている商業書籍もたくさんあります。 ここでは著者の目線から出版業界のテクノロジーをのぞいてみましょう。 作る楽しみと読者の視点 著者が本を書く動機は人それぞれですが技術を広めたい、たくさん売れたい、自分の知識をまとめたいなど目的を持って書き始めます。 また一方で書籍の目
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く