さみっとの部屋

データやAIなどの記事を書きます

人工知能学会2025 参加レポ

AI

はじめに

今年初めて人工知能学会に参加してきたので、簡単にですが参加レポートを書いてみます。

5/29-30の二日間参加し、セッションやポスター展示を見てまわりました。発表はなく聴講のみです。

最近業務でAI活用やアプリ開発を行っているのもあり、LLMやエージェントといった応用側を中心に見てました。

感想

印象に残ったもの

[3A1-GS-10-03] LLMマルチエージェントシステムにおけるエージェント評価手法に関する研究
  • Nomaticaというエージェントを作成
    • 複数エージェントの議論をベースに結果が表示
    • 内部でRAGを用いて、社内データやユーザーデータを活用
    • 課題：正解のないタスクなので、定量評価ができない
  • →このエージェントの精度評価をLLM as a judgeで評価
    • RAGASで評価指標構築
      • 検証データ：1000件以上
      • 評価用LLM：GPT-4o
      • 相談モード、アイディアモード、レビューモードの３つに対して評価
  • 相談モード：「Agent Goal Accuracy」をベースにカスタマイズ
    • ユーザーの意図に基づくGoalをやり取りから推定し、そのGoalを達成できたかを五段階で評価
    • 結果：評価は4以上が8割
  • アイディア・レビューモード
    • 独創性の評価指標を構築
    • 先行研究のプロンプトを参考（ほぼ流用）
    • 結果：3と4が多め
  • 評価結果（割と割愛してます）
    • 相談モード：
      • エージェントの質が高いというよりは、ユーザーが使い方をよくわかっていた（消費者へのインタビューなど）ことが要因と推察
        →ユーザーの利用イメージに合致するエージェントを作れたと言える
    • アイディアモード：
      • こちらもエージェントの質が高いだけではなく、RAGエージェントと独創性という評価指標の相性が良かったのでは

マルチエージェントのタスク遂行に対しての検証データが1000件以上あるのがシンプルにすごいなと思いました。しっかり検証データを用意して、RAGASで評価指標を構築するという王道なアプローチがマルチエージェントにも適用できるのは興味深いです。ただ、評価結果や考察のところで本当に見たいものを計れる評価指標だったのかというトーンの考察があったので、しっかり確立するのは難しいなと感じます。システムごとにやらせていることも違うと思うので、自分の業務で適用する場合はエージェントがやるタスク、評価したい内容をしっかりと言語化し、それに基づいた評価指標を構築→評価・考察し、また言語化して評価指標を構築、、、というループを回すのが大事なのかなと思いました。

[4S1-GS-2-01] 専門ドメインにおけるLLMの文脈理解の分析
  • 一般ドメインと専門ドメインで、LLM内部の処理の違いを見た研究
  • 各ドメインのデータ
    • 一般：JCommonSenseQA
    • 専門：土木系のデータを一般と合わせた選択形式にしたもの
    • 一般の方がキーワード頻度が高く、設問長が短い
  • モデル：日本語系のLLM
  • 結果
    • 一般は9割くらい、専門は3割弱（5択問題なので、ランダムより少し高い程度）
    • この結果をさらに深掘りするために、中間生成エントロピーを比較
      LLMの層は大体30層ちょい
      • 前半の層：6−7層目で、スコアが低い設問ほどエントロピーが高い
        →トークンから単語への変換が完了していないと思われる
      • 後半の層：35層目付近で差が出る。スコアが低い設問ほどエントロピーが高い
        →情報を集約できていない≒文脈を理解できていない
      • 情報を圧縮しきれずに文脈変換やタスク変換の層に移行するとエントロピーが大きくなる
      • →全体として、専門ドメインの方が一般ドメインよりも処理が遅れている

内部での処理が層別にトークン→単語→文脈→タスク、と移ろうと推察し、処理が移行するタイミングで特にエントロピーが増大するという考察がとても面白かったです。LLMの内部構造系の研究は疎く、知らないことだらけなのですが、この発表は考察の方針ややっていることが分かりやすく、納得感がありました。活用方面では専門用語の辞書を作っておくことが一つ効果がありそうだなと思ったのと、この内容はLLMの基盤モデル開発にも活かせそうな知見だと思いました。

ポスター展示

（メモも写真も撮ってないのでかなり曖昧な記憶です…）

表データに答えがあるようなQAのタスクで、Gen AIではなく分類モデルを使うことでGPT4o（記憶曖昧）よりも精度が出たという話が印象的でした。表の行と列に対して「答えがありそうかどうか」の確率をそれぞれ出していき、最終的に最も高い行×列のセルに回答があるとするようなロジックでした。生成AIが万能じゃないという結果は普通に面白いし、分類モデルということでMLエンジニアたちの腕の見せ所かも、と思ったりしました。

そのほか

マルチエージェント系の分野は同じモデルを使った時にいかににうまくエージェント同士を連携させて精度を出すかという話が一定ある印象でした。これは、普通に半年後に出るすごいモデルで一気に精度が塗り替えられる可能性がある分野なのでリスキーとも思えますが、エージェント設計や評価方法といったスキームは廃れないと思うので、研究すること自体に価値はあると思います。AI活用・応用の分野は、専門性の中でどこが廃れやすい部分でどこが廃れにくい部分なのかを意識しながらやっていくのがいいのかしら、と思いました。廃れにくい部分についてちゃんとナレッジが蓄積されて、それが研究組織の中に浸透していけばいい感じなんじゃないかとぼんやり思っています。

AWS AI Day 参加レポ

クラウド AI

2024年9月9日に開催されたAWS AI Dayに参加してきたので、参加レポートを書こうと思います。

オープニングセッション

登壇者

アマゾン ウェブ サービス ジャパン合同会社
Data & AI事業本部 プリンシパル事業開発マネージャー
黒川 亮

内容

生成AIをAWSで使うと何が嬉しいのか？がメインテーマでした

AWSの強み

  • セキュリティ：求められる以上の要件を揃えている
  • APIの多さ：数十で、他クラウドの倍くらいある
  • アップデート頻度：2023年から326件機能追加をしている。ユーザーのニーズベースで開発
  • 持続可能性や地球環境にも配慮

Bedrockの強み

  • 数十のモデルをカスタムして使える
  • RAGもファインチューニングもBedrockで実装可能
  • Bedrockナレッジベース：フルマネージドなRAG作成サービス
  • エージェントも実装可能
    • Agent for Amazon Bedrock：ナレッジベースと連携できる
      • メモリー保持やコード解釈機能が直近追加
  • ガードレールでハルシネーション検出や出力情報制御ができる

所感

セキュリティやAPIの多さはAWSが他クラウドに勝ってる部分かもしれないと感じました。

新人検索エンジニアが挑んだ実例で学ぶ、RAGの性能評価と改善のノウハウ

登壇者

株式会社リクルート
データ推進室 検索エンジニアリング2グループ
中川 皓太 氏、柴田 幸輝 氏

内容

コンテンツ掲載の表現内容の問い合わせをユースケースにしたRAGの実装と改善の話。改善→定量的な評価→訂正的な分析のサイクルを3ヶ月で40以上回し、アプリを開発・修正していたそうです。

  • 「この機能は当社製品だけ」などの表現が適切かどうかの問い合わせにLLMが自動応答

  • BedrockのナレッジベースとPrompt Flowを使い、1日でアプリは作れた

  • 作成後、改善→評価→分析のサイクルを回した

  • 改善：プロンプトエンジニアリングでのRAGの精度向上

  • 評価：データセットを作成し、RAGASのフレームワークで定量的かつ複数指標で評価
    • データセット：質問、回答、回答根拠の組を108件人出で作成
    • 評価指標
      • Answer Similarity：生成された回答と真の回答の類似性
        • ベクトル変換して、その類似度を測る
        • 数値が高い方が類似している
      • Faithfulness：生成された回答がどれだけコンテキスト（検索でヒットした文章）に基づいているか
        • 数値が高い方がコンテキストに一定しており、ハルシネーションリスクが低い
      • 分析：訂正的な仮説を立て、原因分析をして改善へ

所感

質問、回答、回答根拠のデータを人出で作成できているのがとても良いなと思いました。詳細は触れられていませんでしたが、学習データの質はLLMを使ったアプリ開発では(LLM自体の開発もそうだと思いますが)かなり重要な気がしているので、どうやって作ったのか気になりました。

100 以上の生成 AI 事例に見る ビジネスインパクト創出の方程式

登壇者

アマゾン ウェブ サービス ジャパン合同会社 金融事業開発本部長
飯田 哲夫

内容

100以上の事例をもとに、うまくいく事例のポイントを紹介していました。

  • 多くの顧客が生成AI活用を検証→プロダクションへ移行し効果をあげているが、全体で見るとまだ初期フェーズ

  • 一般的なユースケースから初め、業界特化のユースケースに進むことが多い

  • ハイインパクトなユースケースはデータ抽出、商材作成、サポート業務の支援、パーソナライゼーション、営業支援、審査業務支援などが多め

  • 事例の共通点

    • 顧客起点文化：顧客体験や社内の営業・カスタマーサポートの改善といったKPI、効果を定量的に計測している
    • 小規模なチーム（1−4名）でのPoC
      • 「まず始める」、そして加速する
    • 頻繁な実験：ほぼ全ての会社が1−３ヶ月で本番稼働に
      • 実験・傾聴・反復のサイクルを繰り返す
  • データが差別化要因：企業固有や業界固有の課題にアプローチでき、競争力の高いユースケースに発展しうる

所感

顧客起点でユースケースを考え、小さく始めてサイクルを素早く回すのがキーとなりそうです。顧客起点も小さく始めるも色々なところで見かける話なので、かなり真理に近いんだろうなと思ってます。

突撃！隣のAmazon Bedrockユーザー ～YouはどうしてAWSで？～

登壇者

KDDIアジャイル開発センター株式会社
テックエバンジェリスト 御田 稔（みのるん）氏

内容

エンジニア目線でのBedrockの良さを紹介していました。

  • AWSの良さ

    • ビルディングブロックの一つとしてカスタムできる
    • マネージドサービスとして高度な機能が簡単に使える
    • ユーザーが多いので開発者を確保しやすく、知見も豊富

  • 注目機能

    • ナレッジベース：RAGのフルマネージドサービス

    • エージェント：大きな目的を与えるとあとは自律的にAIが作業してくれる

      • Lamba関数実行、Web検索、ナレッジベース探索
    • プロンプトフロー：ローコードでLLMアプリを作成できる（Difyみたいなやつ）

  • アプリ開発のTips

    • 適宜非同期処理を組み込む
    • マルチモーダルモデルを使えば画像も読み込める
      • 図表→画像化→テキスト化することでRAGのデータベースにできる
      • ナレッジベースでマネージドに実現できる
    • エージェントの制御：LangGraphで、エージェントの行動をステートマシンとして細かく設計可能
    • 海外リージョンおすすめ：APIのレイテンシーそこまで落ちない＆AWS内部ならリージョン跨いでも暗号化されるので、最新モデル試すならアメリカのリージョンが良い
  • 生成AIは内製開発向き：新機能がバンバン出るので要件考えて外注が間に合わん
  • →とにかく触ろう。触ると解像度格段に上がるよ！

所感

個人的に一番ワクワクしたセッションでした。途中出していたパワポを自動作成してメールで送るデモを見てここまでできるんだ！とテンションが上がったので、エージェント触ってみたいです。

ハンズオン

こちらを使ってハンズオン：

https://github.com/aws-samples/generative-ai-use-cases-jp

かなり本格的なチャットボットのハンズオンで、Typescriptベースで作り込んでいました。RAG、文章生成、画像生成、動画解析、要約、Webサイトの抽出など、機能も盛りだくさん。

全体を通しての感想

Bedrockすごい！あんまり触ってなかったので触りたくなりました。機能追加の速さはかなり魅力に感じました。
良くも悪くも事例は決して奇抜なものではなく、現状の業務をベースに考えられているものが多いなと思いました。現時点ではニーズ起点の方がビジネス応用しやすいのかもしれません。

LlamaIndex × Azure OpenAIでRAGを試す

AI

タイトル通りですが、LlamaIndexのバージョン更新が早くて2024年1月時点の最新バージョンでの日本語記事がなかなか見つからなかったので、公式ドキュメントを参考に実装した内容をこちらに載せようと思います。

簡単な用語説明

  • LlamaIndex: LLMアプリの構築を支援するデータフレームワークです。今回はRAG(後述)を実装するために使用しています

github.com

  • Azure OpenAI: 正式名称はAzure OpenAI Serviceで、OpenAIのモデルをAzureを通して利用できるサービスです。OpenAIのLLMをpythonで使う際に利用しています

learn.microsoft.com

  • RAG(Retrieval-Augmented Generation): LLMが回答を生成する際に外部の知識を検索させるフレームワークです。ハルシネーション(LLMがもっともらしく嘘をつく現象)を減少させ、事実ベースで回答できるようになることが期待されます

docs.llamaindex.ai

実行環境

  • PC: Mac
  • python: 3.10
  • LlamaIndex: 0.9.31
    ローカル環境でDockerコンテナを立ち上げて実行しました。

実装

  • ライブラリの読み込み
    今回はAzure OpenAIからLLMとEmbeddingのモデルを使ったので、それぞれに対応するライブラリをインポートしています。インポート後にログを出力する設定をしています。
import os

from llama_index.llms import AzureOpenAI
from llama_index.embeddings import AzureOpenAIEmbedding
from llama_index import VectorStoreIndex, SimpleDirectoryReader, ServiceContext
from llama_index import set_global_service_context
import logging
import sys

logging.basicConfig(
    stream=sys.stdout, level=logging.INFO
)  # logging.DEBUG for more verbose output
logging.getLogger().addHandler(logging.StreamHandler(stream=sys.stdout))



  • セットアップ
    API、LLM、embeddingモデル、service contextのセットアップを行います。今回はLLMとしてGPT-4を、embeddingモデルとしてtext-embedding-ada-002を使用しました。APIのバージョンは適宜変更してください。service contextは公式ドキュメントのままに書いていますが、おそらくLlamaIndex側に使うモデルの情報をセットしているんだと思います。
# API
api_key = os.getenv("AZURE_OPENAI_KEY")
azure_endpoint = "https://<your-resource-name>.openai.azure.com/"
api_version_llm = "2023-09-01-preview"
api_version_embed = "2023-05-15"

# llm model
llm = AzureOpenAI(
    model="gpt-4",
    deployment_name="your-deploy-name",
    api_key=api_key,
    azure_endpoint=azure_endpoint,
    api_version=api_version_llm,
)

# embedding model
embed_model = AzureOpenAIEmbedding(
    model="text-embedding-ada-002",
    deployment_name="your-deploy-name",
    api_key=api_key,
    azure_endpoint=azure_endpoint,
    api_version=api_version_embed,
)

# set service context
service_context = ServiceContext.from_defaults(
    llm=llm,
    embed_model=embed_model,
)
set_global_service_context(service_context)



  • データの読み込み・データベース作成
    データはチュートリアルページと同様にエッセイのデータを使用しました。チュートリアルページからダウンロードし、../data/ディレクトリ配下に格納しています。その後VectorStoreIndexを使ってテキストをembeddingし、indexを作成しています。
documents = SimpleDirectoryReader(input_files=["../data/paul_graham_essay.txt"]).load_data()
index = VectorStoreIndex.from_documents(documents)

ログの出力は↓のような感じになります。

INFO:httpx:HTTP Request: POST https://... "HTTP/1.1 200 OK"
HTTP Request: POST https://... "HTTP/1.1 200 OK"
HTTP Request: POST https://... "HTTP/1.1 200 OK"
...



  • クエリ実行と結果出力
    クエリはエッセイの面白かった部分を聞く内容です。このクエリをもとに検索を行い、エッセイ内容を参照して回答をしてくれます。
query = "What is most interesting about this essay?"
query_engine = index.as_query_engine()
answer = query_engine.query(query)

print(answer.get_formatted_sources())
print("query was:", query)
print("answer was:", answer)

↓のように参考にしたソース、クエリ文、回答文が出力されます。

> Source (Doc id: 74acc1a9-8c6d-46c9-b7bd-cd8edf7f6523): Notes

[1] My experience skipped a step in the evolution of computers: time-sharing machines with...

> Source (Doc id: 742cd9ad-d677-4730-9c5c-85069b325989): A lot of Lisp hackers dream of building a new Lisp, partly because one of the distinctive feature...
query was: What is most interesting about this essay?
answer was: The most interesting aspect of this essay is the personal journey and insights of the author, particularly the realization of the potential of online publishing. The author describes a pivotal moment when they discovered the wide reach of the internet after posting a talk online, which garnered 30,000 page views in a single day. This realization led to the understanding that the internet had opened up a new channel for essayists, free from the constraints of traditional print publishing and its gatekeepers. The essay also touches on the theme of working on projects that lack prestige and how this can be a sign of genuine interest and discovery, rather than being driven by the desire to impress others. The author's experiences with Lisp, painting, cooking, and creating startups like Viaweb and Y Combinator, as well as their reflections on the evolution of technology and its impact on various fields, add depth to the narrative.

参考

AWS×Streamlit×GPTでペルソナ作成・リサーチアプリを作ってみた

AI クラウド

こんにちは。ChatGPTがリリースされてからLLM以外の技術トピックをめっきりキャッチアップしなくなってしまい、まずいなと思いつつモチベが上がらない日々を過ごしています。今回はそんなLLMを使ったWEBアプリを作ってみたので、その内容を紹介しようと思います。

サマリ

  • OpenAI APIを用い、GPT-3.5を使って商品情報を入力するとそれに合わせたペルソナを作成・分析してくれるアプリを作った

  • AWSでEC2インスタンスを作成→Dockerコンテナを立てる→PythonのライブラリであるStreamlit1を用いてアプリ作成という手順で作成した

  • 基本的に生成文が著しくズレていることはなく、壁打ちとしては機能しそう。ChatGPTでも同様のことができるが、ペルソナ作成に特化した入出力のフォーマットなので、より楽に使えそう

きっかけ

アプリ作成のきっかけは↓のツイートでした。

このプロンプトを見て良くできてるなあと思いつつも、「毎回ChatGPTにコピペするのは面倒だな」「プロンプトのどの部分を変えるのか分かりにくいな」と感じました。そこで、OpenAIのAPIを使ってアプリの形にして、もっと使いやすくできるんじゃないか？と思い、作成に至りました。

作成手順

ざっくりと作成手順を記載していきます。
DockerfileやPythonコードは↓のGitHubに挙げているので、こちらも必要に応じて見てみてください。

github.com

前提

EC2インスタンスを作成し、VSCodeからSSH接続をする

ここについては以前記事に書いたので、適宜↓を参照してください。

miteinoheya.hatenablog.com

EC2でdockerコンテナを立てる

  • 以下のコマンドを実行してdockerとdocker composeをインストールします
# Dockerのインストール
sudo yum update -y
sudo yum install -y docker
sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -a -G docker ec2-user
newgrp docker
# インストールされたことを確認
docker info
# docker-composeのインストール
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
# インストールされたことを確認
docker-compose --version

  • Dockerfileとdocker-compose.ymlファイルを作成する EC2インスタンスの任意のディレクトリでそれぞれのファイルを作成します。Dockerfileとdocker-compose.ymlは同じディレクトリ配下に置いています。

  • docker-compose.ymlのあるディレクトリに移動して docker-compose up -d を実行する

JupyterLabを立ち上げる

http://[EC2インスタンスのパブリックIPアドレス]:8888/lab
上記のURLを打ち込めば立ち上がると思います。

  • パスワードはDockerfileで記述したもの
  • EC2インスタンスのセキュリティグループのインバウンドルールに8888番ポートを追加しておく

※Streamlitを使ってWebアプリを作るだけならJupyterLabは必要ないのですが、Pythonコードの試行錯誤をするのにノートブックを使い慣れているのでJupyterLabを使っています。

Streamlitを使ってペルソナ作成・リサーチアプリを立ち上げる

  • Pythonコードは上部であげたGitHubのリポジトリにあるので、適宜見てもらえればと思います
  • ターミナルを起動してscriptフォルダに移動し、streamlit run [pythonファイル名]と打ち込むと立ち上がる
    • 出力にある「External URL」から開ける

注意事項

  • おそらくCtrl+C以外でアプリを停止できない(Streamlitの仕様？)
  • ブラウザを消してもJupyterLabのターミナルタブを残したままならrunし続ける

所感

以下に作成したアプリの簡単な所感を書いていきます。

  • 元ツイートと同じような出力が出てきた
  • 入力する部分が分かりやすい：書き換えが楽
  • カスタマイズしやすい：今回は実装していないが、出力結果をファイルにしてエクスポートすることも可能

機能は元のツイートとほぼ変わらないままに、使いやすさはアプリにした分向上したかなと思います。ChatGPTはチャット形式で便利ではありますが、今回のように目的がはっきりしているときはそれ用にカスタマイズする方が便利だなと思いました。

少し簡素ではありますが、以上になります。ではでは。

  1. Streamlitとは、PythonでWebアプリケーションを作成するためのフレームワーク。簡易的にWebアプリを作成するのに向いている↩

GPT3.5にブログを書かせる

AI

こんにちは。最近仕事をサボってChatGPTとかで遊びがちなのですが、AWSとかも使って色々やってた結果ブログを自動作成してくれるツールができました。せっかくなのでブログを書いてもらおうと思います。

ツールについて

こんなものを作りました。

シンプルな構成で、テーマを入力して実行ボタンを押すとブログっぽい文章を出力してくれるだけの機能です。
PythonとStreamlitを使って作りました。Streamlitは使ったことなかったんですが、GenieAI(GPT使ったコード生成ツール)に「コード書いて」って言ったらそれっぽいコードを書いてくれました。内部でプロンプトを書いていて、文字数や文体を指示しているのですが、そこは自分で考えて書いてます。
完全個人用で作ったので、一般公開はしてないです。

使ってみた

適当にテーマを入れてみる

入れたテーマ：戦争と平和
出力↓

タイトル：戦争と平和

こんにちは、私は戦争と平和について考えることがあります。私たちは、平和な社会を築くことが目標であるにも関わらず、現実には世界中で多くの紛争が発生しています。私たちは、戦争がなぜ起こるのか、そして平和を実現するために何ができるのかについて考えていく必要があります。

戦争は、様々な要因によって引き起こされます。国家間の利益対立、宗教的、民族的な対立、資源の争奪などが挙げられます。一方で、平和は、個人や国家が相互に理解し合い、共存することで実現されます。しかし、それは簡単なことではありません。相互理解や共存に必要な教育やコミュニケーションが不足している場合があります。

私たちが平和を実現するためにできることは何でしょうか？まず、個人レベルでの相互理解や共存を推進することが大切です。自分と異なる考え方や文化を理解し、尊重することが求められます。また、政治家や指導者たちは、対話、妥協、協力を通じて紛争の解決を図るべきです。

戦争がなくなることは簡単なことではありませんが、私たちは平和を目指すことができます。相互理解や共存を推進し、紛争解決に向けた取り組みを進めていくことが必要です。私たちが平和を手に入れることができるよう、一人ひとりが行動することが大切です。

それっぽさの塊みたいな文章が出てきました。こういう一般的なお題は得意そうですね。

固有名詞を入れてみる

入れたテーマ：菅田将暉のいいところ
出力↓

タイトル：菅田将暉の魅力、私の見つけたいいところ

こんにちは、私は菅田将暉さんの大ファンです。今回は、私が見つけた菅田将暉さんの魅力についてお話ししたいと思います。

まず、菅田将暉さんの魅力の一つはその人柄です。彼はとても謙虚で、常に周りの人たちを大切にしています。また、彼の笑顔はとても素敵で、見ているだけで心が癒やされます。

そして、もう一つの魅力はその演技力です。菅田将暉さんは、どんな役柄でも自然に演じきることができます。私が特に好きなのは、映画『ちはやふる』での演技です。彼が演じる綾瀬千早の繊細で力強い演技は本当に素晴らしいものでした。

さらに、菅田将暉さんは音楽でも活躍しています。彼が歌う「まちがいさがし」は、とてもキャッチーで心に残る曲です。彼の音楽活動も見逃せない魅力の一つです。

最後に、菅田将暉さんの魅力の一つに、彼のファンとの距離感の近さが挙げられます。彼はSNSを通じて、ファンとのコミュニケーションを大切にしています。また、イベントやライブなどでも、ファンとの交流を大切にしている姿が見られます。

以上が、私が見つけた菅田将暉さんの魅力です。彼の人柄や演技力、音楽活動、そしてファンとの距離感の近さなど、彼の多彩な魅力に私は魅了されています。皆さんも、ぜひ彼のいいところを探してみてください！

思ったよりそれっぽいですが、多分『ちはやふる』には出演してないですね。ただ「まちがいさがし」は実際に楽曲としてあるので、まったくの見当違いではなさそうです。
今回のツールには検索機能はないので、正しい情報が求められるようなテーマは苦手そうですね。

意味不明なテーマの場合

入れたテーマ：くぇｒｔｙ
出力↓

タイトル：「くぇｒｔｙ」という言葉の魅力に迫る

こんにちは、私はくぇｒｔｙについての思いを語りたいと思います。

くぇｒｔｙという言葉は、日本語としては存在しない造語ですが、その言葉の響きや意味に惹かれて、私は今では頻繁に使っています。

くぇｒｔｙとは、何かが形や音のズレを感じさせながら、同時に美しさや面白さを感じさせること。例えば、音楽やアートの中には、くぇｒｔｙな要素が含まれているものがあります。

また、くぇｒｔｙなものは見た目だけでなく、感覚にも訴えかけます。例えば、食べ物の味や匂い、触感などが、くぇｒｔｙな要素を持っていることがあります。

私は、くぇｒｔｙなものを見つけることが好きで、その瞬間に自然と笑顔がこぼれます。くぇｒｔｙなものに出会うことで、心が豊かになり、幸せな気持ちになるのです。

皆さんも、くぇｒｔｙなものを探してみませんか？日常の中にも、意外なところにくぇｒｔｙが潜んでいるかもしれません。

今回は、くぇｒｔｙという言葉の魅力についてお話しました。皆さんにとっても、くぇｒｔｙな要素を感じる瞬間が訪れますように。

わけ分からな過ぎて面白いｗ
くぇｒｔｙって言いたいだけの人みたいになってる。

おわりに

こういうアプリ的なものを作った経験はなかったのですが、自分で考えるのを放棄してAIに聞きまくったらできてしまったので本当に便利な時代になったなと思います。やっぱり検索機能があった方がいいなというのと、文字数を指定できたらいいなと思いました。プロンプトの内容もオプションで変えられるといいかもですね。
実務を考えるとファイル入れて要約するツールとかファイル読み込ませて集計してもらうツールとかはかなり便利かもなと思いました。モチベが湧いたらまたなんか作ろうかなと思ってます。
ではでは。

Lambdaで形態素解析をする

クラウド

最近業務でAWSを触ることが多く、その中で形態素解析をする機会があったので、その際の内容を備忘録として残しておきます。

やったこと

  • AWSのサービスを使い、ファイルがS3に置かれたら自動で形態素解析ができるようなシステムを作る
    • サービスとして、今回はLambdaを採用した
  • 形態素解析ツールとしてMeCabを利用する

手順

今回実装した大まかな手順は以下になります

  1. EC2インスタンスを作成し、SSH接続をする

  2. EC2インスタンス上にDockerとAWS CLIをインストールする

  3. EC2インスタンス上でDockerfile、requirements.txt、lambda_function.pyを作成し、Dockerイメージを作成する

  4. 作成したイメージをAmzon ECRへプッシュする

  5. Lambda関数をコンテナイメージから作成する

  6. S3バケットをトリガーとして設定する
    アーキテクチャの全体像は↓のようになります

手順詳細

FROM public.ecr.aws/lambda/python:3.9

COPY requirements.txt  .
RUN  pip3 install -r requirements.txt --target ./

COPY lambda_function.py   ./
CMD ["lambda_function.lambda_handler"]
  • requirements.txt
mecab-python3==1.0.6
unidic-lite==1.0.8
  • lambda_function.py
    • 入力ファイルはcsv形式で、A列にテキストが入っている想定です
import boto3
import csv
import io
import os
import urllib.parse
from datetime import datetime

import MeCab

s3 = boto3.client("s3")

def lambda_handler(event, context):
    # インプット用S3バケットからファイルを取得
    bucket = event["Records"][0]["s3"]["bucket"]["name"]
    key = urllib.parse.unquote_plus(event['Records'][0]['s3']['object']['key'], encoding='utf-8')
    response = s3.get_object(Bucket=bucket, Key=key)
    input_data = response["Body"].read().decode("utf-8").splitlines()
    csv_reader = csv.reader(input_data)
    headers = next(csv_reader, None) # Skip headers

    # 形態素解析
    mecab = MeCab.Tagger()
    result = []

    for row in csv_reader:
        text = row[0]
        node = mecab.parseToNode(text)
        # parsed_words = []
        # pos_info = []

        while node:
            if node.surface != '':
                result.append(text, node.surface, node.feature])
            node = node.next
        

    # アウトプットファイルを作成
    output_buffer = io.StringIO()
    csv_writer = csv.writer(output_buffer)
    csv_writer.writerow(["元のテキスト", "分解された単語", "情報"])
    csv_writer.writerows(result)

    # アウトプット用S3バケットに保存
    output_bucket = "your-output-bucket"  # アウトプット用バケット名に置き換える
    timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    output_key = f"output_{timestamp}.csv" # Set the output file name with a timestamp
    s3.put_object(Bucket=output_bucket, Key=output_key, Body=output_buffer.getvalue())

  • S3バケットをトリガーとして設定する

    • 関数を作成後、関数の概要図からS3の「＋トリガーを追加」を選択し、S3を指定
    • S3トリガーとなるバケットを選択する

  • ランタイムやメモリの設定変更

    • 処理に時間を要するものは、Lambda関数の「設定」からメモリとタイムアウトの設定を変更し、「保存」

  • 入力データの格納（＝トリガーの発動）

  • 出力バケットの確認

  • 出力用のS3バケットの中身を確認する
    （実行に時間がかかるものもある。15分以内で収まるはず。）

    • S3画面でバケットを選択し、吐き出されたCSVを選択、ダウンロード

  • エラー・バグの対応

    • Lambda関数の「モニタリング」タブから「View CloudWatch Logs」を選択 CloudWatchの該当「ログストリーム」を選択
    • うまくいかないときはエラーが吐かれているはずなので確認してみる

参考