Mycroft-core: اقتراح موحد لإضافة البيانات الوصفية إلى ملفات الحوار

ping: JarbasAl ، KathyReid ، ftyers في حال فاتني شيء أو

يجب أن أعترف أيضًا بالبدائل الواضحة:

1) اقرأ الأسطر في بنية البيانات ، ممثلة للسمات المختلفة ، ثم اضغط على ذلك بـ random.choice(lines where all(attribute in line.attributes for attribute in desired_attributes)) . يقلل هذا بشكل كبير من الحد الأقصى لوقت التشغيل ، ولكنه يزيد بشكل كبير من الحد الأدنى لوقت التشغيل.
2) قم بتحليل الملف ، وتجاهل الأسطر غير الصالحة أثناء تقدمنا ​​، وإعادة السطر الأول الذي يفي بجميع المعايير. نفس الحد الأدنى الافتراضي لوقت التشغيل - حلقة واحدة على سطر واحد - ولكن الحد الأدنى لوقت التشغيل لسمات معينة ، في حالة ملفات الحوار جيدة التنظيم ، يصبح 1 + عدد الأسطر بدون تلك السمات التي تظهر مسبقًا في الملف. في هذه الحالة ، من المرجح أن يكون سحب الإدخالات العشوائية أكثر أداءً في المتوسط . (تحرير: إنه يحد أيضًا من عدد الأسطر الفريدة التي يمكن أن تلبي مجموعة معينة من المعايير ؛ أي ما يزيد عن max_recent_phrases لن يتم الوصول إليه.)
3) تخزين الملفات مؤقتًا في المقام الأول. اعتبارًا من اليوم ، سيكون هذا جيدًا. مع نمو مهارة الريبو ، يصبح من الأسهل والأكثر بروزًا التهام ذاكرة RPi المحدودة. في الوقت الحالي ، لا يمتلك معظمنا سوى بضع عشرات من ملفات الحوار على أجهزة الكمبيوتر الخاصة بنا ، ولكن يومًا ما (نأمل!) سيكون لدينا جميعًا المئات أو الآلاف. أو ربما لا ، إذا دخل شكل آخر من أشكال معالجة اللغة إلى المزيج ، لكنني لا أريد كتابة كود على افتراض أنه يمكن أن يمتص لأنه سيكون عفا عليه الزمن. هكذا أصبحت السنوات المكونة من رقمين مشكلة حقبة لأنفسهم ؛)

يبدو مثيرة جدا للاهتمام. بعض الأفكار بعد القراءة (وبما أنني لم أقرأ المناقشات الفعلية ، فقد أكون خارج القاعدة تمامًا)

هل فكرت في إنشاء تنسيق ملف جديد لملفات الحوار باستخدام json أو yaml لتحديد مربعات الحوار وبيانات التعريف. ستكون الفائدة هي أننا سنستخدم تنسيقًا قياسيًا ولا نحتاج إلى إضافة رمز إضافي لتحليل المتغيرات. سيسهل هذا أيضًا التمييز بين نمط حوار بسيط قديم وأسلوب حوار جديد. وسيكون من التافه إنشاء أداة صغيرة للمساعدة في كتابة ملفات الحوار التي تسمح بتحديد السمات وما إلى ذلك.

هل يمكن القيام ببعض الأشياء في وقت التحميل مثل إسقاط خطوط الجنس غير المتطابقة؟ قد يتطلب ذلك إعادة تحميل الحوارات إذا تم تغيير جنس النظام ...

شيء واحد يجب مراعاته أيضًا هو عملية الترجمة. كيف سيتعين تغيير البرامج النصية التي تولد البيانات لخادم الترجمة للتعامل مع هذا الأمر؟ يجب الاحتفاظ بأصوات مثل البيانات الوصفية في السلسلة أو يحتاج المترجمون إلى أن يكونوا على دراية بالتفاصيل المحيطة بالسلسلة ...

إعادة: إنشاء شكل جديد ، كان الهدف هو تجنب كسر التغييرات. وُلد هذا الاقتراح بعد مشاركة جارباس مع بعض المقترحات المتضاربة لاستخدام أسماء الملفات كبيانات وصفية.

رد: إسقاط أسطر غير متطابقة في وقت التحميل ، أنا لست معارضًا ، لكننا سنحتاج إلى tmpfile لكل ملف حوار ، أليس كذلك؟

لم أكن أدرك أنه كانت هناك أي ترجمة آلية ، لكنني أرجع للآخرين.

حسنًا ، إن الاحتفاظ بالبيانات الوصفية من هذا القبيل سيكون نوعًا من التغيير المفاجئ ، فالإصدارات القديمة من Mycroft-core ستفسر البيانات الوصفية على أنها حوار عادي وسنضطر إلى جعل هذا إصدارًا رئيسيًا فقط (لم يمض وقت طويل حتى 20.02 على الرغم من ذلك لذلك من المحتمل أن يكون ذلك جيدًا). لكن الحصول على تنسيق ملف جديد يعيش جنبًا إلى جنب مع القديم قد يكون أفضل ... ما زلنا ندعم التنسيق القديم ونحمل ملفات .dialog كما نفعل الآن ، باستخدام الإعدادات الافتراضية للبيانات الوصفية. بينما يتم تحليل التنسيق الجديد (.dyaml أو شيء ما) باستخدام الكود الأحدث.

لا أعتقد أننا سنحتاج إلى ملفات tmp ، فقط قم بتحميلها في الذاكرة كما نفعل الآن. إذا أصبحت الذاكرة مشكلة يمكننا القيام بها في ضغط الذاكرة من نوع ما. (ولكن لأكون صادقًا ، هذا ليس المكان الأول الذي سأقوم فيه بالتحسين لتحسين استهلاك الذاكرة في mycroft-core)

لا توجد أي ترجمة آلية ، نحن فقط قرود على آلات كاتبة نقوم بالترجمة الفعلية ولكن هناك نصوص تنقل الحوار والمفردات من وإلى نظام الترجمة.

حسنًا ، إن الاحتفاظ بالبيانات الوصفية من هذا القبيل سيكون نوعًا من التغيير المفاجئ ، فالإصدارات القديمة من Mycroft-core ستفسر البيانات الوصفية على أنها حوار عادي وسنضطر إلى جعل هذا إصدارًا رئيسيًا فقط (لم يمض وقت طويل حتى 20.02 على الرغم من ذلك لذلك من المحتمل أن يكون ذلك جيدًا

الى حد كبير! لم أفكر في الإصدارات القديمة من Mycroft-core لتحليل ملفات .dialog الجديدة. في الواقع ، عندما كنت أفكر في كسر التغييرات ، كنت أفكر في توافق النظام الجديد مع ملفات الحوار القديمة ، التي تفتقر إلى البيانات الوصفية.

قد يكون وجود تنسيق ملف جديد جنبًا إلى جنب مع القديم أفضل ... ما زلنا ندعم التنسيق القديم ونحمل ملفات .dialog كما نفعل الآن ، باستخدام الإعدادات الافتراضية للبيانات الوصفية. بينما يتم تحليل التنسيق الجديد (.dyaml أو شيء ما) باستخدام الكود الأحدث.

لا يمكن أن يضر الأداء ، ولكن ، اقتبس من جارباس مرة أخرى ،

هناك شيء آخر يعجبني في هذا النهج وهو أنه من السهل للغاية أن يستفيد القادمون الجدد ، أحد أهدافنا هو الذكاء الاصطناعي للجميع ، بما في ذلك الأشخاص غير التقنيين

imo ، يجب أن ينخفض ​​الأمر إلى ما هو أسهل بالنسبة للأشخاص للتغلب على رؤوسهم إذا كانت مهارتهم الأولى من Mycroft هي أول تجربة تشفير حقيقية لهم. يعد كل من json و yaml رائعين في ما يفعلونه ، ولكن هناك الكثير من القواعد اللغوية التي تدعو للقلق.

أوافق على أننا بحاجة إلى جعله بسيطًا قدر الإمكان والحفاظ على التنسيق الأساسي الأصلي حوله بالإضافة إلى عقار البوابة. يمكن أن يبدو تطبيق yaml كما يلي:

this is a dialog:
  sarcasm: 10
  speaker_gender: male
  listener_gender: female
  extra: douglas adams fan
this is a second dialog:
  sarcasm: 0
  speaker_gender: male

مما أدى إلى هذا الديكت بيثون

التي لن تكون أكثر من مجرد ^ الفصل مع المسافات. قد تكون المشكلات عند استخدام النقطتين وعلامات الاقتباس.

بالنسبة لي ، يبدو أن تنسيق yaml الجديد هو أنظف طريقة لاعتماد هذه البيانات الوصفية. لن أكرر ما قيل ، لكنني اعتقدت أيضًا أنه نظرًا لأننا اعتمدنا yaml لجوانب أخرى من المهارات - الإعدادات والبيان ، فهو بالفعل تنسيق سيحتاجه المؤلفون بالفعل ، لذلك يحافظ هذا على مزيد من الاتساق في هذا الصدد.

اقتباسات من محادثة مع forslund

أتساءل قليلاً عن كيفية جعل ذلك أكثر صداقة للإنسان ، أعتقد أن قائمة بإدخالات من هذا النوع سيكون من السهل فهمها
{"utterance": "XXX", "atitude": "sarcastic", "gender": "male", "weight": 0.3}

عند التحميل ، سيتم تصفيته حسب الجنس ، والعودة إلى اللغة الافتراضية / ذكر لأن هذا هو صوت mycrot الافتراضي

تحرير: للتوضيح ، إذا كان الجنس مفقودًا ، فإننا نفترض أن الجنس == افتراضي ، ولا توجد حالة لم يتم فيها تعيين الجنس ، ومع ذلك يمكن تحديد / تعديل بعض قيمة "بلا جنس"

ثم يتم تصفيتها حسب الموقف وفقًا لإثبات مفهوم ChanceNCounter ، وفي النهاية سيتم أخذ الوزن في الاعتبار ليكون اختيار بعض خطوط الحوار أكثر احتمالًا من غيرها

شككي الوحيد في هذه المرحلة هو كيفية التعامل مع التغيير السابق لتجنب تكرار الحوارات ، أعتقد أن الوزن نوعًا ما يقلل من هذه الوظيفة

id يقول للاحتفاظ بها لملفات .dialog وتجاهلها ببساطة بالتنسيق الجديد

وما الامتداد الذي يجب أن نستخدمه؟ لا أحب .json كونها في مجلد الإعدادات المحلية ، فهذا أمر محير
.dialog.json ربما؟

أنا شخصياً أفضل json على yaml ، سيكون من الجيد سماع تفضيلات غير المطورين

أنا أعارض ملفات yaml بشكل عام. أود أيضًا أن أكرر طلبي بأن تلتزم Mycroft بقائمة قياسية قابلة للتحقق من أزواج Feature=Value للمعلومات اللغوية وليس تكوين فئات مخصصة . أفضّل اقتراح JarbasAI ، لكن لاحظ أن استخدام .json أقل قابلية للكتابة من قبل الإنسان بكثير من الاقتراح الذي قدمته ChanceNCounter في الأصل. لاحظ أنه في التبعيات العامة يمكن الاشتراك في الميزات مثل Gender[speaker]=Masc و Gender[listener]=Fem .

هذا المثال يلخص الفئات التي نحتاجها ، كل شيء آخر هو إضافة بدون حالة استخدام واضحة حتى الآن
{"utterance": "XXX", "atitude": "sarcastic", "gender": "male", "weight": 0.3}

ملاحظة: الجنس == جنس الجهاز

ftyers بينما تعجبني الطريقة التي تفكر بها ، يبدو أنها لا تحل

JarbasAI لا أرى كيف أن وجود أزواج Feature=Value متناسقة للمعلومات اللغوية هو قيد مصطنع ، إنه أسلوب ترميز ومشكلة توافق. أنا لا أقول إن الناس لا ينبغي أن يكونوا قادرين على تكوين فئاتهم وقيمهم التعسفية. لكن تلك التي تشير إلى المعلومات اللغوية يجب أن تكون متسقة وموحدة.

سأفعلها:

 {"Utt": "XXX", "Attitude": "Sarcastic", "Gender[device]": "Masc", "Gender[listener]": "Fem", "Weight": 0.3}

سأكون سعيدًا أيضًا بـ:

 {"Utt": "XXX", "Features": ["Attitude=Sarcastic", "Gender[device]=Masc", "Gender[listener]=Fem"], "Weight": 0.3}

القيمة اللغوية الوحيدة هنا هي قيمة الجنس ، كل شيء آخر مرتبط بالشخصية أكثر من اللغة ، هل يمكنك مشاركة بعض الروابط ذات الصلة لأزواج Feature=Value ؟

شككي الوحيد في هذه المرحلة هو كيفية التعامل مع التغيير السابق لتجنب تكرار الحوارات ، أعتقد أن الوزن نوعًا ما يقلل من هذه الوظيفة

لست متأكد. لا أعتقد أننا نريد تقييم كل عبارة ، أو حتى معظم العبارات ، ولكن سيكون من الجيد الحفاظ على المهارات الصغيرة البسيطة من تكرار الحوار مرارًا وتكرارًا. لقد قمت بالفعل بتحميل مهارة واحدة لا تتكون من أي شيء سوى لغة معيارية ، وليس هناك سبب يجعل Mycroft يفضل "حسنًا" على "أيًا كان ما تقوله" عندما تخبره بذلك.

كنت أفكر في الأمر بعد أن علقت سابقًا ، واعتقدت أن هذا قد ينجح:

cooldown_phrases = {"easter egg": 1, "another thing": 3}
recent_phrases = [3_ago, 2_ago, 1_ago]
...
def render():
  ...
  locked_phrases = recent_phrases + cooldown_phrases.keys()

ثم استخدم locked_phrases بدلاً من recent_phrases في المنطق الحالي.

من الجدير بالذكر أيضًا أن أوزان العبارات الفردية هي بالتأكيد الجزء الأقل أهمية هنا = P

JarbasAI من هذه القائمة ، من المحتمل أن تكون الميزات ذات الصلة هي:

• NounClass: في اللغات التي تحتوي على NounClass بدلاً من Gender ، مثل لغات Bantu
• الرسوم المتحركة: في اللغات التي تميز بين الجماد وغير الحي ، هل Mycroft هو حي أم غير حي؟
• الأدب: في اللغات ذات الفروق المؤدبة ، أي واحدة يجب أن تُستخدم؟
• Clusivity: في اللغات التي تحتوي على صيغ الجمع الشاملة / الحصرية ، هل ينبغي استخدام شامل أم حصري؟
• الرقم: هل نتحدث عن مخاطبة شخص واحد أم أكثر؟
• واضح: ما نوع المعلومات التي ننقلها؟ أول يد أم غير مباشر؟ -- أو غيرها؟

نقطتي هي أن هذا شيء سهل الاستخدام إلى حد ما ، ولا يتطلب المزيد من البرمجة ، وهو قابل للتوسيع وشامل ومدروس من حيث التنوع اللغوي.

أيضًا ، إذا كنا ننتقل إلى الترميز ، فأنا أريد +1 yaml. أفضل JSON بنفسي ، لكن المطورين غير (اقرأ: الجدد) سيكونون أكثر راحة مع البيانات المحددة بمسافات بيضاء ، وقواميس yaml عبارة عن مسافات بيضاء بنسبة 100٪.

بالطبع ، إذا كانوا يتعلمون تطوير المهارات ، فسوف يحتاجون إلى تعلم جميع أنواع بناء الجملة الأكثر تعقيدًا من JSON ، ولكنه شرط أساسي آخر لتبليل أقدامهم. سأحب ذلك لو كانت مهارات Mycroft هي أول غزوة للمطور الناشئ. في الوقت الحالي ، يمكنك تطوير مهارة لا تحتاج إلى إعدادات ، ولكن من الصعب تطوير مهارة لا تحتاج إلى حوار.

ChanceNCounter تستخدم بعض اللغات مسافة بيضاء لفصل المقاطع بدلاً من الكلمات ، على سبيل المثال الفيتنامية. هل سيكون من الضروري عندئذٍ ابتكار متسللين لتمثيل الفيتناميين؟ كيف يمكن أن يعمل yaml للفيتناميين؟

JarbasAI من هذه القائمة ، من المحتمل أن تكون الميزات ذات الصلة هي:

* NounClass: In languages with NounClass instead of Gender, e.g. Bantu languages

* Animacy: In languages with a distinction between animate and inanimate, is Mycroft animate or inanimate?

* Polite: In languages with Politeness distinctions, which one should be used?

* Clusivity: In languages with inclusive/exclusive plurals, should inclusive or exclusive be used?

* Number: Are we talking about addressing one person or many?

* Evident: What kind of information are we transmitting? First hand or non-first hand? -- or other?

نقطتي هي أن هذا شيء سهل الاستخدام إلى حد ما ، ولا يتطلب المزيد من البرمجة ، وهو قابل للتوسيع وشامل ومدروس من حيث التنوع اللغوي.

هذا يجعل الأمور أكثر وضوحًا ، إنه يعقد بعض الشيء اختيار الحوار ، أعتقد أننا بحاجة إلى تحديد القيم التي نريد حسابها في الجوهر ، وأي القيم يجب أن يستهلكها المطورون فقط ، في حين أن كل هذه القيم جيدة جدًا ، أخذهم جميعًا في الاعتبار للاختيار هو أمر غير عملي ، فقط لأننا لا نملك آلية حتى الآن لمعرفة كيفية استخدام هؤلاء

اللباقة هي أيضًا مناسبة جدًا للبرتغالية

ChanceNCounter تستخدم بعض اللغات مسافة بيضاء لفصل المقاطع بدلاً من الكلمات ، على سبيل المثال الفيتنامية. هل سيكون من الضروري عندئذٍ ابتكار متسللين لتمثيل الفيتناميين؟ كيف يمكن أن يعمل yaml للفيتناميين؟

لهذه الأغراض ، المسافة البيضاء البادئة فقط هي المهمة وفواصل الأسطر.

ChanceNCounter فالمسافة البيضاء لا تفصل القيم؟ كما في مثالforslund ؟

هذا يجعل الأمور أكثر وضوحًا ، إنه يعقد بعض الشيء اختيار الحوار ، أعتقد أننا بحاجة إلى تحديد القيم التي نريد حسابها في الجوهر ، وأي القيم يجب أن يستهلكها المطورون فقط ، في حين أن كل هذه القيم جيدة جدًا ، أخذهم جميعًا في الاعتبار للاختيار هو أمر غير عملي ، فقط لأننا لا نملك آلية حتى الآن لمعرفة كيفية استخدام هؤلاء

اللباقة هي أيضًا مناسبة جدًا للبرتغالية

ألا يمكن استخدام شيء مثل الحد الأقصى للتقاطع بين أزواج Feature=Value المحددة في الجهاز والأزواج Feature=Value في الحوار للاختيار بين الأقوال المتنافسة؟ - بالإضافة إلى الوزن الذي ذكرته.

ChanceNCounter فالمسافة البيضاء لا تفصل القيم؟ كما في مثالforslund ؟

أعتقد أن هذه قيمة واحدة ، {"extra": "douglas adams fan"}

أنا أفضل YAML أعلى من JSON لأنني أستخدمه كثيرًا مع الملفات غير المؤكدة ، و docker-compose ، وهكذا ، لكن يجب أن أعترف أن YAML صعب للغاية في البداية وأكثر عرضة للخطأ.

تمتلك YAML عددًا كبيرًا من الميزات الرائعة مثل المراسي ، والتسلسل ، والتعليقات ، والهياكل العودية ، أو حتى تضمين JSON داخل YAML ...

معرف بدلاً من ذلك فشل json بصوت عالٍ من أخطاء yaml الانزلاق بصمت

@ ftyers هل أفهم بشكل صحيح أن هذه الميزات موجودة على مستوى الكلمات ، ولست متأكدًا مما إذا كانت

تحرير: مرة أخرى ، ترتبط هذه البيانات الوصفية في الغالب بالشخصية ، وليس السمات اللغوية بالضبط

هناك شيء آخر يعجبني في json وهو المراسلات المباشرة إلى python dest ، وبهذه الطريقة يمكن بسهولة تحميل الملفات للتعامل مع الحوار المخصص دون مفاجآت (وليس باستخدام self.speak_dialog)

في العلاقات العامة اللاحقة ، يمكننا التفكير أيضًا في السماح للمطورين بالتأثير على اختيار الحوار من خلال بعض الحجج الإضافية في talk_dialog

(آسف للنشر الثلاثي)

JarbasAI يمكنهم أن يطبقوا على مستوى الكلام أيضًا ، وهو ما لا تمثله ملفات الحوار؟

العلاقات العامة ذات الصلة التي أغلقتها https://github.com/MycroftAI/mycroft-core/pull/1874

هذه المناقشة تحل محل النهج في ذلك العلاقات العامة ، فقط التعليق للحفاظ على الرابط بين العلاقات العامة هنا