Главная Обзор Помощь
Вход
ardo
/
Obsidian
1
0
Ответвить 0
Файлы Задачи 0 Запросы на слияние 0 Вики
Дерево: d91307ed56
Ветки Метки
Obsidian
/
Juhendid
/
Etnomath
/
Sissejuhatus.md

Sissejuhatus.md 57 KB
История Исходник

Etnomatemaatika on uurimisvaldkond, mis käsitleb, kuidas erinevad kultuurid mõistavad, kasutavad ja arendavad matemaatilisi ideid.

Lihtsamalt: see uurib, milline matemaatika peitub igapäevaelus, traditsioonides ja kohalikes teadmistes — näiteks:

  • loendamisviisides,
  • mõõtmises,
  • mustrites ja ornamentides,
  • arhitektuuris,
  • käsitöös,
  • kalendrites ja ajamõõtmises,
  • navigeerimises,
  • mängudes.

Näide: kui mingi rahvas kasutab omaenda viisi esemete loendamiseks või loob sümmeetrilisi mustreid kangakudumisel, siis etnomatemaatika uurib, millised matemaatilised põhimõtted seal taga on.

Selle eesmärk on näidata, et matemaatika ei ole ainult kooli- või teadusmatemaatika, vaid see esineb ka eri kultuuride praktilistes teadmustes.

Kui soovid, võin tuua ka 2–3 konkreetset näidet etnomatemaatikast.

Siin on kolm konkreetset etnomatemaatika näidet:

  1. Aafrika mustrid ja sümmeetria
    Paljudes Aafrika kultuurides kasutatakse kangastel, savinõudel ja kehamaalingutes keerulisi mustreid.
    Nendes leidub:

    • peegelsümmeetria
    • pöördsümmeetria
    • korduvad geomeetrilised kujundid
      Kuigi neid ei kirjeldata valemitega, järgivad need selgeid matemaatilisi reegleid.

  2. Inkate sõlmkirjad (quipu)
    Inkad kasutasid sõlmedest koosnevat nöörisüsteemi arvude talletamiseks.

    • eri tüüpi sõlmed tähistasid eri väärtusi
    • asukoht nööril näitas kümnendsüsteemi kohti
      See on näide matemaatikast ilma kirjalike numbriteta.

  3. Põlisrahvaste loendamis- ja mõõtmissüsteemid
    Mõned rahvad ei loe kümnendsüsteemis, vaid näiteks:

    • viielises süsteemis (käed)
    • kahekümnelises süsteemis (käed + jalad)
      Samuti mõõdetakse pikkust kehaosade järgi (küünar, samm), mis on praktiline ja kultuurispetsiifiline matemaatika.

Kui tahad, võin tuua Eesti või koolitunniga seotud näiteid, kuidas etnomatemaatikat kasutada.

Suurepärane 🙂
Siin on Eesti‑ga seotud ja koolitunnis kasutatavad etnomatemaatika näited.

1. Eesti rahvamustrid ja geomeetria

Eesti rahvarõivaste kindakirjad, vööd ja vaibad sisaldavad:

  • korduvaid mustreid
  • peegelsümmeetriat ja nihkesümmeetriat
  • ruudustikul põhinevat loogikat

Koolis:
Õpilased saavad uurida mustreid, joonistada need ruudulisele paberile ja leida:

  • kordusühiku
  • sümmeetriateljed
  • mustri „reegli“

2. Vanad mõõtühikud ja mõõtmine

Eestis kasutati enne meetermõõdustikku:

  • küünar
  • süld
  • samm

Need põhinesid inimkehal, mitte täpsetel instrumentidel.

Koolis:
Õpilased mõõdavad klassiruumi:

  • sammude
  • küünarde
  • joonlaua abil

Seejärel võrreldakse tulemusi ja arutletakse, miks mõõtühikud peavad olema kokkuleppelised.

3. Rahvakalender ja ajamõõtmine

Talurahvas planeeris töid:

  • kuufaaside
  • päikeseringi
  • rahvakalendri tähtpäevade järgi

See hõlmab tsükleid, perioodsust ja loendamist.

Koolis:
Õpilased:

  • uurivad kuutsükli pikkust
  • koostavad lihtsa kalendri
  • seovad ajamõõtmise murdude ja kordustega

Kokkuvõte (õpilase keeles):

Etnomatemaatika näitab, et matemaatika on olnud olemas juba enne koolimatemaatikat – inimeste igapäevaelus.

Kui tahad, saan:

  • aidata koostada lühikese tunni- või töölehe,
  • seletada teemat algklasside või põhikooli tasemel,
  • või aidata vastata sellele kontrolltöös.

LangChain

LangChain on raamistik, millega ehitada rakendusi, mis kasutavad suuri keelemudeleid. Sellega saab näiteks:

  • ühendada LLM-e tööriistade ja API-dega,
  • hallata prompt’e,
  • teha RAG-lahendusi,
  • pidada vestlusmälu,
  • luua mitmeastmelisi töövooge.

LangGraph on LangChaini ökosüsteemi osa, mis on mõeldud olekuga ja graafipõhiste agentide/töövoogude loomiseks. See sobib eriti siis, kui:

  • protsessis on mitu sammu või haru,
  • agent peab otsustama, mida järgmisena teha,
  • on vaja tsükleid, kordusi või inimese sekkumist,
  • tahad töövoogu paremini juhtida ja jälgida.

Lühidalt:

  • LangChain = üldine tööriistakomplekt LLM-rakenduste ehitamiseks
  • LangGraph = keerukamate agentide ja töövoogude juhtimine graafina

Kui tahad, võin tuua ka lihtsa praktilise näite või selgitada nende vahet arendaja vaates.

Muidugi.

Lihtne vahe praktiliselt

Oletame, et tahad teha dokumendiassistendi, mis:

  1. võtab kasutaja küsimuse,
  2. otsib infot dokumentidest,
  3. otsustab, kas infot on piisavalt,
  4. vajadusel küsib juurde või proovib uuesti,
  5. annab vastuse.

LangChainiga

Sa ehitad selle tavaliselt ketina:

  • küsimus sisse
  • otsing
  • leitud tekst mudelile
  • vastus välja

See on hea, kui voog on üsna sirgjooneline.

LangGraphiga

Sa modelleerid selle graafina, kus on sõlmed nagu:

  • küsimuse analüüs
  • otsing
  • vastuse hindamine
  • uuesti otsing
  • lõppvastus

Ja servad määravad:

  • kui infot piisab → mine lõppvastusesse
  • kui infot ei piisa → tee uus otsing
  • kui küsimus on ebaselge → küsi kasutajalt täpsustust

See on parem, kui loogika on mittelineaarne.

Väga lihtne analoogia

  • LangChain = retsept sammudega A → B → C
  • LangGraph = metrookaart, kus saab valida erinevaid teid ja mõnikord samasse punkti tagasi tulla

Millal kumba kasutada?

Kasuta LangChaini, kui:

  • sul on lihtne chatbot või RAG-rakendus,
  • töövoog on lineaarne,
  • tahad kiiresti prototüüpi teha.

Kasuta LangGraphi, kui:

  • sul on agent, kes peab otsuseid tegema,
  • töövoog sisaldab harusid, tsükleid või retry-loogikat,
  • vajad “human-in-the-loop” lahendust,
  • tahad rohkem kontrolli agentide seisundi üle.

Arendaja vaates

LangChain annab ehitusklotsid:

  • prompt templates
  • model wrappers
  • retrievers
  • tools
  • output parsers

LangGraph lisab nende peale:

  • state management
  • node/edge põhise töövoo
  • conditional routing
  • loopid
  • vastupidavamad agent-süsteemid

Lühike näide ideena

Näiteks klienditoe agent:

LangChain:

  • võta küsimus
  • otsi teadmistebaasist
  • vasta

LangGraph:

  • klassifitseeri küsimus
  • kui arvega seotud → mine billing-agent’i
  • kui tehniline → mine tech-agent’i
  • kui vastus ebakindel → eskaleeri inimesele
  • kui info puudub → küsi kasutajalt täpsustust

Kui tahad, võin järgmisena näidata:

  1. väikest Pythoni näidet,
  2. LangChain vs LangGraph tabelit,
    või 3. kuidas neid koos kasutada.

Selge — vaatame kuidas LangChain ja LangGraph koos töötavad.

Idee lühidalt

  • LangChain = mida agent oskab teha (LLM, retriever, tööriistad)
  • LangGraph = millal ja miks neid tehakse (loogika, harud, tsüklid)

LangGraph ei asenda LangChaini, vaid kasutab selle komponente.

Näidisstsenaarium

Teeme lihtsa klienditoe agendi, kes:

  1. saab kasutaja küsimuse,
  2. otsustab, kas vastata teadmistebaasist või küsida täpsustust,
  3. vajadusel proovib otsingut uuesti,
  4. annab vastuse või suunab inimesele.

1️⃣ LangChaini osad (ehitusklotsid)

from langchain_openai import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain.chains import LLMChain

Mudel

llm = ChatOpenAI(model="gpt-4o-mini")

Prompt vastuse loomiseks

answer_prompt = ChatPromptTemplate.from_template("""
Kasuta järgmist infot küsimusele vastamiseks.

Küsimus: {question}
Info: {context}

Kui infot ei ole piisavalt, ütle "EI_PIISA".
""")

answer_chain = LLMChain(
    llm=llm,
    prompt=answer_prompt
)

👉 See on puhas LangChain: mudel + prompt + chain.

2️⃣ LangGraphi olek (state)

LangGraphis liigub kogu info ühes state’is.

from typing import TypedDict, Optional

class SupportState(TypedDict):
    question: str
    context: Optional[str]
    answer: Optional[str]

3️⃣ LangGraphi sõlmed (node’id)

Iga sõlm kasutab LangChaini loogikat.

Vastuse loomise sõlm

def generate_answer(state: SupportState):
    result = answer_chain.invoke({
        "question": state["question"],
        "context": state.get("context", "")
    })
    return {"answer": result["text"]}

4️⃣ Otsustusloogika (conditional edge)

def needs_more_info(state: SupportState) -> str:
    if state["answer"] == "EI_PIISA":
        return "ask_clarification"
    return "final"

5️⃣ LangGraphi graaf

from langgraph.graph import StateGraph, END

graph = StateGraph(SupportState)

graph.add_node("generate_answer", generate_answer)
graph.add_node("ask_clarification", lambda s: {
    "answer": "Palun täpsusta oma küsimust."
})

graph.set_entry_point("generate_answer")

graph.add_conditional_edges(
    "generate_answer",
    needs_more_info,
    {
        "ask_clarification": "ask_clarification",
        "final": END
    }
)

app = graph.compile()

6️⃣ Käivitamine

result = app.invoke({
    "question": "Mul ei tööta arve allalaadimine",
    "context": ""
})

print(result["answer"])

Mis siin päriselt toimub?

✅ LangChain

  • suhtleb LLM-iga
  • ehitab prompt’i
  • tagastab vastuse

✅ LangGraph

  • hoiab state’i
  • otsustab, kuhu edasi liikuda
  • võimaldab harusid ja tsükleid

Miks see koos on võimas?

Ilma LangGraphita:

  • keeruline hallata retry’sid
  • raske lisada inimese sekkumist
  • loogika läheb if/else kaoseks

LangGraphiga:

  • töövoog on selgelt visualiseereritav
  • agent käitub deterministlikumalt
  • lihtne lisada uusi harusid või agente

Kokkuvõte ühe lausega

LangChain annab tööriistad, LangGraph annab ajupoolkerad.

Kui tahad, võin järgmisena:

  • lisada RAG-i otsingu sellesse graafi,
  • näidata multi-agent varianti,
  • või joonistada skeemi ASCII või pildina.

Väga hea küsimus — vastus on: oleneb, mida sa ehitad.

Lühivastus

✅ On olemas kompaktsemaid / low-code lahendusi
✅ Aga keerukamate agentide puhul läheb ikkagi koodiks (enamasti Pythoniks)

1️⃣ Kui tahad võimalikult kompaktset lahendust

🔹 Variant A — Lihtne RAG / chatbot ilma palju koodita

Sa saad teha:

  • OpenAI + vektorandmebaas (nt Pinecone, Weaviate)
  • LangChain Expression Language (LCEL) – väga kompaktne
  • No-code tööriistad (Flowise, LangFlow)

Näide väga kompaktsest LCEL-ist:

chain = retriever | prompt | llm
response = chain.invoke("Mis on meie tagastuspoliitika?")

See on sisuliselt 1 rida loogikat.

🔹 Variant B — Visuaalsed tööriistad

On olemas:

  • LangFlow
  • Flowise
  • Dify
  • n8n + AI nodes
  • OpenAI Assistants API

Need võimaldavad:

  • lohistada node’e
  • ühendada LLM + retriever + tööriistad
  • seadistada loogikat ilma palju koodi kirjutamata

👉 Väga sobiv MVP või sisemiste tööriistade jaoks.

2️⃣ Millal läheb vältimatult koodiks?

Sa vajad Pythoni (või JS-i), kui:

  • on keeruline äriloogika
  • palju conditional branch’e
  • multi-agent süsteem
  • retry, timeout, error handling
  • human-in-the-loop
  • spetsiifiline integratsioon (ERP, CRM, API-d)
  • tootmiskeskkonna skaleerimine

Sellisel juhul graafipõhine lahendus + kood on praktiliselt vältimatu.

3️⃣ Kas peab igal eri juhtumil nullist kirjutama?

Ei pea.

Tüüpiline arendusmuster:

  1. Teed ühe korraliku agentiraamistiku
  2. Ehitad korduvkasutatavad node’id:
    • retrieve()
    • classify()
    • generate_answer()
    • route()
  3. Lisad uusi use case’e lihtsalt konfigureerides

LangGraph on just selleks tehtud — et sa ei kirjutaks iga agenti nullist.

4️⃣ Mida päris ettevõtted teevad?

Reaalsuses:

  • MVP → low-code või lihtne LangChain
  • Kui kasvab → LangGraph + Python
  • Kui väga suur süsteem → oma agent framework LangGraphi peal

5️⃣ Soovitus sõltuvalt eesmärgist

Eesmärk Soovitus
Väike chatbot LangChain või OpenAI Assistants
Dokumentide Q&A RAG + LCEL
Sisemine tööriist LangFlow / Flowise
Keeruline AI-agent LangGraph + Python
Tootmiskeskkond Kindlasti kood

Kui sa ütled, mida sa täpselt ehitada tahad, oskan öelda:

  • kas piisab kompaktsest lahendusest
  • või tasub kohe graaf + kood teha

Mis tüüpi süsteem sul mõttes on?

See on väga huvitav ja täiesti realistlik eesmärk — ning hea uudis on, et sa ei pea kõike alguses Pythoni koodiga ehitama, aga teatud hetkel on struktuurne raamistik vältimatu.

Allpool annan selge arhitektuurilise soovituse, mis sobib just etnomatemaatika ökosüsteemile (uurimine, probleemide loomine, artiklid).

1️⃣ Mida “ökosüsteem” sinu kontekstis tähendab

Sinu kirjelduse põhjal on sul vaja süsteemi, mis oskab:

✅ koguda ja hoida allikaid
✅ seostada matemaatilisi ideid kultuuriliste praktikatega
✅ luua uurimisküsimusi
✅ genereerida ja lahendada probleeme
✅ aidata kirjutada teadusartikleid
✅ hoida uurimisloogikat ja jälgitavust

See EI ole lihtsalt chatbot.

Järgmised loogilised sammud

Soovitan valida üks:

1️⃣ täita üks konkreetne näide (nt Aafrika mustrid)
2️⃣ kujundada uurimisküsimuste generaator selle mudeli peale
3️⃣ teha hariduslike probleemide loomise skeem

Millisega jätkame?

Teeme ühe konkreetse näite. Valin sellise, mis on etnomatemaatikas üsna tuntud ja hea mudeli testimiseks:

Näide: Aafrika arhitektuuri fraktaalsed mustrid

See on seotud eriti Ron Eglashi töödega, kus ta käsitleb, kuidas mõnede Aafrika kogukondade asulate ja disainide puhul ilmnevad isetaolisus, rekursioon ja skaalastruktuurid.

Ma teen selle sulle nii, nagu see võiks juba sinu andmemudelis olemas olla.

1️⃣ Cultural_Context

id: CC-001
kultuur_kogukond: "Valitud Sahara-taguse Aafrika kogukonnad"
geograafia: "Lääne-, Kesk- ja Lõuna-Aafrika"
ajaperiood: "peamiselt 19.–21. sajandi kirjeldused, osalt varasemad traditsioonid"
keeled: "sõltub kogukonnast"
sotsiaalne_kontekst: "külade planeering, elamuarhitektuur, perekondlik ja kogukondlik ruumikorraldus"
uurija_roll: "sekundaarallikatel põhinev analüüs"
märkused: "Vajab kogukonnapõhist täpsustamist; 'Aafrika' ei tohi jääda homogeniseerivaks kategooriaks."

👉 Väga oluline märkus: etnomatemaatikas tuleb vältida liiga üldistavat “Aafrika matemaatika” käsitlust. Parem on hiljem kitsendada konkreetsetele kogukondadele.

2️⃣ Practice_Artifact

id: PA-001
nimetus: "Külaplaneering ja elamuarhitektuuri ruumimustrid"
tüüp: "arhitektuur"
kirjeldus_emic: "Asustuse ruumiline korraldus väljendab sugulus-, kaitse-, staatuse- või rituaalseid suhteid."
kirjeldus_etic: "Asulate paigutuses ja hoonete struktuuris võib täheldada korduvaid geomeetrilisi ja skaleeruvaid mustreid."
kasutusolukord: "igapäevane elamine, sotsiaalne organiseerumine, rituaalne ja praktiline ruumikasutus"
seotud_kultuurid: ["erinevad Sahara-taguse Aafrika kogukonnad"]
visuaalsed_allikad: ["külaplaanid", "õhuvaated", "joonised", "fotod"]

Siin on hea näha, et:

  • emic = kuidas kogukond ise võiks tähendust mõtestada
  • etic = analüütiline, uurija kirjeldus

3️⃣ Mathematical_Structure

id: MS-001
tüüp: "fraktaalne geomeetria"
formaalne_kirjeldus: "Ruumiline konfiguratsioon sisaldab isetaolisuse tunnuseid, kus sarnane paigutusmuster kordub eri mastaapidel."
mitteametlik_kirjeldus: "Küla või elamugrupi üldkuju sarnaneb väiksemate osade korraldusega."
tasand: "algoritmiline / osaliselt formaalne"
tuntud_matemaatilised_analoogid: ["isetaolisus", "rekursioon", "iteratiivne geomeetriline ehitus"]
märkus_formaliseerimise_kohta: "Tuleb eristada ranget matemaatilist fraktaali ja heuristilist fraktaalsust kultuurilises artefaktis."

👉 See märkus on väga tähtis. Sageli kasutatakse “fraktaali” liiga vabalt. Teaduslikult peab jääma ettevaatlikuks:

  • kas see on range fraktaal
  • või lihtsalt fraktaalilaadne muster

4️⃣ Ethno_Math_Link

praktika_id: PA-001
matemaatika_id: MS-001
seose_tüüp: "implitsiitne / heuristiline"
tõendusmaterjal: "Asulate plaanides ja arhitektuursetes kujundites esineb korduv skaleerumine ning pesastatud ruumiline struktuur."
uurija_interpretatsioon: "Ruumiline organiseerumine võib olla kirjeldatav rekursiivse või fraktaalse loogika abil."
kindluse_aste: "keskmine"
vaidlused_alternatiivsed_tõlgendused: "Võib vaielda, kas tegemist on teadliku matemaatilise konstrueerimisega või uurija tagantjärele formaliseeriva kirjeldusega."

See on vist kogu mudeli üks tähtsamaid osi.

Miks? Sest etnomatemaatikas tekib alati küsimus:

kas kogukond ise kasutab seda matemaatikat sellisel kujul
või
kas uurija projitseerib matemaatilise formaali peale?

See väli aitab hoida metodoloogilist ausust.

5️⃣ Source

Paneme siia ühe tüüpilise allika.

id: S-001
autor: "Ron Eglash"
aasta: 1999
tüüp: "raamat"
tsitaat: "African Fractals: Modern Computing and Indigenous Design"
DOI_URL: "vastavalt väljaande andmetele"
usaldusväärsuse_hinnang: "kõrge, kuid vajab kriitilist võrdlust teiste uurijatega"
märkused: "Oluline lähtekoht, kuid mitte ainus interpretatsioon."

Võiks lisada ka täiendavaid kriitilisi või toetavaid allikaid, et vältida ühe autori ülemäärast domineerimist.

6️⃣ Research_Question

Nüüd teeme sellest uurimisküsimuse.

id: RQ-001
küsimus: "Kuidas ja millises ulatuses saab valitud Aafrika kogukondade külaplaneeringut kirjeldada fraktaalse geomeetria mõistete abil ilma kultuurilist tähendust taandamata pelgalt formaalseks struktuuriks?"
tüüp: "analüütiline / teoreetiline"
seotud_üksused: ["CC-001", "PA-001", "MS-001", "S-001"]
motivatsioon: "Ühendada matemaatiline analüüs ja kultuuriline interpretatsioon viisil, mis on metodoloogiliselt ettevaatlik."
uurimismeetod: "kirjandusanalüüs, visuaalne võrdlus, geomeetriline modelleerimine, interpretatiivne analüüs"
avatud_probleemid: [
  "Kas fraktaalsus on range või heuristiline?",
  "Kas muster on teadlikult kujundatud või emergentne?",
  "Kuidas esitada matemaatiline kirjeldus ilma emic tähendusi vähendamata?"
]

7️⃣ Problem_Task

Nüüd loome sellest ühe haridusliku või uurimusliku probleemi.

id: PT-001
ülesande_tekst: "Võrdle kahte külaplaneeringu skeemi ja analüüsi, kas neis esineb isetaolisuse tunnuseid. Too välja, millised jooned toetavad fraktaalset interpretatsiooni ja millised mitte."
päritolu: "etnomatemaatiline analüüs Aafrika arhitektuuri näitel"
matemaatiline_fookus: "isetaolisus, mastaap, geomeetriline struktuur"
lahendus_lahendusidee: "Õppija tuvastab korduvad paigutusmustrid eri tasanditel ja arutleb, kas sarnasus on piisav fraktaalse kirjelduse jaoks."
didaktiline_eesmärk: "Arendada võimet siduda kultuuriline artefakt geomeetrilise analüüsiga kriitiliselt."
raskusaste: "keskmine / edasijõudnu"

8️⃣ Manuscript

Ja lõpuks, kuidas sellest võiks saada artikkel.

id: M-001
pealkiri: "Fraktaalne mõtlemine ja ruumiline organiseerumine Aafrika arhitektuuri etnomatemaatilises tõlgenduses"
staatus: "mustand"
seotud_uurimisküsimused: ["RQ-001"]
struktuur:
  - "Sissejuhatus"
  - "Etnomatemaatika teoreetiline raamistik"
  - "Fraktaalse geomeetria mõiste ja piirid"
  - "Aafrika arhitektuursete mustrite juhtumianalüüs"
  - "Emic ja etic tõlgenduse pinge"
  - "Järeldused"
kasutatud_allikad: ["S-001"]
metoodika_kirjeldus: "Kombineeritakse sekundaarallikate analüüs, visuaalne struktuurivõrdlus ja matemaatiline formaliseerimine."
piirangud: "Juhtum põhineb peamiselt kirjandusel, mitte esmavälitööl; üldistuste tegemisel tuleb olla ettevaatlik."

9️⃣ Mida see näide sulle näitab

See üks näide demonstreerib, kuidas sinu andmemudel aitab siduda:

  • kultuurilise reaalsuse
  • matemaatilise struktuuri
  • allikad
  • uurimisküsimused
  • õppeülesanded
  • artikli visandi

See tähendab, et sama mudel saab hiljem toetada:

  • teadmistebaasi
  • probleemigeneraatorit
  • artikliassistenti
  • uurimisagenti

🔟 Väga oluline metodoloogiline märkus

Etnomatemaatika puhul soovitan lisada iga kirje juurde veel ühe välja:

epistemiline_ettevaatus

Näiteks:

epistemiline_ettevaatus: "Fraktaalse geomeetria rakendamine on siin uurija analüütiline tööriist, mitte tingimata kogukonna enesekirjelduse osa."

See aitab vältida:

  • romantiseerimist
  • ületõlgendamist
  • anakronistlikku formaliseerimist

Soovitus järgmiseks sammuks

Nüüd oleks väga kasulik teha üks kahest:

  1. teisendada see näide tabelikujule, et saaksid kohe Notioni/Obsidiani panna
  2. teha teine näide täiesti teisest valdkonnast, nt:
    • rahvuslikud mustrid ja sümmeetria
    • rahvamängud ja kombinatoorika
    • kalendrid ja arvusüsteemid
    • kudumine ja geomeetria

Minu soovitus: järgmine samm võiks olla sama näide tabelina, sest siis saad kohe süsteemi ehitama hakata.

Jah — PostgreSQL on väga hea tehniline põhi sinu ökosüsteemile.

Lühivastus

Kui sa tahad ehitada päriselt kasvavat etnomatemaatika uurimisökosüsteemi, siis minu soovitus on:

  • peamine andmebaas: PostgreSQL
  • vektorotsing: pgvector või eraldi vektorandmebaas hiljem
  • dokumentide hoidla: failisüsteem / object storage
  • alguses kasutajaliides: Obsidian / Notion / lihtne admin-vaade

Ehk: PostgreSQL + dokumentide hoidla + hiljem vektorotsing
on väga mõistlik baas.

1️⃣ Miks PostgreSQL sobib sulle hästi?

Sinu süsteem ei ole lihtsalt “chatboti mälu”.
Sul on vaja:

  • struktureeritud entiteete
  • palju seoseid
  • allikate haldust
  • teaduslikku jälgitavust
  • päringuid stiilis:
    • “näita kõik praktikad, mis on seotud sümmeetriaga”
    • “millistel juhtudel on kindluse aste madal”
    • “millistest allikatest tuleb mingi interpretatsioon”
    • “millised uurimisküsimused põhinevad samal artefaktil”

See on klassikaline relatsioonilise andmebaasi juhtum.

PostgreSQL annab:

  • tugevad relatsioonid
  • head JOIN-id
  • JSONB paindlikkuse jaoks
  • full-text search
  • pgvector võimaluse
  • küpse ökosüsteemi

2️⃣ Soovitatav arhitektuur

Variant A — praktiline ja tasakaalus

Sobib sulle kõige paremini alguses

  • PostgreSQL — põhientiteedid ja seosed
  • pgvector — embeddingud ja semantiline otsing
  • MinIO / S3 / failikaustad — PDF-id, pildid, skannid
  • Python backend — ingest, RAG, agentid
  • Obsidian või lihtne veebiliides — sisestus ja märkmed

See on väga tugev ja mitte liiga keeruline.

Variant B — algul eriti lihtne

  • Markdown failid / Obsidian
  • metadata YAML-is
  • hiljem skriptiga PostgreSQL-i

See sobib, kui tahad esimesed 20–50 objekti käsitsi läbi mõelda.

Variant C — enterprise raskekahur

  • PostgreSQL
  • Neo4j
  • eraldi vektorandmebaas
  • dokumentide pipeline
  • API + admin-süsteem

Ausalt: praegu ei soovita. Liiga keeruline liiga vara.

3️⃣ Miks mitte kohe Neo4j või ainult graph DB?

Sinu mudelis on tõesti palju seoseid, nii et võib tunduda, et graafibaas oleks ideaalne.

Aga alguses:

  • teadusandmed vajavad tugevat tabelstruktuuri
  • allikate viited, metainfo, versioonid, staatused jne sobivad paremini SQL-i
  • graafiloogikat saab PostgreSQL-is väga hästi modelleerida join-tabelitega

Seega: graafiline mõtlemine jah, aga tehniline baas pigem PostgreSQL.

Kui hiljem on vaja:

  • keerulist teadmistegraafi,
  • semantilisi seosevõrgustikke,
  • visuaalset uurimist,

siis võib lisada Neo4j või RDF/graph kihi.

4️⃣ Milline võiks olla skeemi põhimudel PostgreSQL-is?

Näiteks põhitabelid:

  • cultural_context
  • practice_artifact
  • mathematical_structure
  • ethno_math_link
  • source
  • research_question
  • problem_task
  • manuscript

Ja seostabelid:

  • practice_source
  • research_question_source
  • manuscript_source
  • practice_cultural_context
  • problem_task_structure

See on väga loomulik SQL-mudel.

5️⃣ Kuidas ühendada struktureeritud ja “pehme” teadusandmestik?

See on sinu valdkonnas oluline, sest kõik ei mahu jäigalt tabelisse.

Selleks kasuta PostgreSQL-is:

🔹 relatsioonid + JSONB

Näiteks:

  • põhiväljad tabeliveergudes
  • keerulisemad märkused, tõlgendused, välitöödetailid JSONB-s

Näide:

  • epistemic_caution võib olla tavaline tekstiväli
  • alternative_interpretations võib olla JSONB massiiv
  • emic_terms võib olla JSONB

Nii saad:

  • struktuuri
  • paindlikkuse
  • hilisema AI kasutuse

6️⃣ Kas pgvector on piisav?

Jah, alguses küll.

Kui sul tekib vajadus:

  • otsida artikleid
  • leida sarnaseid praktikaid
  • vastata küsimustele allikate põhjal
  • teha RAG-i

siis pgvector on väga hea algus.

See tähendab:

  • sama PostgreSQL hoiab nii tavakirjeid kui embeddinguid
  • vähem infrastruktuuri
  • lihtsam hooldada

Hiljem, kui maht läheb väga suureks, saad liikuda:

  • Qdrant
  • Weaviate
  • Pinecone
  • Milvus

Aga alguses pole vaja.

7️⃣ Mida ma sinu puhul konkreetselt soovitaksin

Kui tahad teadlikult ja jätkusuutlikult ehitada:

Faas 1

  • Obsidian / Markdown
  • käsitsi mudeli testimine
  • 20–30 näidet

Faas 2

  • PostgreSQL
  • sama mudel SQL-tabelitena
  • failid eraldi kaustas või object storage’is

Faas 3

  • PostgreSQL + pgvector
  • lihtne RAG
  • allikate otsing
  • uurimisküsimuste assistent

Faas 4

  • Python + LangGraph
  • artikliagent
  • probleemigeneraator
  • uurimisvood

8️⃣ Minu konkreetne tehniline stack-soovitus

Kui tahad praktilist vastust:

  • DB: PostgreSQL 16+
  • Vector: pgvector
  • Backend: Python + FastAPI
  • ORM: SQLAlchemy või SQLModel
  • Migrations: Alembic
  • Document storage: MinIO või lihtsalt kaustastruktuur
  • Parsing: Python (pymupdf, unstructured, pandoc vastavalt vajadusele)
  • Admin/UI: alguses Supabase Studio / pgAdmin / lihtne custom admin
  • AI kiht: LangChain + hiljem LangGraph

9️⃣ Kui tahad eriti väikese keerukusega varianti

Sa võid teha ka nii:

  • Supabase
    • all on PostgreSQL
    • saad auth’i
    • saad admin-liidese
    • saad API üsna kiiresti
    • saad hiljem pgvectori

See on väga hea, kui sa ei taha kohe serverihaldusse minna.

🔟 Lõppsoovitus ühe lausega

Jah — PostgreSQL on sinu ökosüsteemile kõige mõistlikum tehniline põhi.
Mitte sellepärast, et see on “trendikas”, vaid sest sinu probleem on:

  • relatsiooniline,
  • teaduslik,
  • laiendatav,
  • ja hiljem AI-ga rikastatav.

Kui tahad, järgmine samm võiks olla üks neist:

  1. joonistan sulle PostgreSQL tabeliskeemi
  2. kirjutan esimese SQL skeemi mustandi
  3. pakun välja kogu süsteemi arhitektuuri diagrammina
  4. soovitan, kas võtta Supabase või oma PostgreSQL

Minu soovitus: 1 või 2.

Siin on praktiline arhitektuuridiagramm sinu etnomatemaatika ökosüsteemile, alustades Postgresest ja jättes ruumi RAG-ile, agentidele ja artiklikirjutusele.

Kõrgtaseme vaade

                    ┌─────────────────────────────┐
                    │        Kasutajaliides       │
                    │ Obsidian / Web UI / Admin   │
                    └──────────────┬──────────────┘
                                   │
                            HTTPS / API
                                   │
                    ┌──────────────▼──────────────┐
                    │     Rakenduskiht            │
                    │  FastAPI / Python services  │
                    │ - CRUD                       │
                    │ - ingest                     │
                    │ - search                     │
                    │ - article assistant          │
                    │ - problem generator          │
                    └───────┬───────────┬─────────┘
                            │           │
                 SQL/Vector │           │ Files/API
                            │           │
          ┌─────────────────▼───┐   ┌──▼──────────────────┐
          │    PostgreSQL       │   │ Dokumentide hoidla  │
          │ + pgvector          │   │ PDFs, pildid, märkmed│
          │                     │   │ S3 / MinIO / kaustad │
          │ - core tables       │   └─────────┬────────────┘
          │ - relations         │             │
          │ - metadata          │             │
          │ - embeddings        │             │
          └─────────┬───────────┘             │
                    │                         │
                    │                         │ parse/chunk
                    │                         │
          ┌─────────▼───────────┐    ┌───────▼─────────────┐
          │ Otsingu ja RAG kiht │    │ Dokumendi ingest    │
          │ - keyword search    │    │ - PDF parse         │
          │ - vector search     │    │ - OCR vajadusel     │
          │ - hybrid retrieval  │    │ - chunking          │
          └─────────┬───────────┘    │ - embeddings        │
                    │                └─────────┬───────────┘
                    │                          │
                    └──────────────┬───────────┘
                                   │
                           ┌───────▼───────────┐
                           │ AI / Agentikiht   │
                           │ LangChain         │
                           │ LangGraph         │
                           │ - research agent  │
                           │ - article agent   │
                           │ - problem agent   │
                           └───────┬───────────┘
                                   │
                           ┌───────▼───────────┐
                           │ LLM provider      │
                           │ OpenAI / muu LLM  │
                           └───────────────────┘

1. Kihtide rollid

A. Kasutajaliides

See võib alguses olla:

  • Obsidian
  • Notion
  • lihtne veebiliides
  • admin-paneel

Sealt sa:

  • sisestad uusi praktikaid
  • seod allikaid
  • vaatad uurimisküsimusi
  • käivitad artikli- või probleemigeneraatori

B. Rakenduskiht

See on sinu süsteemi “aju” väljaspool LLM-i.

Tüüpilised teenused:

  • kirje loomine/muutmine
  • allikate import
  • dokumentide töötlemine
  • otsingu API
  • artikli mustandi loomine
  • audit / logimine

Soovitus:

  • FastAPI
  • Python
  • taustatööd Celery/RQ/Arq, kui vaja

C. PostgreSQL + pgvector

See on põhituum.

Hoidmiseks:

  • kultuurilised kontekstid
  • praktikad
  • matemaatilised struktuurid
  • seosed
  • allikad
  • uurimisküsimused
  • käsikirjad
  • embeddings

D. Dokumentide hoidla

Siia lähevad:

  • PDF-id
  • fotod
  • skännid
  • intervjuude transkriptsioonid
  • käsikirjade versioonid

Ära pane suuri faile Postgresesse. Pane Postgresesse:

  • failitee
  • URL
  • checksum
  • metadata

E. Ingest-kiht

Kui tood sisse artikli või välitööfaili, siis see kiht:

  • loeb faili
  • teeb OCR-i kui vaja
  • lõikab tükkideks
  • lisab metadata
  • teeb embeddingud
  • salvestab chunkid ja viited

F. Otsingu ja RAG kiht

See teenindab küsimusi nagu:

  • “Millised praktikad on seotud sümmeetriaga?”
  • “Leia allikad, kus arutatakse fraktaalsust arhitektuuris.”
  • “Millised kirjed on seotud kindluse astmega madal?”

Otsing võiks olla:

  • märksõnaotsing
  • semantiline otsing
  • hübriidotsing

G. AI / agentikiht

See kasutab:

  • andmebaasi
  • dokumendiotsingut
  • allikaid
  • uurimismalle

Siin tulevad:

  • uurimisküsimuste generaator
  • probleemide looja
  • artikli assistent
  • allikakriitika assistent

2. Andmevood

Voog 1: Uue allika lisamine

Kasutaja laadib PDF-i üles
→ fail salvestatakse document storage'i
→ ingest teenus parsib teksti
→ tekst tükeldatakse
→ embeddingud luuakse
→ metadata + chunkid lähevad PostgreSQL-i
→ allikas seotakse praktikate / teemadega

Voog 2: Uurimisküsimuse loomine

Kasutaja valib kultuuri + praktika + matemaatilise struktuuri
→ backend teeb päringu seotud allikatele
→ RAG kiht toob toetava materjali
→ research agent loob 5–10 uurimisküsimust
→ kasutaja valib ja salvestab

Voog 3: Artikli mustandi loomine

Kasutaja valib uurimisküsimuse
→ süsteem koondab seotud allikad ja märkmed
→ article agent loob struktuuri
→ iga peatüki jaoks otsitakse tõendusmaterjal
→ mustand salvestatakse käsikirjana

Voog 4: Probleemi genereerimine

Valitakse praktika või matemaatiline struktuur
→ problem agent loob ülesanded
→ lisab lahendusidee
→ seob didaktilise eesmärgiga
→ salvestab problem_task tabelisse

3. Soovitatud teenuste jaotus

[UI]
  ├─ Research dashboard
  ├─ Source manager
  ├─ Manuscript editor
  └─ Problem generator view

[API / Backend]
  ├─ auth
  ├─ entity CRUD
  ├─ relation manager
  ├─ search API
  ├─ ingest API
  ├─ AI orchestration
  └─ audit/logging

[Data]
  ├─ PostgreSQL
  ├─ pgvector
  └─ object storage

[AI]
  ├─ embeddings model
  ├─ LLM
  ├─ LangChain retrieval
  └─ LangGraph workflows

4. Minimaalne MVP-arhitektuur

Kui sa ei taha üle ehitada, siis alusta nii:

Kasutaja
  ↓
FastAPI
  ↓
PostgreSQL + pgvector
  ↓
Kaust / MinIO dokumentidele
  ↓
OpenAI API

Ja funktsioonid:

  • praktikate sisestus
  • allikate sisestus
  • otsing
  • lihtne uurimisküsimuste generaator
  • lihtne artikli mustandi generaator

See on täiesti piisav esimese versiooni jaoks.

5. Millal lisada LangGraph?

Lisa siis, kui sul tekib vajadus:

  • mitmeastmeliseks artikli kirjutuseks
  • allikate kontrolliks enne genereerimist
  • “kui allikaid pole piisavalt, küsi juurde”
  • eri agentide koostööks
  • kvaliteedikontrolli sõlmedeks

Alguses ei pea kõik olema agent.

6. Turvalisus ja teaduslik usaldusväärsus

Sinu süsteemis on väga oluline:

Hoia alles:

  • kust vastus tuli
  • milliste allikate põhjal tekst loodi
  • milline osa on LLM-i süntees
  • milline osa on kasutaja märkus
  • versioonid

Seetõttu lisa arhitektuuri sisse:

  • audit log
  • provenance metadata
  • citation tracking
  • manuscript versioning

Praktiliselt:

AI output
  → salvestatakse eraldi väljana
  → seotud kasutatud source_id-dega
  → märgitakse "draft_generated"

See on hilisema teadustöö jaoks väga oluline.

7. Soovituslik tehniline stack

Lihtne ja tugev:

  • Frontend: alguses lihtne admin/UI või isegi Supabase Studio
  • Backend: FastAPI
  • DB: PostgreSQL
  • Vector: pgvector
  • Storage: MinIO või S3
  • Parsing: PyMuPDF / unstructured
  • LLM: OpenAI
  • AI orchestration: LangChain
  • Workflow: LangGraph hiljem
  • Migrations: Alembic
  • Containerid: Docker Compose alguses

8. Diagramm koos arendusetappidega

FAAS 1
Obsidian / käsitsi andmed
        ↓

FAAS 2
PostgreSQL + FastAPI + failihoidla
        ↓

FAAS 3
pgvector + ingest + RAG otsing
        ↓

FAAS 4
Research agent + article agent
        ↓

FAAS 5
LangGraph workflowd + kvaliteedikontroll + versioonihaldus

9. Minu praktiline soovitus sinu jaoks

Sinu puhul ma ei alustaks:

  • Neo4j-ga
  • mikroteenustega
  • eraldi vektor-DB-ga
  • liiga keerulise front-endiga

Ma alustaks:

  1. PostgreSQL
  2. FastAPI
  3. MinIO või lihtsalt dokumentide kaust
  4. pgvector
  5. üks või kaks AI-workflowd

See annab sulle:

  • teadusliku korrastatuse
  • AI-valmiduse
  • skaleeritavuse
  • väikese keerukuse

Kui tahad, järgmine samm võiks olla üks neist:

  1. teen sulle selle arhitektuuri põhjal kaustastruktuuri ja teenuste nimekirja
  2. joonistan sama arhitektuuri veel detailsemalt koos tabelitega
  3. annan sulle MVP ehitusplaani 30 päevaks
  4. teen Docker Compose tasemel tehnilise stardi

Allpool on detailsem arhitektuur koos põhiteenustega ja seejärel Docker Compose tasemel stardikomplekt, kuhu lisasin ka LangGraphi.

Detailsem arhitektuur

┌──────────────────────────────────────────────────────────────────────────────┐
│                                KASUTAJAD                                     │
│  Uurija / autor / administraator                                            │
└───────────────────────────────┬──────────────────────────────────────────────┘
                                │
                                │ HTTPS
                                ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                             FRONTEND / ADMIN                                 │
│  - Web UI (hiljem)                                                           │
│  - Supabase Studio / pgAdmin / lihtne admin                                  │
│  - Või Obsidian + import                                                     │
└───────────────────────────────┬──────────────────────────────────────────────┘
                                │ REST / WebSocket
                                ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                              FASTAPI BACKEND                                 │
│                                                                              │
│  API kihid:                                                                  │
│  ├─ auth / users                                                             │
│  ├─ entities CRUD                                                            │
│  ├─ search API                                                               │
│  ├─ ingest API                                                               │
│  ├─ manuscripts API                                                          │
│  ├─ AI orchestration API                                                     │
│  └─ audit / provenance                                                       │
│                                                                              │
│  Sisemised moodulid:                                                         │
│  ├─ services/db_service                                                      │
│  ├─ services/storage_service                                                 │
│  ├─ services/embedding_service                                               │
│  ├─ services/retrieval_service                                               │
│  ├─ services/citation_service                                                │
│  ├─ services/manuscript_service                                              │
│  ├─ services/problem_service                                                 │
│  └─ services/research_service                                                │
└───────────────┬───────────────────────┬───────────────────────┬──────────────┘
                │                       │                       │
                │ SQL                   │ S3 API                │ LLM API
                ▼                       ▼                       ▼
┌────────────────────────┐   ┌──────────────────────┐   ┌──────────────────────┐
│ PostgreSQL             │   │ MinIO / S3 storage   │   │ OpenAI / muu LLM     │
│ + pgvector             │   │                      │   │ + embedding model     │
│                        │   │ - PDFs               │   │                      │
│ Core tables:           │   │ - images             │   │                      │
│ - cultural_context     │   │ - notes exports      │   │                      │
│ - practice_artifact    │   │ - manuscript files   │   │                      │
│ - mathematical_struct. │   │ - OCR outputs        │   │                      │
│ - ethno_math_link      │   └──────────────────────┘   └──────────────────────┘
│ - source               │
│ - source_chunk         │
│ - embeddings           │
│ - research_question    │
│ - problem_task         │
│ - manuscript           │
│ - ai_run               │
│ - citation_map         │
│ - audit_log            │
└───────────────┬────────┘
                │
                │
                ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                         INTAKE / INGEST / INDEXING                           │
│                                                                              │
│  Pipeline:                                                                   │
│  1. upload source                                                            │
│  2. parse text (PDF/OCR)                                                     │
│  3. normalize metadata                                                       │
│  4. chunk document                                                           │
│  5. embed chunks                                                             │
│  6. save chunks + vectors + provenance                                       │
│  7. optional auto-link suggestions                                           │
└───────────────────────────────┬──────────────────────────────────────────────┘
                                │
                                ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                       SEARCH / RETRIEVAL / RAG LAYER                         │
│                                                                              │
│  - SQL filters                                                               │
│  - Full-text search                                                          │
│  - pgvector similarity                                                       │
│  - Hybrid retrieval                                                          │
│  - Citation-aware retrieval                                                  │
│  - Entity-scoped retrieval                                                   │
└───────────────────────────────┬──────────────────────────────────────────────┘
                                │
                                ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                         AI ORCHESTRATION LAYER                               │
│                                                                              │
│  LangChain components:                                                       │
│  - prompts                                                                   │
│  - retrievers                                                                │
│  - tool wrappers                                                             │
│  - output parsers                                                            │
│                                                                              │
│  LangGraph workflows:                                                        │
│  - Research Question Generator Graph                                         │
│  - Problem Generation Graph                                                  │
│  - Article Draft Graph                                                       │
│  - Evidence Check Graph                                                      │
│                                                                              │
│  Shared state examples:                                                      │
│  - selected entities                                                         │
│  - retrieved sources                                                         │
│  - evidence sufficiency                                                      │
│  - draft sections                                                            │
│  - citations                                                                 │
│  - human feedback                                                            │
└───────────────────────────────┬──────────────────────────────────────────────┘
                                │
                                ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                             OUTPUTS / ARTEFACTS                              │
│                                                                              │
│  - saved research questions                                                  │
│  - generated problems                                                        │
│  - manuscript drafts                                                         │
│  - citation maps                                                             │
│  - logs of AI runs                                                           │
│  - reproducibility metadata                                                  │
└──────────────────────────────────────────────────────────────────────────────┘

1. Tabelid ja teenused detailsemalt

A. PostgreSQL tabelid

Tuumandmed

  • cultural_context
  • practice_artifact
  • mathematical_structure
  • ethno_math_link
  • source
  • research_question
  • problem_task
  • manuscript

Dokumendi/RAG tabelid

  • source_document
  • source_chunk
  • chunk_embedding

Provenance / AI tabelid

  • ai_run
  • ai_run_input
  • ai_run_output
  • citation_map
  • audit_log

Seostabelid

  • practice_source
  • research_question_source
  • manuscript_source
  • artifact_context
  • problem_structure

B. LangGraphi roll selles arhitektuuris

LangGraph ei ole “eraldi andmebaas” ega “eraldi server”, vaid töövoogude orkestreerija backendis.

Näited workflowdest

1) Research Question Graph

vali entiteedid
→ too allikad
→ kontrolli, kas tõendusmaterjali on piisavalt
→ genereeri küsimused
→ hinda küsimuste kvaliteeti
→ tagasta/paranda

2) Problem Generation Graph

vali praktika või matemaatiline struktuur
→ tuleta võimalik õpieesmärk
→ loo probleem
→ loo lahendusidee
→ kontrolli kultuurilist sobivust
→ salvesta

3) Article Draft Graph

vali research_question
→ koonda allikad
→ jaga artikkel sektsioonideks
→ genereeri iga sektsioon allikate põhjal
→ kontrolli viiteid
→ märgi ebakindlad kohad
→ salvesta mustand

4) Evidence Check Graph

väide
→ leia allikad
→ hinda toetust
→ kui nõrk tugi, märgi hoiatus
→ tagasta tulemus

2. LangGraphi paigutus teenustes

Soovitan nii:

app/
  services/
    ai/
      chains/
      graphs/
        research_question_graph.py
        problem_graph.py
        article_graph.py
        evidence_graph.py
      tools/
        retrieve_sources.py
        get_entity_context.py
        save_manuscript.py
        save_problem.py
        citation_checker.py
      state/
        research_state.py
        article_state.py

See tähendab:

  • LangChain = promptid, retrieverid, tööriistad
  • LangGraph = kogu otsustusloogika

3. Docker Compose tasemel tehniline start

Allpool on praktiline starter-arhitektuur.

Teenused

  • api — FastAPI backend
  • worker — taustatööd ingestiks/AI jooksudeks
  • postgres — PostgreSQL + pgvector
  • minio — failide hoidla
  • redis — järjekord / cache
  • pgadmin — DB admin
  • valikuline: ollama või muu lokaalne LLM, kui tahad hiljem

Kaustastruktuur

ethnomath-platform/
├─ docker-compose.yml
├─ .env
├─ app/
│  ├─ main.py
│  ├─ core/
│  │  ├─ config.py
│  │  └─ logging.py
│  ├─ api/
│  │  ├─ routes/
│  │  │  ├─ entities.py
│  │  │  ├─ sources.py
│  │  │  ├─ search.py
│  │  │  ├─ manuscripts.py
│  │  │  └─ ai.py
│  ├─ db/
│  │  ├─ base.py
│  │  ├─ session.py
│  │  ├─ models/
│  │  └─ migrations/
│  ├─ schemas/
│  ├─ services/
│  │  ├─ ingest/
│  │  ├─ retrieval/
│  │  ├─ storage/
│  │  ├─ manuscripts/
│  │  ├─ problems/
│  │  └─ ai/
│  │     ├─ chains/
│  │     ├─ graphs/
│  │     ├─ tools/
│  │     └─ state/
│  ├─ workers/
│  │  ├─ tasks_ingest.py
│  │  └─ tasks_ai.py
│  └─ tests/
├─ Dockerfile
└─ requirements.txt

docker-compose.yml näidis

version: "3.9"

services:
  postgres:
    image: pgvector/pgvector:pg16
    container_name: ethnomath_postgres
    environment:
      POSTGRES_DB: ethnomath
      POSTGRES_USER: ethnomath
      POSTGRES_PASSWORD: ethnomath_pass
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7
    container_name: ethnomath_redis
    ports:
      - "6379:6379"

  minio:
    image: minio/minio:latest
    container_name: ethnomath_minio
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: minio
      MINIO_ROOT_PASSWORD: minio_secret
    ports:
      - "9000:9000"
      - "9001:9001"
    volumes:
      - minio_data:/data

  api:
    build: .
    container_name: ethnomath_api
    command: uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload
    env_file:
      - .env
    depends_on:
      - postgres
      - redis
      - minio
    ports:
      - "8000:8000"
    volumes:
      - ./:/app

  worker:
    build: .
    container_name: ethnomath_worker
    command: python -m app.workers.tasks_ai
    env_file:
      - .env
    depends_on:
      - postgres
      - redis
      - minio
    volumes:
      - ./:/app

  pgadmin:
    image: dpage/pgadmin4:latest
    container_name: ethnomath_pgadmin
    environment:
      PGADMIN_DEFAULT_EMAIL: admin@example.com
      PGADMIN_DEFAULT_PASSWORD: adminpass
    depends_on:
      - postgres
    ports:
      - "5050:80"

volumes:
  postgres_data:
  minio_data:

.env näidis

DATABASE_URL=postgresql+psycopg://ethnomath:ethnomath_pass@postgres:5432/ethnomath
REDIS_URL=redis://redis:6379/0

MINIO_ENDPOINT=minio:9000
MINIO_ACCESS_KEY=minio
MINIO_SECRET_KEY=minio_secret
MINIO_BUCKET=ethnomath-docs
MINIO_SECURE=false

OPENAI_API_KEY=your_openai_key
OPENAI_CHAT_MODEL=gpt-4.1-mini
OPENAI_EMBED_MODEL=text-embedding-3-large

requirements.txt algversioon

fastapi
uvicorn[standard]
sqlalchemy
psycopg[binary]
alembic
pydantic
pydantic-settings
python-multipart
boto3
redis
rq
langchain
langgraph
langchain-openai
pgvector
pymupdf
unstructured
tiktoken

4. LangGraphi minimaalne integreerimine

Näidisstate

from typing import TypedDict, List, Optional

class ArticleState(TypedDict):
    research_question_id: int
    source_ids: List[int]
    retrieved_evidence: List[str]
    outline: List[str]
    draft_sections: List[str]
    citations: List[str]
    quality_ok: bool
    final_draft: Optional[str]

Näidissõlmed

def gather_sources(state):
    # päring PostgreSQL-ist
    return {"source_ids": [1, 2, 3]}

def retrieve_evidence(state):
    # retriever pgvector + filters
    return {"retrieved_evidence": ["evidence A", "evidence B"]}

def build_outline(state):
    return {"outline": ["Sissejuhatus", "Teoreetiline raamistik", "Analüüs", "Järeldused"]}

def write_sections(state):
    return {"draft_sections": ["...", "...", "..."]}

def check_quality(state):
    ok = len(state["retrieved_evidence"]) > 1
    return {"quality_ok": ok}

def finalize(state):
    return {"final_draft": "\n\n".join(state["draft_sections"])}

Graaf

from langgraph.graph import StateGraph, END

graph = StateGraph(ArticleState)

graph.add_node("gather_sources", gather_sources)
graph.add_node("retrieve_evidence", retrieve_evidence)
graph.add_node("build_outline", build_outline)
graph.add_node("write_sections", write_sections)
graph.add_node("check_quality", check_quality)
graph.add_node("finalize", finalize)

graph.set_entry_point("gather_sources")
graph.add_edge("gather_sources", "retrieve_evidence")
graph.add_edge("retrieve_evidence", "build_outline")
graph.add_edge("build_outline", "write_sections")
graph.add_edge("write_sections", "check_quality")

def route_quality(state):
    return "finalize" if state["quality_ok"] else "retrieve_evidence"

graph.add_conditional_edges("check_quality", route_quality, {
    "finalize": "finalize",
    "retrieve_evidence": "retrieve_evidence",
})

graph.add_edge("finalize", END)

article_app = graph.compile()

See on hea näide, kus LangGraph lisab retry-loogika:

  • kui tõendusmaterjal on nõrk, minnakse uuesti retrievali.

5. Kuidas worker ja LangGraph koos töötavad

Soovitus:

  • API saab käsu: “loo artikli mustand”
  • API paneb töö järjekorda
  • worker käivitab LangGraph workflow

  • tulemused salvestatakse ai_run + manuscript tabelitesse

    POST /ai/article-draft
→ create job
→ worker starts graph
→ graph queries DB + retrieval
→ graph writes draft
→ saves outputs
→ API tagastab staatuse

6. Soovitatud MVP teenused kohe

Kohustuslikud

  • PostgreSQL + pgvector
  • FastAPI
  • MinIO
  • LangChain
  • LangGraph
  • OpenAI
  • üks worker

Mitte kohe vajalik

  • eraldi frontend
  • Neo4j
  • Kubernetes
  • mitu mikroteenust
  • eraldi vektor-DB

7. Minu praktiline soovitus arenduse järjekorraks

Nädalad 1–2

  • docker-compose tööle
  • PostgreSQL
  • MinIO
  • FastAPI skeleton
  • Alembic
  • põhiskeem

Nädalad 3–4

  • source upload
  • PDF parse
  • chunking
  • embeddings
  • pgvector search

Nädalad 5–6

  • entity CRUD
  • research_question CRUD
  • manuscript CRUD
  • citation/provenance logimine

Nädalad 7–8

  • esimene LangGraph:
    • research question graph
  • teine LangGraph:
    • article draft graph

Kui tahad, järgmine loogiline samm on üks neist:

  1. kirjutan sulle nüüd PostgreSQL tabeliskeemi SQL-na
  2. teen FastAPI endpointide loendi
  3. teen sulle LangGraph workflowd kolmele põhifunktsioonile
  4. annan kohe käivitatava starter-koodi struktuuri

Minu soovitus: 1 + 3.