メインコンテンツにスキップ
株式会社ゼットリンカー

Knowledge RAG

社内ナレッジRAGの構築・精度改善

「社内AIを作ったのに、誰も使っていない」——原因はAIの性能ではなく、 データと設計にあることがほとんどです。精度が出ない理由を診断して直すレスキューと、 これから作る場合の構築。どちらの入口からでもご相談いただけます。

社内ナレッジRAGの精度を診断・改善する様子を表すイラスト

Situations

こんな状況ではありませんか?

「AIを入れた」と「ナレッジが回っている」の間には、いくつかの壁があります。

見当違いな回答が表示されたモニターを前にがっかりした表情をしている人物のイラスト

社内AIを作ったのに、答えが的外れで誰も使わなくなった

精度が出ない原因を診断します

隣のデスクの人に尋ねようと困った表情で振り返っている人物のイラスト

結局「詳しい人に聞かないと分からない」が減っていない

使われるAIに立て直します

あちこちに散らばった書類やフォルダの山の中で困惑した表情で探し物をしている人物のイラスト

マニュアル・議事録・過去のやり取りが散らばっていて、探せない

これから作る構築も承ります

埃をかぶったモニター画面を前に寂しげな表情をしている人物のイラスト

導入直後は使われたが、更新されず情報が古びて廃れた

運用が回る仕組みごと作ります

Causes

なぜ社内AIの精度は上がらないのですか?

原因は大きく3つに分かれます。診断では、どこに原因があるかを実際の質問と回答から特定します。

読ませているデータの問題

古い版と新しい版が混在している、暗黙の前提が文書化されていない——精度問題の大半はAIではなくデータ側にあります。

検索・分割設計の問題

文書の切り方・検索の仕方が業務の質問の形と合っていないと、正しい資料があっても引き当てられません。

運用の問題

新しい文書が追加される流れがないと、AIは導入した日の知識で止まります。更新が回る運用設計が必要です。

これから新しく構築する場合の詳細はAIソフトウェア開発(RAG環境開発)を、発注前の準備はコラム社内文書RAGを受託で作るとき、発注前に決める5つのことをご覧ください。

Process

精度改善はどう進みますか?

診断→改善→再展開→運用定着の4ステップ。診断だけで区切ることもできます。

質問と回答のズレを分析する診断の様子のイラスト
01

診断

実際の質問と回答のズレを分析し、原因がデータ・検索設計・運用のどこにあるかを特定します。

データ整備や検索設計を作り直す改善の様子のイラスト
02

改善

原因に応じてデータ整備・検索設計の作り直し・モデル変更を行い、回答の質を検証します。

現場のよくある質問で精度を確認し再展開する様子のイラスト
03

再展開

現場のよくある質問で精度を確認してから再展開し、「もう一度使ってもらう」ところまで伴走します。

現場で使われ続ける仕組みを作る運用定着の様子のイラスト
04

運用定着

文書の更新が自然にAIへ反映される運用の流れを作り、廃れないナレッジ基盤にします。

STEP 01

診断

実際の質問と回答のズレを分析し、原因がデータ・検索設計・運用のどこにあるかを特定します。

STEP 02

改善

原因に応じてデータ整備・検索設計の作り直し・モデル変更を行い、回答の質を検証します。

STEP 03

再展開

現場のよくある質問で精度を確認してから再展開し、「もう一度使ってもらう」ところまで伴走します。

STEP 04

運用定着

文書の更新が自然にAIへ反映される運用の流れを作り、廃れないナレッジ基盤にします。

Assurance

再展開して終わりにしません

一度直しても、また廃れることがあります。使われ続ける状態まで見届けます。

虫眼鏡とグラフのアイコンを持ち、お客様が安心した表情でモニターを見ている様子を表すイラスト

再展開後の精度モニタリング

再展開して終わりにせず、実際の利用状況を見ながら精度が維持できているかを確認します。

聴診器のようなアイコンを持つ担当者と、ほっとした表情を見せるお客様の様子を表すイラスト

廃れた場合の再診断も対応

運用の中で再び精度が落ちてきた場合も、同じ診断プロセスで原因を特定し立て直します。

データベースアイコンの箱をお客様に手渡し、お客様が満足げに受け取っている様子を表すイラスト

構築物は御社の資産に

データ整備・検索設計・システムは御社に帰属します。将来的な内製化や他社への引き継ぎも制限しません。

FAQ

よくある質問

Q. 他社が構築したRAGでも改善をお願いできますか?

A. はい。他社構築・自社構築を問わず診断から承ります。作り直しが不要で設定とデータの整備だけで改善するケースも多くあります。

Q. 精度が上がらない原因は何が多いですか?

A. 最も多いのは読ませているデータ側の問題です。古い文書の混在・文書化されていない暗黙知・質問の形と合わない文書構造など。AIモデルの性能が原因であるケースはむしろ少数です。

Q. これから新しく作る場合もお願いできますか?

A. はい。RAG環境の構築はAIソフトウェア開発の主要メニューです。発注前に決めるべきことはコラム「社内文書RAGを受託で作るとき、発注前に決める5つのこと」にまとめています。

Q. 社内の機密文書を扱うことになりますが、大丈夫ですか?

A. NDA締結の上、扱う文書の範囲と保存場所・学習に使われない構成を設計段階で確定します。「どの文書は読ませない」の線引きも一緒に決めます。

Q. 診断だけお願いすることはできますか?

A. はい。診断レポート(原因の特定と改善の選択肢)までで区切れます。改善を社内で実施いただく形でも大丈夫です。

Tech Stack

対応する技術スタック

課題に合わせて、ちょうどいい技術を選んで組み立てます。一覧にない技術もご相談ください。

受託開発で対応しているFramework「Next.js」の公式ロゴアイコンNext.jsFramework
受託開発で対応しているLibrary「React」の公式ロゴアイコンReactLibrary
受託開発で対応しているLanguage「TypeScript」の公式ロゴアイコンTypeScriptLanguage
受託開発で対応しているBuild「Vite」の公式ロゴアイコンViteBuild
受託開発で対応しているLanguage「Python」の公式ロゴアイコンPythonLanguage
受託開発で対応しているFramework「FastAPI」の公式ロゴアイコンFastAPIFramework
受託開発で対応しているBaaS「Supabase」の公式ロゴアイコンSupabaseBaaS
受託開発で対応しているBaaS「Firebase」の公式ロゴアイコンFirebaseBaaS
受託開発で対応しているLLM「Claude」の公式ロゴアイコンClaudeLLM
受託開発で対応しているLLM「OpenAI」の公式ロゴアイコンOpenAILLM
受託開発で対応しているLLM「Gemini」の公式ロゴアイコンGeminiLLM
受託開発で対応しているFramework「LangChain」の公式ロゴアイコンLangChainFramework
受託開発で対応しているFramework「LangGraph」の公式ロゴアイコンLangGraphFramework
受託開発で対応しているMobile「Expo」の公式ロゴアイコンExpoMobile
受託開発で対応しているCloud「AWS」の公式ロゴアイコンAWSCloud
受託開発で対応しているCloud「Google Cloud」の公式ロゴアイコンGoogle CloudCloud
受託開発で対応しているCloud「Azure」の公式ロゴアイコンAzureCloud
受託開発で対応しているEdge / CDN「Cloudflare」の公式ロゴアイコンCloudflareEdge / CDN

Contact

「使われなかった質問」を3つ持ってきてください

うまく答えられなかった実際の質問がいくつかあれば、初回相談で原因の見当までお伝えできます。

お問い合わせはこちら

ご相談・お見積もりは無料です