Knowledge graph — বস্তু, সম্পর্ক আর প্রশ্ন

আগের পর্বগুলোতে যুক্তি লেখা হয়েছে বাক্য আর নিয়ম দিয়ে: পর্ব ৪৫-এ propositional logic, পর্ব ৪৬-এ first-order logic-এর বস্তু আর সম্পর্ক, পর্ব ৪৭-এ “যদি … তাহলে …” নিয়মের expert system. এই পর্বের প্রশ্ন: হাজারো ছোট তথ্য (কে কোথায় থাকেন, কোন পণ্য কে বানায়) কীভাবে রাখলে যন্ত্র সেগুলো জুড়ে উত্তর দিতে পারে, আর উত্তরের প্রতিটি ধাপ দেখাতেও পারে। বাজারঘর এই কোর্সের কাল্পনিক অনলাইন দোকান; এই পর্বের সব ব্র্যান্ড (Shimul, Bokul, Kodom), বিক্রেতা, গ্রাহক আর অর্ডার বানানো।

১ · জ্ঞান লিখে রাখার পুরোনো স্বপ্ন — semantic network থেকে knowledge graph

পাড়ার দোকানের করিম চাচার মাথায় হাজারো ছোট তথ্য: “রুমানা আপা সিলেট থেকে অর্ডার দেন”, “Kodom-এর cable Shimul S10-এ লাগে”, “Kodom charger-ও বানায়”। “সিলেটের কে কে এমন ব্র্যান্ডের জিনিস নিয়েছেন যারা charger-ও বানায়?” প্রশ্নে তিনি কয়েকটি তথ্য জোড়া লাগিয়ে উত্তর দেন। Knowledge graph এই ছবিটিকে যন্ত্রে লেখার উপায়।

এই ধারার সাধারণ নাম knowledge representation: জ্ঞানকে এমন রূপে লেখা, যাতে যন্ত্র তা থেকে প্রশ্নের উত্তর আর নতুন সিদ্ধান্ত বের করতে পারে। পর্ব ৩-এ দেখা symbolic AI-এর এটি একটি মূল খুঁটি। Knowledge graph একটি বাস্তববাদী আপস: first-order logic-এর পুরো শক্তি নয়, কিন্তু বিপুল সরল তথ্য রাখা আর জুড়ে খোঁজার উপযোগী।

২ · Triple — subject, predicate, object

Knowledge graph-এর একটি তথ্য তিন অংশের একটি ছোট বাক্য, যার নাম triple:

• Subject (কর্তা): কার কথা হচ্ছে। যেমন CB1, একটি USB-C cable.
• Predicate (সম্পর্ক): কী সম্পর্ক। যেমন made_by.
• Object (কর্ম): কার সঙ্গে বা কোন মান। যেমন Kodom, একটি ব্র্যান্ড।

বাক্যের মতো পড়ুন: “CB1 made_by Kodom” মানে “CB1 বানিয়েছে Kodom”. graph-এর ভাষায় CB1 থেকে Kodom-এর দিকে একটি তীর, যার গায়ে লেখা made_by. Object কখনো আরেকটি entity (Kodom), কখনো একটি সাধারণ মান বা literal (যেমন নাম “Kodom USB-C Cable”). বাজারঘরের graph-এ এই রকম ৫০টি triple আছে, ১১ ধরনের predicate দিয়ে:

খেয়াল করুন, অর্ডার নিজেও একটি entity (O2). “মিতু CB1 কিনেছেন” সরাসরি না লিখে অর্ডারের মাধ্যমে লেখা হয়েছে, কারণ কেনাকাটার আরও তথ্য থাকে (তারিখ, দাম, কয়টি); ঘটনাকে নিজস্ব node বানানোর এই কৌশল খুব প্রচলিত।

৩ · Python-এ triple store — set, তিনটি index আর pattern

Triple রাখার সবচেয়ে সরল উপায় Python-এর set, যার প্রতিটি উপাদান একটি tuple: ("CB1", "made_by", "Kodom"). Set একই triple দুবার রাখে না। কিন্তু “S10-এর সঙ্গে কোন কোন পণ্য চলে?” প্রশ্নে subject জানা নেই, আর ৫ কোটি triple একে একে দেখা অসম্ভব ধীর। তাই তিনটি সূচি বা index রাখা হয়: subject দিয়ে, predicate দিয়ে আর object দিয়ে। প্রতিটি index একটি dict, যার চাবি একটি নাম আর মান সেই নামের সব triple-এর set.

প্রশ্ন লেখা হয় triple pattern দিয়ে: triple-এর মতোই তিন ঘর, কিন্তু কোনো ঘরে ? দিয়ে শুরু হওয়া একটি variable থাকতে পারে। (?p, compatible_with, S10) মানে “এমন সব ?p খুঁজুন, যার জন্য (?p, compatible_with, S10) triple-টি store-এ আছে”। একটি মিল পেলে variable একটি মানে বাঁধা পড়ে, একে বলে binding: {?p: CB1}. এটি পর্ব ৪৭-এর নিয়ম মেলানো আর পর্ব ৪৬-এর unification-এর সরলতম রূপ: এখানে variable শুধু একটি নাম, ভেতরে কোনো function বা গঠন নেই।

1s, p, o = (?p, compatible_with, S10)2cands = by_o["S10"]   # s is a variable3for t in cands:4    if t.predicate == p: bind ?p = t.subject

৪ · Multi-hop প্রশ্ন — pattern জোড়া দিয়ে উত্তর

এবার করিম চাচার প্রশ্ন: “সিলেটে থাকেন এমন কোন গ্রাহক এমন একটি পণ্য কিনেছেন, যার ব্র্যান্ড charger-ও বানায়?” কোনো একটি triple-এ এর উত্তর নেই। প্রশ্নটিকে ছয়টি ছোট pattern-এ ভাঙা যায়, যেগুলো একই variable দিয়ে পরস্পরের সঙ্গে বাঁধা:

(?c lives_in Sylhet)      গ্রাহক ?c সিলেটে থাকেন
(?o placed_by ?c)         অর্ডার ?o তাঁর দেওয়া
(?o contains ?p)          সেই অর্ডারে পণ্য ?p
(?p made_by ?brand)       ?p বানিয়েছে ?brand
(?x made_by ?brand)       একই ?brand আরেকটি ?x বানায়
(?x type Charger)         আর ?x একটি Charger

প্রতিটি “hop” মানে graph-এর একটি রেখা পার হওয়া। কৌশল হলো pattern একটি একটি করে join করা: আগের pattern-এর প্রতিটি binding পরের pattern-এ বসিয়ে মেলানো; না মিললে সারি বাদ, একাধিকভাবে মিললে কয়েকটি সারিতে ভাগ। এটি SQL-এর inner join-এর মতো; সাধারণ variable-গুলো join key.

1(?c lives_in Sylhet)2(?o placed_by ?c)3(?o contains ?p)4(?p made_by ?brand)5(?x made_by ?brand)6(?x type Charger)

এই পর্বের ডেটা নিচে পাতায় একটি ছোট লেখা-ফাইল (shop_kg.txt) হিসেবে রাখা আছে, প্রতি লাইনে একটি triple. প্রথম কোড ব্লক সেটি পড়ে store আর তিনটি index বানায়, match একটি pattern মেলায়, আর query pattern-গুলো একে একে join করে। চারটি কোড ব্লক একই namespace ভাগ করে, তাই পরের ব্লক এখানকার function ব্যবহার করে; পরের ব্লক আগে চালালে এটি নিজে আগে চলবে। প্রথমবার চালালে ব্রাউজারে Python নামতে কয়েক সেকেন্ড লাগতে পারে।

from collections import defaultdict
def build(T):                                  # store + three indexes
    global triples, by_s, by_p, by_o
    triples, by_s, by_p, by_o = set(T), *(defaultdict(set) for _ in "spo")
    for t in triples:
        by_s[t[0]].add(t); by_p[t[1]].add(t); by_o[t[2]].add(t)
lines = open("shop_kg.txt", encoding="utf-8").read().splitlines()
build(tuple(l.split(None, 2)) for l in lines if l and l[0] != "#")
print(len(triples), "triples,", len(by_p), "predicates")

def is_var(x): return x.startswith("?")
def match(pattern, b):
    s, p, o = [b.get(x, x) for x in pattern]   # fill bound variables
    cands = (by_s[s] if not is_var(s) else by_o[o] if not is_var(o)
             else by_p[p] if not is_var(p) else triples)
    for t in cands:
        nb = dict(b)
        if all(nb.setdefault(x, v) == v if is_var(x) else x == v
               for x, v in zip((s, p, o), t)):
            yield nb

def query(patterns, show=False):
    rows = [{}]
    for pat in patterns:                       # join, one pattern at a time
        rows = [nb for b in rows for nb in match(pat, b)]
        if show: print(f"  {' '.join(pat):26} -> {len(rows)} rows")
    return rows

print(sorted(r["?p"] for r in query([("?p", "compatible_with", "S10")])))
q = [("?c", "lives_in", "Sylhet"), ("?o", "placed_by", "?c"),
     ("?o", "contains", "?p"), ("?p", "made_by", "?brand"),
     ("?x", "made_by", "?brand"), ("?x", "type", "Charger")]
ans = query(q, show=True)
print(sorted({(r["?c"], r["?p"], r["?brand"]) for r in ans}))

50 triples, 11 predicates
['CB1', 'CH20']
  ?c lives_in Sylhet         -> 3 rows
  ?o placed_by ?c            -> 4 rows
  ?o contains ?p             -> 4 rows
  ?p made_by ?brand          -> 4 rows
  ?x made_by ?brand          -> 8 rows
  ?x type Charger            -> 2 rows
[('Mitu', 'CB1', 'Kodom'), ('Nasrin', 'S10', 'Shimul')]

৫ · Ontology আর schema — class, is-a আর অনুমান

এখন একটি সহজ প্রশ্ন: “বাজারঘরে কোন কোন Electronics পণ্য আছে?” উপরের ৫০টি triple-এ (?x, type, Electronics) একটিও নেই। অথচ মানুষ জানে charger একটি মোবাইল অ্যাক্সেসরি, আর অ্যাক্সেসরি একটি ইলেকট্রনিক্স পণ্য। এই জ্ঞান লেখা থাকে schema-য়, যার আরেক নাম ontology: কোন কোন class বা শ্রেণি আছে, কোনটি কার ভেতরে, আর কোন সম্পর্ক কোন শ্রেণির মধ্যে খাটে।

• Class: একই ধরনের entity-র দল। Phone, Charger, Electronics, Product.
• Instance: একটি নির্দিষ্ট জিনিস, যা কোনো class-এর সদস্য। CH20 একটি Charger: (CH20, type, Charger).
• subClassOf (is-a): একটি class আরেকটির ভেতরে। (Charger, subClassOf, MobileAccessory) মানে প্রতিটি charger একটি mobile accessory-ও।
• Property: সম্পর্ক নিজেও schema-তে বর্ণনা করা যায়। domain আর range বলে সম্পর্কের দুই পাশে কোন class: made_by-এর domain Product, range Brand.

বাজারঘরের ছোট class-স্তর এরকম: Charger, Cable আর PowerBank → MobileAccessory → Electronics → Product; Earbuds → AudioDevice → Electronics; Phone → Electronics. এখান থেকে দুটি নিয়ম চালিয়ে নতুন triple বের করা যায়। প্রতীক দিয়ে লিখলে (→ মানে “তাহলে”, ∧ মানে “এবং”):

নিয়ম ১ (transitivity): (A subClassOf B) ∧ (B subClassOf C) → (A subClassOf C)
নিয়ম ২ (type ওঠে): (x type A) ∧ (A subClassOf B) → (x type B)

প্রথম নিয়মের নাম transitivity: “ভেতরে থাকা” সম্পর্ক চেইন ধরে চলে, যেমন জায়গার part_of-ও। নিয়ম দুটি বারবার চালানো হয় যতক্ষণ না নতুন কিছু আসে; সেই স্থির অবস্থার নাম fixpoint. যে triple নিয়ম থেকে এলো, সেগুলো store-এ লিখে রাখার কৌশলকে বলে materialization. এটি পর্ব ৪৭-এর forward chaining-এর একটি বিশেষ রূপ।

1while True:2    new = rule1(T) | rule2(T)3    new -= T4    if not new: stop  # fixpoint5    T |= new

def infer(T, verbose=True):
    """RDFS-style rules until nothing new: subClassOf is transitive,
    and an instance of a class is also an instance of its superclass."""
    T, rnd = set(T), 0
    while True:
        sub = {(s, o) for s, p, o in T if p == "subClassOf"}
        new = {(a, "subClassOf", c) for a, b in sub for b2, c in sub if b == b2}
        new |= {(x, "type", d) for x, p, c in T if p == "type"
                for c2, d in sub if c == c2}
        new -= T                                   # keep only truly new
        if not new:
            return T, rnd
        rnd += 1
        if verbose:
            print(f"round {rnd}: +{len(new)}", sorted(new)[:3], "...")
        T |= new

full, rounds = infer(triples)
print(len(triples), "->", len(full), "triples after", rounds, "rounds")
def instances(T, cls):
    return sorted(s for s, p, o in T if p == "type" and o == cls)
print("Electronics before:", instances(triples, "Electronics"))
print("Electronics after: ", instances(full, "Electronics"))
print("MobileAccessory:", instances(full, "MobileAccessory"))

wrong = triples | {("Charger", "subClassOf", "Phone")}   # one bad is-a link
bad, _ = infer(wrong, verbose=False)
print("Phones, correct:", instances(full, "Phone"))
print("Phones, wrong  :", instances(bad, "Phone"))

round 1: +13 [('AudioDevice', 'subClassOf', 'Product'), ('BUDS', 'type', 'AudioDevice'), ('CB1', 'type', 'MobileAccessory')] ...
round 2: +15 [('BUDS', 'type', 'Electronics'), ('BUDS', 'type', 'Product'), ('CB1', 'type', 'Electronics')] ...
50 -> 78 triples after 2 rounds
Electronics before: []
Electronics after:  ['BUDS', 'CB1', 'CH20', 'CH33', 'PB10', 'S10']
MobileAccessory: ['CB1', 'CH20', 'CH33', 'PB10']
Phones, correct: ['S10']
Phones, wrong  : ['CH20', 'CH33', 'S10']

৬ · RDF, IRI, Turtle আর SPARQL — rdflib দিয়ে সত্যিকারের run

অন্য প্রতিষ্ঠানের সঙ্গে ডেটা ভাগ করতে চাইলে সবাইকে একই ভাষায় লিখতে হয়। World Wide Web Consortium (W3C)-র মানদণ্ডগুলো:

RDF-এ প্রতিটি entity আর predicate-এর নাম একটি IRI (Internationalized Resource Identifier, ওয়েব ঠিকানার মতো একটি বিশ্বজুড়ে অনন্য নাম, যাতে বাংলার মতো Unicode অক্ষরও চলে)। “Sylhet” লিখলে কোন Sylhet, জেলা না বিভাগ না কোনো দোকানের নাম, তা পরিষ্কার নয়; https://example.org/bazarghar/Sylhet লিখলে নামটি বাজারঘরের নিজের। প্রতিবার পুরো ঠিকানা লেখা কষ্টকর, তাই একটি ছোট উপসর্গ বা prefix ঠিক করা হয়: bz: = https://example.org/bazarghar/. (example.org উদাহরণের জন্য সংরক্ষিত একটি ডোমেইন।) নিচে বাজারঘরের graph-এর একটি ছোট অংশ Turtle-এ। a হলো rdf:type-এর সংক্ষেপ, ; মানে “একই subject, আরেকটি predicate”, আর "…"@bn মানে বাংলা ভাষার একটি লেখা।

@prefix bz:   <https://example.org/bazarghar/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

# ---- schema (ontology) ----
bz:Charger         rdfs:subClassOf bz:MobileAccessory .
bz:Cable           rdfs:subClassOf bz:MobileAccessory .
bz:MobileAccessory rdfs:subClassOf bz:Electronics .
bz:Phone           rdfs:subClassOf bz:Electronics .
bz:madeBy rdfs:domain bz:Product ; rdfs:range bz:Brand .

# ---- data ----
bz:S10  a bz:Phone ;   bz:madeBy bz:Shimul ;
        rdfs:label "Shimul S10"@en, "শিমুল S10"@bn .
bz:CH20 a bz:Charger ; bz:madeBy bz:Shimul ; bz:compatibleWith bz:S10 .
bz:CB1  a bz:Cable ;   bz:madeBy bz:Kodom ;  bz:compatibleWith bz:S10 .
bz:CH33 a bz:Charger ; bz:madeBy bz:Kodom .
bz:BUDS a bz:Earbuds ; bz:madeBy bz:Bokul .

bz:Mitu   bz:livesIn bz:Sylhet .
bz:Nasrin bz:livesIn bz:Sylhet .
bz:Rumana bz:livesIn bz:Sylhet .
bz:Tanvir bz:livesIn bz:Dhaka .
bz:O1 bz:placedBy bz:Rumana ; bz:contains bz:BUDS .
bz:O2 bz:placedBy bz:Mitu ;   bz:contains bz:CB1 .
bz:O3 bz:placedBy bz:Tanvir ; bz:contains bz:S10 .
bz:O4 bz:placedBy bz:Nasrin ; bz:contains bz:S10 .

এবার SPARQL. এর ভেতরের অংশ (WHERE { … }) ঠিক অংশ ৪-এর pattern-এর তালিকা, শুধু লেখার ধরন আলাদা: variable ? দিয়ে শুরু, প্রতিটি pattern-এর শেষে বিন্দু, আর ; দিয়ে একই subject-এর পরের predicate. rdflib (RDF-এর জন্য একটি open-source Python library) পাতার ভেতরের Python-এ আগে থেকে দেওয়া থাকে না, তাই নিচের run লেখকের ডেস্কটপে একটি আলাদা venv-এ করা।

python -m venv .venv
.venv/bin/pip install rdflib==7.6.0     # Windows: .venv\Scripts\pip

from rdflib import Graph
g = Graph()
g.parse("bazarghar.ttl", format="turtle")
print("triples:", len(g))

Q1 = PREFIX + """
SELECT DISTINCT ?customer ?product ?brand WHERE {
  ?customer bz:livesIn bz:Sylhet .
  ?order    bz:placedBy ?customer ;
            bz:contains ?product .
  ?product  bz:madeBy ?brand .
  ?charger  a bz:Charger ;
            bz:madeBy ?brand .
}
ORDER BY ?customer
"""
for row in g.query(Q1):
    print(" ", row.customer.n3(g.namespace_manager),
          row.product.n3(g.namespace_manager), row.brand.n3(g.namespace_manager))

Q2 = PREFIX + """
SELECT ?item ?cls WHERE {
  ?item a ?cls .
  ?cls rdfs:subClassOf* bz:Electronics .
}
ORDER BY ?item
"""
Q3 = PREFIX + """
SELECT ?brand (COUNT(?p) AS ?n) WHERE { ?p bz:madeBy ?brand . }
GROUP BY ?brand ORDER BY DESC(?n) ?brand
"""
Q4 = PREFIX + """
SELECT ?label WHERE { bz:S10 rdfs:label ?label . FILTER(lang(?label) = "bn") }
"""
Q5 = PREFIX + "ASK { bz:Rumana bz:livesIn bz:Dhaka }"

সত্যিকারের run (Python 3.14.4, rdflib 7.6.0, লেখার সময়ের সর্বশেষ স্থিতিশীল সংস্করণ; path বদলে নিরপেক্ষ নাম):

~/bazarghar-kg$ python kg_sparql.py
Python 3.14.4 | rdflib 7.6.0
triples: 32

Q1: Sylhet customers, brand also makes chargers
  bz:Mitu bz:CB1 bz:Kodom
  bz:Nasrin bz:S10 bz:Shimul

Q2: everything that is Electronics (subClassOf* path)
  bz:CB1 via bz:Cable
  bz:CH20 via bz:Charger
  bz:CH33 via bz:Charger
  bz:S10 via bz:Phone

Q3: products per brand
  bz:Kodom 2
  bz:Shimul 2
  bz:Bokul 1

Q4: Bangla label of S10: ['শিমুল S10']
Q5: does Rumana live in Dhaka? False

ফলগুলো থেকে শিক্ষা (Q3 দেখায় SQL-এর মতো GROUP BY আর COUNT):

• Q1 নিজের লেখা store-এর উত্তরই দিল: Mitu আর Nasrin.
• Q2-এর rdfs:subClassOf* একটি property path: * মানে “শূন্য বা তার বেশি ধাপ”। অংশ ৫-এর মতো triple আগে থেকে লিখে না রেখে query চলার সময়েই চেইন ধরে হাঁটা হলো। লক্ষ করুন BUDS নেই: এই ছোট Turtle ফাইলে Earbuds-এর কোনো subClassOf লেখা হয়নি। Schema-তে রেখা না থাকলে উত্তরও নেই, কোনো সতর্কবার্তাও নেই।
• Q4-এ একই পণ্যের দুই ভাষার নাম থেকে lang() দিয়ে বাংলাটি বাছা।
• Q5-এর False মানে “graph-এ এই triple নেই”, “Rumana ঢাকায় থাকেন না” প্রমাণিত নয়। RDF-এর জগৎ সাধারণত open-world assumption মেনে চলে: যা লেখা নেই তা অজানা, মিথ্যা নয়। Database-এর অভ্যাস উল্টো (closed world: না থাকলে মিথ্যা)। ভাবনার প্রশ্ন ২-এ এর পরিণাম দেখবেন।

আর IRI-গুলো আসলে কেমন দেখায়, তা N-Triples রূপে (প্রতি লাইনে একটি পূর্ণ triple, কোনো prefix ছাড়া) একই run-এ S10-এর চারটি triple থেকে দেখুন:

<https://example.org/bazarghar/S10> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://example.org/bazarghar/Phone> .
<https://example.org/bazarghar/S10> <http://www.w3.org/2000/01/rdf-schema#label> "Shimul S10"@en .
<https://example.org/bazarghar/S10> <http://www.w3.org/2000/01/rdf-schema#label> "শিমুল S10"@bn .
<https://example.org/bazarghar/S10> <https://example.org/bazarghar/madeBy> <https://example.org/bazarghar/Shimul> .

৭ · Property graph, Cypher আর জনসাধারণের knowledge graph

Knowledge graph রাখার আরেকটি বড় পরিবার হলো property graph. এখানে node আর edge দুটিরই নিজস্ব property (চাবি-মানের জোড়া) থাকতে পারে: অর্ডারের রেখায় সরাসরি {date: "2026-10-12", qty: 2}. RDF-এ রেখার গায়ে তথ্য রাখতে সাধারণত অর্ডারের মতো একটি মধ্যবর্তী node লাগে (অংশ ২)। Property graph-এর সবচেয়ে পরিচিত query ভাষা Cypher, যার মৌলিক কাজ (pattern এঁকে প্রশ্ন, variable-length path, shortestPath) DBMS কোর্সের graph ডেটাবেস পর্বে চালিয়ে দেখানো আছে। বাজারঘরের প্রশ্নটি Cypher-এ মোটামুটি এমন দেখাবে (উদাহরণ, এখানে চালানো হয়নি; label আর relation-এর নাম আমাদের বানানো):

MATCH (c:Customer)-[:LIVES_IN]->(:District {name: 'Sylhet'}),
      (o:Order)-[:PLACED_BY]->(c),
      (o)-[:CONTAINS]->(p:Product)-[:MADE_BY]->(b:Brand),
      (:Charger)-[:MADE_BY]->(b)
RETURN DISTINCT c.name, p.name, b.name

ছবির মতো তীর আঁকা: (node)-[:REL]->(node). ভেতরের চিন্তা SPARQL-এর মতোই pattern matching, শুধু লেখার ধরন আলাদা।

তুলনাটি মোটা দাগের: কিছু ডেটাবেস দুটি মডেলই সমর্থন করে, আর কোনটি “ভালো” তা বিতর্কের বিষয়। আসল প্রশ্ন: ডেটা অন্যদের সঙ্গে ভাগ হবে আর অর্থ মানদণ্ডে বাঁধা দরকার (RDF-এর দিকে), নাকি একটি অ্যাপের ভেতরে দ্রুত পথ খোঁজাই মূল কাজ (property graph-এর দিকে)?

জনসাধারণের জন্য উন্মুক্ত knowledge graph

দুটি পরিচিত উন্মুক্ত knowledge graph হলো Wikidata আর DBpedia. Wikidata Wikimedia Foundation-এর একটি প্রকল্প, ২০১২ সালে শুরু; যে কেউ সম্পাদনা করতে পারেন, প্রতিটি বস্তুর একটি পরিচয় নম্বর থাকে (Q দিয়ে শুরু), আর প্রতিটি সম্পর্ক বা statement-এর সঙ্গে উৎস (reference) আর অতিরিক্ত শর্ত (qualifier, যেমন “কোন সময় থেকে”) রাখা যায়। নাম অনেক ভাষায় থাকে, বাংলাতেও, আর একটি উন্মুক্ত SPARQL সেবা আছে। DBpedia ২০০৭ সালের দিকে কয়েকটি বিশ্ববিদ্যালয়ের গবেষকদের হাতে শুরু হয়; এটি Wikipedia প্রবন্ধের তথ্যবাক্স (infobox) থেকে স্বয়ংক্রিয়ভাবে triple বের করে। দুটির আকার সময়ের সঙ্গে বদলায়, তাই এখানে কোনো সংখ্যা দেওয়া হলো না।

৮ · Graph-এ হাঁটা — BFS, সবচেয়ে ছোট সম্পর্কের পথ আর networkx

কখনো প্রশ্ন pattern-এ লেখা যায় না, কারণ কত ধাপ লাগবে তা আগে জানা নেই: “Mitu আর Kodom-এর মধ্যে সম্পর্কটা কী?” এর উত্তর হলো দুই node-এর মধ্যে সবচেয়ে কম রেখার পথ। ওজনহীন graph-এ সেটি খোঁজে breadth-first search: শুরুর node থেকে এক ধাপ দূরের সব, তারপর দুই ধাপ দূরের সব, স্তরে স্তরে। পর্ব ৪০-এ BFS ঢাকার রাস্তায় চালানো হয়েছে, আর তার কোড আর জটিলতা DSA কোর্সের BFS পর্বে আছে; এখানে শুধু ব্যবহার। নতুন দুটি বিষয়: তীরের উল্টো দিকেও হাঁটতে হয় (Mitu থেকে O2-তে placed_by উল্টো), আর পথটি রেখার নাম ও দিকসহ ব্যাখ্যা করতে হয়।

নিচের কোড networkx (graph-এর জন্য বহুল ব্যবহৃত Python library, যা পাতার Python-এ আগে থেকেই দেওয়া থাকে) দিয়ে দুটি graph বানায়: দিকসহ G, যাতে রেখার নাম থাকে, আর দিকহীন U, যাতে হাঁটা হয়। ওজন ছাড়া nx.shortest_path BFS-এর একটি রূপ (দুই দিক থেকে একসঙ্গে খোঁজা bidirectional BFS) ব্যবহার করে। শেষে graph-এর একটি ছোট অংশের ছবি।

import networkx as nx
import matplotlib.pyplot as plt

facts = sorted(t for t in triples if t[1] not in ("name", "subClassOf"))
G, U = nx.DiGraph(), nx.Graph()     # U: same edges, walked both ways
for s, p, o in facts:
    G.add_edge(s, o, rel=p); U.add_edge(s, o)
print(G.number_of_nodes(), "nodes,", G.number_of_edges(), "edges")

def explain(path):
    """turn a node path into relation steps, showing edge direction"""
    out = []
    for a, b in zip(path, path[1:]):
        if G.has_edge(a, b): out.append(f"{a} -{G[a][b]['rel']}-> {b}")
        else:                out.append(f"{a} <-{G[b][a]['rel']}- {b}")
    return out

for a, b in [("Mitu", "Kodom"), ("Rumana", "Shimul")]:
    path = nx.shortest_path(U, a, b)   # unweighted: breadth-first search
    print(f"{a} to {b}, {len(path) - 1} hops:")
    for step in explain(path): print("   ", step)
print("BFS layers from Mitu:",
      [sorted(layer) for layer in nx.bfs_layers(U, ["Mitu"])][:3])

pos = {"Mitu": (0, 1), "O2": (1, 1), "CB1": (2, 1), "CH33": (3, 1),
       "Sylhet": (0, 0), "S10": (2, 0), "Charger": (3, 0), "Kodom": (2.5, 2)}
H = G.subgraph(pos)                    # a small piece, fixed positions
fig, ax = plt.subplots(figsize=(6.4, 4))
nx.draw_networkx(H, pos, ax=ax, node_color="#bfdbfe", node_size=900,
                 font_size=8, arrowsize=14)
nx.draw_networkx_edge_labels(H, pos, nx.get_edge_attributes(H, "rel"),
                             font_size=7, ax=ax)
ax.set_title("Part of the Bazarghar knowledge graph"); ax.axis("off")
plt.show()

33 nodes, 40 edges
Mitu to Kodom, 3 hops:
    Mitu <-placed_by- O2
    O2 -contains-> CB1
    CB1 -made_by-> Kodom
Rumana to Shimul, 5 hops:
    Rumana -lives_in-> Sylhet
    Sylhet <-lives_in- Nasrin
    Nasrin <-placed_by- O4
    O4 -contains-> S10
    S10 -made_by-> Shimul
BFS layers from Mitu: [['Mitu'], ['O2', 'Sylhet'], ['CB1', 'Nasrin', 'Rumana', 'SabujStore', 'SylhetDivision']]

৯ · Entity resolution, ডেটার মান, provenance আর গোপনীয়তা

বাস্তবের knowledge graph তৈরি হয় অনেক উৎস জুড়ে, আর প্রতিটি উৎস একই জিনিস নিজের মতো করে লেখে। ধরুন একটি অংশীদার বিক্রেতার পাঠানো অর্ডারে S10 লেখা “shimul s-10” আর “SHIMUL S10 (Black)”, জেলা “sylhet” আর বানান ভুল “Sylet”. এগুলো নতুন node হয়ে বসলে S10-এর বিক্রি কম দেখাবে। একই বাস্তব বস্তুর বিভিন্ন লেখাকে খুঁজে এক node-এ মেলানোর কাজের নাম entity resolution (record linkage বা deduplication নামেও পরিচিত)। পর্ব ২৩-এ duplicate সারি আর বাংলা লেখার পরিষ্কার দেখা হয়েছে; এখানে একই সমস্যা graph-এর node-এ।

নিচের কোড একটি সাবধানী পদ্ধতি নেয়। প্রথমে একটি normalisation key: ছোট হাতের অক্ষর, বন্ধনীর ভেতরের রং ইত্যাদি বাদ, শুধু অক্ষর আর অঙ্ক রাখা; তাতে “SHIMUL S10 (Black)” আর “shimul s-10” দুটিই হয় shimuls10, যা ক্যাটালগের “Shimul S10”-এর key. Key হুবহু মিললে মেলানো হয়। আর হুবহু না মিললেও খুব কাছাকাছি হলে (Python-এর difflib দিয়ে মিলের অনুপাত দেখে) মেলানো হয় না, শুধু মানুষের যাচাইয়ের জন্য তালিকায় তোলা হয়। তারপর একই দুটি প্রশ্ন মেলানোর আগে আর পরে।

import re, difflib
feed = """O7 placed_by Farhana
Farhana lives_in sylhet
O7 contains shimul s-10
O8 placed_by Tanvir
O8 contains SHIMUL S10 (Black)
O9 placed_by Joynal
Joynal lives_in Sylet
O9 contains Kodom usb-c cable"""               # a partner seller's messy feed
raw = {tuple(l.split(None, 2)) for l in feed.splitlines()}
base = set(triples)

def key(text):           # lower case, drop "(...)", keep only letters/digits
    return re.sub(r"[^a-z0-9]", "", re.sub(r"\(.*?\)", "", text.lower()))
canon = {key(o): s for s, p, o in base if p == "name"}       # name -> product id
canon |= {key(o): o for s, p, o in base if p == "lives_in"}  # district names

def resolve(t):
    s, p, o = t
    if p in ("contains", "lives_in"):
        if key(o) in canon:
            return (s, p, canon[key(o)])
        near = difflib.get_close_matches(key(o), list(canon), n=1, cutoff=0.8)
        if near:
            print(f"  review: {o!r} looks like {canon[near[0]]!r}, not merged")
    return t

fixed = {resolve(t) for t in sorted(raw)}
for label, T in [("raw feed", base | raw), ("resolved", base | fixed)]:
    build(T)
    s10 = query([("?o", "contains", "S10"), ("?o", "placed_by", "?c")])
    print(f"{label}: {len(triples)} triples | S10 orders:", len(s10),
          "| Sylhet + charger brand:", sorted({r["?c"] for r in query(q)}))
build(base)                                    # restore the clean graph

  review: 'Sylet' looks like 'Sylhet', not merged
raw feed: 58 triples | S10 orders: 2 | Sylhet + charger brand: ['Mitu', 'Nasrin']
resolved: 58 triples | S10 orders: 4 | Sylhet + charger brand: ['Farhana', 'Mitu', 'Nasrin']

প্রতিটি তথ্যের উৎস — provenance

অংশীদারের ডেটা মেলানোর পর প্রশ্ন ওঠে: “Farhana সিলেটে থাকেন” তথ্যটি কে দিল, কবে, আর কতটা বিশ্বাসযোগ্য? Provenance মানে প্রতিটি তথ্যের উৎস আর ইতিহাসের হিসাব। Knowledge graph-এ এটি রাখার কয়েকটি উপায়: প্রতিটি উৎসের triple আলাদা একটি নাম-দেওয়া graph-এ রাখা (RDF-এ named graph; তখন triple-এর সঙ্গে চতুর্থ একটি ঘর থাকে, তাই একে quad বলা হয়), Wikidata-র মতো প্রতিটি statement-এর সঙ্গে reference রাখা, অথবা property graph-এ edge-এর property হিসেবে source আর retrieved_at. উৎস জানা থাকলে একটি ভুল উৎসের সব তথ্য একসঙ্গে সরানো যায়।

ব্যক্তিগত তথ্য আর graph-এর বাড়তি ঝুঁকি

বাজারঘরের graph-এ গ্রাহকের নাম, জেলা আর কেনাকাটা আছে। আলাদা আলাদা টেবিলে এগুলো কম ক্ষতিকর মনে হয়, কিন্তু graph-এর আসল শক্তি জোড়া লাগানো, আর সেটিই গোপনীয়তার ঝুঁকি: কয়েকটি নিরীহ তথ্য (জেলা, কেনার সময়, পণ্যের ধরন) জুড়ে একজন মানুষকে চেনা বা কেনাকাটা থেকে স্বাস্থ্যের মতো সংবেদনশীল কিছু আন্দাজ করা যেতে পারে। তাই প্রয়োজনের বাইরে ব্যক্তিগত তথ্য না তোলা, আসল নামের বদলে ছদ্ম-পরিচয় (pseudonymous id), query-র অনুমতি বেঁধে দেওয়া, আর মোছার অনুরোধে অনুমিত triple থেকেও মোছা দরকার। ডেটা কমানো আর আইনি দিক নিয়ে বিস্তারিত আছে Cybersecurity কোর্সের privacy engineering পর্বে।

১০ · Knowledge graph, machine learning আর LLM — আর AI-এর যুগে যাচাই

Symbolic AI আর machine learning এখানে প্রতিদ্বন্দ্বী নয়, প্রায়ই একসঙ্গে কাজ করে। তিনটি দিক সংক্ষেপে:

• Link prediction: graph সবসময় অসম্পূর্ণ। “CB1 কি S10-এর পাশাপাশি অন্য কোনো ফোনেও চলে?” এমন অনুপস্থিত রেখা আন্দাজ করার কাজ। এর একটি জনপ্রিয় পথ knowledge graph embedding: প্রতিটি entity আর relation-কে একটি সংখ্যার vector দেওয়া, যাতে সত্যি triple-গুলো vector-এর হিসাবে “মেলে”। যেমন ২০১৩ সালে Bordes ও সহকর্মীদের TransE মডেলে ধারণাটি হলো subject-এর vector + relation-এর vector ≈ object-এর vector. Embedding আর vector search পর্ব ৬৯-এ (গণিতের শুরু পর্ব ৩৩-এ)। এগুলো আন্দাজ, প্রমাণ নয়।
• LLM দিয়ে graph বানানো: পণ্য-বিবরণ বা রিভিউ থেকে triple বের করা দ্রুত, কিন্তু মডেল সম্পর্ক বানিয়েও ফেলতে পারে; উৎসের বাক্যটি provenance হিসেবে রাখা আর নমুনা যাচাই জরুরি।
• Graph দিয়ে LLM-এর উত্তর বাঁধা: RAG পদ্ধতিতে উত্তর লেখার আগে প্রাসঙ্গিক তথ্য খুঁজে মডেলকে দেওয়া হয়; সেই তথ্য knowledge graph থেকে এলে (একটি SPARQL বা pattern query-র ফল) উত্তরের পেছনের triple আর তাদের উৎস দেখানো যায়। কিন্তু এটি hallucination পুরো দূর করে না: graph ভুল বা পুরোনো হতে পারে, query ভুল তথ্য আনতে পারে, আর মডেল সঠিক তথ্য পেয়েও ভুল যোগ করতে পারে। LLM কীভাবে কাজ করে আর তার সীমা পর্ব ৭০-এ।

AI সহকারী Turtle, SPARQL বা rdflib-এর কোড দ্রুত লিখে দেয়, কিন্তু প্রায়ই এই ভুলগুলো করে:

• বানানো prefix বা property: rdfs:subclassOf (ছোট c), schema:madeBy-এর মতো অস্তিত্বহীন নাম; SPARQL তখন error দেয় না, শুধু খালি ফল দেয়, কারণ ভুল নামের triple কোথাও নেই।
• পুরোনো API: rdflib-এর পুরোনো সংস্করণের অভ্যাস, যেমন serialize()-এর ফলকে bytes ধরে .decode() করা (rdflib 6 থেকে এটি string ফেরত দেয়), বা উঠে যাওয়া plugin-এর নাম।
• Closed-world ধরে নেওয়া: “ASK false মানে Rumana ঢাকায় থাকেন না” লিখে দেওয়া, বা FILTER NOT EXISTS-এর ফলকে প্রমাণ বলা।
• আন্দাজকে প্রমাণ বলা: embedding বা LLM-এর আন্দাজ করা রেখা উৎস ছাড়া graph-এ মিশিয়ে ফেলা।

AI-এর লেখা knowledge graph-এর কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রথমে একটি ছোট, হাতে উত্তর জানা graph-এ চালিয়েছি; ফল হাতের হিসাবের সঙ্গে মিলেছে
• প্রতিটি prefix আর property-র নাম ডেটার সঙ্গে মিলিয়েছি; খালি ফল এলে আগে এক-pattern-এর query দিয়ে কোন ধাপে সারি শূন্য হচ্ছে তা খুঁজেছি
• নিজের rdflib, networkx বা ডেটাবেসের সংস্করণ pip show দিয়ে দেখেছি, আর অচেনা method অফিসিয়াল docs-এ মিলিয়েছি
• Schema-র প্রতিটি নতুন is-a রেখা পরীক্ষা করেছি: অনুমানের আগে আর পরে প্রতিটি class-এর সদস্যসংখ্যা মিলিয়ে অদ্ভুত লাফ খুঁজেছি
• মেলানো (merge) entity-র একটি নমুনা মানুষ দিয়ে যাচাই করিয়েছি; আন্দাজ করা রেখা আর হাতে লেখা তথ্য আলাদা চিহ্নে রেখেছি, উৎসসহ
• আসল গ্রাহকের নাম, ফোন নম্বর বা ঠিকানা AI সহকারীতে পেস্ট করিনি; বানানো বা ছদ্মনামের নমুনা ব্যবহার করেছি