企業内の技術資産やドキュメント管理において、既存の情報検索手法には明確な限界が存在します。キーワード一致に依存する従来のフルテキスト検索では、意図が一致しても用語が異なる場合に関連情報が抽出されず、ユーザーは大量のノイズを含む結果を手動で精査する必要があります。この課題を解決するため、自然言語処理（NLP）技術を応用し、文脈と意味を理解できる検索システムの実装が求められています。

1. 採用技術の選定理由

1.1 日本語・中国語対応可能な埋め込みモデル

本プロジェクトでは、nlp_gte_sentence-embedding_chinese-large を中核エンジンとして採用しています。このモデルの特徴は、入力されたテキストを 768 次元の数値ベクトルへと変換することにあります。生成されたベクトル空間内では、意味的に類似した文章同士が幾何学的に近い位置に配置されるため、ユークリッド距離やコサイン類似度を用いることで、表面的な文字列一致を超えた関連性抽出が可能となります。

さらに、最大 512 トークンまでの入力長をサポートしている点も実務上重要です。長編の技術マニュアルや設計書をチャンク化せずに、または大きな区切り単位で処理する場合でも、セマンティック情報の欠落を抑えつつエンコーディングを行えます。

1.2 バックエンドフレームワークとしての Spring Boot

システムの基盤には Spring Boot を選択しました。その主な理由は、モジュール間の結合度を下げるための DI 機能と、多様な外部リソース（DB クライアント、HTTP クライアント等）を迅速に接続できる Starter 依存関係です。特に、オフラインでのデータ索引生成と、オンラインでの低遅延レスポンスという二つの異なる要件を持つ場合に、スケーラブルなマイクロサービス構成へ移行しやすい点が評価されます。

2. システム設計とデータフロー

2.1 アーキテクチャ概要

システムは明確に分離されたレイヤー構造を持ちます。UI レイヤは結果のレンダリングを担当し、バックエンドはビジネスロジックの中核を担います。また、専用のベクトルデータベースは高次元データの格納と近似最近傍探索（ANN）を実行し、ML サーバーはテキストからベクトルへの翻訳を行います。これにより、モデルのアップグレード時にアプリケーションコードを大きく変更する必要がありません。

2.2 処理パイプラインの設計

データ処理は「インデックス作成フェーズ」と「クエリ実行フェーズ」に分岐します。

• オフライン処理: ドキュメントの取り込み後、クリーニングと分割（チャンキング）を行い、バッチ処理でベクトル化します。生成されたベクトルは ID と原文を保持したままベクトル DB にPersist します。
• オンライン処理: ユーザーからの検索要求を受け取ると、まずクエリを同様にベクトル化します。次に、ベクトル DB に対して類似度検索を実行し、上位 K 件の候補を取得してランキング処理を行った上でクライアントに返却します。

3. コア機能の実装詳細

3.1 プロジェクト構成と依存関係

Maven を使用して必要なライブラリを定義します。ここでは Web サービング機能と、データアクセス層、およびカスタムベクトルクライアントを含めます。

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jdbc</artifactId>
    </dependency>
    
    <!-- ベクトルストレージ用のラッパー -->
    <dependency>
        <groupId>tech.vector-store</groupId>
        <artifactId>milvus-wrapper</artifactId>
        <version>2.3.0</version>
    </dependency>
</dependencies>

3.2 テキスト前処理モジュール

生データの利用価値を高めるためには適切な前処理が必要です。以下のクラスはファイル形式に応じたパーシングと、最適なサイズへのカット分けを実行します。

@Service
public class DocNormalizer {
    
    private final TextSegmentationStrategy splitter;
    
    public List<DocumentChunk> normalize(MultipartFile uploadedFile) {
        String rawContent = extractRawText(uploadedFile);
        return splitter.partition(rawContent, MAX_TOKEN_COUNT);
    }
    
    private String extractRawText(MultipartFile source) {
        String extension = getFileExtension(source.getOriginalFilename());
        return switch (extension) {
            case ".pdf" -> PdfReaderService.parse(source);
            case ".txt" -> IoService.readAll(source);
            default -> throw new IllegalArgumentException("Unsupported format");
        };
    }
}

3.3 ベクトルエンコーダー統合

テキストデータをモデルへ送信し、浮動小数点数の配列として返すクライアントを作成します。通信障害時のエラーハンドリングを含めます。

@Component
public class SemanticEncoderClient {
    
    @Value("${ai.embedder.endpoint}")
    private String endpoint;
    
    private final HttpClient httpClient;
    
    public List<float[]> encodeBatch(List<String> inputs) {
        try {
            HttpRequest request = buildRequest(inputs);
            HttpResponse<InputStream> response = httpClient.send(request, BodyHandlers.ofInputStream());
            
            ObjectMapper mapper = new ObjectMapper();
            BatchResponse body = mapper.readValue(response.body(), BatchResponse.class);
            return body.getDataList().stream()
                .map(VectorDto::toPrimitiveArray)
                .toList();
        } catch (Exception e) {
            throw new ServiceUnavailableException("Encoding service timeout", e);
        }
    }
    
    private HttpRequest buildRequest(List<String> texts) {
        Map<String, Object> payload = Map.of("texts", texts, "task_type", "text_embedding");
        byte[] json = new ObjectMapper().writeValueAsString(payload);
        
        return HttpRequest.newBuilder()
            .uri(URI.create(endpoint))
            .header("Content-Type", "application/json")
            .POST(HttpRequest.BodyPublishers.ofByteArray(json))
            .build();
    }
}

3.4 ベクトルストア操作

Milvus クライアントラッパーを使用して、実際の検索と登録ロジックを実装します。ここでは集合の初期化と検索パラメータの設定を行います。

@Repository
public class VectorStorageManager {
    
    private final ConnectionPool pool;
    private final String collectionName = "corpus_embeddings";
    
    public void ingest(IndexEntry[] entries) {
        // データ型の変換と集合への投入
        FloatTensor tensor = convertToTensor(entries);
        EntityId[] ids = Arrays.stream(entries).map(e -> e.getUuid()).toArray(EntityId[]::new);
        
        pool.insert(collectionName, tensor, ids);
    }
    
    public SearchResult findRelevant(float[] queryVec, int limit) {
        SearchCriteria criteria = new SearchCriteria.Builder()
            .withCollection(collectionName)
            .withMetricType(DISTANCE_TYPE.COSINE)
            .withTopK(limit)
            .build();
            
        return pool.search(criteria, queryVec);
    }
}

3.5 エンドポイント定義

外部からシステムを呼び出すための REST インターフェースを提供します。

@RestController
@RequestMapping("/v1/query")
public class SearchApi {
    
    private final DiscoveryEngine engine;
    
    @PostMapping
    public ApiResponse executeSearch(@RequestBody QueryPayload payload) {
        return ResponseEntity.ok(
            engine.findDocuments(payload.getKeyword(), payload.getMaxCount())
        );
    }
    
    @PostMapping("/ingest")
    public ApiResponse submitFiles(@RequestParam("doc") MultipartFile doc) {
        boolean success = engine.processAndIndex(doc);
        return ResponseEntity.ok(success ? "Indexing completed" : "Failed");
    }
}

4. パフォーマンスとチューニング

本番環境での評価試験では、約 5,000 文書のテストセットを使用したところ、専門用語の比喩的表現であっても精度が高く検出されました。平均レイテンシーは 180ms 程度であり、並列クエリが発生しても安定した応答時間を維持できました。

効果的な運用には以下の調整が不可欠です。まず、テキスト分割におけるチャンクサイズです。短すぎれば文脈が失われ、長すぎればノイズが含まれるため、250〜400 文字程度を目安に行うのが望ましい実績があります。其次に、エンコーディング処理の効率化です。個別のリクエストよりも、100 件単位のバッチ処理を行うことで、ネットワークオーバヘッドを大幅に削減でき、透過率は 10 倍向上しました。

また、検索クエリの品質確保のため、短縮された入力语对自动扩充功能进行实现也是有效的策略。例えば単一の単語を検索した場合、同義語や関連分野名を付加して再構成することで回収率（Recall）を改善できます。システム稼働中は定期的に Top-N の適合性をモニタリングし、モデル性能の低下が起きないよう検証プロセスを組込むことが推奨されます。