|
|
@@ -19,6 +19,7 @@ Editor Assistant API は、OpenAI AssistantAPI を使用して、マークダウ
|
|
|
4. **効率性**：
|
|
|
- メモリ使用量を最小限に抑える
|
|
|
- 不要な通信を避け、クライアントへの適切なタイミングでのデータ送信を実現
|
|
|
+ - メッセージの増分送信による通信量削減と、すでに処理済みの要素のスキップによる処理効率の向上
|
|
|
|
|
|
## 重要なインプット
|
|
|
|
|
|
@@ -82,10 +83,23 @@ Editor Assistant API は、OpenAI AssistantAPI を使用して、マークダウ
|
|
|
|
|
|
エディタアシスタントの核心部分は、OpenAI APIからのレスポンスから差分情報を適切に抽出し、効率的にクライアントに送信する機能です。以下のような工夫を行っています：
|
|
|
|
|
|
-- **メッセージと差分の処理の分離**：
|
|
|
- - これはUI/UX要件に基づいた設計判断です。メッセージと差分では、ユーザーに対する重要度と提示タイミングの最適値が異なります。
|
|
|
- - **メッセージ処理**：説明メッセージは変更があればすぐにユーザーに見せるべきです。そのため、最新のメッセージを検出したら即座に通知するロジックを実装しています。
|
|
|
- - **差分処理**：エディタの頻繁な更新はユーザー体験を損なうため、確定した差分のみを送信する制御機構を設けています。
|
|
|
+- **メッセージと差分の処理の統合と最適化**：
|
|
|
+ - UI/UX要件に基づく設計として、メッセージと差分の処理を単一ループで効率的に実装しています。
|
|
|
+ - **メッセージ処理**：メッセージの「増分」（新しく追加された部分）のみをクライアントに送信します。これにより通信量を削減し、クライアント側の処理負荷を軽減します。
|
|
|
+ - **差分処理**：JSONノードとして確定した差分は即座に検出し通知します。ただし、確定していない（変更中の可能性がある）差分は送信を控えることでエディタの過剰な更新を防止します。
|
|
|
+
|
|
|
+- **処理効率の向上メカニズム**：
|
|
|
+ - `processedMessages` Mapを使って、各メッセージ要素の前回の内容を記録し、差分のみを計算します。
|
|
|
+ - `lastProcessedContentLength` を用いて、すでに処理済みの要素をスキップします。これにより大量のデータでも効率的に処理できます。
|
|
|
+ ```javascript
|
|
|
+ // 処理開始位置の最適化 - 確定済み要素のスキップ
|
|
|
+ const startProcessingIndex = Math.max(0, Math.min(this.lastProcessedContentLength, contents.length) - 1);
|
|
|
+
|
|
|
+ // 単一ループでメッセージと差分を処理
|
|
|
+ for (let i = startProcessingIndex; i < contents.length; i++) {
|
|
|
+ // メッセージと差分の処理
|
|
|
+ }
|
|
|
+ ```
|
|
|
|
|
|
- **OpenAIストリームの特性に対応した差分確定判定**：
|
|
|
- OpenAI APIからのJSONストリームは「前方から順に確定していく」特性があります。このAPIの特性を活用し、以下の判定ロジックを実装しています：
|
|
|
@@ -95,17 +109,22 @@ Editor Assistant API は、OpenAI AssistantAPI を使用して、マークダウ
|
|
|
// 差分を確定して送信リストに追加
|
|
|
}
|
|
|
```
|
|
|
- - この条件判定は単なる技術的工夫ではなく、UXの向上を目的としています。確定していない（変更中の可能性がある）差分を頻繁に送信すると、エディタが頻繁に更新されてユーザー体験が悪化するためです。
|
|
|
+ - この条件判定は単なる技術的工夫ではなく、UXの向上を目的としています。確定していない差分を頻繁に送信すると、エディタが頻繁に更新されてユーザー体験が悪化するためです。
|
|
|
|
|
|
- **重複防止メカニズム**：
|
|
|
- 差分の重複送信を避けるため、一意のキーを生成する`getDiffKey`メソッドを実装しています。
|
|
|
- Setデータ構造（`sentDiffKeys`）を使うことで、O(1)の時間複雑度で効率的に重複チェックを行います。
|
|
|
- この実装は、ストリームデータの累積的な性質（同じデータが何度も現れる可能性がある）に対応するために不可欠です。
|
|
|
|
|
|
-- **差分の通知タイミングの最適化**：
|
|
|
- - 全ての差分更新を即座に送信すると、クライアント側での処理負荷が高まります。
|
|
|
- - `processedDiffIndex`と`lastSentDiffIndex`を比較し、新たに確定した差分がある場合のみ通知することで、通信量と処理負荷を削減しています。
|
|
|
- - 最終処理時には`sendFinalResult`で未送信の差分を含めた完全な結果を送信し、データの一貫性を保証します。
|
|
|
+- **増分メッセージ計算の最適化**：
|
|
|
+ - メッセージ要素ごとに前回のメッセージとの差分を計算する`getAppendedContent`メソッドを実装しています。
|
|
|
+ - これにより、クライアントには新たに追加された部分のみを送信でき、通信量を大幅に削減できます。
|
|
|
+ ```javascript
|
|
|
+ private getAppendedContent(previousMessage: string, currentMessage: string): string {
|
|
|
+ // 前回のメッセージから増分部分のみを返す
|
|
|
+ return currentMessage.slice(previousMessage.length);
|
|
|
+ }
|
|
|
+ ```
|
|
|
|
|
|
### 3. エラー耐性とリソース管理
|
|
|
|
Yuki Takei