الاستخراج المنظم
تُحوَّل الفواتير والنماذج إلى JSON مُتحقَّق منه. وإعادة معالجة المستند نفسه تعيد النتيجة المُتحقَّق منها دون استدعاء آخر للنموذج.
الذكاء الاصطناعي وLLMعمليات LLMخطتا Performance وScale
تخزين مؤقت لضوابط الحماية والإشراف
أعد تقديم الإجابات التي اجتازت أدوات التحقق لديك بالفعل، وارفض المخالفين المتكررين دون استدعاء الإشراف أو النموذج مجددًا.
- ذاكرتان، للجيد وللسيئ
- 2
- إعادة تحقق عند الإصابة
- 0
- قيم TTL لحالات الرفض
- قصيرة
الخطوة 1 من 5
ولّد وتحقق
أُنشئت مساحات الأسماء مرة واحدة باستخدام GUARD.CREATE وNCACHE.CREATE. ينتج النموذج JSON، وتتحقق أداتك منه مقابل المخطط قبل تخزين أي شيء.
جلسة توضيحيةplaying
# ولّد وتحقق
hotkv> GUARD.SET validated "Summarize ticket 812 as JSON" "{\"summary\":\"Login fails on Safari\"}"
OK
عرض متحرك بأوامر HotKV حقيقية وردود توضيحية. انقر على أي خطوة للانتقال إليها. تبقى الأوامر والردود بالإنجليزية، تمامًا كما تكتبها وتراها في HotKV.
المشكلة
المخرجات المنظمة وفحوص السلامة بطيئة وتكلّف مالًا. فهناك استدعاء للنموذج، وتحقق من مخطط JSON، وربما نموذج ثانٍ يحكم على الإجابة. والطلبات المتكررة تدفع ثمن كل ذلك مجددًا. والموجّه المسيء نفسه، الذي يرسله سكربت ألف مرة، يذهب إلى الإشراف ألف مرة.
كيف يتعامل HotKV معها
لا تخزّن ذاكرة الحماية المؤقتة إلا الاستجابات التي اجتازت بالفعل التحقق من المخطط أو فحوص ضوابط الحماية لديك، فالإصابة معروف أنها آمنة لإعادة تقديمها كما هي. وتتذكر الذاكرة المؤقتة السلبية حالات الرفض مثل "رفضه الإشراف" مع TTL قصير، فتُرد الطلبات السيئة المتكررة قبل أن تصل إلى خدمة الإشراف أو النموذج.
خطوة بخطوة
ما يحدث، أمرًا بأمر
- 01
ولّد وتحقق
أُنشئت مساحات الأسماء مرة واحدة باستخدام GUARD.CREATE وNCACHE.CREATE. ينتج النموذج JSON، وتتحقق أداتك منه مقابل المخطط قبل تخزين أي شيء.
GUARD.SET validated "Summarize ticket 812 as JSON" "{\"summary\":\"Login fails on Safari\"}" - 02
أعد التقديم دون إعادة فحص
الطلب نفسه مجددًا. الإجابة المخزنة اجتازت التحقق بالفعل، فتُعاد كما هي.
GUARD.GET validated "Summarize ticket 812 as JSON" - 03
الإشراف يرفض موجّهًا
يُرفض موجّه ضار. ويُتذكَّر الرفض لمدة خمس دقائق.
NCACHE.SET refused "prompt:9f31c2" "refused_by_moderation" TTL 300 - 04
السكربت يحاول مجددًا
الموجّه نفسه بعد لحظة يُرد من الذاكرة المؤقتة. ولا يُستدعى الإشراف ولا النموذج.
NCACHE.GET refused "prompt:9f31c2" - 05
قِس الذاكرتين
تعرض كل مساحة أسماء الإصابات والإخفاقات وعمليات الإخلاء والذاكرة.
GUARD.STATS validated
أين يناسب
سيناريوهات من الواقع
تطبيقات الدردشة للمستهلكين
تُرفض سكربتات الإساءة التي تكرر الموجّه نفسه بإلحاح من الذاكرة المؤقتة السلبية، فتبقى تكاليف الإشراف ثابتة.
عمليات البحث التي تفشل
تُخزَّن إجابة "User not found" وغيرها من الإجابات السلبية لفترة قصيرة، فلا تصل إعادة المحاولات إلى الخلفية.
مدمج
ما تحصل عليه
ذاكرة الحماية المؤقتة
لا تُخزَّن إلا الاستجابات التي اجتازت فحوصك، فالإصابة آمنة لإعادة التقديم.
GUARD.SETGUARD.GETالذاكرة المؤقتة السلبية
تذكّر حالات الرفض ونتائج عدم العثور لفترة قصيرة.
NCACHE.SETNCACHE.GETقيم TTL والحدود
قيم TTL افتراضية وحدود للإدخالات لكل مساحة أسماء، مع الإخلاء عند الامتلاء.
GUARD.CREATENCACHE.CREATEالإحصاءات
الإصابات والإخفاقات وعمليات الإخلاء والذاكرة والوفورات لكل مساحة أسماء.
GUARD.STATSNCACHE.STATSأسئلة شائعة
هل يتحقق HotKV من المخرجات بنفسه؟
لا. أداة التحقق أو ضوابط الحماية لديك هي التي تقرر. ولا يخزّن HotKV إلا ما تضعه في ذاكرة الحماية المؤقتة بعد اجتيازه.
كم من الوقت ينبغي تخزين حالات الرفض؟
لفترة قصيرة عادةً، دقائق لا أيامًا، كي لا يبقى أثر تغيير في السياسة أو إيجابية خاطئة. حدّد TTL لكل مساحة أسماء أو لكل إدخال.
ما الخطط التي تتضمنها؟
ذاكرة الحماية المؤقتة والذاكرة المؤقتة السلبية جزء من خطتي Performance وScale.
حالات استخدام ذات صلة
جرّبه على عبء عملك
يتحدث HotKV بروتوكول Redis، لذا يمكنك توجيه عميل موجود إليه وتشغيل هذه الأوامر نفسها.