AI Coding Assistant Lingma:チャットのコンテキストとしてナレッジベースを構築および管理する

この機能を使用できるユーザー

• エディション: Lingma Enterprise Dedicated

• ロール: 組織内の Lingma 管理者とグローバル管理者

アップロードされたファイルを検索拡張ナレッジデータに変換できます。開始する前に、ファイルベースのナレッジデータを準備するための原則と方法に従う必要があります。

ファイル形式

• 一度に最大 10 個のファイルをアップロードできます。

• サポートされている形式は、pdf、docx、txt、markdown、csv です。

• 各ファイルは 5 MB 以下である必要があります。

• ファイル名は 200 文字以下である必要があります。 UFT-8 および GBK でエンコードされたファイルのみがサポートされています。

• 構造化ドキュメントを使用して、情報を見つけやすいようにします。

単一ファイル

単一のファイルをアップロードする場合は、ファイル名、タイトル、形式、およびコンテンツのルールに従っているかどうかを確認します。詳細と例については、以下を参照してください。

ファイルの種類と命名

• 種類: Markdown 形式が推奨されます。 Word や PDF と比較して、Markdown 形式はファイル処理に適しています。

• エンコード: 文字の互換性を最大限に高めるために、UTF-8 を使用してください。

• ファイルの命名: 名前は短く明確にし、モデルが簡単に理解できるようにします。不明瞭な略語、数字、記号は使用しないでください。次に例を示します。

  やってはいけないこと	やるべきこと
  一般的すぎる、類似しすぎている、または混乱を招く可能性のある名前は使用しないでください。 コーディング仕様 セキュリティ仕様 1 セキュリティ仕様 2 SR3	ファイルの内容と目的を指定する名前を使用します。 Java 言語プログラミング仕様 API データセキュリティ管理仕様 クラウドアカウントセキュリティ管理仕様

ファイル構造

• 階層構造: 見出しを使用してファイル内のコンテンツを整理します。モデルが理解しやすいように、各固有名詞を独自の行に記述します。

• すべてのレベルのタイトル: すべてのレベルのタイトルは明確かつ簡潔で、簡単に区別できる必要があります。不明瞭な略語、数字、記号は使用しないでください。ファイルのキーワードをリストしないでください。問題が発生する可能性があります。

  やってはいけないこと

  やるべきこと

  AccessKey ペアの安全な使用に関する仕様 [目次] キーワード: AK、セキュリティ仕様、AccessKey I. 定義 AccessKey ペアは、認証に使用されるキーペアです。各 AccessKey ペアは、AccessKey ID と AccessKey シークレットで構成されます。 AccessKey ペアを使用すると、API リクエストを送信することでシステムサービスに安全にアクセスできます。このファイルは、AccessKey ペアの使用規則を明確にし、システムのセキュリティと安定性を確保することを目的としています。 AccessKey ID は、ユーザーの ID を検証するために使用されます。 AccessKey シークレットは、署名文字列を暗号化し、リクエストの一意性と否認防止を確保するために使用されます。 2. 使用上の注意 AccessKey シークレットの機密性を確保し、権限のない第三者に開示しないでください。最小権限の原則に従って API 操作の権限を付与し、タスクの完了に必要な権限のみを付与します。 AccessKey シークレットは 90 日ごとに変更してください。 AccessKey ペアの使用状況を記録し、使用ログを定期的に確認して異常な動作を排除し、不要な権限を取り消します。 3. セキュリティ対策 AccessKey ペアのセキュリティを確保するために、次の簡略化されたセキュリティ対策を実施しています。本番環境では、ハードコーディングを防ぐために、環境変数を使用して AccessKey ペアを優先的に保存します。コードに直接公開されないように、構成管理システムを使用して AccessKey ペアを一元管理します。同時に、ログをフィルタリングして、AccessKey シークレットが記録されないようにします。権限を定期的に確認して、AccessKey ペアに必要な最小限の権限のみが付与されていることを確認します。さらに、異常検出メカニズムを確立して、疑わしい AccessKey 使用アクティビティを迅速に特定して対応します。これらの対策を組み合わせることで、AccessKey ペアの安全で合理的な使用が保証されます。 4. API 呼び出し例 ● 例 1 Node.js で API 呼び出しに AccessKey ペアを使用する: Node.js では、Axios ライブラリを使用して API リクエストを送信し、リクエストヘッダーに AccessKey ペアを含めることができます。次のサンプルコードは、署名認証に AccessKey ペアを使用する API リクエストを示しています。 [サンプルコードブロック] ● 例 2 Python で API 呼び出しに AccessKey ペアを使用する: Python では、requests ライブラリを使用して AccessKey ペアを含む API リクエストを送信できます。次のサンプルコードは、リクエストを構築して署名を追加する方法を示しています。 [サンプルコードブロック]

  AccessKey ペアの安全な使用に関する仕様 /* 邪魔な要素を削除する: ファイルの先頭にあるコンテンツやキーワードなど、リコールする必要のない情報を削除します。 専門用語の説明: 専門用語とその説明をエントリの形式でリストして、モデルがより適切にクエリして理解できるようにします。 */ I. 定義 ● AccessKey ペア: AccessKey ペアは、認証に使用されるキーペアです。各 AccessKey ペアは、AccessKey ID と AccessKey シークレットで構成されます。 AccessKey ペアを使用すると、API リクエストを送信することでシステムサービスに安全にアクセスできます。 ● AccessKey ID: AccessKey ID は、ユーザーの ID を検証するために使用されます。 ● AccessKey シークレット: AccessKey シークレットは、署名文字列を暗号化し、リクエストの一意性と否認防止を確保するために使用されます。 /* 大きな段落文を使用しないでください。箇条書き文を使用すると、モデルが理解しやすくなります。 */ 2. 使用上の注意 ● 機密性: AccessKey シークレットは厳重に機密にして、権限のない第三者に開示しないでください。 ● 最小権限の原則: 最小権限の原則に従って API 操作の権限を付与し、タスクの完了に必要な権限のみを付与します。 ● 定期的なローテーション: AccessKey シークレットは 90 日ごとに変更することをお勧めします。 ● 監視と監査: AccessKey ペアの使用状況を記録し、使用ログを定期的に確認して異常な動作を排除します。 ● 適時の失効: AccessKey ペアを使用する必要がなくなった場合は、適時に権限を取り消します。 3. セキュリティ対策 ● 環境変数: 本番環境では、ハードコーディングではなく環境変数を使用して AccessKey ペアを保存します。 ● 構成管理: 構成管理システムを使用して AccessKey ペアを管理し、コードに直接公開されないようにします。 ● ログフィルタリング: AccessKey シークレットがログエントリに表示されないようにします。 ● 権限レビュー: AccessKey ペアの権限設定を定期的にチェックして、最小権限の原則に準拠していることを確認します。 ● 異常検出: 異常検出メカニズムを確立して、疑わしいアクティビティを適時に検出して処理します。 /* API 呼び出し例のタイトルが不明確です。例 1 と例 2 をより具体的な名前に変更します。 */ 4. API 呼び出し例 ● Node.js で API 呼び出しに AccessKey ペアを使用する例 Node.js では、Axios ライブラリを使用して API リクエストを送信し、リクエストヘッダーに AccessKey ペアを含めることができます。次のサンプルコードは、署名認証に AccessKey ペアを使用する API リクエストを示しています。 [サンプルコードブロック] ● Python で API 呼び出しに AccessKey ペアを使用する例 Python では、requests ライブラリを使用して AccessKey ペアを含む API リクエストを送信できます。次のサンプルコードは、リクエストを構築して署名を追加する方法を示しています。 [サンプルコードブロック]

ファイルのセクションと段落

• 関連するコンテンツを同じ段落またはセクションにまとめて、情報を明確かつ関連付けておきます。

• 重要な詳細は省略したり、略語を使用したりしないでください。コンテンツが同じ場合は、「上記と同じ」と言う代わりに繰り返します。具体的な内容を記述してください。

• 意味のない空白行は使用しないでください。

• 箇条書きと適切なインデントを使用して、コンテンツを理解しやすくします。

  やってはいけないこと	やるべきこと
  意味のない空白行を避ける 6.3 メソッドレシーバー レシーバーの名前は、クラス名の最初の小文字にちなんで付けることをお勧めします。 関数が 20 行を超える場合は、レシーバーの名前に単一文字を使用しないでください。 「me」、「this」、「self」などの紛らわしい名前は使用しないでください。	意味のない空白行を削除する 6.3 メソッドレシーバー ● レシーバーの名前は、クラス名の最初の小文字にちなんで付けることをお勧めします。 ● 関数が 20 行を超える場合は、レシーバーの名前に単一文字を使用しないでください。 ● 「me」、「this」、「self」などの紛らわしい名前は使用しないでください。
  「上記と同じ」、略語、または代名詞を使用しないでください。 4.6 Go のインターフェース命名規則 命名規則は構造体と同じです。 または 3.2 命名規則と構造体命名規則と同じ	具体的な内容を明確に記述して説明します。 4.6 Go のインターフェース命名規則 ● CamelCase 命名方法を使用します。アクセスコントロールの要件に従って、最初の文字に大文字または小文字を使用します。 ● Customer、WikiPage、Account、AddressParser など、名詞または名詞句を構造体名として使用します。動詞は使用しないでください。 ● Data や Info など、意味が広すぎる構造体名は使用しないでください。

画像、表、マルチメディアコンテンツ

ファイルの段落で画像や表を使用する場合は、次のヒントを参考にしてください。

• ファイル内の表の処理:

  • 表形式の要件:

    • 最初の行を表ヘッダーに使用します。

    • 最初の行に表名を入れないでください。

  • 表構造の説明: 表構造に特別なルールはありません。コンテンツに基づいて列と行を設計できます。

  • スタイルを簡潔にする: 背景色やフォントスタイルなどの余分な書式設定を削除します。明確な表の線とデフォルトのスタイルを使用します。

  • 追加の注意事項:

    • Enterprise Dedicated Edition では、Lingma には表データの精度を維持するための高度な機能があります。

• ファイル内の画像の処理:

  • 画像の代わりにテキストを使用する: テキストを使用して情報を共有します。画像に少量のテキストが含まれていて、重要な詳細が含まれている場合は、情報をテキストとして記述します。

  • イラストを追加する: すべての重要な図に明確なイラストを含めて、主題を説明しやすくします。

• その他:

  • 特殊文字: 解析の問題を避けるために、絵文字やその他の特殊文字は使用しないでください。

  • ヘッダー、フッター、ウォーターマーク、注釈: これらは視界を遮る可能性があるため、使用しないでください。

  • ファイルの背景: ユーザーエクスペリエンスに問題が発生する可能性があるため、背景を使用しないでください。

  • 均一なテキストの向き: すべてのテキストが同じ方向を向いていることを確認します。

  • オーディオとビデオ: オーディオやビデオを含めないでください。

さまざまな形式のファイル

• Markdown: Markdown 形式を使用することをお勧めします。

• Word:

  • 更新された形式を使用する: Word バージョン 2007 以降を使用します。

  • グローバルスタイルを使用する: グローバル見出しと段落スタイルを使用します。

  • 文字スタイルを使用しない: 特殊なフォントの書式設定、罫線、網掛けなどの文字スタイルは使用しないでください。

  • 段落スタイルを使用する: 段落スタイルを使用して、書式設定の一貫性を保ちます。

• PDF:

  • 画像を使用しない: 画像を PDF ファイルに直接変換しないでください。画像の重要な情報をテキストとして記述し、このトピックで説明されているファイル要件に従ってください。

  • 圧縮ファイルを含めない: ファイルに圧縮ファイルが含まれていないことを確認します。

  • 単一列レイアウトを維持する: 1 列レイアウトを使用して、コンテンツが正しく解析されるようにします。

• CSV:

  • 画像を使用しない: これにより、テキストを検索できるようになります。

  • 圧縮ファイルを埋め込まない: ファイルに圧縮ファイルを埋め込まないでください。

  • 最初の行を表ヘッダーとして使用する: 最初の行を表ヘッダーとして使用します。表の最初の行に表名を入れないでください。

    注意事項:

    • 推奨: よくある質問 (FAQ) に質問と回答のペアを保存します。検索精度を向上させるには、次のことを確認してください。

      • 質問が明確に表現されている。

      • 回答が簡潔で理解しやすい。

      • 用語がユーザーになじみがある。

      • キーワードが強調表示されている。

    • 複雑なデータテーブルを CSV でアップロードしないでください。処理に非常に時間がかかり、失敗する可能性があります。

複数ファイル

ドキュメントを作成するときは、それ自体で理解でき、集約され、一貫性があり、包括的であることを確認してください。これにより、ユーザーは必要なものをすばやく見つけることができ、ドキュメントの有用性が向上します。ドキュメントを整理して扱いやすくするためのヒントを次に示します。

ナレッジ独立性: 各ドキュメントには、必要なすべての情報が単独で含まれている必要があります。

• 異なるドキュメントで情報を繰り返さないでください。

• 各ファイルが、それ自体で完全かつ正確な情報を提供する、自己完結型のナレッジユニットであることを確認します。

ナレッジ集約: 関連するすべての情報を同じトピックに集約します。

• これにより、関連するトピックがまとめて保持され、理解しやすくなります。

一貫性: 異なるファイルの類似情報が一貫性があり、標準化されていることを確認します。

• すべてのドキュメントで同じスタイルと言葉を使用します。

• スタイルガイドと用語集を作成して従うことで、一貫性を確保します。

包括性: すべてのドキュメントが完全で、最新で、正確であることを確認します。

• ナレッジベースがすべての一般的な質問に明確に答えられることを確認します。 API について記述する場合は、重要なすべての部分と詳細を含めます。

• 定期的にチェックと更新を行い、不足している情報を追加し、古いコンテンツを削除します。

上記のガイドラインは、企業ナレッジベース管理者が高品質の製品ドキュメントを作成し、ユーザーの満足度とエクスペリエンスを向上させるのに役立ちます。ドキュメントを体系的に整理および管理することで、情報の正確性、使いやすさ、および整合性が確保され、ユーザーにより信頼性の高いナレッジリソースベースが提供されます。