मनोबल में सुधार होने तक गॉड एंडपॉइंट जारी रहेगा

मनोबल में सुधार होने तक गॉड एंडपॉइंट जारी रहेगा



ग्राफसीएमएस हाइग्राफ इसे फ़ेडरेटेड कंटेंट प्लेटफ़ॉर्म कहता है:

छवि

गैट्सबी इसे कंटेंट मेश कहते हैं:

छवि

अपोलो तुरंत बाहर आता है और इसे सुपरग्राफ कहता है:

छवि

यह कोई नई बात नहीं है, मैट स्लोटनिक ने समझदारी से इसे कहा है सॉफ़्टवेयर में सबसे कठिन कार्यशील ग्राफ़िक:

छवि

और ग्राफक्यूएल भक्तों के पास एयरबाइट और फाइवट्रान में अपने स्वयं के डेटा इंजीनियरिंग समानताएं हैं।

विचार

मूल्य प्रस्ताव स्पष्ट है – यदि केवल हम इन सभी गड़बड़ चीजों को एक इंटरफ़ेस के अनुरूप बना सकते हैं, तो डेवलपर्स उन्हें क्वेरी करने और तेजी से हल करने में सक्षम होंगे, जिससे डेवलपर अनुभव में सुधार होगा, ब्ला ब्ला ब्ला। यह समस्या कंपनी के आकार के साथ अच्छी तरह से बढ़ती है, कोई भी इसे करना नहीं चाहता है, यह परिचालन और विश्लेषणात्मक जरूरतों के लिए आवश्यक है, जिससे स्टार्टअप के लिए यह एक अच्छी समस्या बन जाती है। रणनीति 101, या बल्कि, रणनीति पत्र वी।

लेकिन इसमें बहुत कुछ है IF:

  • मेंटेनेन्स कोस्ट: इंटरफ़ेस हर समय टूटते हैं और किनारे के मामलों/परफ मुद्दों में चलते हैं, औसतन (1-3 घंटे? यह बहुत तेज है, औसत एक तरह से अर्थहीन हैं) रखरखाव का एक सप्ताह
  • बंद करना: लोग खुद को आपके एसडीके और एपीआई में बंद कर रहे हैं, और यह देखते हुए कि इनमें से कोई भी गॉड एंडपॉइंट अभी तक समय की कसौटी पर खरा नहीं उतरा है (यहां तक ​​​​कि GitHub प्रबंधित नहीं हुआ है ग्राफक्यूएल को डिफ़ॉल्ट/आसान बनाने के लिए), यह एक जोखिम भरा प्रस्ताव है।
    • इस अर्थ में डेटा इंजीनियरिंग कंपनियों के लिए यह आसान है, क्योंकि वे डेटा को एकीकृत करते हैं, कोड को नहीं, जो लंबे समय तक चलता है।
  • प्रोत्साहन: डेटा साइलो आपको अपना डेटा क्यों निकालने देना चाहता है? वे भी अपने उपयोगकर्ताओं के लिए एक गॉड एंडपॉइंट क्यों नहीं बना सकते? अनिवार्य https://xkcd.com/927/ संदर्भ (बोनस अंक यदि आप बिना क्लिक किए जानते हैं कि वह xkcd क्या है)

भगवान समापन बिंदु के रूप में मानक

हर साल करोड़ों डॉलर घरेलू और विक्रेता दोनों ही इस चीज़ को हल करने में लगे हुए हैं। यह संभवतः आवश्यक कार्य है, यह गन्दा काम है, और यह छोटे पैमाने पर अलाभकारी है/केवल दशक के न्यू गॉड एंडपॉइंट फ्लेवर के लिए अगले बिग बैंग रीराइट तक चलता है।

हालाँकि यह असुंदर लगता है। हम इस समस्या पर अंतहीन समय और पैसा खर्च करके इस समस्या को बलपूर्वक बढ़ा रहे हैं, लेकिन इससे इसका समाधान नहीं होता है ईमेल और टर्मिनल आउटपुट और एचटीएमएल “समाधान” हो गया है।

जो होना चाहिए वह है मानकों – जिसे डेटा उत्पादक और डेटा उपभोक्ता और सभी बीच के टूलींग अनुकूलित कर सकते हैं, जिससे इन पर सट्टेबाजी में उपयोगकर्ता का विश्वास बढ़ जाता है। हाल के उदाहरणों के संदर्भ में, मैं ओपनटेलीमेट्री से प्रेरित हूं, हालांकि इसमें लाइटस्टेप के लिए रॉकेटशिप परिणाम नहीं था, लेकिन ऐसा लगता है कि यह टेलीमेट्री इंटरफ़ेस को सफलतापूर्वक परिभाषित कर रहा है जिसे सभी निर्माता और उपभोक्ता अब स्वीकार कर रहे हैं।

कभी-कभी मानक समिति द्वारा डिज़ाइन किए जाते हैं (जेएस में, विंटरसीजी अभी विशेष रूप से दिलचस्प है, लेकिन इसमें पर्याप्त क्षमता नहीं है), कभी-कभी उनका निर्णय एक अत्यंत प्रभावशाली खिलाड़ी द्वारा किया जाता है (JSX, S3, OCI और Postgres विभिन्न डोमेन के उदाहरण हैं) जो अनिवार्य रूप से “जीत” चुके हैं। बेशक यह एक सवाल पैदा करता है – चूँकि “जीतने” से पहले एक सामान्य मानक स्थापित करना आवश्यक नहीं है, क्या प्रयास करना भी उपयोगी है? मेरी समझ यह है कि बिना मानकों के जीतना और जीतना “लड़ाई जीतने लेकिन युद्ध हारने” के बराबर है।

भाषा ईश्वर समापन बिंदु के रूप में

बेशक, यह एलएलएम का युग है, कोई भी ब्लॉगपोस्ट मानवता द्वारा विकसित पहले इंटरफ़ेस पर विचार किए बिना पूरा नहीं होगा: प्राकृतिक भाषा.

दूसरे शब्दों में, यहां तक ​​कि मानकों में भी समस्याएं हैं – उन्हें सीखने की अवस्था की आवश्यकता होती है, उनमें डिज़ाइन संबंधी खामियां हो सकती हैं, और वे लचीले नहीं होते हैं (लगभग परिभाषा के अनुसार – एक मानक जितना अधिक लचीला होगा, वह उतना ही कम उपयोगी/विश्वसनीय होगा)। मानक मशीन संचार के लिए अनुकूलित होते हैं, लेकिन भाषाएँ मानव संचार के लिए अनुकूलित होती हैं।

यह संभावित रूप से कैसा दिखता है?

यदि आप इस तरह की प्रणाली लागू कर रहे हैं, तो कृपया आंशिक सूचना समाधान भी लागू करें:

  • प्रश्न: कितने भुगतान किए गए?
  • उत्तर: अपर्याप्त जानकारी – किसके द्वारा कितने भुगतान? किस समयावधि में?
  • प्रश्न: ओह क्षमा करें – ‘joe@freshpizza.com’ द्वारा
  • उत्तर: ठीक है, किए गए भुगतानों की संख्या देख रहा हूँ 'joe@freshpizza.com'…किस समयावधि में
  • प्रश्न: ओह, फिर से क्षमा करें – पिछले 3 महीनों में!

उस तरह की चीज़, लेकिन एपीआई टोकन, लॉगिन और अन्य गुम जानकारी के लिए (मैंने इसमें से कुछ को अपने 2019 एडेप्टिव इंटेंट-आधारित सीएलआई स्टेट मशीन्स टॉक में कवर किया है, जो मेरे 2016 एलेक्सा कौशल के अनुभव से सूचित है)। चूँकि यह एक मानव-इन-द-लूप प्रक्रिया है, आप एक टेम्पोरल चाहेंगे।

क्या यह सिर्फ चैटबॉट नहीं है? अब मुझे तकनीक में काफी समय हो गया है और मुझे याद है कि पिछली बार बातचीत संबंधी वाणिज्य को बहुत प्रचारित किया गया था और वह कहीं नहीं गया (यकीनन विवादास्पद), और एआई सहायक दुनिया पर कब्ज़ा करने जा रहे थे। तो हाँ, एक जोखिम है कि हम केवल क्लिप्पी 2022 संस्करण को फिर से तैयार करने के लिए बहुत सारे समारोहों से गुजरेंगे। लेकिन दोनों सिरों पर डेटा की मात्रा, और बेहतर प्राकृतिक भाषा समझ द्वारा अनलॉक किए गए नए उपयोगकेस, शायद इसे एक और शॉट के लायक बनाते हैं।

हां, यह पार्स करने के लिए 1000 गुना अधिक महंगी क्वेरी है, लेकिन यह समय के साथ कम हो सकती है, और यह मनुष्यों के लिए अंतिम मील की चीज़ हो सकती है, लेकिन आप एक दूर के भविष्य की कल्पना कर सकते हैं जहां एलएलएम इतने सस्ते होंगे कि प्रणाली अन्य प्रणालियों से बात करें इसी तरह – एपीआई या मानक तोड़ने की समस्या को हमेशा के लिए हल करना।





Source link

Postagens Similares

  • Schema zu WebAssembly kompilieren – Eli Benderskys Website

    Eines meiner ältesten Open-Source-Projekte – Bob – hat vor ein paar Monaten seinen 15. Geburtstag gefeiert. Bob ist eine Suite von Implementierungen der Programmiersprache Scheme in Python, einschließlich eines Interpreters, eines Compilers und einer VM. Damals habe ich mich mit CPython-Interna befasst und war sehr neugierig, wie CPython-ähnliche Bytecode-VMs funktionieren. Bob führte ein Experiment durch,…

  • Laat het em-dashboard met rust

    Ik erger me aan alle haat tegen het em-dashboard. Terwijl Matthew Butterick briljant vastlegt, voegt het pauzes toe aan zinnen. Of specifieker en belangrijker voor mij: het voegt pauzes toe denken…wat zou kunnen Dan zinnen worden. Dit is wat Butterick over hen zegt. Het em-streepje wordt gebruikt om een ​​pauze te maken tussen delen van…

  • நிலையான தள ஜெனரேட்டர்கள் | கெவ் குயிர்க்

    📅 25 நவம்பர் 2025 | ⏱️ ~2 நிமிட வாசிப்பு ஜான் வான் டென் பெர்க் மூலம் (முரண்பாடாக) அவற்றின் வெளியீடு மிகவும் எளிமையானதாக இருந்தாலும், நிலையான தள ஜெனரேட்டர்கள் வேர்ட்பிரஸ்ஸை விட மிகவும் சிக்கலானவை என்பதை ஜான் பேசுகிறார். இடுகையைப் படிக்கவும் 👉🏻 நான் ஜனவரி மாதத்திலிருந்து இந்த இடுகையை ஒருமுறை டச்சு மொழியிலிருந்து மொழிபெயர்த்தேன், உண்மையில் அதைப் படிக்க முடிந்தது. ஒரு நிலையான தள ஜெனரேட்டரின் வெளியீடு மிகவும் எளிமையானது, இருப்பினும் அவற்றை…

  • Opplastingen (novelle)

    Mitt første forsøk på å bringe tilbake novellen på ~30 år. Jeg smilte da du åpnet øynene for den første dagen av resten av livet ditt. Vel, metaforisk. Jeg ville ha smilt hvis jeg kunne. I praksis spilte jeg den forhåndsinnstilte smileanimasjonen på skjermen nærmest deg. Jeg kunne selvfølgelig generere en bare for denne anledningen,…

  • 苦い錠剤のエンジニアリング |ダニエル・ミースラー

    私の AI エンジニアリングの随所で使用している、Bitter-Pilled Engineering (BPE) と呼ばれる新しい概念があります。 このアイデアは、リチャード・サットンのエッセイ「The Bitter Lesson」から来ています。 とりあえず、私のまとめです。 このエッセイでは、AI を制御、修正、強化しようとする人間の試みはすべて、ある種の価値がないと主張しています。なぜなら、より多くのハードウェアやより優れたアルゴリズムなどを通じて AI の知能を高めると、それ 人間のアプローチでできることよりもはるかに知性を向上させます。 私たち人間が AI には決して持たない魔法を持っていると考えるのはとても魅惑的ですが、その魔法は多くの場合単なる傲慢です。 実際にはそれよりも強いです。それだけでなく、 もっと良くならない 私たちが助けようとしても、おそらくそうなるでしょう はるかに悪い。 本質的に、実際には優れているわけではないため、優れていると思われるガイダンスによって AI のネイティブ機能を汚染することは避けるべきです。 エッセイからのいくつかの引用: 「70 年にわたる AI 研究から読み取れる最大の教訓は、コンピューティングを利用する一般的な手法が最終的には最も効果的であり、それを大幅に上回るということです。」 「私たちが望んでいるのは、私たちが発見したものを含む AI エージェントではなく、私たちと同じように発見できる AI エージェントです。」 「この恣意的な複雑さを見つけて捕捉できるメタメソッドのみを組み込む必要があります。」 「発見を組み込むと、発見プロセスがどのように行われるかを理解することが難しくなるだけです。」 私の要点: 論理、知性、効率についての私たちの考え方はおそらく原始的です したがって、AI に物事を「教える」方法にこれらのルールやアイデアをハードコーディングすべきではありません。 AI が賢くなるにつれて、第一原理に基づいて同じことを行うためのより良い方法が考え出されます。 残念ながら、私はその逆をする傾向が非常に強いので、この BPE の概念で自分自身をたたきつけなければなりません。 したがって、AI システムを構築するときの私自身の BPE ルールは次のとおりです。 自分の得意なアイデアや「賢い」アイデアをシステムに組み込んで、足場を過度に設計しないでください。代わりに、構築する足場が、より賢くなる基礎となる AI に対して堅牢で脆弱でないことを確認してください。 Source link

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *