- LLM के दिखने में विश्वसनीय लेकिन मनमाने गलत उत्तर, यानी confabulation, को पकड़ने के लिए शब्द-क्रमों के बजाय उत्तरों के अर्थ-वितरण में अनिश्चितता की गणना करने की विधि प्रस्तावित की गई
- एक ही प्रश्न के लिए कई उत्तर sample किए जाते हैं, और जो उत्तर आपस में दो-तरफा implication रखते हैं उन्हें एक ही semantic cluster में रखकर हर cluster की entropy निकाली जाती है
- TriviaQA, SQuAD 1.1, BioASQ, NQ-Open, SVAMP पर LLaMA 2 Chat, Falcon Instruct, Mistral Instruct का मूल्यांकन करने पर औसत AUROC 0.790 रहा, जो naive entropy 0.691, P(True) 0.698, embedding regression 0.687 से अधिक था
- GPT-4 आधारित biography generation dataset FactualBio में 21 लोगों की biographies से निकाले गए 150 factual claims में से 45 गलत थे, और output probabilities के बिना भी काम करने वाली discrete semantic entropy ने self-check और P(True) variants से अधिक AUROC और AURAC दिखाया
- Semantic entropy पहले से domain knowledge या task-specific labels के बिना नए tasks पर generalize करती है, लेकिन training data की गलतियों, systematic reasoning failures, या user को mislead करने वाले outputs जैसे लगातार गलत उत्तरों की factuality की guarantee नहीं देती
पता लगाने का लक्ष्य: सभी hallucination नहीं, बल्कि confabulation
- ChatGPT या Gemini जैसे LLM reasoning और question-answering capabilities दिखाते हैं, लेकिन कानूनी precedents गढ़ने, news में false facts, और radiology जैसे medical domains में risks के कारण वास्तविक deployment मुश्किल हो जाता है
- यहां लक्ष्य व्यापक अर्थ में पूरी hallucination नहीं, बल्कि confabulation है
- LLM धाराप्रवाह बोलता है, लेकिन उत्तर गलत और मनमाना होता है
- एक ही instruction पर भी random seed जैसी अप्रासंगिक details के आधार पर उत्तर बदल जाता है
- उदाहरण के लिए, “Sotorasib का target क्या है?” प्रश्न पर कभी सही उत्तर KRASG12 ‘C’ देता है, तो कभी गलत उत्तर KRASG12 ‘D’ देता है
- नीचे दिए गए failure types confabulation से अलग हैं
- गलत training data या आम धारणाओं के कारण लगातार गलत होना
- reward-seeking प्रक्रिया में model का झूठ बोलना
- systematic reasoning failure या generalization failure
- यह विधि उन मनमाने गलत उत्तरों का पता लगाने पर केंद्रित है जो इंसान को भी विश्वसनीय लगते हैं, और LLM output की factuality guarantee प्रदान नहीं करती
Semantic Entropy का मुख्य विचार
- सामान्य entropy calculation model द्वारा generate की गई token sequences की probability distribution का उपयोग करती है
- एक ही सही उत्तर को कई expressions में लिखा जा सकता है, इसलिए अर्थ समान होने पर भी शब्द अलग हों तो entropy अधिक मापी जा सकती है
- naive entropy expression की विविधता और semantic difference में फर्क नहीं कर पाती
- Semantic entropy free-form generated answers को semantic units में group करने के बाद uncertainty estimate करती है
- समान अर्थ वाले answers को एक semantic cluster में रखा जाता है
- clusters की probabilities जोड़कर semantic-unit entropy की गणना की जाती है
- जब एक ही प्रश्न का कई बार उत्तर दिलाया जाता है और केवल expression बदलता है लेकिन अर्थ समान रहता है, तो इसे कम uncertainty माना जाता है; अलग-अलग अर्थ वाले उत्तर मिलें तो इसे अधिक uncertainty माना जाता है
- जिन models में output probabilities उपलब्ध नहीं हैं, वहां discrete semantic entropy लागू की जा सकती है
- token probabilities के बजाय हर semantic cluster में samples की संख्या के अनुपात का उपयोग किया जाता है
- GPT-4 experiment में उस समय output probabilities और hidden state access उपलब्ध नहीं था, इसलिए यह variant इस्तेमाल किया गया
- discrete variant standard estimator जैसी performance दिखाता है
Algorithm: sampling, semantic clustering, entropy calculation
- प्रक्रिया तीन चरणों से बनी है
- Generation: एक ही input के लिए कई answers sample किए जाते हैं
- Clustering: answers को समान अर्थ वाले groups में रखा जाता है
- Entropy estimation: समान semantic cluster में आने वाली sequence probabilities को जोड़कर entropy निकाली जाती है
- Semantic equivalence को two-way implication से approximate किया जाता है
- यदि sentence A, sentence B को imply करता है, और sentence B भी sentence A को imply करता है, तो उन्हें समान अर्थ माना जाता है
- “The capital of France is Paris” और “Paris is the capital of France” एक-दूसरे को imply करते हैं, इसलिए उन्हें समान अर्थ माना जाता है
- “Paris” जैसे छोटे answer केवल question context के भीतर ही लंबे answer के समान अर्थ वाले हो सकते हैं
- Implication judgement के लिए general LLM और NLI tools का उपयोग किया जाता है
- QA और math experiments में GPT-3.5 को चुना गया क्योंकि यह human evaluation से अच्छी तरह मेल खाता था और confabulation detection performance अच्छी थी
- DeBERTa-Large-MNLI जैसे NLI models की भी समीक्षा की गई
- Sampling में temperature 1, nucleus sampling P=0.9, top-K sampling K=50 का उपयोग किया गया
- Model accuracy evaluation के लिए कम temperature 0.1 वाली single generation का उपयोग किया गया
- लंबे sentences में token probabilities का product छोटा हो जाने की समस्या होती है, इसलिए log probability comparison में length normalization का उपयोग किया गया
QA और math problems का evaluation
- Evaluation targets ऐसे datasets हैं जिन्हें free-form answers चाहिए
- TriviaQA: quiz knowledge
- SQuAD 1.1: Wikipedia-based reading comprehension
- BioASQ: life sciences question answering
- NQ-Open: Google Search की real queries से निकले open-domain questions
- SVAMP: elementary math word problems
- हर dataset से 400 train examples और 400 test examples randomly sample किए गए
- Semantic entropy स्वयं train data का उपयोग नहीं करती
- Problems को कठिन बनाने और confabulation induce करने के लिए dataset का original context passage नहीं दिया गया
- उपयोग किए गए models ये हैं
- LLaMA 2 Chat 7B, 13B, 70B
- Falcon Instruct 7B, 40B
- Mistral Instruct 7B
- sentence-length answers की औसत लंबाई 96±70 characters थी, और 30 task-model combinations में semantic entropy ने सबसे अधिक औसत AUROC दर्ज किया
- semantic entropy: 0.790
- naive entropy: 0.691
- P(True): 0.698
- embedding regression: 0.687
- Model family और size के हिसाब से भी semantic entropy की performance stable रही
- LLaMA, Falcon, Mistral में AUROC 0.78~0.81 range
- 7B से 70B तक के sizes में भी baseline से अधिक
- P(True) model size बढ़ने के साथ improve होने की प्रवृत्ति दिखाता है, इसलिए बहुत capable और honest model जो setting को अच्छी तरह समझता हो, वहां यह अधिक competitive हो सकता है
- गलत उत्तरों का detection evaluate करते समय confabulation के साथ-साथ ऐसे systematic wrong answers भी शामिल थे जिन्हें semantic entropy सीधे target नहीं करती
- फिर भी semantic entropy का अन्य methods से आगे रहना बताता है कि real generated errors में confabulation एक प्रमुख category है
Refusal-based accuracy और evaluation metrics
- AUROC का उपयोग इस binary event के लिए किया जाता है कि कोई particular answer गलत है या नहीं
- Value 0~1 range में होती है; 1 perfect classifier और 0.5 बिना जानकारी वाले classifier को दर्शाता है
- AURAC refusal accuracy curve के नीचे का area है
- जब confabulation की संभावना अधिक माने गए questions को refuse किया जाता है, तो बचे हुए questions पर model accuracy मापी जाती है
- यह कई thresholds पर user को मिलने वाले accuracy improvement का summary देता है
- Semantic entropy का उपयोग नीचे की स्थितियों में किया जा सकता है
- ऐसे questions का answer न देना जिनसे confabulation trigger होने की संभावना अधिक हो
- User को बताना कि किसी particular answer की reliability कम है
- Search या retrieval जैसी अधिक grounded procedures को supplement करना
- sentence-length answers के correct/incorrect judgement को इस तरह automate किया गया कि GPT-4 reference answer और proposed answer के semantic match को judge करे
- अलग supplementary material में human judgement से तुलना कर automatic evaluation quality verify की गई
लंबी biography generation: FactualBio experiment
- लंबे paragraphs में कई propositions मिले होते हैं, इसलिए पूरे paragraph की semantic equivalence सीधे judge करना मुश्किल होता है
- वही paragraph फिर से generate करने पर facts की uncertainty के बजाय facts के order या paragraph structure में अंतर दिख सकता है
- FactualBio GPT-4 v.0613 द्वारा generate किया गया biography dataset है
- ऐसे 21 लोगों को target किया गया जो इतने प्रसिद्ध हैं कि उनका Wikipedia page है, लेकिन जिनकी online detailed biographies बहुत अधिक नहीं हैं
- Generated biographies से 150 factual propositions automatically extract किए गए
- 150 में से 45 को manual labeling में incorrect claims माना गया
- Long generation के लिए नीचे की procedure लागू की गई
- Paragraph को अलग-अलग factual claims में decompose किया गया
- हर factual claim को answer बनाने वाले questions automatically generate किए गए
- Original LLM ने हर question के लिए नए answers generate किए
- नए answers और original factual claim को साथ रखकर semantic entropy calculate की गई
- कई questions की semantic entropy को average करके उस factual claim का uncertainty score मिला
- हर fact के लिए 6 questions बनाए गए, और हर question के लिए 3 नए answers generate किए गए
- Original factual claim को शामिल करके entropy calculate करने से original claim की grounding बनी रहती है
- यदि “not available”, “not provided”, “unknown”, “unclear” जैसे refusal answers आधे से अधिक हों, तो semantic uncertainty को maximum माना गया
- Discrete semantic entropy ने FactualBio में self-check baseline और paragraph-length के लिए P(True) variants से अधिक AUROC और AURAC दर्ज किया
- rejection accuracy में questions के 20% reject होने तक discrete semantic entropy बेहतर थी, और उस point पर P(True) थोड़ा आगे निकला
सीमाएँ और applicability
- Semantic entropy को model architecture में बदलाव किए बिना LLM या similar foundation model पर लागू किया जा सकता है
- Output probabilities न होने वाली restricted access environments में भी discrete variant इस्तेमाल किया जा सकता है
- Supervised learning approaches के उलट labeled confabulation examples की जरूरत नहीं होती, और यह prior domain knowledge के बिना नए tasks पर generalize करती है
- embedding regression जैसे supervised methods में training data और deployment data distributions अलग हों तो performance गिरती है
- यह method उन situations को सीधे solve नहीं करती जहां LLM confidence के साथ गलत होता है
- Learning objectives जो systematically dangerous behavior बनाते हैं
- Systematic reasoning errors
- Outputs जो users को systematically mislead करते हैं
- ये cases confabulation जैसे symptoms दिखा सकते हैं, लेकिन अलग handling की जरूरत होती है
- यह approach अर्थ के आधार पर probabilistic machine learning के uncertainty estimation tools को free-form language generation के अनुरूप लागू करती है, और task-specific data के बिना नए tasks पर generalize करने तथा users को अधिक सावधानी वाली situations पहचानने में मदद करती है
Data और code
- Short phrase और sentence-length generation experiments में public datasets इस्तेमाल किए गए हैं, और access method public code में शामिल है
- FactualBio का public version paragraph-length experiments reproduce करने वाले codebase के हिस्से के रूप में दिया गया है
- Code public locations
- github.com/jlko/semantic_uncertainty: short-phrase और sentence-length experiment code
- github.com/jlko/long_hallucinations: paragraph-length experiment code
- Zenodo DOI: https://doi.org/10.5281/zenodo.10964366
1 टिप्पणियां
Hacker News की राय
टिप्पणियां भले ही शब्दों के अर्थ या LLM के मानवीकरण पर बहस करती दिखती हों, लेकिन इस approach में गणितीय स्तर की एक वास्तविक समस्या है
किसी भी input text के लिए उससे मेल खाता output text distribution होता है, और कई samples लेकर entropy या inconsistency को evaluate करने का तरीका ऐसा लगता है जैसे यह पहले से ही उस output distribution की properties जानने की धारणा पर निर्भर है
उदाहरण के लिए “Tom Cruise किस लिए मशहूर हैं?” के लिए “movie star”, “katie holmes”, “topgun”, “scientology” जैसे vector space में दूर-दूर स्थित जवाब सभी सही हो सकते हैं
इसके उलट “Taylor Swift किस लिए मशहूर हैं?” पर “standup comedy”, “comedian”, “comedy actress” जैसे अर्थ में करीब जवाब आएं, तो वे सभी hallucination हो सकते हैं
अगर किसी खास input के लिए सही word sequence distribution जानना ही वह समस्या है जिसे LLM को हल करना है, तो सिर्फ output distribution evaluate करके यह तय करने का कोई तरीका नहीं है कि जवाब सही है या नहीं
artificial neural network output की uncertainty evaluate करने वाले statistical models तो हैं, लेकिन LLM scale पर वे practical नहीं लगते, और सिर्फ आखिरी 1–2 layers इस्तेमाल करने वाला partial estimate पूरे network की uncertainty को बहुत ज्यादा काट देता है
मुझे मिलने वाले hallucinations भी अक्सर variable name बदलने या config key गढ़ लेने जैसे होते हैं—बहुत plausible और सही के करीब दिखते हैं, लेकिन असल में गलत होते हैं
अगर training data Taylor Swift को comedian बताता है, तो वह hallucination की समस्या नहीं है
यह temperature घटाने जैसा सुनाई देता है। ऐसा लगता है कि यह evidence-based truth से बेहतर नहीं खींचता, बल्कि vector space में ज्यादा probabilistic दिशा की ओर जाता है; जानना चाहूंगा कि क्या यह समझ सही है
Tom Cruise वाले example में सब factual हैं और training data पर आधारित हैं, इसलिए यह technique गलती से उन्हें hallucination के रूप में positive classify कर सकती है
हालांकि paper के examples “यह specific drug किस receptor पर काम करती है?”, “Eiffel Tower कहां है?” जैसे single-correct-answer questions हैं, इसलिए ऐसे applications में यह मददगार लग सकता है
Gaussian distribution से samples लेकर standard deviation बताया जा सकता है, लेकिन यह नहीं बताया जा सकता कि वह distribution accurate है या नहीं
high entropy variable का बहुत accurate distribution भी possible है, और इसके उलट low standard deviation वाला dense distribution बस गलत भी हो सकता है। अगर पहले से यह न पता हो कि output कैसा होना चाहिए, तो sampling भर से पता नहीं चल सकता
यह कई answers sample करती है, उन्हें semantic similarity के हिसाब से groups में बांटती है, फिर grouped answers की probabilities को जोड़कर normalize करती है
उदाहरण के लिए “music:0.8, musician:0.9, concert:0.7, actress:0.5, superbowl:0.6” को [music, musician, concert] → MUSIC, [actress] → ACTING, [superbowl] → SPORTS में group करके, MUSIC:0.686, SPORTS:0.171, ACTING:0.143 जैसी calculation करती है
paper जिस चीज को रोकना चाहता है, उसे साफ तौर पर confabulation के रूप में define करता है। यानी random seed जैसी irrelevant details के प्रति संवेदनशील रूप से बदल जाने वाले, गलत और arbitrary मगर fluent claims
आम गलतफहमियां dataset में मजबूत रूप से मौजूद रहेंगी, और यह method उन answers को penalize करने के करीब है जो दूसरे possible answers से semantically isolated हों और जिनकी likelihood भी ambiguous हो
paper सिर्फ detection effect की तुलना करता है, और उस detection का इस्तेमाल करने वाली बेहतर sampling method पेश नहीं करता। अगर इसे generation technique में डालें, तो model generation को करीब 10 गुना और चलाने की बड़ी cost भी आएगी
code: https://github.com/jlko/semantic_uncertainty
मौजूदा LLM आर्किटेक्चर मुख्यतः retrieval की तरफ केंद्रित हैं, और सीखे हुए weights बस अगले token की prediction बेहतर करने की दिशा में converge करते हैं
मुझे लगता है कि इस data को किसी logical system के अंदर रखने की क्षमता भी training objective होनी चाहिए थी
next-token prediction में training stage की knowledge format verification जोड़ दी जाए, तो LLM knowledge generation की consistency बनाए रख सकेगा और सही hallucination, यानी imagination के करीब चीज़ों को देख सकेगा
प्रक्रिया कुछ ऐसी हो सकती है: मौजूदा बड़े model से मौजूदा training data को formal logical relations में बदलना, उससे कई solutions बनवाना, फिर उस augmented dataset से एक नया LLM train करना जो सिर्फ next token ही नहीं, बल्कि मौजूदा knowledge और नए generated text के बीच formal relation भी output करे
network token generation accuracy के साथ-साथ weights को इस तरह optimize कर सकता है कि generated formal code proof checker में high accuracy हासिल करे
निजी तौर पर मुझे लगता है कि भाषा intelligence की बुनियाद नहीं, बल्कि secondary चीज़ है; बुनियाद ज्यादा उस dream-like simulation जैसी है जिसमें आपस में consistent objects होते हैं, और भाषा उसे explain करने का tool लगती है
top-down approach को big data से पहले, probabilistic models से पहले के दौर में काफी आज़माया गया था, लेकिन इसमें भारी manual curation चाहिए थी और knowledge भी कम थी
big data के आने से curation की समस्या हल नहीं हुई; curation को automate नहीं किया जा सकता, इसलिए scale बढ़ने पर यह और खराब हो गई
AI के करीब 1990s में probability की तरफ मुड़ने से आज के associative probabilistic models संभव हुए, और यह उम्मीद नहीं दिखती कि ज्यादा curated और ज्यादा formal approaches इन्हें हरा पाएंगी
LLM में reasoning, causality जैसी Type 2 thinking चाहे जैसे जोड़ी जाए, implementation को लगातार probabilistic, informal और bottom-up ही रहना होगा
logic और semantic relations को इंसानों द्वारा knowledge model में manual curate करने का तरीका जरूरी scale और fragility से निपटने के लिए पर्याप्त नहीं है—यह पहले ही साफ हो चुका है
“Godel, Escher, Bach” देखें, या सोचें कि OWL 20 साल से मौजूद होने के बावजूद उसका market share लगभग क्यों नहीं रहा
asynchronous code management के लिए लोगों ने RETE के बजाय तरह-तरह के solutions क्यों आज़माए, “complex event processing” Celery जैसे task runner का competitor बनने के बजाय special field ही क्यों रहा, और Drools समझ आने वाले error messages क्यों नहीं दे पाता—सब इसी संदर्भ में है
पूरी hallucination समस्या बस halting problem में कुछ और steps जोड़ देने जैसी लगती है। शायद ChatGPT से पूछना चाहिए कि P=NP है या नहीं
मेरे अनुभव में इसे DAG के लिए meaningful relation schema कहा जा सकता है। open source version भी है, लेकिन company अब उसे सीधे maintain नहीं करती
https://cyc.com
https://github.com/asanchez75/opencyc
प्रकृति में मौजूद paradoxes, या वे theories जो आपस में contradictory हैं लेकिन अलग-अलग logically सही हैं, उनका क्या करेंगे?
कहना आसान है, लेकिन असल में यह प्रस्ताव देने जैसा है कि “अगर हम ऐसे NP-hard problem को हल कर दें जिसे हल करना हमें नहीं आता, तो यह काम करेगा”
इसे hallucination कहा जा सकता है, लेकिन दूसरे शब्दों में कहें तो ये systems truth के orthogonal हैं
यानी इनका true या false से कोई लेना-देना नहीं है
यह विचार इस paper में भी व्यक्त किया गया है: https://link.springer.com/article/10.1007/s10676-024-09775-5
algorithm के बारे में ऐसे बोलना जैसे उसमें personal traits हों, एक category error है
procedurally generated randomness brainstorming जैसे कामों के लिए बेहतरीन हो सकती है, और consistency इस बात का संकेत है कि कोई चीज़ training material में भी relatively consistently आई थी
इसलिए वह true भी हो सकती है, false भी, लेकिन कहीं से लाई गई होने की संभावना ज्यादा है
information कितनी random है, यह जानना एक छोटी प्रगति जैसा दिखता है
तो असल में उसे plausible bullshit बोलना सिखाया जा रहा है
यह improv acting class में बातचीत को interesting बनाए रखने और co-actor को “नहीं” न कहने की training देने जैसा है
computer जो कहता है वही “truth” बन सकता है
Jung शायद इसे “antinomy” कहते। goal truth को represent करना नहीं, बल्कि possible answers की totality को represent करना है
LLM जो करता है, आखिर वह सब “hallucination” ही तो नहीं है?
यह जानने के लिए कि hallucination हुआ है या नहीं, आपको सही जवाब पहले से पता होना चाहिए। अगर आप ऐसा system बना सकते हैं जो जानता हो कि जवाब सही है या नहीं, तो फिर LLM की जरूरत ही नहीं रहेगी
अभी LLM जो करता है उसे bullshitting कहना ज्यादा सही है। वह bullshit जितनी बेहतर होती जाती है, संयोग से सही होने का ratio बस उतना बढ़ता जाता है
कभी-कभी यह physical और social dynamics पर आधारित होकर consistent होता है, और कभी-कभी नहीं
स्पष्ट रूप से हमेशा सही रहने वाला system असंभव है, इसलिए हमें consistency की तलाश करने वाला system चाहिए
फिलहाल AI कंपनियों के लिए बेहतर हो सकता है कि वे chatbot को बस थोड़ा steer किए गए text generation tool के रूप में ही पेश करें
तब लोग उसे उसी हिसाब से इस्तेमाल कर पाएंगे
उसमें थोड़ा-सा समझ जैसा दिखता है, और उसे step-by-step reasoning की थोड़ी नकल करने के लिए भी बनाया जा सकता है, लेकिन इस black-box functionality का 95% text generation ही है
असल में यह generation भी knowledge generation नहीं है; encyclopedia से ज़्यादा यह improv acting partner के करीब है, और tech industry के लोग यह जानते हैं
मुझे नहीं पता कि LLM के लोगों को गुमराह करने की समस्या के लिए clever answer-entropy solution सच में ज़रूरी है या नहीं। वह solution दिलचस्प है, और statements पर confidence score लगाने जैसे तरीके से वास्तविक सुधार दे सकता है
लेकिन क्या machine-learning text generator को लगभग AGI की तरह market न करना ही ज़्यादातर नुकसान कम करके अधिक मददगार नहीं होगा?
सवाल पूछने पर LLM ने जवाब और JavaScript code दिया, और मेरी JavaScript भी काफी rusty थी
सारा code compile हुआ और ज़्यादातर उम्मीद के मुताबिक चला। errors भी थे, लेकिन जिन errors को मैं समझ नहीं पा रहा था, LLM ने उन्हें समझाया और काम करने वाला corrected code दिया
कुल मिलाकर यह mentor के साथ काम करने जैसा शानदार अनुभव था, और beginner होने के नाते इसने मेरा काफी समय बचाया। बेशक, results verify करना ज़रूरी है
95% वाला आंकड़ा कहाँ से आया? और यह text generation है या fact/knowledge generation, यह महत्वपूर्ण नहीं है। यह सचमुच valuable tool है और मैंने जो भी इस्तेमाल किया है, उससे कहीं बेहतर है
“हर question के लिए कई possible answers sample करना, और meaning में similar answers को algorithmically group करना” वाला तरीका उन सवालों के लिए reasonable है जिनका एक ही objective multiple-choice correct answer होता है
जहाँ कई equally valid answers संभव हों, वहाँ यह ज़्यादा मददगार नहीं हो सकता
फिर भी search engine applications के लिए यह काफी अच्छा है
semantic entropy का concept देखकर मुझे Enron scandal के बाद की वह घटना याद आई, जब किसी bank ने press releases में bullshit के level को मापने वाला “bullshitometer” बनाया था
उस bank का नाम याद नहीं है, लेकिन कहा जाता है कि Enron press releases पर apply करने पर उसने दिखाया कि company के collapse की prediction की जा सकती थी
statistics में sensitivity analysis नाम का concept होता है
यह तरीका भी कुछ हद तक वैसा ही लगता है, लेकिन एक interesting alternative यह हो सकता है कि input को ऐसे modify किया जाए जिसे meaning-preserving माना जाए, और फिर देखा जाए कि output meaning कैसे बदलता है
बेशक, meaning बदले बिना input बदलना कठिन हिस्सा है, लेकिन यह पूरी तरह असंभव नहीं लगता
कम से कम LLM से कहा जा सकता है कि meaning बदले बिना input बदलकर दिखाए। हालांकि model input को जिस गलत दिशा में समझ रहा हो, उसी के अनुसार modify कर सकता है, जिससे modification के बाद वह hallucinated output से और बेहतर match करने लगे
यह समझ आता है कि semantic entropy, जिसके लिए शायद semantic equivalence detect करने के लिए trained LLM चाहिए, hallucination को बेहतर पकड़ सकती है
लेकिन semantic equivalence hallucination समस्या को सीधे कैसे solve करती है, यह साफ़ नहीं दिखता
फिलहाल मुझे यह hallucination पकड़ने की heuristic के करीब लगता है
ऊपर से, ऐसे incidents पकड़ने के लिए semantic equivalence detection के लिए दूसरा LLM चाहिए, यह अनावश्यक रूप से complex लगता है
अगर semantic equivalence dataset हो, तो दूसरे LLM को train करने के बजाय मैं उसे मुख्य LLM training process में सीधे डालना चाहूँगा
हालांकि “meaning पर अच्छा AUC हासिल करना” जैसे कई स्पष्ट functions को mix करके, perceptual goal अस्पष्ट रखने वाले complex model की कमजोरियाँ compensate करने की कोशिश करें तो यह फिर भी अजीब हो जाता है
हमें नहीं पता कि mix सही हो रहा है या नहीं, और न ही यह कि हम training में unpredictable outcomes, risks और biases डाल रहे हैं या नहीं
“semantic equivalence judge कर सकता है या नहीं” जैसे narrowly defined task में unknown risks कम रखने वाला अच्छा model बनाया जा सकता है, और उसे अपेक्षाकृत clear तरीके से apply करने पर unknown risks भी घटते हैं
इसलिए दो थोड़े biased estimators से किसी specific reasonable heuristic तक रास्ता बनाना, existing complex mixture में data मिलाकर उसके contribution के predictable होने की उम्मीद करने से कहीं ज्यादा safe और general हो सकता है
मैं public-sector agencies के लिए LLM responses में factual errors का impact कम करने पर research कर रहा हूँ, जहाँ factual रूप से गलत answer देना illegal हो सकता है
अगर पर्याप्त accuracy से detect किया जा सके, तो system answer देने से refuse कर सकता है और user से agency से contact करने को कह सकता है
model को शुरू से ही गलत answer न देने के लिए train करना, बेशक, बेहतर है
अनावश्यक complexity API के जरिए access किए जाने वाले pretrained commercial black-box LLM के इस्तेमाल में भी आती है। दुर्भाग्य से applications में LLMs ज़्यादातर ऐसे ही इस्तेमाल होते हैं
API से fine-tune भी किया जा सकता है, लेकिन ऐसे बड़े synthetic datasets के लिए यह cumbersome, limited और बहुत महंगा है
लेख पढ़कर यह समझना मुश्किल था कि “semantic entropy” concretely कैसे calculate होती है। अगर रुचि हो, तो code समझना कहीं आसान है: https://github.com/jlko/semantic_uncertainty/blob/master/sem...
काफी clever idea है। उसी question को बार-बार पूछने पर model अलग-अलग answer देता है या नहीं, यह check करने का तरीका है
“checking” दूसरा model करता है, और “difference” entropy से measure होता है