法律のデータ構造と検索
デジタル庁は、法令標準 XML スキーマに準拠した、現行の法令データをe-Gov法令検索というサイト上で公開しています[1]。今回、この法令XMLをパースするPythonライブラリ ja-law-parser をつくり、法令データの全文検索をしてみました。 この記事では、日本の法令とそのデータ構造、法令XMLパーサについて解説し、最後に、それらを使った法令データの全文検索システムを実装する方法をご紹介します。法令検索の実装についても、GitHubリポジトリで公開しています。 この記事は、情報検索・検索技術 Advent Calendar 2023の16日目の記事です。 法律と法令 法律とは 法律の制定と公布 法律と法令の違い 法律の改正 法令のデータ構造 e-Govの法令データ 法令標準XMLスキーマ 法令番号と法令ID 題名 本則と附則 条・項・号 編・章・節・款・目 法令XMLパーサ：
まもなく17周年を迎えるpixivでは、長年にわたり作品などの全文検索基盤としてApache Solrを使用してきました。 しかし、サービスの規模が拡大する中で、従来の基盤に問題が生じていました。これを受けて、pixivでは全文検索基盤のリプレイスを実行しました。 今回のリプレイスにより、pixivでは検索結果の更新反映時間や検索APIのレイテンシが大幅に短縮されました。また、今後のスケールに対応可能になり、新機能開発においても全文検索が容易に利用できるようになりました。 本記事では、pixivの全文検索基盤の歴史や、今回オンプレミス環境でElasticsearchクラスタを構築し、リプレイスを完了するまでの取り組みについてご紹介します。 こんにちは。pixivのnamazuです。最近、私たちのチームで進めていたpixivの全文検索基盤のリプレイスが完了しました。この機会に、pixivの全
Search and analytics, data ingestion, and visualization – all at your fingertips.
本記事は日本オラクルが運営する下記Meetupで発表予定の内容になります。発表までに今後、内容は予告なく変更される可能性があることをあらかじめご了承ください。下記セッションでは、本記事の内容以外にデモンストレーションも実施する予定です。 ※セミナー実施済の動画に関しては以下をご参照ください。 はじめに 2022年暮れ、ChatGPTの登場以降、あらゆる企業がDXの在り方を問われはじめ、大規模言語モデルの仕組みをどのように業務に取り入れるかを検討されていると思います。 その検討の一つとして、「GPT(LLM)が学習していない企業内のデータや最新のデータも有効活用すべき」 という点は非常に大きな論点なのではないでしょうか。 ご存じの通り、LLMとはインターネット上に存在するドキュメントデータをクローリングにより大量に収集し、それを学習データとして機械学習にかけたモデルです。 従って、至極当たり
ElasticsearchとKibanaがオープンソースライセンスに復帰、Elasticが発表。AWSがフォークに投資し、市場の混乱は解決されたと
ElasticsearchとKibanaがオープンソースライセンスに復帰、Elasticが発表。AWSがフォークに投資し、市場の混乱は解決されたと オランダに本社を置くElasticは、ElasticとKibanaのライセンスにオープンソースライセンスであるAGPLを追加すると発表しました。 3年前の2021年、同社はElasticをマネージドサービスとして提供しているAWSを名指しで非難しつつ、ElasticのライセンスをApache License 2.0から、商用サービス化を制限する「Server Side Public License」（SSPL）と「Elastic License」のデュアルライセンスへ変更しました。 それ以来、ElasticとKibanaはオープンソースではなくなっていました。 同社CEO Shay Banon氏は、今回のオープンソースへの復帰を発表したブログの
ElasticsearchによるZOZOTOWNへのベクトル検索の導入検討とその課題 - ZOZO TECH BLOG
こんにちは。検索基盤部の橘です。ZOZOTOWNでは、商品検索エンジンとしてElasticsearchを利用し、大規模なデータに対して高速な全文検索を実現しています。 Elasticsearchに関する取り組みは以下の記事をご覧ください。 techblog.zozo.com 検索基盤部では、ZOZOTOWNの検索結果の品質向上を目指し、新しい検索手法の導入を検討しています。本記事ではベクトル検索と呼ばれる検索手法に関して得た知見を紹介します。 ※本記事はElasticsearchバージョン8.9に関する内容となっています。 目次 目次 ベクトル検索とは ベクトル検索に期待すること Elasticsearchを使用したベクトル検索の導入 導入の簡略化 デプロイ可能な埋め込みモデル ベクトル検索のクエリ ハイブリッド検索とは Elasticsearchを用いたハイブリッド検索 RRF(Reci
Redis、クラウドベンダなどによる商用サービスを制限するライセンス変更を発表。今後はRedis社とのライセンス契約が必須に
インメモリデータストアRedisの開発元であるRedis社は、これまでオープンソースとして開発してきたRedis 7.4ソースコードのライセンスを、Redis Source Available License (RSALv2)とServer Side Public License (SSPLv1)のデュアルライセンスに変更すると発表しました。 このライセンス変更により、同社の許可なくRedisを用いたマネージドサービスなどを提供することができなくなります。 下記はライセンス変更を発表した同社ブログ「Redis Adopts Dual Source-Available Licensing」からの引用です。 Under the new license, cloud service providers hosting Redis offerings will no longer be permi
かなり昔に Elasticsearch ベースの検索システム（Heineken）を作っていた。 Elasticsearch で部内 Wiki 検索高速化 - Speaker Deck 特に更新せず数年動かしていたのだけど、サーバーの置き換えに伴って Kubernetes に置きたいよねという話になり、ついでに Elasticsearch も新しくしたいよね、となった結果、現状のフロントエンドだと最新の Elasticsearch では動かないということがわかった。 nonylene.hatenablog.jp フロントエンドの改修が必要なわけだが、ここでフロントエンドの構成を見ると… FlowType create-react-app PureComponent Bootstrap 3 古すぎる！絶対アップデート難しいし触りたくない技術しかない。 フロントまわりの構成を変えたいとずっと思っ
「SREの現場から」と題した本連載では、さまざまな企業におけるSREの実践事例を不定期に紹介していきます。 こんにちは、LINE株式会社の加藤（maru）です。SREチームに所属し、主にLINEスタンプや着せかえ、ホームタブ、ウォレットタブでEmbedded SREとして信頼性の改善に従事しています。 LINE株式会社は、コミュニケーションアプリ「LINE」を機軸として、コミュニケーション・コンテンツ・エンターテイメントなどモバイルに特化した各種サービスの開発・運営と広告事業に加え、Fintech事業、コマース事業などを展開しています。基軸となる「LINE」アプリは2023年現在、世界で約2億人が利用しており、LINEスタンプと呼ばれる画像を用いたコミュニケーションがユーザー同士で活発に行われている点が大きな特徴のひとつです。 これから数回にわたり、SREの私が主に担当しているLINEスタ
Elasticsearch 6系および7系への無停止アップグレード事例 - はてなブックマーク編 - Hatena Developer Blog
はてなブックマークチームのエンジニアリングマネージャー id:yigarashi です。はてなブックマークでは全文検索エンジンとしてElasticsearchを利用しており、最近6.8および7.10への無停止アップグレードを実施しました。非互換な変更の影響を真っ向から受けるユースケースでしたが、リスクを分割し少しずつ対処することで迅速かつ安全にアップグレードできました。本記事ではポイントを絞りつつアップグレードの様子をまとめます。 アップグレードに至る経緯 はてなブックマークでは長らくElasticsearchの5系を使っていました。エントリーとブックマークの検索を中心にサービスのかなりの部分を支える重要なミドルウェアですが、大きな変化は以下の記事にある2020年のAWSへの移転が最後（その時もメジャーバージョンは変わらず）で、なかなかElasticsearchの面倒を見られていませんでし
Elasticsearchのパフォーマンス問題をプロファイラを使って解決する | メルカリエンジニアリング
search infra teamのmrkm4ntrです。我々のチームではElasticsearchをKubernetes上で多数運用しています。歴史的経緯によりElasticsearchのクラスタは全てElasticsearchクラスタ専用のnode pool上で動作していました。ElasticsearchのPodは使用するリソースが大きいため、このnode poolのbin packingが難しくコストを最適化できないという問題がありました。そこで全てのElasticsearchクラスタを専用のnode poolから他のワークロードと共存可能なnode poolへ移行しました。ほとんどのクラスタが問題なく移行できたのですが、唯一移行後にlatencyのスパイクが多発してしまうものがありました。 この記事では、その原因を調査する方法と発見した解消方法について説明します。 発生した現象 共
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
pixivの全文検索基盤とElasticsearchによるリプレイス - pixiv inside
Elasticsearch is Open Source, Again
【ChatGPT】とベクトルデータベースによる企業内データの活用(いわゆるRAG構成) - Qiita
検索システムのフロントを SSR・Remix で作り直した - Unyablog.
LINEの「あけおめLINE」過負荷対策(1) ― リスクマネジメントの全体像と「発生可能性の低減」 | gihyo.jp