ਹਰ ਕੁਝ ਮਹੀਨਿਆਂ ਬਾਅਦ, ਓਪਨ-ਸੋਰਸ ਕਮਿਊਨਿਟੀ ਇੱਕ ਹੋਰ AI ਫਰੇਮਵਰਕ ਤਿਆਰ ਕਰਦੀ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਭਾਰੀ C++ kernels ਦੇ ਆਲੇ-ਦੁਆਲੇ Python bindings ਲਗਾਉਂਦੇ ਹਨ, ਜਾਂ ਉਹ ਅਬਸਟਰੈਕਸ਼ਨ ਲੇਅਰਾਂ (abstraction layers) ਨੂੰ ਇੰਨਾ ਉੱਚਾ ਰੱਖਦੇ ਹਨ ਕਿ ਸਿਰਫ਼ runtime ਹੀ ਉਨ੍ਹਾਂ ਮਾਡਲਾਂ ਨਾਲੋਂ ਭਾਰੀ ਹੋ ਜਾਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਉਹ ਸੇਵਾ ਕਰਦੇ ਹਨ। CatAI ਇਸ ਦੇ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ C++ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਇੱਕ native AI engine ਹੈ, ਜੋ tensor math ਤੋਂ ਉੱਪਰ ਵੱਲ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਮਕਸਦ PyTorch ਦੇ ਉੱਪਰ ਇੱਕ ਹੋਰ ਦੋਸਤਾਨਾ ਸਤਹ (skin) ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਹਾਰਡਵੇਅਰ ਦੀ ਸੀਮਾ ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ, ਮੈਮੋਰੀ ਦੇ ਹਰ ਬਾਈਟ ਅਤੇ ਕੰਪਿਊਟ ਦੇ ਹਰ ਸਾਈਕਲ 'ਤੇ ਕਬਜ਼ਾ ਕਰਨਾ ਹੈ।

ਇੱਕ ਹੋਰ Engine ਦੀ ਲੋੜ ਕਿਉਂ?

ਜੇਕਰ ਤੁਸੀਂ ਕੁਝ ਵੀ production ਵਿੱਚ ਭੇਜਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਦਰਦ ਨੂੰ ਜਾਣਦੇ ਹੋ। ਇੱਕ standard deep-learning stack ਨੂੰ container ਵਿੱਚ ਲਿਆਓ ਅਤੇ ਦੇਖੋ ਕਿ ਕਿਵੇਂ image ਕਈ gigabytes ਤੱਕ ਫੁੱਲ ਜਾਂਦੀ ਹੈ। Dependencies ਇੱਕ ਦੂਜੇ ਨਾਲ ਲੜਦੀਆਂ ਹਨ। Python interpreter latency ਵਧਾ ਦਿੰਦਾ ਹੈ। ਉਹ dispatcher ਜੋ ops ਨੂੰ CUDA ਜਾਂ CPU ਵੱਲ ਭੇਜਦਾ ਹੈ, ਉਹ ਇੱਕ ਅਜਿਹਾ ਸੂਖਮ overhead ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਿਸਦਾ profile ਬਣਾਉਣਾ ਅਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਇਹ ਦਰਜਨਾਂ nested frameworks ਵਿੱਚ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ। Edge devices, embedded robotics, ਜਾਂ latency-sensitive backends ਲਈ, ਇਹ ਨੁਕਸਾਨ ਅਸਲੀ ਹੈ। ਇੱਕ ਸ਼ੁੱਧ C++ engine ਵਿਚੋਲੇ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਬਿਨਾਂ ਕਿਸੇ garbage collection, global interpreter lock, ਅਤੇ ਭਾਸ਼ਾਵਾਂ ਵਿਚਕਾਰ serialization ਦੇ, ਸਿੱਧਾ operating system ਅਤੇ silicon ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ।

CatAI ਇਸ ਨੂੰ ਇੱਕ ਫੀਚਰ ਵਜੋਂ ਲੈਂਦਾ ਹੈ, ਸਮਝੌਤੇ ਵਜੋਂ ਨਹੀਂ। ਇਹ ਪ੍ਰੋਜੈਕਟ C++ ਵਿੱਚ ਬਿਲਕੁਲ ਸ਼ੁਰੂ ਤੋਂ (from scratch) ਲਿਖਿਆ ਜਾ ਰਿਹਾ ਹੈ ਕਿਉਂਕਿ ਲੇਖਕ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ ਕਿ tensors RAM ਵਿੱਚ ਕਿਵੇਂ ਰਹਿੰਦੇ ਹਨ, ਉਹ cache hierarchies ਵਿੱਚ ਕਿਵੇਂ ਹੁੰਦੇ ਹਨ, ਅਤੇ threads ਵਿੱਚ across kernels ਨੂੰ ਕਿਵੇਂ schedule ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਮੈਸੋਕਿਜ਼ਮ (masochism) ਨਹੀਂ ਹੈ। ਇਹ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਸੀਮਤ ਹਾਰਡਵੇਅਰ ਤੋਂ ਪ੍ਰਦਰਸ਼ਨ (performance) ਕੱਢ ਰਹੇ ਹੋ, ਤਾਂ ਵਿਵਹਾਰ ਅਨੁਮਾਨਯੋਗ (predictable) ਹੋਵੇ।

"From Scratch" ਦਾ ਅਸਲ ਮਤਲਬ ਕੀ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ ਫਰੇਮਵਰਕਾਂ ਵਿੱਚ, tensor math ਨੂੰ cuDNN, oneMKL, ਜਾਂ MPS ਵਰਗੀਆਂ vendor libraries ਵਿੱਚ ਅਪਾਰਦਰਸ਼ੀ (opaque) calls ਰਾਹੀਂ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ। ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਲਈ ਇਹ ਬਿਲਕੁਲ ਸਹੀ ਹੈ, ਪਰ ਇਹ ਕਾਰਜ ਦੀ ਮਕੈਨਿਕਸ ਨੂੰ ਛੁਪਾ ਦਿੰਦਾ ਹੈ। CatAI ਆਪਣਾ ਖੁਦ ਦਾ core tensor math ਅਤੇ memory layouts ਲਿਖ ਰਿਹਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਉਹ ਮੁੱਢਲੇ data structures ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਜੋ multi-dimensional arrays ਨੂੰ ਰੱਖਦੇ ਹਨ, ਇਹ ਚੁਣਨਾ ਕਿ strides ਅਤੇ offsets ਦੀ ਗਣਨਾ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ access pattern ਦੇ ਆਧਾਰ 'ਤੇ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਕਿ ਡੇਟਾ ਨੂੰ row-major, column-major, ਜਾਂ custom tiled formats ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਹੈ।

ਇਹ ਡੂੰਘਾ systems work ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਹੱਥ ਨਾਲ ਇੱਕ matrix-multiply kernel ਲਿਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ torch.matmul ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਸੋਚਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ L1 cache lines, register pressure, ਅਤੇ loop tiling ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ। ਤੁਸੀਂ target CPU ਦੀ SIMD width ਦੇ ਅਧਾਰ 'ਤੇ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ 32x32 tiles ਲਈ block ਕਰਨਾ ਹੈ ਜਾਂ 64x64 ਲਈ। ਤੁਸੀਂ allocations ਨੂੰ 64-byte boundaries ਨਾਲ align ਕਰਦੇ ਹੋ ਤਾਂ ਜੋ AVX-512 loads cache lines ਨੂੰ cross ਨਾ ਕਰਨ। ਤੁਸੀਂ ਸਵਾਲ ਕਰਦੇ ਹੋ ਕਿ ਕੀ std::vector tensor storage ਲਈ ਸਹੀ container ਹੈ, ਜਾਂ ਕੀ ਇੱਕ custom arena allocator ਤੁਹਾਨੂੰ ਪੂਰੇ inference graph ਵਿੱਚ ਬਿਹਤਰ locality ਅਤੇ zero fragmentation ਦਿੰਦਾ ਹੈ।

Memory layout ਵੀ ਉਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਸਾਧਾਰਨ (naive) n-dimensional array ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ channels-last image data ਨੂੰ channels-first pattern ਵਿੱਚ access ਕੀਤਾ ਜਾਂਦਾ ਹੈ। CatAI ਵਿੱਚ, ਇਹ layouts first-class citizens ਹਨ, ਨਾ ਕਿ export time 'ਤੇ ਚੱਲਣ ਵਾਲੇ graph optimizer ਦੁਆਰਾ ਸੰਭਾਲੇ ਜਾਣ ਵਾਲੇ afterthought।

Optimization ਦੀ ਮਾਨਸਿਕਤਾ

Bare-metal optimization ਇੱਕ buzzword ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ nanoseconds ਗਿਣਨਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦੇ। ਇਸਦਾ ਮਤਲਬ ਹੈ operations ਨੂੰ fuse ਕਰਨਾ ਤਾਂ ਜੋ intermediate results ਕਦੇ ਵੀ CPU registers ਜਾਂ L1 cache ਨੂੰ ਨਾ ਛੱਡਣ। ਇਸਦਾ ਮਤਲਬ ਹੈ layer-norm ਦੇ ਅਗਲੇ ਇੱਕ GELU ਨੂੰ ਇੱਕ ਸਿੰਗਲ kernel ਵਜੋਂ ਲਾਗੂ ਕਰਨਾ, ਜਿਸ ਨਾਲ DRAM ਤੱਕ ਦਾ ਪੂਰਾ round-trip ਬਚ ਜਾਂਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ OpenMP defaults 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ ਆਪਣਾ ਖੁਦ ਦਾ thread pool ਲਿਖਣਾ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਤੁਹਾਡਾ workload bursty ਹੈ ਅਤੇ ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ runtime ਹਰ forward pass ਵਿੱਚ threads ਨੂੰ spawn ਅਤੇ join ਕਰੇ।

ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਇਹ ਸਮਝਣਾ ਕਿ assembly ਕਦੋਂ ਨਹੀਂ ਲਿਖਣੀ ਹੈ। ਕਈ ਵਾਰ compiler, hand-written intrinsics ਨਾਲੋਂ ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ loop ਨੂੰ vectorize ਕਰਦਾ ਹੈ। ਅਨੁਸ਼ਾਸਨ ਮਾਪ (measurement) ਹੈ: profile ਕਰੋ, hypothesis ਬਣਾਓ, ਇੱਕ variable ਬਦਲੋ, ਅਤੇ ਫਿਰ ਤੋਂ profile ਕਰੋ। ਇਹ engine ਉਹਨਾਂ ਲੋਕਾਂ ਦੁਆਰਾ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੈ ਜੋ ਇਸ ਮਿਹਨਤ ਦਾ ਅਨੰਦ ਲੈਂਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਕਦੇ ਵੀ ਇੱਕ batch ਤੋਂ ਦੋ ਮਿਲੀਸੈਕਿੰਡ ਘਟਾਉਣ ਲਈ convolution loop ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਵਿੱਚ ਇੱਕ ਦੁਪਹਿਰ ਬਿਤਾਈ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਸੱਭਿਆਚਾਰ ਨੂੰ ਸਮਝਦੇ ਹੋ।

ਸਾਨੂੰ ਕਿਸਦੀ ਲੋੜ ਹੈ

ਇਹ ਕੋਈ ਇੱਕ-ਬੰਦੇ ਦਾ ਸ਼ੋਅ ਨਹੀਂ ਹੈ। ਜ਼ੀਰੋ ਤੋਂ backend ਬਣਾਉਣ ਲਈ ਅਜਿਹੀਆਂ ਵੱਖਰੀਆਂ ਹੁਨਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਸ਼ਾਇਦ ਹੀ ਕਿਸੇ ਇੱਕ ਦਿਮਾਗ ਵਿੱਚ ਇਕੱਠੀਆਂ ਹੋਣ। ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਪੜ੍ਹ ਰਹੇ ਹੋ ਅਤੇ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਬਾਰੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਥੇ ਦੇਖੋ ਕਿ ਤੁਸੀਂ ਕਿੱਥੇ ਫਿੱਟ ਹੋ ਸਕਦੇ ਹੋ:

  • C++ developers ਜੋ ਆਧੁਨਿਕ ਸਟੈਂਡਰਡ ਜਾਣਦੇ ਹਨ ਪਰ ਇਹ ਵੀ ਜਾਣਦੇ ਹਨ ਕਿ ਕਦੋਂ templates ਕਾਰਨ compilation bloat ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਲੋੜ ਪੈਣ 'ਤੇ raw pointers ਅਤੇ ਉਚਿਤ ਹੋਣ 'ਤੇ smart pointers ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਸੌਖਾ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ syntax sugar ਦੇ ਨਾਲ-ਨਾਲ binary size ਦੀ ਵੀ ਉਨੀ ਹੀ ਚਿੰਤਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

  • Math experts ਜੋ non-standard activations ਲਈ backward-pass gradients ਕੱਢ ਸਕਦੇ ਹਨ, mixed-precision training ਵਿੱਚ numerical stability ਬਾਰੇ ਵਿਚਾਰ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੋਡ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ algorithms ਨੂੰ optimize ਕਰ ਸਕਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਸਮਝਾ ਸਕਦੇ ਹੋ ਕਿ log-sum-exp trick ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਹੀ ਮਾਨਸਿਕ ਸਥਿਤੀ ਵਿੱਚ ਹੋ।

  • Low-level memory specialists ਜੋ allocators, page faults, ਅਤੇ NUMA topology ਬਾਰੇ ਸੋਚਦੇ ਹਨ। ਇੰਜਣ ਨੂੰ graph execution ਲਈ memory pools, kernels ਲਈ scratch buffers, ਅਤੇ training steps ਦੌਰਾਨ tensor storage ਨੂੰ leak ਜਾਂ fragment ਕੀਤੇ ਬਿਨਾਂ ਦੁਬਾਰਾ ਵਰਤਣ ਲਈ ਰਣਨੀਤੀਆਂ ਦੀ ਲੋੜ ਹੈ।

  • Systems engineers ਜੋ ਸਮਝਦੇ ਹਨ ਕਿ ਕਿਵੇਂ ਇੱਕ ਗਲਤ syscall ਪੂਰੇ training loop ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ। Scheduling, I/O, ਅਤੇ synchronization primitives ਉਹ ਗੂੰਦ ਹਨ ਜੋ ਗਣਿਤ (math) ਨੂੰ ਇਕੱਠਾ ਰੱਖਦੇ ਹਨ।

ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਚਾਰਾਂ ਖੇਤਰਾਂ ਵਿੱਚ ਵਿਸ਼ਵ ਪੱਧਰੀ ਮਾਹਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲੇ ਇੱਕ kernel ਜਾਂ ਇੱਕ allocator ਤੋਂ ਸ਼ੁਰੂਆਤ ਕਰਨਗੇ ਅਤੇ ਜਿਵੇਂ-ਜਿਵੇਂ architecture ਮਜ਼ਬੂਤ ਹੋਵੇਗਾ, ਬਾਕੀ ਚੀਜ਼ਾਂ ਸਿੱਖਣਗੇ।

Architecture ਅਤੇ Custom Math

Backend logic ਸਾਂਝੇ ਤੌਰ 'ਤੇ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਸ਼ੁਰੂਆਤ architecture ਬਾਰੇ ਬਹਿਸਾਂ ਤੋਂ ਹੁੰਦੀ ਹੈ। ਕੀ ਇੰਜਣ ਇੱਕ static computation graph ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ, ਜਿੱਥੇ runtime ਤੋਂ ਪਹਿਲਾਂ ਪੂਰੇ ਮਾਡਲ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ optimize ਕੀਤਾ ਜਾਂਦਾ ਹੈ? ਜਾਂ ਕੀ ਇਹ automatic differentiation ਲਈ ਇੱਕ tape ਦੇ ਨਾਲ eager execution ਦਾ ਸਮਰਥਨ ਕਰੇਗਾ? autodiff ਨੂੰ ਕਿਵੇਂ ਦਰਸਾਇਆ ਜਾਵੇਗਾ—operator overloading, source transformation, ਜਾਂ ਇੱਕ graph IR? ਇਹ ਫੈਸਲੇ ਬਾਕੀ ਸਭ ਕੁਝ ਤੈਅ ਕਰਦੇ ਹਨ।

Custom neural net math ਦਾ ਮਤਲਬ ਸਿਰਫ਼ standard layers ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਨਵੇਂ ਲੇਅਰਾਂ ਦੀ ਕਾਢ ਕੱਢਣ ਦੀ ਆਜ਼ਾਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ non-standard sparse kernel ਵਾਲਾ convolution variant ਜਾਂ ਅਜਿਹਾ activation function ਚਾਹੁੰਦੇ ਹੋ ਜਿਸਦਾ ਸਾਹਿਤ (literature) ਵਿੱਚ ਕੋਈ ਨਾਮ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ C++ forward ਅਤੇ backward passes ਲਿਖਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਿੱਧਾ ਇੰਜਣ ਵਿੱਚ ਜੋੜ ਦਿੰਦੇ ਹੋ। ਉੱਥੇ ਲੜਨ ਲਈ ਕੋਈ Python API ਨਹੀਂ ਹੈ, ਅਤੇ ਕੋਈ monkey-patching ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਗਣਿਤ ਹੀ ਕੋਡ ਹੈ, ਅਤੇ ਕੋਡ ਹੀ ਇੰਟਰਫੇਸ ਹੈ।

ਕਿਵੇਂ ਸ਼ਾਮਲ ਹੋਣਾ ਹੈ

ਜੇਕਰ ਇਹ ਤੁਹਾਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਪੂਰਾ ਪ੍ਰੋਜੈਕਟ ਬ੍ਰੇਕਡਾਊਨ ਅਤੇ ਮੌਜੂਦਾ roadmap ਲੇਖਕ ਦੀ Dev.to post 'ਤੇ ਵਿਸਥਾਰ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਿਤ ਹੈ। ਤੁਸੀਂ ਵੇਰਵੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਹੁਣ ਤੱਕ ਕੀ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਅਤੇ ਸਮਝ ਸਕਦੇ ਹੋ ਕਿ ਬਿਲਕੁਲ ਕਿੱਥੇ ਮਦਦ ਦੀ ਲੋੜ ਹੈ।

Project details: https://dev.to/banana_cool/building-a-native-c-ai-engine-catai-from-scratch-looking-for-collaborators-l8m

ਉਹਨਾਂ ਲਈ ਇੱਕ Telegram ਗਰੁੱਪ ਵੀ ਹੈ ਜੋ ਗੱਲਬਾਤ ਕਰਨਾ, ਸਵਾਲ ਪੁੱਛਣਾ, ਜਾਂ ਤੁਰੰਤ pull request ਕਰਨ ਦੀ ਵਚਨਬੱਧਤਾ ਤੋਂ ਬਿਨਾਂ ਤਰੱਕੀ ਨੂੰ ਫੋਲੋ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ।

Community: https://t.me/GyaanSetuAi

ਅਸਲ ਸਿੱਖਿਆ (The Real Takeaway)

ਆਧੁਨਿਕ AI stack ਇੱਕ black box ਬਣ ਗਿਆ ਹੈ। ਅਸੀਂ frameworks ਨੂੰ ਜਾਦੂਈ ਉਪਕਰਣਾਂ ਵਾਂਗ ਮੰਨਦੇ ਹਾਂ: ਡਾਟਾ ਅੰਦਰ ਜਾਂਦਾ ਹੈ, ਮਾਡਲ ਬਾਹਰ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ deployment ਸਮੇਂ ਇਹ ਅਸਪਸ਼ਟਤਾ (opacity) ਸਾਨੂੰ ਮੁਸੀਬਤ ਵਿੱਚ ਨਹੀਂ ਪਾਵੇਗੀ। CatAI ਉਸ ਆਰਾਮ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ। ਇਸ ਤਰੀਕੇ ਨਾਲ ਬਣਾਉਣਾ ਹੌਲੀ ਹੈ। ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਕੋਡ ਲਿਖੋਗੇ, ਜ਼ਿਆਦਾ segfaults ਨੂੰ debug ਕਰੋਗੇ, ਅਤੇ ਉਹਨਾਂ ਅਨੁਮਾਨਾਂ (assumptions) ਬਾਰੇ ਮੁੜ ਵਿਚਾਰ ਕਰੋਗੇ ਜੋ ਉੱਚ-ਪੱਧਰੀ frameworks ਤੁਹਾਡੇ ਤੋਂ ਲੁਕਾਉਂਦੇ ਹਨ। ਪਰ ਤੁਸੀਂ ਇਹ ਵੀ ਸਮਝੋਗੇ ਕਿ ਮਸ਼ੀਨ ਇਸ ਤਰ੍ਹਾਂ ਕਿਉਂ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਅਜਿਹੀ ਉਦਯੋਗ ਵਿੱਚ ਜਿੱਥੇ ਹਰ ਕੋਈ ਹਾਰਡਵੇਅਰ ਨੂੰ abstract ਕਰਨ ਦੀ ਦੌੜ ਵਿੱਚ ਹੈ, ਉੱਥੇ ਦੂਜੀ ਦਿਸ਼ਾ ਵਿੱਚ ਜਾਣਾ ਅਤੇ 'touching the metal' ਵਿੱਚ ਅਸਲ ਮੁੱਲ ਹੈ। ਇਹੀ ਉਹ ਸਮਝ ਹੈ ਜੋ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨੂੰ ਜੋ APIs ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਉਸ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ ਜੋ ਸਿਸਟਮ ਬਣਾਉਂਦਾ ਹੈ।