LLMの事前評価のシステムアーキテクチャを紹介します
この記事の概要 こんにちは。PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事では、「YOJO事業部のプロダクト内で使用されているLLM（Large Language Models）の機能の性能を事前評価するための仕組み」について、システムのアーキテクチャをご紹介しています。 LLMを用いて実現している具体的な機能については詳しく触れていませんので、その点ご理解ください。 LLMにおける事前評価とは何か まず、プロダクトにおけるLLM（Large Language Models）機能の評価がどのようなものかについて簡単に説明します。 LLMの特徴の一つとして、「出力が確率的である（毎回異なる）」という点があります。そのため、LLMで生成された文章や出力に対しては、出力結果の良し悪しを定量的に計測する方法が必要になります。 弊社における定量的な計測は、大きく次の2
コードは読めなければならない - idesaku blog
ストレス発散がてら書いたネガティブな愚痴り記事が思いの他ブクマしていただくことになり驚いている。みなさん苦労されているようですね。コメントなども多数頂戴したので、調子に乗って返答記事などポストしてみる。*1 コードは読めなければならない 自分のスタンスを明確にしておこうと思う。 コードは読めなければならない。*2 UKTKKNSHINFがダメな理由は、それが読めないからである。頑張って慣れれば読めないこともない、というものは話にならない。容易に読めなければならない。 それに規則性があるなら他のプロジェクトにも転用できない？母音抜きルールを。 他に転用できるんだったら、全社的な生産性向上に寄与できるんじゃないの？母音抜きルールで。 UKTKKNSHINFコンバータ作りました、それとUKTKKNSHINFってそんなにひどい？ | さくらたんどっとびーず 規則性があればよいのであれば、プログラミ
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」という言葉も、昔から有名だったというこ
参照系と更新系の非対称性について、追補 - たなかこういちの開発ノート
以前の記事を補足、あるいは主張を一部修正するものです。 〜・〜 サブジェクト指向とは？ ある要求仕様のセットがあったとき、そこに仕様変更のライフサイクルに違いのあるサブセットが認められるならば、それらは、同一のデータ資源（＝オブジェクト）に関わることであっても、別々の“モデル”として捉えよう、というのがサブジェクト指向の一つの意図です。例えば、「受注」という同じデータ（≒管理対象）に関わることでも、「注文受付オペレーター」観点の“モデル”と「販売管理担当」観点の“モデル”とでは、要求仕様のセットが異なるし、その後の仕様変更の発生タイミングや頻度も異なるでしょう。そういった状況においては、「受注」サブドメインに関わる全ての要求を一つの集約やエンティティに全て載せてしまうと、いわゆるファット・モデルとなり、当初段階はなんとかやり遂げたとしても、その後の仕様変更の度に、当初開発段階に近い苦労を都
大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える - ぷらすのブログ
モノリシックなプロジェクトにおいて、トップレベルのディレクトリ構成が異なる 2 つのディレクトリ構成を考え、それらの違いは何で、どちらが優れているか？という問いについて考えた。そして、「複雑な概念をトップレベルのディレクトリ構成にした方が良いのでは？」という結論に落ち着いた話をする。 はじまり ちょっとしたシナリオを想像してみよう。 プロジェクト立ち上げ期 「最近のトレンドはレイヤードアーキテクチャだ！」 そう言って、プロジェクトはスタートした。 . ├── application │ ├── xxx_usecase.go │ ├── xxx_repository.go │ ├── yyy_usecase.go │ └── yyy_repository.go ├── domain │ ├── xxx.go │ └── yyy.go ├── infrastructure │ └── xxx_
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 の発表資料です。
依存関係逆転の原則の重要性について
こんにちは！eurekaのAPIチームでエンジニアをやっているrikiiです。 最近ついにAPIチームでモブプロを始めました。前は設計や実装について一人で悩んでたりした部分が、すぐ議論できたりホワイトボードに図で書いて理解を深めたりして、問題が素早く解決できてすごくいい感じで進んでいます。 さて、今回も前回の続きでSOLID原則の1つのDIP（依存関係逆転の原則）について書こうと思います。 eurekaではgo言語を使っているので、goを使ったコード例とともに説明していきたいと思います。 ちなみに依存関係逆転の原則とはSOLID原則と呼ばれるオブジェクト指向設計原則のうちのひとつです。 SOLID原則とは？下記5つの原則の頭文字を取ってまとめた、オブジェクト指向設計原則のことです。 ・S : The Single Responsibility Principle（単一責任の原則） ・O :
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の実践力に転機が訪れる時。 チームがオブジェクト指向を体で覚えた時。 チームがインクリメンタルな設計を体で覚えた時。 チームでオブジェクト指向とインクリメンタルな設計を体で覚えるための指針。 QCon Tokyo 2016
Event Sourcing+CQRS を活用するスケーラブルアプリケーション開発 / event-sourcing-cqrs-v2 - Speaker Deck
AWS Dev Day 2018 マイクロサービスアーキテクチャの裏側の巻
ドメイン駆動設計 失敗したことと成功したこと
その時は最善の実装だと思っていたことでも、月日が立つことで、それは間違いだったと気づくことがあります。 5年という歳月はそれを気づかせるには十分な時間で、 DDDをやり始めた初期の頃に書かれたコードは良くディスられたりしています。 そのコードは何を失敗していたのか？そして、それは改善するために改善した事とは？ BIGLOBEにおける"今"のいいコードの書き方をできる限り具体的な事例を元に紹介します。
Goのパッケージ構成の失敗遍歴と現状確認
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
メイヤー先生の偉大さとCommand-Query分離 - 檜山正幸のキマイラ飼育記 (はてなBlog)
バートランド・メイヤー（Bertrand Meyer）先生は、とにかく偉大です。局所的には、無理筋な例え話や強引な主張で僕らを笑わしてくれるのですが、全体としては実にまったく正しいことを言っています。 メイヤー先生の主張のなかでも、僕がもっとも影響を受けて、はてしなく役立っているのは「Command-Query分離の原則」です。オブジェクトやシステムのインターフェイス＆実装を「CommandとQueryに分けろよ」という提案。Commandは値を持たず、副作用（つうか、主作用だけど）だけを持ちます。Queryは副作用を持たず値だけを返します。 Commandとは何であるか、Queryとは何であるか、副作用を持つ／持たないとは何であるか -- これらの概念は、日常直感に頼るだけではなくて、正確に定義することができます。 Queryが副作用を持たないことから、同じQueryを二度発行すると、同
ドメインモデル貧血症 - Martin Fowler's Bliki (ja)
これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真ドメインモデル」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな振る舞いしかない、ということに気づくと思います。 ドメインのロジックをドメインオブジェクトの中に入れないという設計ル
僕とDDDとClean ArchitectureとやっぱりDDD - kenfdev’s blog
2022/04/21更新 ふりかえってみて、この記事は手段と目的をごっちゃにしちゃった自分がよくわかる記事です。 DDDは「どうやってコードを書くか」が問題ではありません。その点を勘違いしちゃってるエンジニアの話として、続きを読みたい人は読んでください🙏 DDD（Domain Driven Design）って難しいですよね。難しい難しいとばかり考えていた僕もようやく最近になって少しずつわかってきた気がします。そのきっかけとなった書籍と僕のストーリーを本記事で紹介できたらと思います。 TL;DR Clean Architectureはなんとなくわかる DDDは難しい と感じている人は「Domain-Driven Design in PHP」を読むと道が拓けるかもしれない。 leanpub.com 僕とDDD DDDといえばEvansのドメイン駆動設計： エリック・エヴァンスのドメイン駆動設
gRPC-JSON proxy - 世界線航跡蔵
grpc-gateway という gRPC からJSON APIへの変換プロキシ生成機を書いた。 これを使えばシステム内部ののmicroservicesはgRPCで通信しつつ公開APIはJSON APIで提供する、みたいなことが簡単になる。 なお、gRPCそのものについては mattnさんの記事 が参考になる。 背景 gRPCの良い点はいくつもある。 データはデフォルトでprotocol buffersで直列化される。ベストではないにせよ十分にコンパクト且つ高速だし、サイズで言えばJSONとは比べるべくもない。 簡単に複数の言語でサーバーのテンプレートやクライアントを生成できる。通信の詳細はgRPCにまかせて開発者はサーバーロジックの実装に注力できる。 design by Googleという安心感。 gRPCの素晴らしさは認めるものの、一方では欠点もある。まず、クライアントライブラリの多く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DDDのユビキタス言語についての考察、研究
Railsで作るBFFの功罪
集約の設計と実装
