दूसरे उछाल की शुरुआत | AI का पूरा इतिहास

011965〜1977 · ज्ञान की शक्ति

ज्ञान में ही शक्ति है

एक समझदार कंप्यूटर को सोचने के अच्छे तरीके चाहिए, या बहुत सारा ज्ञान?

1965 में स्टैनफ़र्ड विश्वविद्यालय आए फ़ाइगेनबाउम (Feigenbaum) और उनके साथियों ने DENDRAL में रसायन विशेषज्ञों का अनुभव शामिल किया। यह प्रोग्राम सभी संभव आणविक संरचनाओं की सूची बनाता था। विशेषज्ञों के मास स्पेक्ट्रोमेट्री डेटा पढ़ने के अनुभव को जैसे नियमों में लिखकर संभावित संरचनाओं की संख्या घटाई गई। निल्सन (Nilsson) (2010) के उदाहरण में, 14,715,813 संरचनाएँ डेटा से जुड़े नियमों के कारण लगभग 1,284,792 रह गईं, और एक अन्य माप जोड़ने पर केवल 1 बची।

दाईं ओर के चित्र में, 3 तरह के हिस्सों में से 6 को कतार में रखने के 729 तरीकों को नियम जोड़कर कम किया जाता है। जितना ज्ञान बढ़ता है, जाँचने वाली संभावनाओं की संख्या उतनी ही बड़े पैमाने पर घटती है।

1970 के शोधपत्र में 3 लेखकों ने लिखा, (अनुवाद)। 1977 में फ़ाइगेनबाउम ने विशेषज्ञों का ज्ञान कंप्यूटर में डालने के काम को ज्ञान इंजीनियरिंग कहा और इसे (अनुवाद) में समेटा।

N_बाकी ≈ N × r₁ × r₂ × … × r_k

N: सभी संभावित विकल्पों की संख्या
r_i: नियम i लगाने के बाद बचने वाला अनुपात (≈ एक अनुमान है, जब नियम एक-दूसरे को प्रभावित नहीं करते)

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:सरकार के श्वेतपत्र (2016) में (अनुवाद) लिखा है
मूल स्रोत के अनुसार:विशेषज्ञों के अनुभव को नियमों में बदलने वाला DENDRAL (1965 से) पहले आया था। इससे जुड़े शोधकर्ताओं ने 1993 के शोधपत्र के शीर्षक में DENDRAL को (अनुवाद) कहा। किस बिंदु से किसी प्रोग्राम को एक्सपर्ट सिस्टम माना जाए, इसके अनुसार जवाब बदलता है।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_knowledge_prune.py

# u06 知識で候補を絞る：専門家の「決まり」を足すたびに、考える候補が減っていく
#
# どの出来事か：1965 年からの DENDRAL（記録 dendral_1965）と、1977 年のファイゲンバウムの論文
#   「知識の中に力がある」（記録 feigenbaum_knowledge_bottleneck_1977）。
#   DENDRAL は、化学式から考えられる分子構造を網羅し、化学者の経験的なルールで候補を絞り込んだ。
#   Nilsson（2010）の例では、14,715,813 通りの構造が、質量分析のデータで約 1,284,792 通りに、別の測定も加えると 1 通りに絞られた。
# 仕組み：分子の代わりに、A・B・C の 3 種類の部品を 8 個つなぐ「並べ方」を全通り生成する（3 の 8 乗＝6,561 通り）。
#   専門家のルール（このサイトが作った例）を 1 つずつ適用して、残る候補を数える。
#   力任せの探索よりも、候補を絞り込む知識のほうが、答えに早く近づけることが分かる。
# 試してみよう：
#   - RULES の順番を入れ替えると、途中の数はどう変わるか。最後の数は変わるか
#   - 部品の数 N を 10 にすると、全体の数と、残る数はどうなるか

import math
from itertools import product

N = 8
PARTS = "ABC"

# 専門家のルール（このサイトが作った例）。どれも「この形はありえない」という知識
RULES = [
    ("はじめは A", lambda s: s[0] == "A"),
    ("C と C はとなり合わない", lambda s: "CC" not in s),
    ("B はちょうど 2 個", lambda s: s.count("B") == 2),
    ("最後は C", lambda s: s[-1] == "C"),
    ("A の次に B は来ない", lambda s: "AB" not in s),
    ("C はちょうど 3 個", lambda s: s.count("C") == 3),
    ("3 番目と 6 番目は同じ", lambda s: s[2] == s[5]),
    ("B と B はとなり合わない", lambda s: "BB" not in s),
    ("2 番目は A", lambda s: s[1] == "A"),
]

cands = ["".join(p) for p in product(PARTS, repeat=N)]
print(f"部品 {N} 個の並べ方：全部で {len(cands):,} 通り")

def bar(n):
    """対数目盛のバー表示（# 6 個で 10 倍）"""
    return "#" * max(1, round(math.log10(max(n, 1)) * 6)) if n else ""

for name, ok in RULES:
    cands = [s for s in cands if ok(s)]
    print(f"  ＋ルール「{name}」→ 残り {len(cands):>5,} 通り  {bar(len(cands))}")

print("\n残った候補：", cands[:10], "…" if len(cands) > 10 else "")
print("\nDENDRAL の実際の数値（Nilsson 2010）：14,715,813 → 約 1,284,792 → 1")
print("ルール（知識）を加えるほど、調べる数が桁違いに減る。これが「知識の中に力がある」の意味の 1 つ")

021972〜1978 · MYCIN

को जोड़ने वाला विश्वास गुणांक

वाले नियमों को आपस में कैसे जोड़ा जाए?

लगभग 1972 से, स्टैनफ़र्ड विश्वविद्यालय के शॉर्टलिफ़ (Shortliffe) और उनके साथियों ने MYCIN बनाया। यह प्रोग्राम बैक्टीरिया से होने वाले संक्रमणों के लिए दवा चुनने में डॉक्टरों को सलाह देता था। डॉक्टरों के ज्ञान को ऐसे नियमों में लिखा गया: अगर (जाँच का परिणाम ऐसा है), तो (बैक्टीरिया शायद ऐसा है)। शुरुआत में लगभग 200 नियम थे, जो 1978 तक लगभग 500 हो गए।

हर नियम के साथ विश्वास गुणांक (−1〜+1) होता है, जो बताता है कि वह कितना निश्चित है। शर्त अनिश्चित होने पर नियम के विश्वास गुणांक को शर्त की निश्चितता से गुणा किया जाता है। निर्माताओं की पुस्तक के उदाहरण में, नियम का विश्वास गुणांक 0.7 हो और उसकी 1 शर्त की निश्चितता 0.6 हो, तो परिणाम 0.42 होता है। जब कोई दूसरा नियम भी उसी निष्कर्ष का समर्थन करे, तो नीचे के सूत्र से दोनों को जोड़ा जाता है।

दाईं ओर के चित्र में (यह चिकित्सा का नहीं, साइकिल का उदाहरण है) कमजोर नियम जोड़ने पर विश्वास गुणांक 1 के पास पहुँचता जाता है, चाहे नियम कितने भी कमजोर हों। पुस्तक बताती है कि यह जोड़ने का तरीका प्रायिकता के सिद्धांत से नहीं, सहज समझ से तय किया गया था। निल्सन (Nilsson) (2010) द्वारा उद्धृत पाठ्यपुस्तक के अनुसार, नियम बढ़ने पर दूसरे नियमों के विश्वास गुणांक भी सुधारने पड़ते थे।

संयुक्त विश्वास गुणांक ＝x＋y(1 − x)

x: अब तक का विश्वास गुणांक
y: नए नियम से मिला विश्वास गुणांक (नियम का विश्वास गुणांक × शर्त की निश्चितता; 2 या अधिक शर्तें हों, तो सबसे कम निश्चितता)

इस्तेमाल किए गए नियमों की संख्या और संयुक्त विश्वास गुणांक

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_expert_rules.py

# u06 エキスパートシステムの仕組み：「もし〜なら〜」のルールと確信度、「なぜ？」に答える
#
# どの出来事か：1972 年からの MYCIN（記録 mycin_1972）。医師の知識を「もし〜なら〜」のルールとして書き込み、
#   ルールごとに確からしさ（確信度）を設定し、なぜそう判断したかを説明できた。初めは約 200、1978 年に約 500 のルール。
# このサンプル：同じ仕組みで「自転車の調子が悪い理由」を診断する（医学の助言はしない）。
#   ゴール（原因の候補）から逆向きに、ルールを使って確かめていく（後ろ向き推論）。
# 試してみよう：
#   - FACTS の答えを変えると、結論と確信度がどう変わるか
#   - ルールにない症状（例：「ベルが鳴らない」）を入れると、何も判断できない → 知識を書き足す手間（知識獲得のボトルネック）

FACTS = {   # 利用者の回答（はい＝True、いいえ＝False）
    "こぐと音がする": True,
    "チェーンがさびている": True,
    "タイヤを押すとへこむ": False,
    "ブレーキをかけていないのに重い": True,
    "ベルが鳴らない": True,
}

RULES = [
    # (番号, 条件（すべて満たす場合）, 結論, ルールの確信度)
    ("R1", ["こぐと音がする", "チェーンがさびている"], "チェーンの油切れ", 0.8),
    ("R2", ["タイヤを押すとへこむ"], "空気が少ない", 0.9),
    ("R3", ["ブレーキをかけていないのに重い", "タイヤを押すとへこむ"], "空気が少ない", 0.6),
    ("R4", ["ブレーキをかけていないのに重い"], "ブレーキがこすれている", 0.5),
    ("R5", ["こぐと音がする"], "チェーンの油切れ", 0.3),
]
GOALS = ["チェーンの油切れ", "空気が少ない", "ブレーキがこすれている"]

def combine(a, b):
    """同じ結論を別のルールが支持したときの計算（MYCIN の確信度の合成。正の値同士）"""
    return a + b * (1 - a)

def prove(goal, depth=0):
    """ゴールの確信度を求め、どのルールを使ったかの説明も返す。"""
    cf, why = 0.0, []
    for no, conds, concl, strength in RULES:
        if concl != goal:
            continue
        cond_cfs = [1.0 if FACTS.get(c) else 0.0 for c in conds]
        if min(cond_cfs) > 0:
            this = strength * min(cond_cfs)
            cf = combine(cf, this)
            why.append(f"{no}：もし {'・'.join(conds)} なら {concl}（確信度 {strength}）")
    return cf, why

for g in GOALS:
    cf, why = prove(g)
    print(f"{g}：確信度 {cf:.2f}")
    for w in why:
        print(f"   なぜ？ → {w}")

unknown = [f for f, v in FACTS.items() if v and not any(f in conds for _, conds, _, _ in RULES)]
print("\nルールが 1 つもないため、何も判断できなかった回答：", unknown)
print(f"現在のルールの数：{len(RULES)}。MYCIN は 1978 年に約 500。ルールを書き足し、直し続けるのが大仕事だった")

031970 का दशक · इन्फ़रेंस इंजन

आगे और पीछे से तर्क करना

बहुत सारे नियम हों, तो मशीन पहले कौन-सा नियम इस्तेमाल करती है?

विशेषज्ञों का ज्ञान नियमों के रूप में लेकर उत्तर और उसके कारण बताने वाले प्रोग्राम को एक्सपर्ट सिस्टम कहते हैं। नियमों को जोड़कर उत्तर तक पहुँचने वाला हिस्सा इन्फ़रेंस इंजन है। MYCIN के निर्माताओं की पुस्तक (1984) ने नियम जोड़ने के 2 तरीके बताए। आगे से तर्क करना (डेटा से) ज्ञात तथ्यों से शुरू होता है और नियमों को “अगर” से “तो” की ओर जोड़ता है। पीछे से तर्क करना (लक्ष्य से) उस लक्ष्य से शुरू होता है जिसे जाँचना है, पीछे की ओर चलता है और केवल उन तथ्यों के बारे में पूछता है जो अभी मालूम नहीं हैं। MYCIN मुख्य रूप से पीछे से तर्क करता था और उसे साक्ष्य जुटाने वाला प्रोग्राम भी कहा गया।

दाईं ओर के चित्र में (साइकिल का उदाहरण) 2 तरीकों की तुलना करें। आगे से तर्क करने में पहले सभी सवाल पूछे जाते हैं, फिर नियम इस्तेमाल होते हैं। पीछे से तर्क करने में केवल लक्ष्य से जुड़े सवाल पूछे जाते हैं।

MYCIN में नियमों का संग्रह (ज्ञान भंडार) और इन्फ़रेंस इंजन अलग थे। इसलिए चिकित्सा के नियम हटाकर EMYCIN नाम का खाली ढाँचा बनाया गया (E का अर्थ empty, यानी खाली है)। इसका उपयोग कर की योजना जैसे विषयों पर सलाह देने वाले सिस्टमों में भी हुआ।

आगे से: तथ्य → निष्कर्ष　　पीछे से: लक्ष्य → सवाल

आगे से: अगर (शर्त) से तो (निष्कर्ष) की ओर जाना
पीछे से: उलटी दिशा में “तो” से “अगर” तक जाना और केवल अधूरी जानकारी पूछना

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_forward_backward.py

# u06 前向き推論と後ろ向き推論：同じルールでも、適用する順番で「聞く質問の数」が変わる
#
# どの出来事か：MYCIN（記録 mycin_1972）。開発者たちの本（1984）は、分かっている事実からルールを左から右へ
#   つないでいくやり方を前向き（データから進む）、確かめたいゴールからルールを右から左へたどり、
#   足りない事実だけを聞くやり方を後ろ向き（ゴールから進む）と呼び、MYCIN は主に後ろ向きを使ったと書いている。
# このサンプル：医学ではなく「自転車の調子が悪い理由」の知識（このサイトが作ったルール）で比較する。
# 試してみよう：
#   - TRUTH（実際の状態）を変えて、それぞれ何問質問するかを比べる
#   - GOAL を「空気が少ない」に変える。後ろ向き推論は、どの質問を省略するか

TRUTH = {  # 使う人に聞けば分かる事実（実際の状態）
    "こぐと音がする": True,
    "チェーンがさびている": False,
    "雨の中に置いていた": True,
    "タイヤを押すとへこむ": False,
    "ブレーキをかけていないのに重い": True,
    "前に乗ったのは 1 か月以上前": True,
    "空気を入れたのは最近": False,
    "ブレーキのレバーが戻りにくい": False,
}

RULES = [  # (番号, もし（すべて満たせば）, なら)。「〜でない」は「not 〜」と書く
    ("R1", ["雨の中に置いていた"], "さびやすい所にあった"),
    ("R2", ["前に乗ったのは 1 か月以上前"], "しばらく乗っていない"),
    ("R3", ["こぐと音がする", "チェーンがさびている"], "チェーンの油切れ"),
    ("R4", ["こぐと音がする", "さびやすい所にあった"], "チェーンの油切れ"),
    ("R5", ["タイヤを押すとへこむ"], "空気が少ない"),
    ("R6", ["しばらく乗っていない", "ブレーキをかけていないのに重い", "not 空気を入れたのは最近"], "空気が少ない"),
    ("R7", ["ブレーキをかけていないのに重い", "ブレーキのレバーが戻りにくい"], "ブレーキがこすれている"),
]
GOAL = "チェーンの油切れ"

def forward():
    """前向き推論：まず事実をすべて確認し、使えるルールがなくなるまで適用を繰り返す"""
    known = dict(TRUTH)  # すべての質問を行う
    asked = len(TRUTH)
    changed = True
    while changed:
        changed = False
        for no, conds, concl in RULES:
            if concl not in known and all(known.get(c[4:]) is False if c.startswith("not ") else known.get(c) for c in conds):
                known[concl] = True
                changed = True
                print(f"   {no} を適用 → {concl}")
    return known.get(GOAL, False), asked

def backward(goal, known, asked, depth=0):
    """後ろ向き推論：ゴールを結論に持つルールを探し、その条件を新たなゴールとしてたどる。事実なら質問する"""
    if goal in known:
        return known[goal]
    concl_rules = [r for r in RULES if r[2] == goal]
    if not concl_rules:  # どのルールの結論でもない＝使う人に尋ねる事実
        known[goal] = TRUTH[goal]
        asked.append(goal)
        print("   " + "  " * depth + f"質問：{goal}？ → {'はい' if TRUTH[goal] else 'いいえ'}")
        return known[goal]
    for no, conds, _ in concl_rules:
        print("   " + "  " * depth + f"{no} を試す（{goal} を確かめるため）")
        ok = True
        for c in conds:
            neg = c.startswith("not ")
            v = backward(c[4:] if neg else c, known, asked, depth + 1)
            if v == neg:
                ok = False
                break
        if ok:
            known[goal] = True
            return True
    known[goal] = False
    return False

print("■ 前向き推論（データから）：")
ans, n = forward()
print(f"   答え：{GOAL} は {'あり' if ans else 'なし'}。聞いた質問 {n} 問\n")

print("■ 後ろ向き推論（ゴールから）：")
asked = []
ans = backward(GOAL, {}, asked)
print(f"   答え：{GOAL} は {'あり' if ans else 'なし'}。聞いた質問 {len(asked)} 問")
print("\n後ろ向き推論は、ゴールに関係のある質問しかしない。開発者たちが MYCIN を、証拠を集めるプログラムと呼んだ理由がここにある")

041970 का दशक · स्पष्टीकरण

मशीन से “क्यों?” पूछ सकते हैं

मशीन के दिए उत्तर पर कोई व्यक्ति कैसे भरोसा करे?

MYCIN के निर्माताओं ने शुरू से ही कारण समझाने को एक महत्त्वपूर्ण लक्ष्य माना था। जब MYCIN कोई सवाल पूछता, तो उपयोगकर्ता WHY (यह क्यों पूछ रहे हो?) लिख सकता था। MYCIN उस ऊपर के लक्ष्य को दिखाता जिसे वह अभी जाँच रहा था, साथ ही लक्ष्य को सवाल से जोड़ने वाला नियम भी दिखाता था। बार-बार WHY लिखने पर वह और ऊपर तक जाता था। HOW (यह कैसे पता चला?) लिखने पर वह इस्तेमाल किया गया नियम दिखाता, या बताता कि उपयोगकर्ता ने खुद ऐसा उत्तर दिया था।

दाईं ओर का चित्र साइकिल के बारे में सलाह का है। सवालों के उत्तर देते हुए “क्यों?” कुछ बार दबाएँ। चित्र में उन नियमों की कड़ी दिखेगी जिनकी अभी जाँच हो रही है।

पीछे से तर्क करने में हर सवाल किसी नियम की शर्त जाँचने के लिए आता है। इसलिए नियमों की कड़ी के रूप में कारण बताया जा सकता है।

क्यों? → ऊपर का लक्ष्य ＋ नियम　कैसे? → नियम／उत्तर

लक्ष्य: वह निष्कर्ष जिसे अभी जाँचना है
कड़ी: लक्ष्य से सवाल तक जुड़े हुए नियम

पुस्तक के अध्याय 18 में WHY और HOW के संवाद के उदाहरण हैं। वे चिकित्सा के उदाहरण हैं, इसलिए चित्र में उनकी जगह साइकिल का उदाहरण लिया गया है।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_why_how.py

# u06 「なぜ？」と「どうやって？」に答える相談の機械
#
# どの出来事か：MYCIN（記録 mycin_1972）。開発者たちの本（1984）の第 18 章によると、MYCIN が質問している時、
#   使う人は WHY（なぜそれを聞くのか）と入力できた。MYCIN は、いま確かめようとしている上のゴールと、
#   そのゴールと質問をつなぐルールを示した。WHY を繰り返すと、さらに上のゴールへさかのぼった。
#   HOW（どうやってそれが分かったのか）と入力すると、使ったルールか、使う人自身が答えたことを示した。
# このサンプル：医学ではなく「自転車の調子が悪い理由」の小さな知識（このサイトが作ったルール）。
#   input() の代わりに、ANSWERS に答えを、COMMANDS に質問ごとに打つ言葉を書いておく。
# 試してみよう：
#   - COMMANDS に "なぜ" を 3 回並べると、どこまでさかのぼるか
#   - ANSWERS を変えると、どのルールが使われ、HOW の答えがどう変わるか

ANSWERS = {"こぐと音がする": True, "チェーンがさびている": False, "雨の中に置いていた": True}
COMMANDS = {"雨の中に置いていた": ["なぜ", "なぜ"]}  # この質問の時に打つ言葉
HOW_AT_END = ["チェーンの油切れ", "さびやすい所にあった", "こぐと音がする"]

RULES = [
    ("R3", ["こぐと音がする", "チェーンがさびている"], "チェーンの油切れ", 0.8),
    ("R4", ["こぐと音がする", "さびやすい所にあった"], "チェーンの油切れ", 0.6),
    ("R1", ["雨の中に置いていた"], "さびやすい所にあった", 0.7),
]

how = {}    # 分かったこと → どうやって分かったか
stack = []  # いま確かめているゴールと使っているルール（WHY のために記録）
known = {}  # 分かったこと → はい・いいえ

def ask(fact):
    print(f"質問：{fact}？")
    level = len(stack)  # WHY で、どこまでさかのぼったか
    for cmd in COMMANDS.get(fact, []):
        print(f"  ** {cmd}")
        if cmd == "なぜ":
            if level == 0:
                print("     （これが、いちばん上のゴールです）")
                continue
            level -= 1
            goal, (no, conds, concl, cf) = stack[level]
            print(f"     → {concl} を確かめるためです。{no}：もし {'・'.join(conds)} なら {concl}（確信度 {cf}）")
    ans = ANSWERS[fact]
    print(f"  答え：{'はい' if ans else 'いいえ'}")
    how[fact] = "あなたがそう答えた"
    return ans

def prove(goal):
    if goal in known:
        return known[goal]
    rules = [r for r in RULES if r[2] == goal]
    if not rules:
        known[goal] = ask(goal)
        return known[goal]
    for rule in rules:
        stack.append((goal, rule))
        ok = all(prove(c) for c in rule[1])  # all は、いいえが出たところで止まる
        stack.pop()
        if ok:
            how[goal] = f"{rule[0]} を使った（{'・'.join(rule[1])} がそろった）"
            known[goal] = True
            return True
    how[goal] = "使える決まりが無かった"
    known[goal] = False
    return False

result = prove("チェーンの油切れ")
print(f"\n結論：チェーンの油切れ は {'あり' if result else 'なし'}\n")
for f in HOW_AT_END:
    print(f"** どうやって「{f}」が分かった？ → {how.get(f, 'まだ分かっていない')}")

051974 · फ़्रेम

स्थिति के ढाँचे में ज्ञान रखना

सिर्फ “जन्मदिन की पार्टी” सुनते ही केक और उपहारों का खयाल क्यों आता है?

जून 1974 में, MIT के मिन्स्की (Minsky) ने अपनी रिपोर्ट (अनुवाद) में यह विचार दिया: जब कोई व्यक्ति नई स्थिति का सामना करता है, तो स्मृति से फ़्रेम नाम की संरचना निकालता है और उसके विवरण बदलकर उसे वास्तविक स्थिति के अनुसार ढालता है। फ़्रेम को उन्होंने (अनुवाद) कहा; इसमें खाली खाने (स्लॉट) होते हैं। इन खानों में आमतौर पर क्या होता है, उसके मान (डिफ़ॉल्ट मान) पहले से अस्थायी रूप से भरे होते हैं। रिपोर्ट में बच्चे की जन्मदिन की पार्टी में जाने का उदाहरण दिया गया।

दाईं ओर के चित्र को कहानी का 1-1 वाक्य पढ़वाएँ। लिखे हुए मानों से खाली खाने भरते हैं। जहाँ जानकारी नहीं दी गई है, वहाँ डिफ़ॉल्ट मान के आधार पर माना जाता है। डिफ़ॉल्ट मान से अलग होने पर खाना बैंगनी हो जाता है।

मिन्स्की ने बताया कि उनका लेखन (अनुवाद) जैसे रुख पर आधारित था। फिर आखिरी खंड में लिखा, “सामान्य ज्ञान को प्रभावी ढंग से दर्शाने की संभावना पर संदेह … कई छोटे कथन, जो अलग-अलग “सत्य” हों” (अनुवाद)। उन्होंने खुद फ़्रेम सिस्टम नहीं बनाया; कुछ वर्ष बाद उनके छात्रों ने बनाया (निल्सन (Nilsson), 2010)।

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर सबको एक साथ ऐसे बताया जाता है: “2रे उछाल का AI वह था जिसमें ज्ञान को या तर्क के सूत्रों के रूप में बहुत बड़ी मात्रा में लिखा जाता था”
मूल स्रोत के अनुसार:उसी समय का 1 प्रमुख विचार, फ़्रेम, आमतौर पर क्या होता है इसकी अपेक्षाएँ रखने वाले ढाँचे में ज्ञान दर्शाने की कोशिश करता था।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_frames.py

# u06 フレーム：よくある場面のひな型に、スロット（空き欄）と「とりあえずの値」を持たせる
#
# どの出来事か：1974 年 6 月のミンスキーの報告「知識を表すための枠組み」（記録 minsky_frames_1974）。
#   人は新しい場面に出会うと、記憶からフレームという枠組みを取り出し、細かいところを直して現実に合わせる、という考え方。
#   フレームにはスロット（空き欄）があり、そこには、ふつうはこうだというデフォルト（とりあえずの値）が入っている。
#   報告は、子どもの誕生会に行く場面を例に挙げている。
# このサンプル：誕生会のフレーム（スロットととりあえずの値は、このサイトが作った例）に、物語の文を 1 つずつ読ませる。
#   文に書かれた値でスロットを埋め、書かれていない所は、とりあえずの値で「たぶん〜」と考える。
#   とりあえずの値と違うことが書かれていたら「予想とちがう」と知らせる。
# 試してみよう：
#   - STORY に「ケーキはなかった」の文を足すと、どうなるか
#   - レストランのフレームを作って、同じ物語を読ませる（スロットがどれだけ埋まるか）

FRAME = {  # スロット（空き欄） → とりあえずの値
    "主役": "誕生日の子",
    "場所": "主役の家",
    "食べ物": "ケーキ",
    "プレゼント": "おもちゃ",
    "遊び": "ゲーム",
    "終わりに": "ろうそくを吹き消す",
}

STORY = [  # (文, スロット, 書かれた値)。文から値を取り出す処理は、ここでは人が書いておく
    ("今日はケンの 8 歳の誕生会だ。", "主役", "ケン"),
    ("みんなで公園に集まった。", "場所", "公園"),
    ("ぼくは本を包んで持っていった。", "プレゼント", "本"),
    ("おやつは大きなすいかだった。", "食べ物", "すいか"),
]

filled = {}
for sentence, slot, value in STORY:
    filled[slot] = value
    mark = "予想とちがう！" if value != FRAME[slot] and slot != "主役" else "埋まった　"
    print(f"{sentence:<16} → {slot}＝{value}　{mark}（とりあえずの値は {FRAME[slot]}）")

print("\n現在のフレーム：")
for slot, default in FRAME.items():
    if slot in filled:
        print(f"  {slot:<6}：{filled[slot]}（物語に書いてあった）")
    else:
        print(f"  {slot:<6}：たぶん {default}（書いていないので、とりあえずの値）")

print("\n書いていないことまで「たぶん」で埋められるのが、フレームの強み。")
print("そのかわり、とりあえずの値が現実と違うこともある（すいかの誕生会）。")

061979 · MYCIN का प्रदर्शन

नाम छिपाकर अंक देना

मशीन का उत्तर अच्छा है या नहीं, इसे निष्पक्ष ढंग से कैसे जाँचा जाए?

1979 के मूल्यांकन में, मस्तिष्क और रीढ़ की झिल्लियों में सूजन के रोग, मेनिन्जाइटिस, के 10 मरीजों में से हर 1 के लिए 10 उपचार योजनाएँ जुटाई गईं। ये MYCIN, स्टैनफ़र्ड के संक्रामक रोगों के 5 शिक्षक-चिकित्सकों, संक्रामक रोगों के एक फ़ेलो, आंतरिक चिकित्सा के एक रेज़िडेंट (प्रशिक्षु डॉक्टर), एक मेडिकल छात्र और वास्तव में किए गए उपचार की थीं। स्टैनफ़र्ड के बाहर के संक्रामक रोगों के 8 विशेषज्ञों ने बिना यह जाने कि किसने कौन-सी योजना दी थी, एक-एक करके अंक दिए (8 × 100＝800 मूल्यांकन)।

MYCIN की उपचार योजनाओं में से 65% के लिए (अनुवाद) कहा गया। 5 शिक्षक-चिकित्सकों के लिए यह अनुपात 42.5〜62.5% (औसत 55.5%) था। विशेषज्ञों के बहुमत ने जिन मरीजों के लिए MYCIN की योजना स्वीकार की, उनकी संख्या भी 10 में से 7 थी। दाईं ओर के चित्र में मापदंड बदलें और नाम दिखाएँ।

फिर भी निर्माताओं की पुस्तक (1984) कहती है, (अनुवाद)। वे यह भी चाहते थे कि नियमित उपयोग से पहले विशेषज्ञों का बहुमत 90% या उससे अधिक मामलों में उसे स्वीकार करे।

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर कहा जाता है, “MYCIN विशेषज्ञ डॉक्टरों से अधिक सटीक था, फिर भी कानून और ज़िम्मेदारी के मुद्दों के कारण अस्पतालों में उसका उपयोग नहीं हुआ”
मूल स्रोत के अनुसार:निर्माताओं की पुस्तक में बताए कारण थे: ज्ञान जोड़ने के खर्च और कर्मचारियों की समस्या, अगले शोध पर आगे बढ़ने की इच्छा, और सबसे बढ़कर यह बात कि (अनुवाद)। इनमें से कई कारण उपयोग की सुविधा और लगने वाली मेहनत से जुड़े थे।

071979〜1982 · PROSPECTOR

गुणक लगाकर अनुमान करना

सतह पर मिले संकेतों से भूमिगत खनिज निक्षेप का अनुमान कैसे लगाया जाए?

SRI का PROSPECTOR खनिज खोजने वाले भूवैज्ञानिक विशेषज्ञों को सलाह देने वाला AI था। 1979 में टोक्यो के अंतरराष्ट्रीय सम्मेलन में भी इसके प्रदर्शन का विश्लेषण प्रस्तुत हुआ। इसके नियम ऐसी कड़ियों में जुड़े थे: क्रिस्टल के आकार की खाली जगहों वाली चट्टान सल्फ़ाइड होने का संकेत है; सल्फ़ाइड के ऊपर बैराइट हो, तो वहाँ ठोस सल्फ़ाइड के निक्षेप हो सकते हैं। इस तरह तर्क से निष्कर्ष निकालने का नेटवर्क बनता था।

MYCIN के विश्वास गुणांक से अलग, PROSPECTOR ने प्रायिकता और बेयस के नियम का उपयोग किया। विशेषज्ञ हर नियम के लिए 2 संख्याएँ देते हैं: शर्त सही हो, तो ऑड्स कितने गुना होंगे (LS), और शर्त सही न हो, तो कितने गुना होंगे (LN)। दाईं ओर के चित्र में संकेत दबाने पर नेटवर्क के रास्ते से प्रायिकता बदलती है (गुणकों की संख्याएँ इस साइट ने उदाहरण के लिए बनाई हैं)।

1982 में माउंट टॉलमन (वॉशिंगटन राज्य) के मानचित्र डेटा से मोलिब्डेनम के निक्षेप की संभावना का +5〜−5 वाला मानचित्र बनाया गया।

ऑड्स ← ऑड्स × LS (हाँ) या × LN (नहीं)　　प्रायिकता ＝ ऑड्स ÷ (1＋ ऑड्स)

ऑड्स: होने की संभावना ÷ न होने की संभावना
LS · LN: विशेषज्ञों द्वारा तय किए गए 2 गुणक

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर कहा जाता है, “PROSPECTOR ने ऐसे खनिज निक्षेप खोजे जिन्हें मनुष्य नहीं खोज पाए थे”
मूल स्रोत के अनुसार:निर्माताओं के विवरण के अनुसार, उस जगह खनन कंपनी पहले ही 200 से अधिक छेद खोदकर निक्षेप खोज चुकी थी। वहाँ उसने (अनुवाद) और (अनुवाद) का सही अनुमान लगाया। और (अनुवाद)। यह बात केवल इसके एक निर्माता की पुस्तक से जाँची गई है।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_prospector_odds.py

# u06 PROSPECTOR の推論方法：「A は B を示す」ルールに、2 つの倍率をつけてオッズをかけ算する
#
# どの出来事か：SRI の PROSPECTOR（記録 prospector_mount_tolman_1982）。Nilsson（2010）によると、
#   ルールは「結晶の形の空洞がある岩は、硫化物がある印」（ルール 22）や、
#   「硫化物の上に重晶石があれば、塊状の硫化物の鉱床があるかもしれない」（ルール 3）のような形で、
#   ルール同士がつながった「推論の網」になっていた。地質の専門家はルールごとに 2 つの数値を与えた。
#   条件が正しい時にオッズが何倍に増えるか（ここでは LS）と、条件が誤りの時に何倍に減るか（ここでは LN）である。
#   それをベイズの規則で使い、結論の確率を計算した。
# このサンプル：同じ構造の小さなネットワーク（倍率と初期確率は、このサイトが作った数）。
#   手がかりの入力は はい（True）・いいえ（False）・分からない（None）。
#   ネットワーク途中の結論（硫化物がある）は確率で次へ渡す。その計算（はい と いいえ の間を直線で補間する）は、
#   このサンプルのやり方で、本物の PROSPECTOR の式そのものではない。
# 試してみよう：
#   - EVIDENCE の答えを変えて、鉱床の確率がどう動くかを見る
#   - LS を大きくすると、1 つの手がかりの影響がどれだけ変わるかを見る

PRIOR = {"硫化物がある": 0.10, "塊状の硫化物の鉱床": 0.01}

# (手がかり, 結論, LS＝正しい時の倍率, LN＝誤りの時の倍率)
RULES = [
    ("結晶の形の空洞がある岩", "硫化物がある", 20.0, 0.8),
    ("方鉛鉱が見つかった", "硫化物がある", 50.0, 0.9),
    ("硫化物がある", "塊状の硫化物の鉱床", 5.0, 0.2),
    ("重晶石が上にある", "塊状の硫化物の鉱床", 8.0, 0.6),
]

EVIDENCE = {"結晶の形の空洞がある岩": True, "方鉛鉱が見つかった": None, "重晶石が上にある": True}

def odds(p):
    return p / (1 - p)

def prob(o):
    return o / (1 + o)

def factor(pe, pe0, ph0, ls, ln):
    """手がかりの確率 pe から、結論のオッズを何倍にするかを計算する（はい＝LS、いいえ＝LN、初期値のまま＝1 倍）"""
    p_yes, p_no = prob(odds(ph0) * ls), prob(odds(ph0) * ln)
    if pe >= pe0:
        p = ph0 + (p_yes - ph0) * (pe - pe0) / (1 - pe0)
    else:
        p = p_no + (ph0 - p_no) * pe / pe0
    return odds(p) / odds(ph0)

def infer(node, depth=0):
    """結論の確率を、下の手がかりから順に計算する。手がかりの確率を返す"""
    pad = "  " * depth
    if node in EVIDENCE:
        v = EVIDENCE[node]
        return 0.5 if v is None else (1.0 if v else 0.0), 0.5
    o = odds(PRIOR[node])
    print(pad + f"{node}（初期確率 {PRIOR[node]:.3f}）")
    for ev, concl, ls, ln in RULES:
        if concl != node:
            continue
        pe, pe0 = infer(ev, depth + 1)
        f = factor(pe, pe0, PRIOR[node], ls, ln)
        o *= f
        print(pad + f"  ← {ev}（{pe:.2f}）：オッズ ×{f:.2f} → {prob(o):.3f}")
    return prob(o), PRIOR[node]

p, _ = infer("塊状の硫化物の鉱床")
print(f"\n塊状の硫化物の鉱床がある確率：{p:.3f}（初期確率は {PRIOR['塊状の硫化物の鉱床']}）")
print("手がかりはかけ算で効く。専門家が決めるのは、ルールごとの 2 つの倍率だけである")

081980 · R1 (XCON)

गायब हिस्सों को पहचानना

कंप्यूटर के ऑर्डर से उसे जोड़ने का नक्शा बनाने वाले नियम कैसे होते हैं?

कार्नेगी मेलन विश्वविद्यालय के मैकडरमॉट (McDermott) ने R1 बनाया, जिसे कंपनी के भीतर XCON कहते थे। यह DEC के VAX कंप्यूटर के ऑर्डर से हिस्सों की व्यवस्था तय करता था। एक कंप्यूटर में आमतौर पर लगभग 90 हिस्से होते थे, और ऑर्डर में अक्सर ज़रूरी हिस्से छूट जाते थे। R1 उन्हें पहचानकर जोड़ता और व्यवस्था का नक्शा बनाता था। जनवरी 1980 से DEC के कारखाने में इसका नियमित काम के लिए उपयोग हुआ।

R1 काम के नोट्स देखता, शर्तों से मेल खाते सभी नियम खोजता और उनमें से 1 को लागू करता। यह प्रक्रिया बार-बार चलती थी। 1980 के शोधपत्र में नियमों की संख्या 772 थी। एक ऑर्डर के लिए औसतन 1,056 बार नियम लागू होते थे और गणना का औसत समय 2.5 मिनट था। दाईं ओर के चित्र में “1 चक्र चलाएँ” दबाएँ (हिस्से और नियम इस साइट ने उदाहरण के लिए बनाए हैं)।

① शर्तें पूरी करने वाले सभी नियम खोजें → ② 1 चुनें → ③ लागू करके नोट्स बदलें → ①

काम के नोट्स: मौजूदा काम (जाँच, व्यवस्था, जोड़ना) और ज्ञात जानकारी

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_configurator.py

# u06 注文書から、足りない部品を足して、箱に並べる：「条件がそろった決まりを 1 つ実行する」をくり返す
#
# どの出来事か：R1（社内名は XCON）。1980 年 1 月から DEC の工場で使われた（記録 xcon_r1_dec_1980）。
#   1980 年の論文によると、R1 は OPS4 という言語で書かれ、作業のメモ（working memory）を見て、
#   条件を満たすルールをすべて見つけ、そのうち 1 つを実行する処理を繰り返した（recognize-act cycle）。
#   注文には必要な部品の不足が多く、それに気づいて補うのが大きな仕事だった。1 台は通常約 90 の部品。
# このサンプル：本物の VAX の部品ではなく、このサイトが作った小さな部品表と 8 つのルール。
#   ルールは「いまの作業（文脈）」ごとに分かれている（R1 のルールも、文脈の条件から始まっていた）。
# 試してみよう：
#   - ORDER のディスクを 5 台にすると、制御装置はいくつ追加されるか
#   - ルール R2 を消すと（RULES から外すと）、どんな誤った組み立てになるか

ORDER = {"CPU": 1, "メモリ": 3, "ディスク": 3, "端末": 2}
SLOTS_PER_BOX = 4          # 1 つの箱に入る基板の数（このサイトが作った数）
DISKS_PER_CONTROLLER = 2   # 1 つの制御装置につなぐディスクの数（このサイトが作った数）

wm = {"文脈": "点検", "部品": dict(ORDER), "箱": [[]], "置いた": {k: 0 for k in ORDER}, "ケーブル": 0, "足した": []}
BOARDS = ["CPU", "メモリ", "制御装置", "端末の板"]  # 箱の中に差し込む部品

def add(part, why):
    wm["部品"][part] = wm["部品"].get(part, 0) + 1
    wm["置いた"].setdefault(part, 0)
    wm["足した"].append(part)
    return f"{part} を追加（{why}）"

def next_unplaced():
    for p in BOARDS:
        if wm["置いた"].get(p, 0) < wm["部品"].get(p, 0):
            return p
    return None

def place(p):
    box = wm["箱"][-1]
    box.append(p)
    wm["置いた"][p] += 1
    return f"{p} を 箱 {len(wm['箱'])} の {len(box)} 番に配置"

RULES = [  # (名前, 条件, 実行)
    ("R1 制御装置が足りない", lambda: wm["文脈"] == "点検" and wm["部品"].get("制御装置", 0) * DISKS_PER_CONTROLLER < wm["部品"]["ディスク"],
     lambda: add("制御装置", "ディスクに対して不足")),
    ("R2 端末の板が無い", lambda: wm["文脈"] == "点検" and wm["部品"].get("端末", 0) > 0 and wm["部品"].get("端末の板", 0) == 0,
     lambda: add("端末の板", "端末をつなぐため")),
    ("R3 点検おわり", lambda: wm["文脈"] == "点検",
     lambda: wm.update(文脈="置く") or "不足なし → 文脈を「置く」へ"),
    ("R4 箱がいっぱい", lambda: wm["文脈"] == "置く" and next_unplaced() and len(wm["箱"][-1]) >= SLOTS_PER_BOX,
     lambda: wm["箱"].append([]) or add("箱", "空きが無い")),
    ("R5 次の板を置く", lambda: wm["文脈"] == "置く" and next_unplaced(),
     lambda: place(next_unplaced())),
    ("R6 置きおわり", lambda: wm["文脈"] == "置く",
     lambda: wm.update(文脈="ケーブル") or "配置完了 → 文脈を「ケーブル」へ"),
    ("R7 ディスクにケーブル", lambda: wm["文脈"] == "ケーブル" and wm["ケーブル"] < wm["部品"]["ディスク"],
     lambda: wm.update(ケーブル=wm["ケーブル"] + 1) or add("ケーブル", "ディスク 1 台に 1 本")),
    ("R8 おわり", lambda: wm["文脈"] == "ケーブル",
     lambda: wm.update(文脈="おわり") or "組み立て図を出力"),
]

cycle = 0
while wm["文脈"] != "おわり" and cycle < 100:
    cycle += 1
    ready = [r for r in RULES if r[1]()]          # ① 条件を満たすルールをすべて探す
    name, _, act = ready[0]                       # ② 1 つ選ぶ（ここでは表の上にあるもの＝特別なルールを優先）
    print(f"{cycle:>2} [{len(ready)} 個そろった] {name}：{act()}")   # ③ 実行して、作業のメモを書き換える

print("\n組み立て図：")
for i, box in enumerate(wm["箱"], 1):
    print(f"  箱 {i}：" + " ｜ ".join(box))
print(f"注文に無かったが追加した部品：{', '.join(wm['足した'])}")

091981 · जापान

उदाहरण वाक्य की नकल से अनुवाद

क्या व्याकरण के सभी नियम लिखे बिना भी अनुवाद हो सकता है?

क्योटो विश्वविद्यालय के मकोतो नागाओ (Makoto Nagao) ने लिखा कि उस समय के मशीन अनुवाद में एक विरोधाभास था: (अनुवाद)। इसलिए उन्होंने ऐसा तरीका सुझाया जिसमें अंग्रेज़ी और जापानी के बहुत सारे जोड़े वाले उदाहरण वाक्य रखे जाएँ, जैसे कोई व्यक्ति विदेशी भाषा सीखता है। जिस वाक्य का अनुवाद चाहिए, उससे सबसे मिलते-जुलते उदाहरण को खोजकर शब्द बदलें और अनुवाद करें। यह विचार अक्टूबर 1981 के NATO सम्मेलन में प्रस्तुत करने के लिए लिखे गए पाठ में था। वह सम्मेलन टोक्यो के पाँचवीं पीढ़ी के अंतरराष्ट्रीय सम्मेलन (19〜22 अक्टूबर) के अगले सप्ताह हुआ था।

उस पाठ के उदाहरण में, A man eats vegetables. (एक व्यक्ति सब्जियाँ खाता है।) से He eats potatoes. का अनुवाद वह आलू खाता है के रूप में किया जाता है। कारण यह है कि समानार्थी शब्दों के शब्दकोश में man और he, तथा vegetable और potato पास हैं। Acid eats metal. इस उदाहरण से मिलता-जुलता नहीं है, इसलिए अम्ल धातु को क्षरित करता है जैसा दूसरा उदाहरण चाहिए। दाईं ओर के चित्र में इसे आज़माएँ।

2015 की वैज्ञानिक संस्था की पत्रिका के शुरुआती लेख में लिखा है कि इस (अनुवाद) से बहुत बड़े पाठ डेटा और सांख्यिकी का उपयोग करने वाले अनुवाद पर शोध आगे बढ़ा।

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:कहा जाता है, “मकोतो नागाओ के 1984 के शोधपत्र ने उदाहरणों से मशीन अनुवाद की शुरुआत की”
मूल स्रोत के अनुसार:यह विचार अक्टूबर 1981 के सम्मेलन के पाठ में पहले ही लिखा जा चुका था। यह पुस्तक के रूप में 1984 में प्रकाशित हुआ।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_example_mt.py

# u06 例文をまねて訳す：最も似た例文を探し、単語を入れ替える（長尾真さんの 1981 年の着想）
#
# どの出来事か：長尾真さんの 1981 年 10 月の原稿（記録 nagao_analogy_translation_1981）。
#   英語と日本語の対訳例文を蓄えておき、訳したい文に最も似た例文を探す。
#   対応する単語を置き換えられるか（意味が近いか）をシソーラス（類語辞典）で確認し、
#   適切であれば、例文の訳語を置き換えて訳文を作る。
# このサンプル：例文と訳は、原稿の表にある例（A man eats vegetables. など）。
#   シソーラス（単語の分類）と類似度のスコアは、このサイトが作った小さな例。
# 試してみよう：
#   - EXAMPLES から「酸は金属を侵す」の組を消すと、Sulphuric acid eats iron. はどう訳されるか
#   - 自分で例文の組と、辞書の単語を追加してみる

EXAMPLES = [  # (主語, 動詞, 目的語) の英語と、その訳の (主語, 目的語, 動詞)
    (("man", "eats", "vegetables"), ("人", "野菜", "たべる")),
    (("acid", "eats", "metal"), ("酸", "金属", "侵す")),
]
# 類語の辞書：言葉 → (仲間の名前, 日本語)。仲間の木：生き物 > 人、物 > 食べ物・化学の物・金属
THESAURUS = {
    "man": ("人", "人"), "he": ("人", "彼"), "she": ("人", "彼女"), "president": ("人", "大統領"),
    "vegetables": ("食べ物", "野菜"), "potatoes": ("食べ物", "じゃがいも"), "bread": ("食べ物", "パン"),
    "acid": ("化学の物", "酸"), "sulphuric acid": ("化学の物", "硫酸"),
    "metal": ("金属", "金属"), "iron": ("金属", "鉄"), "copper": ("金属", "銅"),
}
PARENT = {"人": "生き物", "食べ物": "物", "化学の物": "物", "金属": "物"}

def close(a, b):
    """2つの単語の類似度：同じ単語 1.0、同じ仲間 0.8、同じ上位概念 0.3、その他 0"""
    if a == b:
        return 1.0
    ga, gb = THESAURUS[a][0], THESAURUS[b][0]
    if ga == gb:
        return 0.8
    return 0.3 if PARENT[ga] == PARENT[gb] else 0.0

def translate(subj, obj):
    best, best_s = None, -1
    for (es, ev, eo), jp in EXAMPLES:
        s = close(subj, es) * close(obj, eo)  # 両方とも置き換えられるときだけ、スコアが高くなる
        print(f"   例文「{es} {ev} {eo}」との近さ {s:.2f}")
        if s > best_s:
            best, best_s = ((es, ev, eo), jp), s
    if best_s < 0.5:
        return None
    (_, _, _), (js, jo, jv) = best
    return f"{THESAURUS[subj][1]}は{THESAURUS[obj][1]}を{jv}。"

for subj, obj in [("he", "potatoes"), ("sulphuric acid", "iron"), ("acid", "vegetables")]:
    print(f"訳したい文：{subj.capitalize()} eats {obj}.")
    out = translate(subj, obj)
    print(f"   → {out if out else '似た例文がないため、訳を出力しない'}\n")
print("eat の訳が「たべる」か「侵す」かは、文法規則ではなく、似た例文によって決まった")

101982〜1986 · जापान

यह कौन-सा उछाल था?

1980 के दशक के जापान में, उस समय AI की लोकप्रियता को क्या कहा जाता था?

जापान के राष्ट्रीय संसद पुस्तकालय की पूरे पाठ में खोज में, अक्टूबर 1982 की एक पत्रिका में पहले ही यह वाक्य था: (अनुवाद)। अगले महीने उसी पत्रिका ने लगभग 20 साल पहले के उछाल को (अनुवाद) कहा। 1985 में एक पुस्तक में (अनुवाद), संसद में (अनुवाद; यानी अभी 2वाँ उछाल है), और एक पत्रिका के विशेषांक के शीर्षक में (अनुवाद) लिखा था। उछालों को गिनने का तरीका एक जैसा नहीं था।

इसकी शुरुआत के कारण भी हर लेखक ने अलग बताए: पाँचवीं पीढ़ी की परियोजना, MYCIN की सफलता, फ़ाइगेनबाउम (Feigenbaum) की ज्ञान इंजीनियरिंग और AI बनाने के औज़ार। उछाल के बीच ही (अनुवाद) जैसा आलोचनात्मक स्वर भी था।

जुलाई 1986 में, 700 से अधिक लोग जुटे और जापानी कृत्रिम बुद्धिमत्ता सोसायटी बनी। उसके स्थापना प्रस्ताव में लिखा था कि अमेरिका में 1980 से AAAI है, फिर भी (अनुवाद)। दाईं ओर के चित्र में एक-एक नाम देखें।

111984 · उम्मीदें और चेतावनियाँ

एक ही सम्मेलन के 2 कमरे

उछाल के बीच, बेचने वाले और शोध करने वाले क्या एक ही भविष्य देख रहे थे?

अगस्त 1984 में, ऑस्टिन स्थित टेक्सास विश्वविद्यालय में अमेरिकी कृत्रिम बुद्धिमत्ता संस्था (AAAI) का सम्मेलन हुआ। प्रदर्शनी में, विशेषज्ञों का ज्ञान शामिल करने वाले AI टूल TIMM के ब्रोशर ने दावा किया, (अनुवाद)। उसमें लिखा था कि एक्सपर्ट सिस्टम बीमार नहीं पड़ते, नौकरी नहीं छोड़ते और समय से पहले रिटायर नहीं होते। एक पत्रकार को बेचने वालों की बातें कभी-कभी (अनुवाद) जैसी सुनाई देती थीं।

उसी सम्मेलन की “AI का अंधकार युग” चर्चा में, संचालक मैकडरमॉट (McDermott) ने (अनुवाद) बताई। लगभग 5 वर्षों के भीतर अमेरिका की रणनीतिक कंप्यूटिंग परियोजना विफल हो जाती है, जापान की पाँचवीं पीढ़ी भी अटक जाती है, नई कंपनियाँ दिवालिया हो जाती हैं, धन मिलना बंद हो जाता है और सभी अपने शोध का नाम बदल लेते हैं। उन्होंने बताया कि कुछ लोग इसे कहते हैं। दाईं ओर के चित्र में साल आगे बढ़ाएँ और देखें कि कौन-सी घटना कब हुई।

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर कहा जाता है, “1984 की चर्चा ने AI की सर्दी का बिल्कुल सही अनुमान लगाया था (सही निकली चेतावनी)”
मूल स्रोत के अनुसार:संचालक ने खुद कहा था, (अनुवाद)। उस स्थिति के कई हिस्से बाद में घटित हुए, लेकिन 5 वर्ष बाद सभी एक साथ नहीं हुए।

121983〜1984 · सामान्य समझ

पुरुष मरीज का “एम्नियोटिक द्रव”

जो बात नियमों में नहीं लिखी है, क्या मशीन उसे “गलत” पहचान सकती है?

MYCIN की पुस्तक (1984) के एक फुटनोट में यह कहानी है। जॉन मैककार्थी (John McCarthy) ने (अनुवाद) एक पुरुष मरीज के जाँच के नमूने (कल्चर का स्रोत) के रूप में एम्नियोटिक द्रव, यानी गर्भ में भ्रूण के चारों ओर का द्रव, दर्ज किया। MYCIN गलती पहचान नहीं पाया और उसने इसे स्वीकार कर लिया। इसका कारण था कि पुरुषों में एम्नियोटिक द्रव नहीं होता, यह आम जानकारी नियमों में कहीं नहीं लिखी थी।

मैककार्थी ने 1984 के लेख (अनुवाद) में बताया कि MYCIN को यह अनुमान नहीं है कि उपचार के बाद क्या होगा। वह (अनुवाद) का उत्तर भी नहीं दे सकता। निल्सन (Nilsson) (2010) ने ऐसे सिस्टमों की कमजोरी को नाज़ुक (brittle) कहा है।

दाईं ओर के चित्र में (साइकिल के बारे में सलाह) कोई असंभव उत्तर चुनें। सामान्य समझ के नियम जोड़ने पर सिस्टम उसे पहचान सकता है। लेकिन उत्तरों के प्रकार बढ़ने पर, उनकी आपसी संगति जाँचने वाले जोड़ों की संख्या तेज़ी से बढ़ती है।

जाँचने वाले जोड़ों की संख्या ＝n(n − 1)／2

n: उत्तरों (तथ्यों) के प्रकारों की संख्या। n＝100 हो, तो 4,950 जोड़े; 1,000 हो, तो 499,500 जोड़े

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर ऐसी बात सुनने को मिलती है: “एक कहानी है कि मैककार्थी ने MYCIN को छेड़ा था (अफ़वाह)”
मूल स्रोत के अनुसार:MYCIN के निर्माताओं ने खुद 1984 की पुस्तक के फुटनोट में को स्रोत बताया है। लेकिन मैककार्थी के 1984 के लेख में यह कहानी नहीं है।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_common_sense.py

# u06 常識の穴：ルールに書いていない「ありえない組み合わせ」を、システムはそのまま受け入れてしまう
#
# どの出来事か：MYCIN の本（1984）の注に書かれた話（記録 mycin_mccarthy_amniotic_1983）。ジョン・マッカーシーさんが
#   男性患者の検査材料を羊水と入力したところ、MYCIN は間違いに気づかず受け入れた。
#   マッカーシーさんは 1984 年の文章で、いくつかのエキスパートシステムには常識が必要だ、と書いた。
# このサンプル：医学ではなく自転車の相談（このサイトが作った知識）。ありえない答えを入力しても、ルールは動いてしまう。
#   「常識の決まり」（2 つの答えが両立するか）を足すと気づけるが、答えの種類 n が増えると、
#   確認する組み合わせの数は n（n − 1）／ 2 で増えていく。
# 試してみよう：
#   - COMMON_SENSE を空にすると、どうなるか
#   - n を 10・100・1000 にして、組み合わせの数を見る

FACTS = {"車輪の数": 3, "こぐと音がする": True, "チェーンの無い自転車": True, "空気を入れたのは今朝": True, "タイヤを押すとへこむ": True}

RULES = [
    (lambda f: f["こぐと音がする"], "チェーンの油切れ（確信度 0.3）"),
    (lambda f: f["タイヤを押すとへこむ"], "空気が少ない（確信度 0.9）"),
]

COMMON_SENSE = [  # 両立しない組み合わせ（このサイトが作った常識のルール）
    (lambda f: f["車輪の数"] != 2, "自転車の車輪は 2 つのはず（三輪車の相談ではない）"),
    (lambda f: f["チェーンの無い自転車"] and f["こぐと音がする"], "チェーンが無いのに、チェーンの油切れは考えられない"),
    (lambda f: f["空気を入れたのは今朝"] and f["タイヤを押すとへこむ"], "今朝入れたのにへこむなら、パンクを先に疑う"),
]

print("■ ルールだけ：")
for cond, concl in RULES:
    if cond(FACTS):
        print("   結論：", concl)

print("\n■ 常識のルールを足すと：")
for bad, why in COMMON_SENSE:
    if bad(FACTS):
        print("   おかしい！", why)

print("\n答えの種類 n と、両立するか確認する組み合わせの数 n(n-1)/2：")
for n in (5, 10, 100, 1000, 10000):
    print(f"   n = {n:>6,} → {n * (n - 1) // 2:>12,} 組")
print("常識は、書き出そうとすると膨大な数になる。この「もろさ」を、常識を大量に書き込んで乗り越えようとしたのが、1985 年の CYC プロジェクトだ。")

131985 · भविष्यवाणी

एक विश्वकोश जितनी सामान्य समझ

सारी सामान्य समझ लिखने में कितने साल लगेंगे?

1985 में, टेक्सास राज्य के ऑस्टिन स्थित MCC के लेनाट (Lenat) और उनके साथियों ने CYC परियोजना की घोषणा की। यह बहुत सारी सामान्य समझ की मदद से एक्सपर्ट सिस्टम की और ज्ञान जुटाने की कठिनाई दूर करने की कोशिश थी। अगले 10 वर्षों में वे 1 खंड वाले विश्वकोश (लगभग 30,000 प्रविष्टियाँ) का ज्ञान और उसके आधार की सामान्य समझ लिखेंगे। लगभग 400 प्रविष्टियाँ वे खुद ध्यान से लिखेंगे; बाकी को बहुत सारे टाइप करने वाले लोग कॉपी करके सुधारेंगे। काम की मात्रा (अनुवाद) थी। उन्होंने यह भी लिखा कि लगभग 10 वर्षों में लक्ष्य तक न पहुँचने पर परियोजना पर बड़े स्तर पर फिर से विचार करेंगे।

2023 में लेनाट और मार्कस (Marcus) ने CYC को (अनुवाद) कहा। उन्होंने लिखा कि उसके ज्ञान भंडार में हाथ से लिखे करोड़ों कथन हैं, जिन्हें 40 वर्षों और 2,000 व्यक्ति-वर्ष की मेहनत से बनाया गया। दाईं ओर के चित्र में साल आगे बढ़ाएँ।

लेकिन 150 व्यक्ति-वर्ष विश्वकोश टाइप करने वालों के काम के लिए थे और 2,000 व्यक्ति-वर्ष पूरे ज्ञान भंडार के लिए। इसलिए दोनों की गणना का दायरा समान नहीं है। कितनी सामान्य समझ लिखना पर्याप्त होगा, यह 1985 में भी अज्ञात था और आज भी अज्ञात है।

व्यक्ति-वर्ष ＝ लोगों की संख्या × वर्षों की संख्या　　2,000 व्यक्ति-वर्ष ÷ 40 वर्ष ＝ औसतन 50 लोग

व्यक्ति-वर्ष: 1 व्यक्ति के 1 वर्ष के काम की मात्रा

141982〜1987 · जापान

अनुवाद सॉफ़्टवेयर और

1980 के दशक में नियमों वाला मशीन अनुवाद कहाँ तक काम आ सकता था?

वित्त वर्ष 1982 में सरकार की विज्ञान और प्रौद्योगिकी एजेंसी की मशीन अनुवाद परियोजना Mu शुरू हुई। इसका लक्ष्य यह दिखाना था कि विज्ञान और तकनीक के शोधपत्रों के सारांशों का जापानी और अंग्रेज़ी के बीच अनुवाद किया जा सकता है। क्योटो विश्वविद्यालय के मकोतो नागाओ (Makoto Nagao) और उनके साथियों ने इसका नेतृत्व किया, और यह 1986 तक चली। उन्होंने 3 चरणों के लिए व्याकरण और शब्दकोश बनाए: वाक्य का विश्लेषण, उसकी संरचना को दूसरी भाषा के रूप में बदलना और वाक्य बनाना।

कंपनियों ने भी अनुवाद सॉफ़्टवेयर जारी किए (1984 में फ़ुजित्सु का ATLAS, मई 1986 से हिताची का HICATS/JE आदि)। सितंबर 1987 में हाकोने के मशीन अनुवाद शिखर सम्मेलन में नागाओ ने कहा, (अनुवाद)। उपयोगकर्ताओं की (अनुवाद) वाली अपेक्षा के बारे में उन्होंने कहा, (अनुवाद), और कंपनियों के बढ़ा-चढ़ाकर किए विज्ञापन को भी इसका एक कारण बताया। माज़्दा ने रखरखाव मैनुअल के अनुवाद में इसका उपयोग किया। शुरुआत में केवल 40% अनुवादों के लिए (अनुवाद) कहा गया, लेकिन उसने बताया कि फ़ुजित्सु के साथ सुधार करके सटीकता लगभग 80% तक पहुँचाई।

दाईं ओर के चित्र में तकनीकी शब्दों का शब्दकोश जोड़ें। मैनुअल के वाक्यों का अनुवाद हो सकेगा, लेकिन आम वाक्यों का अनुवाद नहीं बदलेगा।

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर माना जाता है, “मशीन अनुवाद का वास्तविक काम में उपयोग बहुत बाद में शुरू हुआ (2010 के दशक के डीप लर्निंग वाले अनुवाद से)”
मूल स्रोत के अनुसार:1987 के सम्मेलन के रिकॉर्ड के अनुसार, जापान में 10 से अधिक कंपनियाँ अनुवाद सॉफ़्टवेयर बेच रही थीं, और माज़्दा जैसी कंपनियाँ मैनुअल के अनुवाद के लिए उनका उपयोग भी करती थीं।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_transfer_mt.py

# u06 ルールに基づく翻訳機：解析 → 変換 → 生成の 3 段階と、専門用語の追加による精度の向上
#
# どの出来事か：国の機械翻訳プロジェクト Mu（1982〜1986 年、記録 mu_mt_project_1982）と、1980 年代の日本企業の翻訳ソフト
#   （記録 japan_commercial_mt_1984_1987）。Mu の 1985 年の論文では、解析・変換・生成の 3 段階の文法と辞書が示された。
#   1987 年の会議で、マツダは翻訳ソフトで自動車の整備マニュアルを翻訳し、初めは「よい、または直せる」訳が 40% だったが、
#   富士通と調整して約 80% の精度にしたと報告した。
# このサンプル：短い英文を日本語に翻訳する、このサイトが作った小さな翻訳機（本物の Mu や ATLAS ではない）。
#   ①解析：単語の品詞を辞書で引き、主語・動詞・目的語を見つける。
#   ②変換：英語の語順（主語・動詞・目的語）を日本語の語順（主語・目的語・動詞）へ並べ替える。
#   ③生成：助詞を補って文にする。辞書にない単語があると、訳を出さずに元の単語を残す。
# 試してみよう：
#   - ADD_DOMAIN を True にして、マニュアルの文の翻訳精度がどう変わるかを見る
#   - 日常の文（EVERYDAY）の精度は変わるか

ADD_DOMAIN = False

DICT = {  # 単語 → (品詞, 訳)。n＝名詞、v＝動詞
    "the": ("det", ""), "a": ("det", ""), "mechanic": ("n", "整備士"), "checks": ("v", "点検する"),
    "replace": ("v", "交換する"), "car": ("n", "車"), "engine": ("n", "エンジン"), "he": ("n", "彼"),
    "eats": ("v", "食べる"), "bread": ("n", "パン"), "reads": ("v", "読む"), "book": ("n", "本"),
}
DOMAIN = {  # 整備マニュアルの用語（専門用語の辞書）
    "technician": ("n", "整備士"), "tightens": ("v", "締める"), "tighten": ("v", "締める"), "bolt": ("n", "ボルト"),
    "drain": ("v", "抜く"), "oil": ("n", "オイル"), "inspect": ("v", "点検する"), "brake": ("n", "ブレーキ"),
    "pads": ("n", "パッド"), "coolant": ("n", "冷却水"),
}
MANUAL = ["the technician tightens the bolt", "drain the oil", "inspect the brake pads", "replace the coolant",
          "the mechanic checks the engine"]
EVERYDAY = ["he eats bread", "a child reads the book", "he reads a letter"]

def translate(sentence, dic):
    words = sentence.split()
    tags = [dic.get(w, ("?", w)) for w in words]                      # ① 解析：辞書を引く
    if any(t == "?" for t, _ in tags):
        return None, "辞書にない：" + ", ".join(w for w, (t, _) in zip(words, tags) if t == "?")
    nouns = [tr for t, tr in tags if t == "n"]
    verb = next((tr for t, tr in tags if t == "v"), None)
    vi = next(i for i, (t, _) in enumerate(tags) if t == "v")
    subj = next((tr for t, tr in tags[:vi] if t == "n"), None)          # 動詞より前の名詞＝主語
    obj = next((tr for t, tr in tags[vi + 1:] if t == "n"), None)       # 動詞より後の名詞＝目的語
    obj = "".join(tr for t, tr in tags[vi + 1:] if t == "n") or obj     # 名詞が 2 つ続く時は連結する
    out = (f"{subj}は" if subj else "") + (f"{obj}を" if obj else "") + verb   # ② 変換 ③ 生成
    return out + "。", ""

dic = dict(DICT, **(DOMAIN if ADD_DOMAIN else {}))
for name, test in (("整備マニュアルの文", MANUAL), ("日常の文", EVERYDAY)):
    ok = 0
    print(f"■ {name}（専門用語の辞書 {'あり' if ADD_DOMAIN else 'なし'}）")
    for s in test:
        out, why = translate(s, dic)
        ok += out is not None
        print(f"   {s:<32} → {out or '（訳せない）' + why}")
    print(f"   翻訳できた割合：{ok}/{len(test)}\n")
print("ルールに基づく翻訳機は、専門辞書とルールを追加するほど、その分野では精度が上がる。ただし分野外の文の精度は上がらない。")

151985 · जापान

गायन के अनुसार बजाने वाला रोबोट

अगर कोई थोड़ा ऊँचे स्वर में गाने लगे, तो साथ बजने वाला संगीत कैसे बदलेगा?

वासेदा विश्वविद्यालय की कई प्रयोगशालाओं ने 1980 में तैयारी शुरू की और 1981 से वाद्य बजाने वाला रोबोट WABOT-2 बनाया। सब कुछ करने वाला रोबोट बनाने के बजाय, उन्होंने लक्ष्य को (अनुवाद) तक सीमित किया, जिसमें कुशल हाथों और बुद्धि दोनों की ज़रूरत होती है। यह लोगों से जापानी में बात करता है, कैमरे से बाज़ार में मिलने वाला संगीत का लिखित स्वरपत्र लगभग 15 सेकंड में पढ़ता है और दोनों हाथों की उँगलियों तथा दोनों पैरों से इलेक्ट्रॉनिक ऑर्गन बजाता है। इसकी कुल स्वतंत्र गतियों की संख्या 50 थी और केवल गति के नियंत्रण के लिए 53 छोटे कंप्यूटर इस्तेमाल होते थे।

गायन के साथ बजाने के लिए यह गाने की आवाज़ से उसी समय स्वरों का डेटा बनाता है और स्मृति में रखे स्वरपत्र से तुलना करके अंतर खोजता है। अंतर तय मान (सीमा मान) से अधिक होने पर अगले प्रदर्शन में गीत का स्वरमान बदलकर गाने की आवाज़ से मिलाता था। स्वर की ऊँचाई को आधार 12 में लिखा जाता है: ऊपर का अंक ऑक्टेव और नीचे का अंक अर्धस्वर बताता है। पूरे सिस्टम को जोड़ने वाला नियंत्रण if-then नियमों के रूप में लिखा गया था। दाईं ओर के चित्र में गायक के स्वर का अंतर बदलें।

अर्धस्वरों की संख्या ＝12 × log₂(गायन की आवृत्ति ÷ स्वरपत्र के स्वर की आवृत्ति)

log₂: उस संख्या को पाने के लिए 2 को किस घात तक उठाना होगा
आवृत्ति 2 गुना: 1 ऑक्टेव (12 अर्धस्वर)

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर कहा जाता है, “त्सुकुबा एक्सपो में इलेक्ट्रॉनिक ऑर्गन बजाने वाला वासेदा विश्वविद्यालय का WABOT-2 था”
मूल स्रोत के अनुसार:निर्माताओं के 1985 और 1987 के शोधपत्रों के अनुसार, विज्ञान एक्सपो में जापान सरकार के थीम मंडप में प्रदर्शन करने वाला रोबोट WABOT-2 के आधार पर सुमितोमो इलेक्ट्रिक इंडस्ट्रीज़ का बनाया WASUBOT था।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_transpose.py

# u06 歌声に合わせて移調する：歌の高さのずれを半音単位で測り、伴奏を移調する
#
# どの出来事か：1985 年の演奏ロボット WABOT-2（記録 wabot2_wasubot_expo85_1985）。開発者らの 1985 年の論文によると、
#   歌声トラッキングの仕組みは、歌声からその場で音符コードを生成し、記憶させた楽譜と比較して演奏と歌声のずれを検出した。
#   ずれが一定のしきい値を超えると、次の演奏時に歌声に合わせて曲を移調した。
#   音の高さは 12 進数で表し、上の桁がオクターブ、下の桁が半音の違いを表した。
# このサンプル：同じ考え方で作った小さなモデル。歌声の周波数（Hz）は、このサイトが作った数（歌う人が 3 半音高く歌い出したと仮定）。
#   半音の数 ＝ 12 × log₂（歌の周波数 ÷ 楽譜の音の周波数）
# 試してみよう：
#   - SHIFT を -2 や 0.4 に変える（しきい値より小さいずれでは移調しない）
#   - THRESHOLD を変える

import math
import random

SCORE = [60, 60, 67, 67, 69, 69, 67, 65, 65, 64, 64, 62, 62, 60]  # 楽譜の音（番号 60 ＝ ド。1 つ上がると半音上）
SHIFT = 3.0       # 歌う人が楽譜より何半音高く歌うか（このサイトが作った数）
THRESHOLD = 0.5   # これより大きなずれで移調する（このサイトが作った数）
random.seed(6)

def hz(n):
    """音の番号 → 周波数（番号 69 ＝ 440 Hz のラ）"""
    return 440 * 2 ** ((n - 69) / 12)

def note_code(n):
    """論文と同じ考え方の 12 進法：上の桁＝オクターブ、下の桁＝半音（0〜11）"""
    o, s = divmod(round(n), 12)
    return f"{o}{'0123456789AB'[s]}"

sung = [hz(n + SHIFT) * (1 + random.gauss(0, 0.01)) for n in SCORE]   # 歌声（わずかに揺れる）
diffs = [12 * math.log2(f / hz(n)) for f, n in zip(sung, SCORE)]
print("楽譜 → 歌声（音符コード）  ずれ（半音）")
for n, f, d in zip(SCORE, sung, diffs):
    print(f"  {note_code(n)} → {note_code(69 + 12 * math.log2(f / 440))}   {d:+.2f}")

mean = sum(diffs) / len(diffs)
print(f"\nずれの平均：{mean:+.2f} 半音")
if abs(mean) > THRESHOLD:
    k = round(mean)
    print(f"しきい値 {THRESHOLD} を超えた → 伴奏を {k:+d} 半音移調する")
    print("移調した伴奏：", " ".join(note_code(n + k) for n in SCORE))
else:
    print("ずれが小さいので、そのまま演奏する")

161965 · फ़ज़ी सेट

कितने cm से कोई “लंबा” है?

“लंबे कद वाले व्यक्ति” की सीमा कितने cm है?

1965 में, कैलिफ़ोर्निया विश्वविद्यालय, बर्कले के ज़ादेह (Zadeh) ने अपने शोधपत्र (अनुवाद) में ऐसे समूहों का वर्णन किया जिनकी सीमा स्पष्ट नहीं होती, जैसे (अनुवाद)। उन्होंने 0〜1 की संख्या (सदस्यता की मात्रा) से बताया कि हर तत्व समूह का कितना सदस्य है। शोधपत्र में (अनुवाद) के उदाहरण के लिए f(10)＝0.2 और f(100)＝0.95 जैसे मान दिए गए हैं।

उन्होंने गणना के नियम भी तय किए। “A नहीं” के लिए 1 − f, “A या B” के लिए बड़ा मान और “A और B” के लिए छोटा मान लिया जाता है। दाईं ओर के चित्र में सामान्य सेट, जो 175 cm पर अचानक 0 से 1 हो जाता है, और धीरे-धीरे बदलने वाले फ़ज़ी सेट की तुलना करें। शोधपत्र यह भी कहता है कि यह सांख्यिकी से बिल्कुल अलग विचार है।

1980 में उन्होंने पीछे मुड़कर कहा कि वे शुरू से जानते थे कि fuzzy (धुँधला) शब्द में तुच्छ समझने का भाव है।

A नहीं: 1 − f_A　A या B: max(f_A, f_B)　A और B: min(f_A, f_B)

f_A: सेट A की सदस्यता की मात्रा (0〜1)
max · min: बड़ा मान · छोटा मान

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_membership.py

# u06 ファジィ集合：「入る・入らない」ではなく、「どのくらい入るか」を 0〜1 の数で表す
#
# どの出来事か：1965 年のザデーの論文「ファジィ集合」（記録 zadeh_fuzzy_sets_1965）。
#   論文は、ものがどれくらいその集合に含まれるかを、0 から 1 の数値（所属度）で表した。
#   例として「1 よりずっと大きい実数」の集合を挙げ、f(0)=0、f(1)=0、f(5)=0.01、f(10)=0.2、f(100)=0.95、f(500)=1 とした。
#   また、「でない」は 1 − f、「または」は大きい方（Max）、「かつ」は小さい方（Min）と定めた。
# このサンプル：①論文の数値を、あいだを直線でつないで使う ②「背が高い」「重い」の度合い（このサイトが作った例）から、
#   かつ・または・でない を計算する。
# 試してみよう：
#   - tall() の 160・185 を変えて、「背が高い」の度合いの形を変える
#   - 通常の集合（175 cm 以上なら 1、それ以外は 0）と比べる

POINTS = [(0, 0), (1, 0), (5, 0.01), (10, 0.2), (100, 0.95), (500, 1)]  # 論文の例

def much_greater_than_1(x):
    for (x0, y0), (x1, y1) in zip(POINTS, POINTS[1:]):
        if x0 <= x <= x1:
            return y0 + (y1 - y0) * (x - x0) / (x1 - x0)
    return 1.0

def ramp(x, a, b):
    """a 以下で 0、b 以上で 1、その間を直線でつなぐ（このサイトが作った例）"""
    return 0.0 if x <= a else 1.0 if x >= b else (x - a) / (b - a)

def tall(cm):
    return ramp(cm, 160, 185)

def heavy(kg):
    return ramp(kg, 55, 85)

print("「1 よりずっと大きい数」の度合い（論文の数値を直線で補間）")
for x in (1, 5, 10, 50, 100, 300):
    print(f"  {x:>4} → {much_greater_than_1(x):.2f}")

print("\n背が高い（ファジィ）と通常の集合（175 cm 以上）")
for cm in (158, 168, 174, 176, 182, 190):
    print(f"  {cm} cm → ファジィ {tall(cm):.2f}   通常 {1 if cm >= 175 else 0}")

print("\nかつ・または・でない（身長 178 cm・体重 62 kg の人）")
t, h = tall(178), heavy(62)
print(f"  背が高い {t:.2f}、重い {h:.2f}")
print(f"  背が高い かつ 重い   ＝ min = {min(t, h):.2f}")
print(f"  背が高い または 重い ＝ max = {max(t, h):.2f}")
print(f"  背が高く ない        ＝ 1 − f = {1 - t:.2f}")

171987 · जापान

फ़ज़ी नियंत्रण से मेट्रो रोकना

कुशल चालक ठीक निशान पर, बिना झटके के, ट्रेन कैसे रोकता है?

15 जुलाई 1987 को सेंदाइ शहर की मेट्रो शुरू हुई। हिताची के बनाए स्वचालित संचालन उपकरण में (अनुवाद) का उपयोग हुआ। कंपनी के 1988 के लेख के अनुसार, इसमें 3 चीज़ें जोड़ी गई थीं: (अनुवाद; अगर〜तो〜का रूप) में लिखे AI (ज्ञान इंजीनियरिंग) के नियम, कुशल चालक के कौशल की जगह काम करने वाला सिमुलेशन, और कई मापदंडों को 0〜1 की संतुष्टि के मानों में दर्शाकर जोड़ने वाला फ़ज़ी सिद्धांत। यात्रा के आराम, रुकने की स्थिति की सटीकता और ऊर्जा की बचत में सुधार हुआ। लेख इसे (अनुवाद) कहता है (यह इसे बनाने वाली कंपनी का कथन है)।

दाईं ओर का चित्र उसी विचार का सरल उदाहरण है, सेंदाइ का वास्तविक उपकरण नहीं। रुकने की स्थिति की त्रुटि और ब्रेक के बदलाव (झटके) के आधार पर 3 तरीकों की तुलना करें: केवल 1 नियम इस्तेमाल करना, कई नियम मिलाना, और आगे का अनुमान लगाकर अधिक संतुष्टि वाला ब्रेक चुनना।

संतुष्टि ＝min(रुकने की स्थिति से संतुष्टि, यात्रा के आराम से संतुष्टि) → सबसे अधिक मान वाला ब्रेक चुनें

रुकने की स्थिति से संतुष्टि: आगे का अनुमान लगाकर, लक्ष्य के जितना करीब रुकें उतना 1 के करीब
यात्रा के आराम से संतुष्टि: ब्रेक का बदलाव जितना कम हो उतना 1 के करीब (इस चित्र की व्यवस्था)

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर माना जाता है, “फ़ज़ी घरेलू उपकरणों का लोकप्रिय शब्द है”
मूल स्रोत के अनुसार:घरेलू उपकरणों से पहले ही इसका उपयोग 1987 में शुरू हुई सेंदाइ शहर की मेट्रो के स्वचालित संचालन में हो रहा था।

समय के साथ ब्रेक की ताकत

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_fuzzy_brake.py

# u06 ファジィ制御で電車を止める：「近くて速ければ、強めにブレーキ」のあいまいなルール
#
# どの出来事か：1987 年 7 月 15 日、仙台市の地下鉄が開業。列車の自動運転に「予見ファジィ制御」を使った
#   （記録 sendai_subway_fuzzy_ato_1987）。上手な運転士の技を、「もし〜なら〜する」の形のルールで書いた。
#   ファジィ集合そのものは、1965 年のザデーの論文から始まった（記録 zadeh_fuzzy_sets_1965）。
# このサンプル：同じ考え方の小さなモデル（仙台の装置そのものではない）。ホームの停止位置の 200m 手前から
#   時速 60km で入ってくる電車を止める。ルールはどちらも同じ 3 つ（少し→弱く、中くらい→中くらい、たくさん→強く）。
#   ①通常のルール：最も当てはまる 1 つだけを使う　②ファジィ制御：あてはまり具合に応じて 3 つを混ぜて使う。
#   停止位置の誤差と、ブレーキの強さの変わり方（乗り心地）を比べる。
# 試してみよう：
#   - OUT（ルールごとのブレーキの強さ）を変えてみる
#   - DT（制御の間隔の秒数）を 1.0 にすると、止まり方はどう変わるか

DT = 0.5           # 0.5 秒ごとに計算して制御する
MAX_DECEL = 1.2    # 最大ブレーキで 1 秒に速さが何 m/s 落ちるか（仮の数）

def tri(x, a, b, c):
    """三角形の「あてはまり具合」（0〜1）。b でいちばん 1 に近い"""
    if x <= a or x >= c:
        return 0.0
    return (x - a) / (b - a) if x < b else (c - x) / (c - b)

def need_ratio(dist, speed):
    """停止位置でちょうど止まるのに必要な減速度が、最大ブレーキの何倍か（先を読む＝予見）"""
    return speed * speed / (2 * max(dist, 0.5)) / MAX_DECEL

def memberships(dist, speed):
    ratio = need_ratio(dist, speed)                   # 1 なら最大ブレーキが必要
    few = tri(ratio, -1.0, 0.0, 0.6)                  # 必要な減速度は「少し」
    mid = tri(ratio, 0.3, 0.7, 1.0)                   # 「中くらい」
    big = min(1.0, max(0.0, (ratio - 0.8) / 0.3))     # 「たくさん」
    return few, mid, big

OUT = (0.1, 0.6, 1.0)   # ルールごとのブレーキの強さ：少し → 弱く、中くらい → 中くらい、たくさん → 強く

def fuzzy_brake(dist, speed):
    """ファジィ制御：3 つのルールを、あてはまり具合で重みをつけて混ぜる"""
    m = memberships(dist, speed)
    w = sum(m)
    return sum(mi * o for mi, o in zip(m, OUT)) / w if w else 0.0

def crisp_brake(dist, speed):
    """通常のルール：同じ 3 つのルールのうち、いちばん当てはまる 1 つだけを使う（はい・いいえ）"""
    m = memberships(dist, speed)
    return OUT[m.index(max(m))]

def run(brake):
    pos, v, t, last = 0.0, 60 / 3.6, 0.0, 0.0
    jumps, biggest = 0.0, 0.0
    while v > 0 and t < 300:
        b = brake(200 - pos, v)
        jumps += abs(b - last)
        biggest = max(biggest, abs(b - last))
        last = b
        v = max(0.0, v - b * MAX_DECEL * DT)
        pos += v * DT
        t += DT
    return 200 - pos, jumps, biggest, t

for name, f in (("通常のルール（1 つだけ使う）", crisp_brake), ("ファジィ制御（混ぜて使う）", fuzzy_brake)):
    err, jumps, biggest, t = run(f)
    print(f"{name}：停止位置の誤差 {err:+.1f} m（＋は手前）、ブレーキの強さの変化の合計 {jumps:.1f}、1 回での最大変化 {biggest:.2f}、停止まで {t:.0f} 秒")
print("ブレーキの強さの変化が小さいほど、乗っている人はがくんと揺れない")

181980〜1990 · भविष्यवाणी को परखना

“मानक साधन” वॉशिंग मशीन में आया

फ़ज़ी के बारे में लगाए गए अनुमान का परिणाम कहाँ दिखा?

सितंबर 1980 में, ज़ादेह (Zadeh) ने लिखा कि फ़ज़ी सेट सिद्धांत का उपयोग औद्योगिक प्रक्रिया नियंत्रण से चिकित्सा में रोग पहचानने तक होने लगा है और (अनुवाद)। उन्होंने कोई अंतिम वर्ष नहीं बताया।

7 वर्ष बाद, 1987 में सेंदाइ शहर की मेट्रो ने इसे अपनाया। 1989 में 48 कंपनियों ने अंतरराष्ट्रीय फ़ज़ी इंजीनियरिंग अनुसंधान प्रयोगशाला (LIFE) बनाई। 1 फ़रवरी 1990 को मात्सुशिता इलेक्ट्रिक ने वॉशिंग मशीन “आइसाइगो Day फ़ज़ी” जारी की। पानी का गंदलापन स्थिर होने में लगने वाले समय और उसके स्थिर होने पर प्रकाश पारगम्यता के आधार पर, यह (अनुवाद) जैसे 6 नियमों से धुलाई का समय तय करती है। उस वर्ष नए शब्द और प्रचलित शब्द पुरस्कारों की नए शब्द श्रेणी का स्वर्ण पुरस्कार को मिला। दाईं ओर के चित्र में गंदगी की मात्रा और प्रकार बदलें।

धुलाई का समय ＝Σ(मेल की मात्रा × नियम का समय) ÷ Σ मेल की मात्रा

मेल की मात्रा: min(T की मात्रा, V की मात्रा)
T: गंदलापन स्थिर होने में लगने वाला समय
V: स्थिर होने पर प्रकाश पारगम्यता

समय के साथ प्रकाश पारगम्यता का बदलाव (वक्र और नियम दोनों इस साइट ने उदाहरण के लिए बनाए हैं)

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_fuzzy_washer.py

# u06 ファジィ洗濯機：水の濁り方から、洗い時間を 6 つの「もし〜なら〜」ルールで決める
#
# どの出来事か：1990 年 2 月 1 日に発売された松下電器の全自動洗濯機（記録 fuzzy_washer_ryukogo_1990 と、
#   ザデーの 1980 年の予測記録 zadeh_fuzzy_standard_tool_prediction_1980）。開発者の 1990 年の記事によると、
#   排水弁の近くで光を当て、洗濯水を通る光の強さ（透過度）を測定する。洗い始めると汚れが溶け出して透過度が下がり、
#   やがて落ち着く。落ち着くまでの時間 T（泥の汚れは早く、脂の汚れは遅い）と、落ち着いたときの透過度 V（汚れが多いほど低い）
#   から、6 つのルールのファジィ推論で洗い時間を決めた。ルールは「飽和時間が長く、かつ透過度が低ければ
#   洗濯時間をとても長くする」のような形式で、家庭で集めたデータと作る人のコツから作られた。
# このサンプル：同じ仕組みの簡易推論。6 つのルールの中身・形・時間（分）の数は、このサイトが作った例。
#   「かつ」は最小値（min）をとる。ルールごとの洗い時間を、あてはまり具合で重みをつけて平均する（後件部が数値の簡便法）。
# 試してみよう：
#   - T と V を変えて、洗い時間がなめらかに変化するか確認する
#   - ルールを 1 つ削除すると、どこで時間が急変するか確かめる

def ramp(x, a, b):
    return 0.0 if x <= a else 1.0 if x >= b else (x - a) / (b - a)

def t_short(t): return 1 - ramp(t, 60, 180)     # 落ち着くのが早い（秒）
def t_long(t): return ramp(t, 60, 180)          # 落ち着くのが遅い
def v_high(v): return ramp(v, 0.4, 0.8)         # 透過度が高い（きれい）
def v_mid(v): return 1 - abs(v - 0.55) / 0.25 if abs(v - 0.55) < 0.25 else 0.0
def v_low(v): return 1 - ramp(v, 0.3, 0.6)      # 透過度が低い（汚れが多い）

RULES = [  # (T の形, V の形, 洗い時間（分）)
    (t_short, v_high, 4), (t_short, v_mid, 7), (t_short, v_low, 10),
    (t_long, v_high, 6), (t_long, v_mid, 10), (t_long, v_low, 15),   # 飽和時間が長く、かつ透過度が低い → とても長く
]

def wash_time(T, V, show=False):
    w = [min(ft(T), fv(V)) for ft, fv, _ in RULES]
    if show:
        for (ft, fv, m), wi in zip(RULES, w):
            print(f"   もし T が{'短い' if ft is t_short else '長い'}、かつ V が{ {v_high: '高い', v_mid: '中くらい', v_low: '低い'}[fv]} なら {m:>2} 分 … あてはまり {wi:.2f}")
    return sum(wi * m for wi, (_, _, m) in zip(w, RULES)) / sum(w)

T, V = 150, 0.35   # 脂の汚れが多い場合（このサイトが作った数）
print(f"T = {T} 秒、V = {V}")
print(f"→ 洗い時間 {wash_time(T, V, show=True):.1f} 分\n")

print("T を変えたときの洗い時間（V = 0.5）")
for t in range(40, 221, 30):
    m = wash_time(t, 0.5)
    print(f"   T = {t:>3} 秒 → {m:4.1f} 分 " + "■" * round(m))

191980〜1989 · रखरखाव

नियम लगातार बढ़ते गए

नियमों वाला AI एक बार बन जाए, तो क्या काम पूरा हो जाता है?

R1 (XCON) के नियम जून 1980 के 772 से लगातार बढ़े। DEC ने रखरखाव सँभाला, तब लगभग 1,000 नियम थे। जुलाई 1982 के आसपास लगभग 2,000, 1984 में 2,500, और 1989 में संबंधित सिस्टमों को मिलाकर 17,500 हो गए। ऐसा इसलिए हुआ क्योंकि DEC के हर नए उत्पाद के साथ कंप्यूटर जोड़ने का काम खुद बदलता था।

DEC के लोगों के 1984 के लेख के अनुसार, ज्ञान लगातार जोड़ने में हर वर्ष लगभग 4 लोगों के काम जितनी मेहनत लगती थी। रखरखाव के बारे में उन्होंने कहा, (अनुवाद), और इसके लिए विशेष रूप से प्रशिक्षित लोग चाहिए। उसी 1984 में प्रदर्शनी के ब्रोशर ने दावा किया था कि एक्सपर्ट सिस्टम नौकरी नहीं छोड़ते और रिटायर नहीं होते।

नए नियम पुराने नियमों से विरोध तो नहीं करते, यह जाँचना ज़रूरी है। दाईं ओर के चित्र में किसी बिंदु को दबाने पर उस समय के नियमों की संख्या और उनके जोड़ों की संख्या दिखाई देती है।

जोड़ों की संख्या ＝n(n − 1)／2

n: नियमों की संख्या। 772 हों, तो 297,606 जोड़े; 17,500 हों, तो लगभग 153 मिलियन जोड़े

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर कहा जाता है, “XCON हर वर्ष 40 मिलियन डॉलर बचाने वाला बेहद सफल AI था”
मूल स्रोत के अनुसार:यह संख्या DEC के एक व्यक्ति के 1989 के शोधपत्र में दिए (अनुवाद) के अनुमान की है। इस साइट ने इसे केवल निल्सन (Nilsson) के उद्धरण से जाँचा है। DEC के लोगों के 1984 के लेख में कोई धनराशि नहीं दी गई; उसमें रखरखाव की मेहनत बताई गई है।

201977〜 · ज्ञान जुटाना

सँकरी नली को चौड़ा कैसे करें?

विशेषज्ञ के मन का ज्ञान कंप्यूटर में कैसे डाला जाए?

1977 में, फ़ाइगेनबाउम (Feigenbaum) ने अपने आमंत्रित शोधपत्र (अनुवाद) में लिखा, (अनुवाद)। बॉटलनेक का अर्थ बोतल की गर्दन जैसी सबसे सँकरी जगह है। ज्ञान निकलवाने में कम मेहनत लगने का उदाहरण भी था। फेफड़ों की जाँच के परिणामों से रोग पहचानने वाले प्रोग्राम PUFF ने विशेषज्ञों से 50 घंटे से कम बातचीत और 10 व्यक्ति-सप्ताह से कम काम में 55 नियम बनाए।

उसी शोधपत्र ने नली चौड़ी करने के एक रास्ते के रूप में META-DENDRAL को प्रस्तुत किया। यह प्रोग्राम उन अणुओं के माप के डेटा से अपने आप नियम खोजता है जिनकी संरचना ज्ञात है। बताया गया कि मिले नियमों की गुणवत्ता विशेषज्ञों के नियमों के बराबर थी। दाईं ओर का चित्र सबसे सरल तरीका दिखाता है: उत्तरों के साथ दिए उदाहरणों से एक-एक करके खोजना।

मनुष्यों के लिखे नियमों को लगातार सँभालना पड़ता था। डेटा से सीखने का रास्ता अध्याय 8 और 9 में आगे बढ़ता है।

जो आपको लगता है कि आप जानते हैंआम तौर पर कही जाने वाली बात:अक्सर इस तरह विभाजन किया जाता है: “दूसरे उछाल के AI में विशेषज्ञों का ज्ञान केवल मनुष्यों द्वारा हाथ से लिखा जा सकता था; डेटा से सीखना तीसरे उछाल से शुरू हुआ”
मूल स्रोत के अनुसार:बॉटलनेक के बारे में लिखे गए 1977 के उसी शोधपत्र ने इसके एक उत्तर के रूप में META-DENDRAL प्रस्तुत किया था, जो डेटा से अपने आप नियम खोजता है।

यह “आज़माएँ” वाली प्रक्रिया का Python कोड है। ▶ चलाएँ दबाने पर नीचे नतीजा दिखेगा। संख्याएँ बदलकर फिर से चलाकर देखें।

u06_rule_induction.py

# u06 データからルールを見つける：人から聞き出す代わりに、正解付きのデータから「もし〜なら〜」を作る
#
# どの出来事か：1977 年のファイゲンバウムの論文（記録 feigenbaum_knowledge_bottleneck_1977）。
#   論文は、専門分野の知識を手に入れることがボトルネック（いちばん狭い通り道）の問題だった、と書いた。
#   その答えの 1 つとして、構造の分かっている分子の測定データからルールを見つけるプログラム META-DENDRAL を紹介した。
# このサンプル：分子ではなく、自転車の相談の例（このサイトが作ったデータ）。正解（原因）の付いた事例から、
#   「多くの例をまちがいなく説明できる条件」を 1 つずつ選んでルールにし、説明できた例を除いて繰り返す
#   （例を順にカバーしていくやり方。META-DENDRAL の手順そのものではない）。
# 試してみよう：
#   - EXAMPLES の正解を 1 つ変えると、見つかるルールはどう変わるか
#   - 例を減らすと、ルールはどうなるか

EXAMPLES = [  # (こぐと音, さび, 雨ざらし, へこむ, 重い, 答え)
    (1, 1, 1, 0, 0, "油切れ"), (1, 0, 1, 0, 1, "油切れ"), (1, 1, 0, 0, 0, "油切れ"), (1, 0, 1, 0, 0, "油切れ"),
    (0, 0, 0, 1, 1, "空気"), (0, 0, 1, 1, 1, "空気"), (1, 0, 0, 1, 1, "空気"), (0, 1, 0, 1, 0, "空気"),
    (0, 0, 0, 0, 1, "ブレーキ"), (0, 1, 0, 0, 1, "ブレーキ"), (0, 0, 1, 0, 1, "ブレーキ"),
]
NAMES = ["こぐと音がする", "さびている", "雨ざらし", "タイヤがへこむ", "重い"]

def conds():
    """1 つか 2 つの「〜がある／無い」の組み合わせをすべて作る"""
    single = [((i, v),) for i in range(len(NAMES)) for v in (1, 0)]
    pairs = [(a[0], b[0]) for a in single for b in single if a[0][0] < b[0][0]]
    return single + pairs

def fits(ex, cond):
    return all(ex[i] == v for i, v in cond)

def say(cond):
    return " かつ ".join(NAMES[i] + ("" if v else " でない") for i, v in cond)

left = list(EXAMPLES)
while left:
    best = None
    for cond in conds():
        covered = [ex for ex in left if fits(ex, cond)]
        labels = {ex[-1] for ex in covered}
        # 説明できる例が多く、誤りがない（答えが 1 種類だけ）条件を選ぶ。同じなら短く、「ある」の多い条件を優先する
        score = (len(covered), -len(cond), sum(v for _, v in cond))
        if len(labels) == 1 and (best is None or score > best[2]):
            best = (cond, covered, score)
    if best is None:
        print("これ以上、誤りのないルールは作れない")
        break
    cond, covered, _ = best
    print(f"見つけたルール：もし {say(cond)} なら {covered[0][-1]}（{len(covered)} 個の例を説明）")
    left = [ex for ex in left if ex not in covered]

print(f"\n{len(EXAMPLES)} 個の例から、人に聞かずにルールを作った。ただし、例にないことは分からない")

ज्ञान में ही शक्ति है

“शायद” को जोड़ने वाला विश्वास गुणांक

आगे और पीछे से तर्क करना

मशीन से “क्यों?” पूछ सकते हैं

स्थिति के ढाँचे में ज्ञान रखना

नाम छिपाकर अंक देना

गुणक लगाकर अनुमान करना

गायब हिस्सों को पहचानना

उदाहरण वाक्य की नकल से अनुवाद

यह कौन-सा उछाल था?

एक ही सम्मेलन के 2 कमरे

पुरुष मरीज का “एम्नियोटिक द्रव”

एक विश्वकोश जितनी सामान्य समझ

अनुवाद सॉफ़्टवेयर और “यह एक भ्रम है”

गायन के अनुसार बजाने वाला रोबोट

कितने cm से कोई “लंबा” है?

फ़ज़ी नियंत्रण से मेट्रो रोकना

“मानक साधन” वॉशिंग मशीन में आया

नियम लगातार बढ़ते गए

सँकरी नली को चौड़ा कैसे करें?

इस अध्याय में क्या अभी अज्ञात है?

को जोड़ने वाला विश्वास गुणांक

अनुवाद सॉफ़्टवेयर और