Supervised Learning of Universal Sentence Representations From Natural Language Inference Dataは自然言語推論のデータセットであるStanford Natural Language Inference (SNLI) を使った文の埋め込みベクトルを生成モデルを教師あり学習を提案した。 7種類のネットワークアーキテクチャを12種類のタスクで評価したところ、双方向LSTMと最大値プーリングを採用したアーキテクチャが最も高い性能を発揮した。
Instruction Finetuningは訓練データにない種類のタスクのゼロショットを改善するファインチューニングの一種で、Finetuned Language Models Are Zero-Shot Learnersで知られるようになった。 もとの文献ではInstruction tuningと呼ばれている。 Scaling Instruction-Finetuned Language Modelsは、学習データ、モデルのパラメタの数、chain-of-thoughtのデータを増やすと、instruction tuningで学習したモデルの性能を向上できることを示した。
Reading Wikipedia to Answer Open Domain Questionsで提案されたDrQAは、ドメインを問わない事実を問う質問に対して、Wikipediaの文書のある文字列区間を解答とみなして出力する。 DrQAは質問に関係する文書を収集するDocument RetrieverとDocument Readerから構成される。 Document Retrieverは、バイグラムのTF-IDFで質問と類似するWikipediaを検索し、上位5位の文書をDocument Readerに渡す。 Document Readerは、Document Retrieverから渡された質問と応答を別の方法で分散表現に変換する。 最後に質問と応答の分散表現を比較し、応答の解答と推定した区間を出力する。
Language Models are Few-Shot Learnersは、Few-shot learningで学習したGPT-3とパラメタ数の少ないファインチューニングしたモデルのタスク処理を比較し、パラメタ数を大幅に増やすことでも予測性能を向上できることを示した。 GPT-3のパラメタ数は1750億であり、その数は、比較対象のファインチューニングされたモデルよりも10倍ほど大きい。 GPT-3のネットワークアーキテクチャはGPT-2と大きく変わらないが、Sparse Transformerに似た注意機構を導入したところが異なる。
コンシステントハッシュ法は、Content Delivery Network (CDN) 規模のキャッシュシステムの負荷分散に使われている。 コンシステントハッシュ法を提案したConsistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Webは、特定のキャッシュサーバーへのリクエストの集中を避けることを目的にする。
コードカバレッジに対する批判を散見する。 たとえば、Googleのソフトウェアエンジニアリングの11.2.4節「コードカバレッジについてもメモ」には、コードカバレッジに対する2つの批判がある。 まず、最低限満たすべきコードカバレッジを設定すると、すぐに水準を下回るコードがすぐにリポジトリに取り込まれはじめる。 次に、テストカバレッジが保証するのはテストがコードが実行することだけであり、実行したコードにあるバグを見つけるとは限らない。
このような経験則や論理による批判にくらべると、実験にもとづく批判を見聞することは少ないだろう。 Coverage Is Not Strongly Correlated with Test Suite Effectivenessは、ICSE 2024でMost influential paper ICSE N-10に選ばれた文献で、OSSのテストカバレッジとテストの有効性の相関を調べた。 Apache POI, Closure, HSQLDB, JFreeChart, Joda Timeのコードベースをミューテーション解析し、テストケースの有効性を、テストケースを失敗させた変異体の数で定量化した。 テストケースの数とテストスイートのカバレッジは、有効性との間に中から高の相関があった。 一方、テストケースの数を固定すると、カバレッジと有効性の相関は低から中に減少した。
Go1.5で、ガベージコレクション (GC) のアルゴリズムが3色マーキングによるコンカレント マーク&スイープに変わった。 このアルゴリズムの起源を辿ると、1978年のOn the Fly Garbage Collection an Exercise in Cooperationにいきつく。 ポインタをたどってヒープを黒や灰色に着色するマーキングフェーズと、解放してよい白のヒープを解放するアペンディングフェーズ、この2つのフェーズを繰り返す。 アルゴリズムはStop The World (STW)を抑制することを主眼におく。
2015年に書かれたThe Go BlogのGo GC: Prioritizing low latency and simplicityによれば、3色マーキングのコンカレント マーク&スイープはエンタープライズ向けのGCではない。 それでも、3色マーキングの考え自体はJavaのZGCなど他のガベージコレクションで採用されている。
CAP定理の一貫性、可用性、ネットワークの分断耐性のトリレンマは、1つを完全に切り捨てるのではなく、現実には、3つの性質の優先順位をつける問題になる。 システムの一貫性と可用性の均衡を設計するときは、求める一貫性に対して実現できる可用性を知らないといけない。 Highly Available Transactions Virtues and Limitations は、既存の一貫性を両立できる可用性の水準と対応させ、両性質の強さで一貫性と可用性のペアを半順序関係に整理した。
分散システムのテストをClojureで実装するためのフレームワークにJepsenがある。 Jepsenのテストケースは、システムへの操作、操作後のシステムに期待する状態、障害と操作のスケジューリングの3要素からなる。 テストケースは、スケジューリング通りに操作と障害を起こし、最後にシステムの応答が期待通りか確認する。 Jepsenの公式サイトにはJepsenによる主要な分散システムのテスト結果が公開されている。 また、Kubernetes内部で使わているKVSのetcdの公式ウェブサイトにもJepsenのテスト結果が公開されている。 分散システムの開発側からも参照されているので、分散システムにおけるJepsenの認知度は高いように思える。
その一方で、公式ドキュメントは整備されていないようだった。 たとえば、チュートリアルはetcdを例題にJepsenの使い方を解説しているが、etcdのクライアントライブラリが古く、実際に実装してもチュートリアル通りに実行できない。 かわりに、2相コミットするアプリケーションとテストケースを実装したが、実装のためにJepsenのソースコードを調べる必要があった。 実装したアプリケーションとテストケースはGitHubのリポジトリに公開してある。
それでも、依然として、Jepsenを使ってテストケース実装するほうが、スクラッチからテストケースを実装するよりも効率的ではあると思う。 そこで、今後の備忘録をかねて、Jepsenを試すにあたって、チュートリアルに不足を感じた部分を書き留めておく。