ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿੱਚ Text-to-SQL ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ

ਜ਼ਿਆਦਾਤਰ Text-to-SQL ਡੈਮੋ ਬਹੁਤ ਸਾਫ਼-ਸੁਥਰੇ ਹੁੰਦੇ ਹਨ।

ਉਹ ਸਰਲ schema ਅਤੇ ਸਪੱਸ਼ਟ table ਦੇ ਨਾਮ ਵਰਤਦੇ ਹਨ। ਉਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਇੱਕ ਜਾਂ ਦੋ tables ਬਿਲਕੁਲ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ। ਇਹ ਇੱਕ ਡੈਮੋ ਲਈ ਤਾਂ ਠੀਕ ਹੈ, ਪਰ ਇੱਕ ਅਸਲ ਕੰਪਨੀ ਵਿੱਚ ਇਹ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।

ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡੇਟਾਬੇਸ ਵਿੱਚ, ਮੁਸ਼ਕਲ ਹਿੱਸਾ SELECT clause ਨਹੀਂ ਹੈ। ਮੁਸ਼ਕਲ ਹਿੱਸਾ join path ਹੈ।

ਇੱਕ ਮਾਡਲ ਗਾਹਕ ਅਨੁਸਾਰ ਰੈਵੇਨਿਊ (revenue) ਲਈ ਇੱਕ ਵੈਧ query ਲਿਖ ਸਕਦਾ ਹੈ। SQL ਚੱਲ ਜਾਂਦਾ ਹੈ। ਡੈਸ਼ਬੋਰਡ ਅੰਕ ਦਿਖਾਉਂਦਾ ਹੈ। ਪਰ ਜਵਾਬ ਗਲਤ ਹੁੰਦਾ ਹੈ।

ਇਹ ਕਿਉਂ ਹੁੰਦਾ ਹੈ?

• customer table ਅਧਿਕਾਰਤ ਮਾਸਟਰ ਲਿਸਟ ਨਹੀਂ ਹੈ।
• revenue field ਵਿੱਤ (finance) ਦੁਆਰਾ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵਰਜ਼ਨ ਨਹੀਂ ਹੈ।
• ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ (regions) ਵਿੱਚ ਰਿਕਾਰਡ ਡੁਪਲੀਕੇਟ ਹਨ।
• join ਕਾਰਨ fanout ਗਲਤੀਆਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ।
• ਵਿੱਤੀ ਕੈਲੰਡਰ (fiscal calendars) ਕੈਲੰਡਰ ਸਾਲਾਂ ਤੋਂ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ।

ਵਿਆਕਰਣਕ (syntactically) ਤੌਰ 'ਤੇ ਵੈਧ query ਇੱਕ ਭਰੋਸੇਯੋਗ query ਨਹੀਂ ਹੁੰਦੀ।

ਅਸਲ production ਸਿਸਟਮ ਬਹੁਤ ਉਲਝੇ ਹੋਏ ਹੁੰਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਮਿਸਿੰਗ foreign keys, legacy tables, ਅਤੇ one-to-many ਰਿਲੇਸ਼ਨਸ਼ਿਪਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜੋ ਅੰਕਾਂ ਨੂੰ ਵਧਾ ਦਿੰਦੇ ਹਨ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਇਨਸਾਨਾਂ ਨੂੰ ਵੀ ਕਿਸੇ join 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਰਾਣੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਜਾਂ ਵਿੱਤ ਵਿਭਾਗ (finance) ਨੂੰ ਪੁੱਛਣਾ ਪੈਂਦਾ ਹੈ।

ਇੱਕ AI ਮਾਡਲ ਸਿਰਫ਼ ਨਾਮ ਅਤੇ ਕਾਲਮ ਦੇਖਦਾ ਹੈ। ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦਾ ਹੈ। ਕਦੇ-ਕਦੇ ਇਹ ਅੰਦਾਜ਼ਾ ਖ਼ਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ।

fanout ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ orders ਨੂੰ order lines ਨਾਲ ਅਤੇ ਫਿਰ shipments ਨਾਲ join ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ order ਨੂੰ ਕਈ ਵਾਰ ਗਿਣਿਆ ਜਾ ਸਕਦਾ ਹੈ। SQL ਸਹੀ ਹੈ, ਪਰ ਨਤੀਜਾ ਗਲਤ ਹੈ।

Metadata ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਕਾਲਮ ਦੇ ਨਾਮ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕੀ ਕੋਈ ਰਿਲੇਸ਼ਨਸ਼ਿਪ ਵਿੱਤੀ ਰ