FiNCにおける人工知能とその表現について。

1. ウェルネスAIとグラフDB
FiNC CTO 南野充則

2. 目次
1. 自己紹介/会社紹介
2. FiNC人工知能：ウェルネスAI
3. リレーショナルDBとグラフDB
4. ウェルネスAIの課題
5. 導入によるメリット

3. ①自己紹介
・Swiftと画像解析
最近のブーム
大学時起業、受託開発と
コンサルティングの会社
を営み、FiNCへ。
南野 充則
取締役 CTO
経歴
・ダイエット実験
好きなAWS
・S3

4. ①会社紹介
モバイルヘルスケアベンチャー / 科学×専門家

5. ②FiNC人工知能：ウェルネスAI
＝
管理栄養士とトレーナーの英知を集めた人工知能。

6. ②FiNC人工知能：ウェルネスAI
個人の生体情報をインプットすることによって、その人
に最適なアドバイスを可能にする

7. ③課題
UserとLifeLog、LifeLogとTag、TagとItem（食事、運
動、生活習慣改善行動）といった関連テーブルが多数
LifeLog Tag Item
join多すぎる。効率のいいクエリをなかなか書けない。

8. ④グラフDB
出典：Learning Neo4j、Rik Van Bruggen
<リレーショナルDB>
・述語論理に基づいたリレーショナルモデルを採用
・強い整合性と表現力の豊かさが特徴
<グラフDB>
・ノードとエッジという2つの要素から構成されるグラ
フを扱うことに特化
・柔軟性と高速なグラフ演算が特徴

9. リレーショナルDBでもグラフ扱えるよ？
テーブル構造として表現することは可能。
・効率的なクエリを書くことは困難。
例1)リレーションの数だけ中間テーブルが必要でjoinが増える。
例2)経路を見つける時も1度見つかっても最短経路である保証はない
・そもそもSQLは宣言型、最短経路問題は手続き的な解法が必要
・整合性を保証するのが難しい(エッジの追加後にループや閉路がな
い、エッジを削除してもグラフが連結している、平面的)
参考) SQLアンチパターン(Naive Trees)
http://qiita.com/hirashunshun/items/06adf4f42f03a9f3b63d

10. ⑤メリット
1. Joinを考えなくていい
2. 経路検索が容易
3. 複数条件も容易

11. ⑤メリット
Join の手間がかからない
ex.) 「食事タグ」がついた生活習慣改善行動（タスク）
を取得
# 1-1. Cypher
MATCH (task:`Task`)<--(tag:`Tag`)
WHERE tag.name = ‘食事’ RETURN task;
# 1-2. SQL
SELECT * FROM tasks
INNER JOIN tags_tasks ON tasks.id = tags_tasks.tag_id
LEFT JOIN tags ON tags.id = task_sets.tag_id
WHERE tags.name = '食事'

12. ⑤メリット
経路検索が容易
ex.) 自分のLv.4 のタスクで食事タグがついているもの
# 2-1. Cypher
MATCH (tag: `Tag`)-->(lv_up_task:`Task`)<-[r*3]-(task:`Task`)
WHERE tag.name = "食事"
RETURN lv_up_task;
# 2-2. SQL
SELECT * FROM tasks
LEFT JOIN level_up_paths as lv2_paths ON tasks.id = lv2_paths.task_id
LEFT JOIN level_up_paths ON lv3_paths ON
lv2_paths.next_task_id = lv3_paths.task_id
LEFT JOIN level_up_paths ON lv4_paths ON
lv3_paths.next_task_id = lv4_paths.task_id
INNER JOIN tags_tasks ON lv4_paths.next_task_id = tags_tasks.task_id
LEFT JOIN tags ON tags.id = tags_tasks.tag_id
WHERE tags.name = '食事'

13. ⑤導入によるメリット
複数条件も容易
ex.) ビタミン, 夏, 間食タグのうち、2つ以上持つタスク
# 3-1. Cypher
MATCH (task:`Task`)<-[r]-(tag:`Tag`)
WHERE tag.name IN ['ビタミン', '夏', '間食']
WITH task, count(r) as tags_count
WHERE tags_count >= 2 RETURN task;
# 3-2. SQL
SELECT * FROM tasks
LEFT JOIN tasks.id = filter.id
( SELECT tasks.id, COUNT (*) as tags_count FROM tasks
INNER JOIN tags_tasks ON tasks.id = tags_tasks.tag_id
LEFT JOIN tags ON tags.id = task_sets.tag_id
WHERE tag.name IN ['ビタミン', '夏', '間食']
GROUP tasks.id
HAVING tags_count >= 2
) as filter

14. 1. クエリ書くの簡単
2. データの可視化楽しい
3. 栄養士・ディレクターとのコミュニケーション
円滑化
4. データを実験的に試すのは⃝
5. 本番環境で試すのはもう少し検証必要
1. スケーラビリティ
2. パフォーマンス
グラフDBに詳しい方。是非教えてください。
現在はNeo4jを使用（Railsと相性いい?）

15. ご静聴ありがとうございました。