A fridge is indeed a valid payment device: one of the client's payment rulebooks lists fridges, cufflinks, handbags and clothes among the devices you can pay through, and the built assistant answers such questions with citations to the rulebook.
Azure Table Storage is a Microsoft Azure storage service identified in the video as the simple logging solution for a retrieval-augmented generation assistant. In that system, it records questions, tool calls, answers, feedback, and interaction events such as source clicks and answer copies.
A retrieval-augmented chat assistant built for an anonymous Belgian payments client. It answers questions from a corpus of roughly 270 PDF rulebooks spanning thousands of pages, preserving section paths and chunk order so larger passages can be reconstructed and converting tables to CSV while retaining relationships between headings and values. Its retrieval pipeline combines dense embeddings with BM25 using reciprocal rank fusion. A serving agent can widen retrieval through four tools, progressing from search results to sections, full documents, and multiple rulebooks while applying context limits to prevent oversized documents from dominating the answer. Responses are streamed as Markdown with separate source cards and include section and page citations. The system was used internally by dozens of users and evaluated with traces, citation checks, and Promptfoo.
Promptfoo is an AI application security and evaluation platform for testing prompts, RAG systems, agents, models, and guardrails. It can run evaluation tests with LLM-judge scoring against defined criteria and verify citations against source documents; in the described payment-rules assistant, it was used to assess answer quality and investigate apparent regressions against the underlying evidence. Its security workflows simulate context-aware attacks, including prompt injection, jailbreaks, data leaks, business-rule violations, insecure agent tool use, and toxic-content generation, and can run in development and CI/CD workflows. Promptfoo also provides automated red teaming, code scanning, MCP security testing, remediation guidance, and continuous monitoring, with integrations for AI applications, agent frameworks, CI/CD systems, and on-premises or cloud deployments.
Pydantic is a Python data-validation library that uses type hints to parse, validate, and serialize data. In the cited agent system, it defines structured UI components, including source cards and checklists, that the agent can expose. The Pydantic stack also includes Pydantic AI for building type-safe production agents and Pydantic Logfire for monitoring agent behavior, LLM calls, costs, and applications.
Qdrant is an open-source vector search engine written in Rust for storing vectors with JSON payloads and querying them through an API. It performs vector similarity search using HNSW traversal, applies metadata filters during retrieval, and supports dense, sparse, hybrid, and multivector search, along with reranking methods such as ColBERT and maximum marginal relevance. Qdrant can run on-premises, in hybrid or private deployments, at the edge through Qdrant Edge, or as the fully managed Qdrant Cloud service. The project is used for AI retrieval and supports synchronization between local or edge deployments and cloud-based memory.
Searchable transcript of Your Fridge Is a Valid Payment Device — Eleonora Drykina & Nina Žižakić, In The Pocket — AI Engineer (25:02). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by AI Engineer. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:00 مرحبًا بكم في حديثنا بعنوان "ثلاجتك هي وسيلة دفع معتمدة: نظام RAG غير اعتيادي في بيئة الإنتاج". دعوني أبدأ بشرح هذا العنوان . هذه صفحة من إحدى كراسات القواعد الخاصة بعملائنا. إنها واحدة من الوثائق العديدة التي بنينا نظام RAG الخاص بنا حولها. قد تتوقع وثائق مالية جافة، وهذا هو الحال في معظمها بالفعل. لكن هناك أيضًا بعض التفاصيل الممتعة والمثيرة. على سبيل المثال، هذه الصفحة التي تعرض قائمة بالأجهزة التي يمكنك الدفع من خلالها .
00:42 هناك أشياء متوقعة مثل الهواتف والبطاقات، ولكن هناك أيضًا أشياء مبتكرة مثل أزرار الأكمام، وحقيبة اليد، والملابس، وحتى الثلاجة. لقد وجدت أنه من الرائع حقًا العثور على حقيقة ممتعة كهذه في وثائق كنت أتوقع أن تكون مملة للغاية. لنقدم أنفسنا. هذه هي الصورة الوحيدة التي لدينا لنا معًا. نحن لا نرتدي سماعات الواقع الممتد عادةً، لكن في ذلك اليوم في المكتب كنا نجرب جميع أنواع الأدوات الممتعة.
01:21 أنا نينا. أنا مهندسة ذكاء اصطناعي. >> وأنا إليونورا. أنا مهندسة منتجات. نحن نعمل في شركة "In The Pocket" ، وهو استوديو للمنتجات الرقمية يقع مقره الرئيسي في بلجيكا. نحن نساعد عملائنا في التحول نحو الذكاء الاصطناعي وتطوير البرمجيات المخصصة. >> واليوم سنتحدث عن مشروع RAG الذي بنيناه لأحد عملائنا، وهي شركة تكنولوجيا مالية بلجيكية كبيرة. ستبقى الشركة مجهولة الهوية خلال هذا الحديث.
01:57 في جوهرها، هذه مشكلة كلاسيكية من مشاكل RAG. في هذا الحديث، نريد استعراض القرارات التقنية التي كان علينا اتخاذها والتعمق في كيفية بناء هذا النظام. هذا حديث كان سيكون مفيدًا لنا في بداية هذا المشروع. إذًا، ما هي المشكلة التي نواجهها؟ يدير عميلنا أكبر نظام دفع في بلجيكا، وجميع قواعد هذا النظام مدونة في كراسات قواعد . هذه عبارة عن ملفات PDF ، حوالي 270 ملف PDF.
02:44 أي حوالي 6,000 صفحة. الكثير من المعلومات موجودة في جداول. حوالي 3,000 جدول. وهذه هي الطريقة التي ينظمون بها معرفتهم. الكثير من المعرفة المهمة موجودة داخل الجداول نفسها. كما أن كراسات القواعد تشير إلى بعضها البعض كثيرًا. فإحدى الكراسات تحيلك إلى أخرى، وتلك تحيلك إلى أخرى، وهكذا. إن تطبيق RAG لمؤسسة مالية يأتي ببعض التحديات. التحدي الأول هو الاستشهادات والمراجع .
03:28 بالطبع، يجب أن تكون الإجابات صحيحة دائمًا. لكن في السياق المالي تحديدًا، تزداد أهمية ذلك. لذا، يجب أن تستشهد كل إجابة بقسم وصفحة كتاب القواعد بدقة. حتى يتمكن الأشخاص من معرفة مصدر الإجابة. والأمر الثاني هو التأسيس المعرفي. فنموذج اللغة الكبير الذي يعمل في الخلفية هو نموذج عام، لذا تم تدريبه على معرفة عامة . إنه يعرف الكثير، بما في ذلك معلومات عن أنظمة دفع أخرى وكيفية عملها أو رسومها.
04:07 لذا كان علينا تحديد والتأكد من نوع المعرفة المسموح باستخدامها. على سبيل المثال، من المقبول معرفة ماهية البنك، فهذا منطقي، وهو ليس شيئًا سيتم تعريفه في كتب القواعد. لكن ما تفرضه أنظمة الدفع الأخرى أو كيفية عملها ، لا ينبغي أن يظهر في الإجابة إلا إذا كان مذكورًا في كتب القواعد. هذا هو الشكل الذي يبدو عليه الحل الذي بنيناه. إنه برنامج دردشة آلي. تطرح سؤالاً ويجيب بناءً على كتب القواعد هذه.
04:45 إذا كانت الإجابة في جدول، فسيقوم بعرض ذلك الجدول أيضًا. أسفل الإجابة توجد قائمة بالمصادر التي استخدمها لاستخراج أو صياغة الإجابة، مع تحديد القسم والجزء من كتاب القواعد ليتمكن المستخدم من فتحه. في هذا المثال، سألت: "هل يمكنني الدفع باستخدام ثلاجتي؟" حصلت على إجابة، ويمكنني بعد ذلك طرح أسئلة متابعة أيضًا. هذا هو الشكل الذي يبدو عليه النظام بأكمله. إنه يتكون من جزأين.
05:22 على اليسار توجد عملية الفهرسة، وهي ما نقوم به دون اتصال بالإنترنت. مع كل إصدار جديد من كتب القواعد، نقوم بتحويل ملفات PDF هذه إلى أجزاء وتخزينها في قاعدة بيانات متجهية. وعلى اليمين يوجد جزء الخدمة، وهو الجزء المتصل بالإنترنت لكل سؤال يطرحه المستخدم. يبحث الوكيل في قاعدة البيانات المتجهية هذه، ثم يتم بث الإجابة للمستخدم. سأتحدث عن الفهرسة، وستتحدث إليونورا عن جزء الخدمة.
05:58 حول الفهرسة، الإعداد بسيط للغاية. نبدأ بملفات PDF، ونقسمها إلى أجزاء، ونضيف بيانات وصفية لكل جزء. نقوم ببعض المعالجة الخاصة للجداول، ثم ننشئ التضمينات. نقوم بإنشاء نوعين من التضمينات (embeddings)، تضمين كثيف وتضمين BM25. لذا، سأقوم الآن بالتفصيل في الخطوات الثلاث الأولى، وستتحدث إليونورا لاحقاً عن التضمينات. حسناً، الخطوة الأولى هي تقسيم ملفات PDF إلى أجزاء، الطريقة التي يعمل بها ذلك هي استخراج النص من كل صفحة، ونقوم بتقسيمه إلى فقرات، ونجمع الفقرات في جزء واحد حتى يصل إلى حوالي 2000 حرف، كما نحرص أيضاً على عدم تقسيم
06:59 أي جدول على جزأين. نقوم أيضاً باكتشاف عناوين الأقسام باستخدام التعبيرات النمطية ( regular expressions)، مثل: الفصل الثالث، أو 4.2.1. وهذا يمنح كل جزء مسار القسم الخاص به. على سبيل المثال، هذا الجزء موجود في الفصل الرابع، القسم 4.2. ويُستخدم هذا المسار لإضافة مرجع، ولكن يُستخدم أيضاً لجلب القسم بالكامل عندما يحتاج الوكيل إلى مزيد من السياق. وكل هذا يعمل لأننا لا نجعل الأجزاء متداخلة.
07:42 لذا، القسم عبارة عن مجموعة من الأجزاء فقط. وإذا قمت بإعادة ترتيبها، فإنها تعود إلى حالتها الأصلية. بالنسبة للخطوة الثانية، نقوم بإضافة بيانات وصفية لكل جزء. لذا، في هذا المثال، نرى نص الجزء من كتاب قواعد الثلاجة هذا. وفي الأسفل توجد بعض حقول البيانات الوصفية. نحن بحاجة إلى اسم كتاب القواعد ورقم الصفحة حتى نتمكن من عرضها في المرجع أو في بطاقة المصدر للمستخدم.
08:21 ومع ذلك، يمكن للمستخدم الوصول إلى الرابط المؤدي لملف PDF. نستخدم أيضاً مسارات الأقسام، سواء للمرجع أو لتمكين الوكيل من جلب القسم بالكامل دفعة واحدة. ولدينا أيضاً فهرس الأجزاء الذي يسمح للوكيل بإعادة تجميع قسم أو حتى كتاب قواعد بالكامل. يستخدم الوكيل معرفات كتب القواعد ليكون قادراً على الحصول على قائمة بجميع كتب القواعد أو معرفة ما هو متاح. وفي وقت الفهرسة لكل كتاب قواعد، نقوم باستخدام نموذج لغوي كبير (LLM) لإنشاء ملخص يتم إرفاقه بكل جزء ليعبر عن كتاب القواعد الخاص به.
09:20 وبهذه الطريقة يعرف الوكيل المستند الذي يأتي منه المقطع. أما البقية، فبقية البيانات الوصفية هي عبارة عن حقول منطق عمل. إذن، أي كتاب قواعد هو، وأي القواعد ينطبق عليها، وما إذا كان يحتوي على جدول، وهذه هي الأمور التي يستخدمها الوكيل أو يحصل عليها مع نتائج البحث. ثم الخطوة الثالثة هي معالجة الجدول. هذه الخطوة مهمة لأنه كما قلت، هناك الكثير من المعرفة داخل الجداول.
10:04 في البداية لم ندرك ذلك نوعاً ما. لذا، كانت معالجتنا الأولية مجرد جلب مباشر للنص العادي من ملف PDF، ولم ينسق ذلك الجداول بشكل جيد. لكن في هذا المثال الوهمي، ترى أن الحقل المحلي يمتد عبر صفوف متعددة، وعبر الحدود عبر صفين آخرين، ثم يمتد الاسترداد عبر كليهما. لذا، إذا لم يكن ذلك واضحاً أو مصاغاً جيداً في نص، نعم، يمكن للوكيل جلب معلومات خاطئة، وخاصة في أشياء مهمة مثل الرسوم، من المهم جلب الصف الصحيح والعمود الصحيح.
10:50 لذا، ما نقوم به هو تحويل الجداول إلى تنسيق CSV، فنقوم أساساً بتكرار تلك الحقول، ثم نحن...وبهذه الطريقة يجلبها الوكيل، وعندما يجلبها، فإنه يجلب الصف الصحيح. هذا هو الصف الذي يحتاجه. وقد أحدث ذلك فرقاً كبيراً حقاً في دقة الإجابات. حسناً، كان هذا كل ما يتعلق بالفهرسة. الآن، لدينا حوالي 4000 قطعة نصية. والآن ستتحدث إليونورا عن جزء التقديم. أجل. >> حسناً، الجزء السابق قام ببناء الفهرس.
11:47 الآن هذا الجزء سيدور حول العثور على هذه القطع العشر الصحيحة من أصل 4000 قطعة تم إعدادها. الخطوة الواضحة هنا هي اللجوء إلى التضمينات الكثيفة للسؤال وتحويل كل قطعة إلى متجه، ثم مقارنة المسافة. وهذا رائع للمعنى، لكن رموز قواعد العمل، وأسماء الرسائل، والمعرفات الدقيقة ستبدو كضوضاء بالنسبة للتضمين، ولكن بالنسبة للعضو الذي يطرح السؤال، غالباً ما يكون هذا هو جوهر السؤال.
12:19 مع خوارزمية BM25، لدينا صورة معكوسة. الرموز الدقيقة ستعمل، لكن إعادة الصياغة لن تعمل . لذا، قمنا بدمج كليهما في استدعاء واحد (Quadrant) ودمجهما باستخدام دمج الرتب المتبادل. تضمين كثيف لأعلى 50، و BM25 لأعلى 50، يتم دمجهما للوصول إلى أفضل 30، ثم إعادة الترتيب لضمان تماسك القسم، وتُغذي أفضل 10 نتائج للوكيل. الشيء الجيد في RRF هو أننا لسنا بحاجة لمعايرة النتائج بين هذين المسارين.
12:50 في تقييم الاسترجاع فقط لـ 63 سؤالاً مقارنة بالتضمينات الكثيفة وحدها، رفع النهج الهجين معدل الإصابة من 92%إلى 97%، ولم يفقد أي سؤال كانت التضمينات الكثيفة قادرة على العثور عليه بالفعل. حسناً، لدينا الآن 10 أجزاء مناسبة، لكن ليس كل سؤال يتناسب مع 10 أجزاء. بعضها مرتبط ببعضها الآخر في سلسلة. يشير دليل إلى آخر، ولن تكتمل الإجابة إلا إذا تتبعت ذلك الرابط.
13:25 وبعضها يتطلب نطاقاً أوسع. رسوم هذا النوع من المعاملات لن تتناسب أبداً مع أفضل 10 نتائج لأي شيء. لذا، بدلاً من خط أنابيب ثابت للاسترجاع ثم التوليد، يمتلك وكيلنا أربع أدوات. من الضيق إلى الواسع. البحث في كتيبات القواعد يأتي دائماً في المقام الأول. هذه هي الأجزاء العشرة التي تحدثنا عنها في الشريحة السابقة. إذا لم يكن ذلك كافياً، فإن أداة استرجاع أقسام الكتيب تسحب القسم بالكامل مرتباً حسب تسلسل الأقسام.
13:54 وهو بالضبط النهج الذي ذكرته نينا في وقت سابق. تخزين تسلسل القسم. وهذا التوسع هنا-الابتعاد عن التفاصيل-هو مجرد جلب كل جزء بهذا المسار مرتباً حسب فهرس الجزء . فوق ذلك توجد أداة استرجاع كتيب القواعد بالكامل، والتي تعمل فقط مع الكتيبات الصغيرة. وأداة سرد الكتيبات المتاحة عندما يحتاج الوكيل لمعرفة ما هو موجود أصلاً. لذا، فإن حواجز الحماية جعلت هذا يعمل من الناحية العملية.
14:28 أولاً، إذا كان الكتيب كبيراً جداً (أكثر من 100 ألف رمز تقريباً)، ترفض أداة الكتيب الكامل إفراغ محتوياته في السياق، وتعيد قائمة الأقسام المتاحة بدلاً من ذلك مع تحذير بأن الكتيب طويل جداً. ثانياً، إذا لم يتطابق اسم القسم، فإنها تعيد الأقسام المتاحة ليتمكن الوكيل من المحاولة مجدداً بدلاً من الاستسلام أو محاولة اختراع الاسم. وأخيراً، توجد أداة تسمى "تعليمات الانضباط" في المطالبة .
15:04 لأن معظم الأسئلة تتطلب من استدعاءين إلى أربعة، وقبل الاستدعاء السادس، يُطلب من الوكيل أن يسأل نفسه عما إذا كان يجلب شيئاً جديداً حقاً أو يعيد صياغة بحث فشل بالفعل من قبل. وهذه الفكرة جاءت من مراقبتنا للمسارات الحقيقية عندما حاول الوكيل إجراء نفس البحث مراراً وتكراراً على أمل أن تظهر النتيجة في النهاية. إذن، تكلفة كل هذا هي زمن الاستجابة، بمتوسط 38 ثانية لكل إجابة.
15:38 هذا ليس مجرد رد محادثة. إنها مهمة بحثية صغيرة . نحن نعتمد على البث المباشر لنجعل الـ 38 ثانية تبدو وكأن شيئاً ما يحدث بالفعل، وليست مجرد محادثة عالقة. وهذا يقودني إلى الشريحة التالية. في تكرارنا الأول، أردنا حقًا الابتعاد عن واجهة مستخدم روبوتات الدردشة التقليدية. وقد جهزنا مكونات الواجهة ووصفتها كنماذج Pydantic متاحة للوكيل، قائلين: "هذه هي المكونات المتاحة لديك".
16:12 "استخدمها في إجابتك جنبًا إلى جنب مع النص". على سبيل المثال، كانت بطاقة المصدر مكونًا، ويمكن أن يكون الحدث مكونًا، أو قائمة مرجعية قابلة للطي، وهكذا. كانت الفكرة هي الحصول على واجهة مستخدم مُنشأة بواسطة الذكاء الاصطناعي، لتكون أكثر قابلية للقراءة من مجرد نص عادي. المشكلة هي أنك لا تستطيع بث كائن Pydantic جزئي. إنه لا يصبح ملف JSON صالحًا إلا عند وصول الرمز الأخير.
16:38 كما ترون هنا، بالنسبة لنظام تستغرق إجاباته 38 ثانية، كان ذلك يعني 38 ثانية من الفراغ على الشاشة، ثم يظهر كل شيء دفعة واحدة. لذا، الحل الذي أنقذ التجربة كان تقسيم الإجابة إلى أجزاء. الآن يقوم الوكيل ببث نصوص Markdown رمزًا برمز، وتقوم الواجهة الأمامية بتنسيقها مباشرةً فور وصولها. ثم تكون بطاقة المصدر جزءًا واحدًا يمثل مكون واجهة مستخدم حقيقي. إنه لا يحتوي على أي معلومات قد ترغب في النقر عليها قبل قراءة الإجابة كاملة.
17:12 لذا، نحن لا نفقد شيئًا بالانتظار حتى اكتمال بث الإجابة قبل إضافة هذا المكون. وهذا يمنحنا بطاقة قابلة للنقر بدلاً من رابط عادي داخل النص، وهو أمر أفضل للمستخدم . ولكن بمجرد ظهور هذه الإجابة على الشاشة، السؤال التالي هو ما الذي سيفعله المستخدم بها فعليًا. هل سينقر على المصدر، أم ينسخ الإجابة، أم يواصل المحادثة، أم يغادر؟ هذه هي تجربة المستخدم التي نريد تتبعها، وهذا يقودنا إلى التسجيل.
17:50 لذا، في الوقت الحالي، اخترنا أبسط حل للتسجيل، وهو Azure table storage. نحن نسجل كل سؤال، واستدعاء للأداة، وإجابة، وتعليقات إيجابية كانت أم سلبية، بالإضافة إلى أحداث مثل النقر على المصدر أو نسخ الإجابة، مع سجل المحادثة الذي نبقيه صغيرًا عمدًا. إنه يكتفي بآخر 20 رسالة فقط كسياق. بالنسبة لمرحلتنا الحالية في هذا المنتج ، هذا يكفي. بمجرد نمو المنتج، سنعرف ما الذي سنحتاجه فعليًا حينها.
18:29 وكيف نعرف أن أيًا من هذا يعمل بالفعل؟ أسئلة التقييم لدينا تأتي من مصادر حقيقية، وجولتين من اختبار المستخدمين مع أعضاء فعليين، بالإضافة إلى إرشادات سلوكية لما يجب وما لا يجب على نظام الذكاء الاصطناعي فعله. على سبيل المثال، لا تقدم نصائح، ابقَ محايدًا تجاه المنافسين، وصرح بوضوح عندما لا يكون هناك شيء مذكور في كتيبات القواعد. لدينا حوالي 86 اختباراً شاملاً تم تشغيله باستخدام Promptfoo، مع تقييم كامل من وكيل LLM وفقاً لمعايير محددة، بالإضافة إلى التحقق من الاستشهاد بالمستند المصدر الصحيح، وتقييم الاسترجاع فقط الذي أجريناه
19:11 سابقاً. هناك أمران تعلمناهما من إجراء الاختبارات ونود مشاركتهما: أولاً ، تقييمات نموذج اللغة تحتوي على مستوى ضوضاء ، وعليك إعادة التشغيل قبل الوثوق بأي تغيير. على سبيل المثال، عندما أجرينا تقييمنا الخاص، لم يتكرر حدوث خمس من أصل 12 حالة تغيير. والثاني، أحياناً يكون القالب المعياري نفسه هو الخلل، وليس النموذج. فقد واجهنا تاريخاً وهمياً ظل المقيم يعاقب عليه، ليتضح لاحقاً أن هذا التاريخ كان نصاً فعلياً موجوداً في كتيب القواعد.
19:58 >> أجل. والآن، فيما يخص الاستخدام. لقد أطلقنا مساعد كتيب القواعد هذا في شهر يونيو. في البداية، تم إطلاقه فقط للمستخدمين الداخليين لعملائنا، والهدف هو إطلاقه بحلول نهاية العام لأعضائهم الخارجيين وعملائهم. حتى الآن، لدينا بعض أرقام الاستخدام الأولية. لدينا حوالي 900 سؤال حتى الآن. مقسمة إلى أكثر من 100 محادثة، وهناك حوالي 34 شخصاً يستخدمونه فعلياً. قمنا أيضاً بجمع ملاحظات الإعجاب وعدم الإعجاب، لكن معظم المستخدمين توقفوا عن استخدام هذه الميزة بعد الشهر الأول.
20:59 ولدينا أيضاً معلومات حول عدد المرات التي تم فيها النقر على المصادر أو نسخ الإجابات. هذه هي الأرقام المتوفرة لدينا. نستخدم الذكاء الاصطناعي أيضاً لأغراض التحليلات. على الجانب الأيمن، نرى كيف قام نموذج اللغة بتفسير ذلك. ما لاحظناه هو أنه في الشهر الأول، بينما كنا نسأل الناس، أجرينا بعض عمليات " الفريق الأحمر"(اختبار الاختراق). كان الناس يحاولون كسر المساعد ومحاولة إخراجه عن الموضوع أو طرح أسئلة خارج النطاق.
21:38 لكن بحلول الشهر الثالث، كانت أكثر من 90%من الأسئلة أسئلة فعلية وحقيقية. ثانياً، يستخدم الناس الأداة لحالات واقعية. لقد رأينا أشخاصاً يستخدمونها عبر نسخ بريد إلكتروني من عملائهم وطلب المساعدة في الرد عليه . أو يقومون بنسخ رسالة بروتوكول حقيقية أو جدول، ثم يصيغون رداً يرغبون في مراجعته. ثالثاً، نظراً لعدم حصولنا على الكثير من التعليقات عبر الإعجاب وعدم الإعجاب ، حاولنا تفسير مشاعر المحادثة من خلال النظر إلى الأسئلة المتابعة.
22:24 إذا قال الأشخاص "شكرًا" أو انتقلوا إلى موضوع جديد، فإننا نعتبر ذلك تفاعلاً إيجابيًا. أما إذا سألوا عن الشيء نفسه مرة أخرى، فمن المحتمل أن التفاعل كان سلبيًا. وبناءً على ذلك، رأينا أن معظم المحادثات سارت على ما يرام. إذًا، باختصار، ما هي الدروس الرئيسية المستفادة من هذا المشروع حتى الآن؟ فيما يخص المستندات، وجدنا أنه من المهم الحفاظ على بنيتها. لذا، فإن الأقسام مهمة لاسترجاع الإجابات، وكذلك لتمكين الوكيل من إلقاء نظرة شاملة على المعرفة.
23:20 لاحظنا أيضًا أن الجداول تتطلب معالجة خاصة وطريقة تعامل مختلفة. أما من جانب الوكيل، فكما ذُكر، كان من المهم منحه مستويات تكبير متعددة وتحديد مقدار السياق الذي يحتاجه، وبشكل عام كان من المفيد جدًا التحول من الاستدعاء الفردي للنموذج اللغوي إلى الاسترجاع عبر الوكيل. لاحظنا أن أرقام التقييم ارتفعت بشكل ملحوظ. من منظور تجربة المستخدم، كان البث المباشر هو ما جعله أداة قابلة للاستخدام وجيدة.
24:11 ونحن لا نضيف مكونًا منظمًا إلا عندما تتطلبه تجربة المستخدم. وأخيرًا، وجدنا أنه من المهم الاختبار مع مستخدمين حقيقيين في وقت مبكر، واستخدام هذه المقابلات لإنشاء مطالبات التقييم التي تساعدنا في تشكيل المنتج واتخاذ القرارات بشأن ما إذا كان ما نعتبره تحسينًا هو بالفعل كذلك. شكرًا لكم على الاستماع إلى حديثنا. >> شكرًا.