LLMの事前評価のシステムアーキテクチャを紹介します
この記事の概要 こんにちは。PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事では、「YOJO事業部のプロダクト内で使用されているLLM（Large Language Models）の機能の性能を事前評価するための仕組み」について、システムのアーキテクチャをご紹介しています。 LLMを用いて実現している具体的な機能については詳しく触れていませんので、その点ご理解ください。 LLMにおける事前評価とは何か まず、プロダクトにおけるLLM（Large Language Models）機能の評価がどのようなものかについて簡単に説明します。 LLMの特徴の一つとして、「出力が確率的である（毎回異なる）」という点があります。そのため、LLMで生成された文章や出力に対しては、出力結果の良し悪しを定量的に計測する方法が必要になります。 弊社における定量的な計測は、大きく次の2
コードは読めなければならない - idesaku blog
ストレス発散がてら書いたネガティブな愚痴り記事が思いの他ブクマしていただくことになり驚いている。みなさん苦労されているようですね。コメントなども多数頂戴したので、調子に乗って返答記事などポストしてみる。*1 コードは読めなければならない 自分のスタンスを明確にしておこうと思う。 コードは読めなければならない。*2 UKTKKNSHINFがダメな理由は、それが読めないからである。頑張って慣れれば読めないこともない、というものは話にならない。容易に読めなければならない。 それに規則性があるなら他のプロジェクトにも転用できない？母音抜きルールを。 他に転用できるんだったら、全社的な生産性向上に寄与できるんじゃないの？母音抜きルールで。 UKTKKNSHINFコンバータ作りました、それとUKTKKNSHINFってそんなにひどい？ | さくらたんどっとびーず 規則性があればよいのであれば、プログラミ
Data Vault モデリングのご紹介 - Safie Engineers' Blog!
データ分析基盤グループでデータエンジニアをしている平川です。 近年注目されてきているDataVaultに関して、全3回(予定)で記事を書かせていただく予定です。 第1回の記事では、DataVaultとは何なのか？どんな特徴があるのかを書いていきます。 参考までに、1~3回の内容を紹介しておきます。(内容は変わる可能性が大いにありますのでお許しください🙇♂️) 第1回: DataVaultってなに？どんな特徴があるの？ ← 今回はここ 第2回: dbtvaultを使って実際にDataVaultモデリングでテーブルを作ってみた 第3回: BusinessVaultの使い所や特徴的なSatelliteの利用におけるハマったところや良いところ これまでのデータモデリング手法 3NF ディメンショナルモデリング DataVaultとは何か? Hub Link Satellite モデリングにおけ
『要求仕様の探検学―設計に先立つ品質の作り込み』……”要求されなかったことは決して実現されない”なんて話は30年前から言われていたことなんだ - Magnolia Tech
要求仕様の探検学―設計に先立つ品質の作り込み 作者:ゴーズ,D.C.,ワインバーグ,G.M.,Gause,Donald C.,Weinberg,Gerald M.,ヤナ川 志津子,純一郎, 黒田発売日: 1993/08/01メディア: 単行本 いつ買ったのかも覚えていないし、確実に買ったまま読んでいなかった本を本棚から発見して読み始めた。 『要求仕様の探検学―設計に先立つ品質の作り込み』……もうこのタイトルの時点でたぶんこの2021年において色々な人が読まなければいけない本じゃないだろうか。 本書は、長年システム開発のコンサルタントを勤めていたドナルド・C・ゴーズと、ジェラルド・M・ワインバーグによる所謂システム開発における”要件定義工程”のノウハウを解説した本だ。 原著は1989年に出版され、日本語訳が出たのも1993年と非常に古い本だ。タイトルだけ見るとウォーターフォール的な「最初の工
「クリーンアーキテクチャ」をこう読んだ - No Purpose
Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘発売日: 2018/08/01メディア: Kindle版 読み終えた。良い本だったと思う。 この本を読んだモチベーション Goで書かれた簡素なレイヤードアーキテクチャによるマイクロサービスを会社で触る機会があったり、新たなサービスの切り出しを検討していたりして、Rails以外のサーバサイド設計についてもっと知見を深めたかった。 そんな中で、上司との1on1で「マイクロサービスパターン」を紹介してもらい、その本を読む前段の読み物としてよさそうと感じた。 「Design It!」を社内の読書会で読んでいて、アーキテクチャ関連の本をほかにも読みたかった。 僕はこう読んだ 例の"同心円状(玉ねぎ)のアーキテクチャ"(= "クリーンアーキテクチャ"
技術的負債の四象限 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
複雑さを相手に抽象化を盾にしましょう - エニグモ開発者ブログ
こんにちは、サーバーサイドエンジニアの Steven です。 この記事は Enigmo Advent Calendar 2020 の 11 日目の記事です。 抽象化という単語とその議論をそれほど目にすることがありませんが、設計においては極めて重要な概念だと思いますので、ここで抽象化は何を指すのか、何のためのものなのか、どうやるのかを説明してみます。 ソフトウェア・エンジニアリングとは それが明確となっていないと、どうして抽象化が必要なのかは曖昧となってしまうこともあるかと思いますので、まずは方針にしていることについて語ります。 解釈は複数あると思いますが、一つの文章で表すと、ソフトウェア・エンジニアリングとは人間のアイデアをアルゴリズムに変換することだと思います。 人間の観点で、不確定で無限とも取れるアイデアを、限り有る計算関数の組み合わせで有限なものに変えるとも取れます。 決まった特定な
DRYについてのよくある誤解 - ひがやすを技術ブログ
WEB+DB PRESS vol.49で、「現場で役立つDRYの基礎知識」が特集されています。とても、良い記事だと思うので、ぜひみなさん、読んでください。 ただ、ちょっと補足をしておきます。 記事の中で、DRYは、「達人プログラマー」の中で、とりあげられ、Railsによって広まったとされています。確かに、Rubyの世界ではそうかもしれないけど、DRY原則というのは、ERモデリング(DOA)の世界では、ずっと「One Fact In One Place」という言葉で知られてきました。 ERモデリングにおける正規化は、「One Fact In One Place」を具体的に実現するための手段です。 DRYという言葉そのものを広めたのは、間違いなくRailsです。しかし、DRYの考え方そのものは、昔からあったし、「One Fact In One Place」という言葉も、昔から有名だったというこ
技術的負債を抱えながら突っ走る -日々15分の改善活動- - valid,invalid
開発しているシステムが大規模かつ老朽化しかけていることもあり、最近は負債の返却を念頭に置いて普段の開発をしている。 前提として、個人的には負債を返す頻度は多いほど良い*1と考えている。 この立場に立つときに生まれる問い、「では、日々の開発のスピードを落とさずに頻度を上げるためにどうすれば良いか？」の1つの答えとして「まずは15分向き合ってみる」というのを実践している*2。その実践に関するメモが本記事である。 TL;DR たった15分でも日々負債に向き合ってみると良い 全体像も見えない、どれだけ時間をとられるかわからないものならなお良い ここでいう負債には技術的負債だけでなく使われていないが残存している機能など（便宜的にプロダクト負債と呼んでみる）も含む 全体像が不明瞭で手も付けづらい何かが頭の片隅にあること自体が精神衛生上よくない 一方、わずかづつでも改善に向かっているという実感を個人ない
デザインシステムをデザインシステムだと考えない思考実験 - takanorip blog
「デザインシステムをやってます！」というと、かっこいい名前のついた箱を作ってやっているイメージがある。 GitHubのPrimir、AdobeのSpectrum、ShopifyのPolaris、など。 名前をつけることは、そのデザインシステムを社内外に浸透させるために重要だ。 名前があることでコミュニケーションがスムーズになるし、デザインシステムの雰囲気や目的を伝えやすくなる。 しかし、この「名前のついた箱を用意しないとデザインシステム構築を始められない」っぽい雰囲気が実は良くないのかもしれない。 名前なんて後から考えれば良いのではないか、最初は箱なんて必要なくてドキュメントとデザインファイルと実装のなんとなくのまとまりがあれば良いのではないか、と最近考えている。 じゃあどうすれば名前の呪縛から逃れられるのか。 その答えは「デザインシステムをデザインシステムだと考えないこと」なのではないか
参照系と更新系の非対称性について、追補 - たなかこういちの開発ノート
以前の記事を補足、あるいは主張を一部修正するものです。 〜・〜 サブジェクト指向とは？ ある要求仕様のセットがあったとき、そこに仕様変更のライフサイクルに違いのあるサブセットが認められるならば、それらは、同一のデータ資源（＝オブジェクト）に関わることであっても、別々の“モデル”として捉えよう、というのがサブジェクト指向の一つの意図です。例えば、「受注」という同じデータ（≒管理対象）に関わることでも、「注文受付オペレーター」観点の“モデル”と「販売管理担当」観点の“モデル”とでは、要求仕様のセットが異なるし、その後の仕様変更の発生タイミングや頻度も異なるでしょう。そういった状況においては、「受注」サブドメインに関わる全ての要求を一つの集約やエンティティに全て載せてしまうと、いわゆるファット・モデルとなり、当初段階はなんとかやり遂げたとしても、その後の仕様変更の度に、当初開発段階に近い苦労を都
大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える - ぷらすのブログ
モノリシックなプロジェクトにおいて、トップレベルのディレクトリ構成が異なる 2 つのディレクトリ構成を考え、それらの違いは何で、どちらが優れているか？という問いについて考えた。そして、「複雑な概念をトップレベルのディレクトリ構成にした方が良いのでは？」という結論に落ち着いた話をする。 はじまり ちょっとしたシナリオを想像してみよう。 プロジェクト立ち上げ期 「最近のトレンドはレイヤードアーキテクチャだ！」 そう言って、プロジェクトはスタートした。 . ├── application │ ├── xxx_usecase.go │ ├── xxx_repository.go │ ├── yyy_usecase.go │ └── yyy_repository.go ├── domain │ ├── xxx.go │ └── yyy.go ├── infrastructure │ └── xxx_
ドメイン駆動設計という仕事の流儀
Devlove2012 カンファレンス 発表資料。 ドメイン駆動設計。アプリケーションアーキテクチャ、開発プロセス、設計スタイル。腕を磨く。
TCCパターンとSagaパターンでマイクロサービスのトランザクションをまとめてみた - Qiita
はじめに UL Systems Advent Calendar 2018の10日目です。 マイクロサービスアーキテクチャでシステムを構築した際、更新対象が複数のサービスをまたがる場合は、トランザクションの扱いが途端に難しくなります。なかでも、障害発生時に各サービス間の処理をロールバックするためには補償(補正)トランザクションが必要になり、複雑なトランザクション制御が求められます。補償トランザクションとは、処理の途中で失敗した場合に、それを取り消すことで実行結果を打ち消す処理のことです。補償トランザクションの実装は、打ち消す処理を提供するサービスと、それを呼び出すサービスの双方に負担があり、設計や実装が複雑になりがちです。 トランザクションには、1つのトランザクション内で1つのリソース(DBなど)処理のみ行うローカルトランザクションと、1つのトランザクション内で複数のリソース処理を行うグロー
Python におけるドメイン駆動設計(戦術面)の勘どころ
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon
Builderscon Tokyo 2019 の発表資料です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あきらめる Atomic Design
なぜ技術がないと 面白いゲームが創れないのか？
DDDのユビキタス言語についての考察、研究
フェーズに応じて育てるデザインシステム
