Solusi Autonomous AI Berbasis Model Kecil : Integrasi LLM, Memory, Tools, Rules, Controller, dan Mathematical Verifier

oleh : Arlan Wijaya

I. Pendahuluan

Saat ini, perkembangan Artificial Intelligence (AI) pada umumnya diarahkan pada penggunaan Large Language Model (LLM) dengan jumlah parameter yang semakin besar. Model dengan puluhan hingga ratusan miliar parameter memang memiliki kemampuan reasoning dan pemahaman bahasa yang sangat tinggi, tetapi yang menjadi kendala adalah kebutuhan hardware juga semakin besar. Keadaan tersebut menjadi masalah ketika AI ingin dijalankan secara lokal pada komputer kantor biasa, terutama komputer kantor yang hanya menggunakan CPU dan tidak memiliki GPU.

Dari keadaan tersebut, muncul pendekatan lain yang dapat menjadi solusi hal tersebut yaitu : tidak semua kemampuan AI harus berada di dalam parameter model. Sebagian kemampuan dapat dipindahkan ke perangkat lunak di sekitar LLM, seperti database sebagai memory, Python sebagai calculator dan verifier, database sebagai sumber data, serta controller sebagai pengatur proses. Dengan pendekatan ini, model kecil seperti 3B parameter ((3 billion parameters = 3 milyar) atau 7B parameter dapat digunakan sebagai "otak" reasoning, sementara pekerjaan deterministik diberikan kepada program yang lebih ringan dan lebih dapat dipercaya.

Dari pembahasan tersebut muncul konsep :

​ ​ AI Agent = LLM + Controller + Memory + Tools + Rules + Verifier

Persamaan tersebut diatas bukan penjumlahan matematis literal, tetapi digunakan untuk menggambarkan bahwa autonomous AI merupakan sebuah sistem yang terdiri dari beberapa komponen yang saling bekerja sama. Tulisan ini membahas bagaimana konsep tersebut dapat diwujudkan, termasuk penggunaan database sebagai memory, script Python sebagai mathematical verifier, dan penerapannya pada pengembangan Odoo. Lebih tepatnya untuk mengambarkan konsep tersebut adalah persamaan fungsi AI Agent matematis berikut yang dituliskan secara lengkap sebagai berikut :

​ ​ A = V(R(T(C(L, Database, VectorDB)))) 

Keterangan :

dengan:

• L = LLM
• M = Memory
• C = Controller
• T = Tools
• R = Rules
• V = Verifier
• A = tindakan/hasil akhir AI Agent

II. Pembahasan

1. LLM Bukan Keseluruhan AI Agent

LLM pada dasarnya merupakan fungsi probabilistik yang menghasilkan output berdasarkan input dan parameter yang telah dipelajari saat training model.

Secara sederhana dapat ditulis:

​ ​y = LLM(x;θ)

di mana x adalah input, y adalah output, dan θ adalah parameter model.  Dimana 

​ ​LLM(x;θ)=fn​(fn−1​(…f2​(f1​(x;θ))))

Jadi LLM adalah singkatan dari Large Language Model, tetapi dalam notasi tersebut ia diperlakukan sebagai fungsi/model yang menerima x dan parameter θ, lalu menghasilkan y.  Contoh:

​ ​y = LLM("Apa ibu kota Indonesia?";θ)​

menghasilkan:

​ ​y="Jakarta"​

Parameter bukan sekadar "data biasa". Parameter merupakan nilai numerik yang diperoleh melalui proses training dan digunakan model untuk menentukan pola hubungan antara input dan output.

Sebagai contoh sebuah Model 3B mempunyai sekitar tiga miliar parameter, sedangkan model 70B mempunyai sekitar tujuh puluh miliar parameter. Secara umum, semakin besar jumlah parameter, semakin besar pula kebutuhan komputasi dan memory.

Berdasarkan hal tersebut di atas tidak selalu model kecil berarti sistem AI menjadi lemah (kurang baik). Perbedaannya terletak pada bagaimana sistem tersebut dirancang. Sebuah Model 3B yang hanya digunakan sebagai chatbot mungkin memiliki keterbatasan. Tetapi model 3B yang dilengkapi database, tools, controller, rules, dan verifier dapat menjadi sebuah agent yang jauh lebih berguna.

Dengan demikian, kita dapat membedakan:

​ ​LLM ≠ AI Agent

LLM merupakan salah satu komponen dari AI Agent.

2. Model Kecil dengan Pembagian Pekerjaan

Model besar melakukan banyak pekerjaan secara internal. Misalnya ketika diminta menghitung pajak, mencari data pelanggan, membaca dokumen, atau membuat file, model mencoba menggunakan kemampuan internalnya untuk melakukan pekerjaan tersebut. Pendekatan autonomous agent memisahkan pekerjaan tersebut.

LLM diberikan tugas:

Think

sedangkan tools diberikan tugas:

Do

Sebagai contoh, pengguna mengatakan:

"Hitung PPN invoice PT ABC dan buat jurnalnya."

LLM tidak perlu menghitung semuanya sendiri.

LLM dapat menentukan:

1. Ambil invoice.
2. Ambil nilai dasar transaksi.
3. Hitung pajak.
4. Buat jurnal.
5. Periksa apakah jurnal balance.

Kemudian pekerjaan aktual diberikan kepada tools.

Python dapat menghitung:

​ ​Tax = Base×Rate

Database dapat mengambil informasi vendor.

Odoo tool dapat membuat journal entry.

Verifier memeriksa:

​ ​∑Debit = ∑Credit

Dengan demikian, pekerjaan LLM menjadi lebih kecil dan lebih terstruktur.

3. Controller sebagai Pengatur Agent

Jika LLM hanya diberikan tools tanpa pengatur, sistem dapat melakukan tindakan yang tidak efisien. LLM mungkin memanggil tool terlalu banyak, mengulangi pencarian, atau melakukan tindakan yang tidak diperlukan.

Karena itu dibutuhkan Controller.

Controller menentukan:

​ ​at​ = C(pt​,st​) ....(dibaca fungsi controller)

di mana pt​ adalah plan dan st​ adalah kondisi sistem saat itu.

Contohnya:

User
 ↓
LLM
 ↓
Plan
 ↓
Controller
 ├── read invoice
 ├── query vendor
 ├── calculate tax
 └── create journal

Controller juga dapat menentukan kapan proses harus dihentikan dan kapan harus kembali ke LLM untuk melakukan perencanaan ulang.

Dengan demikian autonomous agent bukan hanya:

Input\rightarrowOutput

tetapi:

State0 → State1 → State2 →⋯→ State n

hingga tujuan tercapai.

4. Database sebagai Memory AI

Salah satu konsep penting dari pembahasan adalah bahwa memory AI tidak harus berada di dalam parameter LLM.

Kita dapat mempunyai:

​ ​Mt​=Databaset​

Parameter model tetap:

​ ​θt+1​=θt​

sementara memory dapat berubah:

​ ​Mt+1​=Mt​+ΔM

Sebagai contoh, database dapat menyimpan:

PT ABC → Account 510100
PT XYZ → Account 520100
PT Maju → Account 530200

Ketika pengguna meminta:

"Buat jurnal invoice PT ABC."

Agent tidak perlu meminta LLM mengingat informasi tersebut dari training. Agent cukup melakukan query:

SELECT account
FROM vendors
WHERE name = 'PT ABC';

Database memberikan:

	​	​510100

Informasi tersebut kemudian diberikan kepada LLM sebagai context.

Secara sederhana:

​ ​M(query)=Database(query)

kemudian:

​ ​y=LLM(x,M(query))

Pendekatan ini sangat penting untuk komputer dengan hardware terbatas karena tidak perlu melakukan retraining model hanya untuk menambahkan pengetahuan perusahaan.

5. Memory Tidak Harus Membuat AI Lambat

Database memang menambahkan proses retrieval, tetapi tidak berarti AI menjadi lebih lambat secara keseluruhan.  Misalnya tanpa memory, LLM harus membaca 50.000 token context:

TLLM​=8s

Dengan memory eksternal, database hanya mengambil informasi yang relevan:

Tquery​=0.05s

dan context yang diberikan kepada LLM hanya 1.000 token:

TLLM​=1.5s

Maka:

Ttotal​=0.05+1.5=1.55s

dibandingkan:

8s

Memory eksternal justru dapat mempercepat agent.

Karena itu strategi yang baik adalah:

Retrieve\rightarrowFilter\rightarrowCompress\rightarrowReason​

bukan memasukkan seluruh database ke dalam prompt.

Untuk memory terstruktur seperti vendor, customer, invoice, rules, dan history, SQLite sangat menarik karena ringan dan dapat berjalan pada komputer kantor biasa. Untuk dokumen dan pencarian berdasarkan makna, vector database dapat digunakan.

6. Tools sebagai Perpanjangan Kemampuan LLM

Tools adalah program yang melakukan pekerjaan tertentu.

Contohnya:

Calculator
Filesystem
Python
Shell
Browser
Database
Odoo

Secara matematis, sebuah tool dapat dipandang sebagai fungsi:

st+1= T(at, st)

Tool menerima action dan state, kemudian menghasilkan state baru.

Misalnya:

Tcalculator​(12M×0.11)=1.32M

LLM tidak perlu melakukan kalkulasi tersebut sendiri.

Demikian juga:

Tdatabase​(query)→data

atau:

Todoo​(create_invoice)→invoice

Dengan pembagian tersebut, LLM menjadi pengambil keputusan sedangkan tools menjadi pelaksana.

7. Rules sebagai Pembatas AI

Autonomous AI tidak boleh mempunyai kebebasan tanpa batas. Karena itu diperlukan rules.

Rules dapat ditulis sebagai fungsi:

R(a,s)∈{0,1}

Jika:

R(a,s)=1

maka tindakan diperbolehkan.

Jika:

R(a,s)=0

maka tindakan ditolak.

Contohnya dalam accounting:

Amount > 50M ⇒ Approval Required

Jika agent mencoba melakukan posting transaksi Rp100 juta tanpa approval:

R(action)=0

Controller harus menolak tindakan tersebut.

Rules dengan demikian menjadi lapisan pembatas antara reasoning LLM dan tindakan nyata.

8. Mathematical Verifier

Salah satu bagian yang terpenting dari arsitektur solusi system ini adalah Verifier. LLM bersifat probabilistik. Artinya, LLM dapat menghasilkan jawaban yang terlihat benar tetapi sebenarnya salah. sebaliknya dapat dibuat deterministik.

Secara sederhana:

​ ​V(y)∈{0,1}​

dengan:

​ ​V(y)=1

jika hasil valid, dan:

​ ​V(y)=0

jika hasil tidak valid.

Misalnya LLM membuat jurnal:

Debit=12.100.000 Credit=11.100.000

Verifier menghitung:

E=Debit−Credit E=1.000.000

Karena:

E=0

maka:

V=0

Jurnal ditolak.

9. Verifier AI bisa Dibuat sebagai Script Python

Verifier tidak harus menggunakan AI. Bahkan lebih baik jika bagian yang dapat dihitung secara deterministik menggunakan script Python.

Contoh sederhana:

def verify_balance(debit, credit):
    difference = debit - credit

    return {
        "valid": difference == 0,
        "debit": debit,
        "credit": credit,
        "difference": difference,
    }

Jika:

debit  = 12.100.000
credit = 12.100.000

hasilnya:

valid = True

Jika berbeda:

valid = False
difference = 1.000.000

Verifier bahkan dapat mengembalikan feedback kepada LLM:

Debit: 12.100.000
Credit: 11.100.000
Difference: 1.000.000
Status: INVALID

Kemudian agent melakukan replan.

10. Verifier sebagai Constraint Engine

Verifier dapat memiliki banyak constraint:

​ ​C1, C2,…,Cn

dan:

​ ​V(x)=i=1⋀n​Ci​(x)​

Untuk accounting misalnya:

C1​:∑Debit=∑Credit C2​:Tax=Base×Rate C3​:Account∈ValidAccounts C4​:Vendor∈Vendors

Maka:

V=C1​∧C2​∧C3​∧C4​

Jika semua benar:

1∧1∧1∧1=1

maka transaksi valid.

Jika salah satu constraint gagal:

1∧1∧0∧1=0

maka transaksi ditolak.

11. Odoo Verifier, sebagai contoh kasus

Konsep yang sama dapat diterapkan untuk pengembangan Odoo. LLM dapat menghasilkan Python, XML, manifest, security rule, dan JavaScript. Namun kode tersebut tidak langsung dianggap benar.

Kita dapat membuat:

VOdoo​=VPython​∧VManifest​∧VModel​∧VView​∧VXPath​∧VSecurity​∧VDependency​∧VRuntime​​

Contohnya, Python verifier dapat menggunakan ast.parse() untuk memeriksa syntax.

XML verifier dapat memeriksa apakah XML valid.

Odoo verifier dapat memastikan model yang digunakan memang tersedia.

Dependency verifier memeriksa apakah module yang dibutuhkan terdapat di environment.

XPath verifier dapat memeriksa apakah elemen target benar-benar ditemukan pada view yang diwarisi.

Security verifier dapat memastikan model mempunyai access rule.

Kemudian runtime verifier dapat menginstall module pada database testing dan menjalankan test.

Dengan demikian:

LLM
 ↓
Generate Odoo Code
 ↓
Static Verification
 ↓
Install Test Module
 ↓
Run Tests
 ↓
Verifier
 ↓
PASS / FAIL

Jika gagal, error diberikan kembali kepada LLM untuk diperbaiki.

12. Autonomous Loop

Semua komponen tersebut kemudian membentuk autonomous loop:

​ ​pt​=LLM(x,mt​,st​)​ at​=C(pt​,st​)​ st+1​=T(at​,st​)​ vt​=V(st+1​)​

Jika:

vt​=1

maka:

DONE

Jika:

vt​=0

maka:

REPLAN

dan LLM menerima feedback dari verifier.

Dengan demikian sistem bukan lagi sekadar chatbot.

User
 ↓
LLM
 ↓
Plan
 ↓
Controller
 ↓
Rules
 ↓
Tools
 ↓
Result
 ↓
Verifier
 ├── PASS → DONE
 └── FAIL → REPLAN → LLM

13. Agent Efisien vs Agent Tidak Efisien

Dua agent dapat menggunakan LLM yang sama tetapi mempunyai performa berbeda. Sebagai contoh misal Agent 1 mempunyai memory yang baik dan hanya membutuhkan tiga tool calls.

Cost(A1)=2.85s

Agent 2 tidak mempunyai memory yang baik, melakukan terlalu banyak pencarian dan mengalami kesalahan sehingga harus retry.

Cost(A2)=25.5s

Maka:

2.8525.5 ≈ 8.95

Agent 1 hampir sembilan kali lebih efisien.

Hal tersebut menunjukkan bahwa efisiensi autonomous AI tidak hanya ditentukan oleh ukuran LLM.

Efficiency=f(LLM,Memory,Controller,Tools,Rules,Verifier)​

Karena itu model 3B yang dikelilingi sistem yang baik dapat lebih praktis daripada model 7B atau 14B yang tidak mempunyai arsitektur agent yang baik.

14. Implementasi pada Komputer Kantor Biasa

Arsitektur pada pembahasan ini sangat sesuai untuk menjalankan AI secara lokal di komputer kantor biasa.

Contoh:

Local Autonomous AI
│
├── Ollama
│   └── LLM 3B / 7B
│
├── Controller
│
├── Memory
│   ├── SQLite
│   └── Vector Store
│
├── Tools
│   ├── Python
│   ├── Filesystem
│   ├── Database
│   └── Odoo
│
├── Rules
│
├── Verifier
│   ├── Mathematical
│   ├── Odoo
│   ├── Database
│   └── Security
│
├── Scheduler
│
└── Audit Log

LLM menggunakan CPU untuk reasoning, sementara SQLite, Python, SQL, dan verifier melakukan pekerjaan deterministik dengan kebutuhan resource yang relatif kecil. Untuk sistem seperti ini, framework open-source agent dapat digunakan sebagai dasar controller/orchestration, sedangkan komponen khusus seperti Odoo tools dan verifier dapat dikembangkan sendiri.

III. Kesimpulan

Konsep utama yang muncul dari pembahasan essay ini yaitu membangun autonomous AI tidak harus berarti membuat LLM yang sangat besar. Kemampuan AI dapat dibagi ke dalam beberapa komponen yang memiliki fungsi berbeda.

​ ​AI Agent = LLM + Controller + Memory + Tools + Rules + Verifier

LLM bertugas melakukan reasoning dan menghasilkan rencana. Controller mengatur proses. Memory menyimpan informasi yang dapat digunakan kembali. Tools melakukan pekerjaan nyata. Rules membatasi tindakan. Verifier memeriksa hasil secara deterministik.

Pendekatan ini menghasilkan prinsip:

LLM → Think

Memory → Remember

Controller → Coordinate

Tools → Do

Rules → Limit

Verifier → Check

Dengan demikian, sistem tidak mengharuskan LLM selalu benar. LLM bisa saja menghasilkan kesalahan, tetapi kesalahan tersebut dapat dideteksi oleh verifier dan dikembalikan sebagai feedback kepada agent.

​ ​LLM → Action → Verifier → Feedback → Replan

Inilah yang membuat pendekatan tersebut menjadi solusi untuk membangun Local Autonomous AI pada hardware terbatas misalnya komputer kantor. Model kecil dapat digunakan sebagai mesin reasoning, sementara database, Python, SQL, Odoo, dan mathematical verifier menangani pekerjaan yang lebih deterministik. Untuk pengembangan Odoo, pendekatan tersebut bahkan dapat berkembang menjadi autonomous coding agent:

​ ​Requirement → Plan → Code → Verify → Test → Fix → Verify → Deploy

Dengan demikian, tujuan akhirnya bukan membuat "LLM yang lebih besar", tetapi membuat sistem AI yang lebih terstruktur, efisien, dapat diverifikasi, dan mampu bekerja secara autonomous.