ਅਸੀਂ ਇੱਕ LLM ਨੂੰ CI ਲੌਗਸ ਦੇ ਟੈਰਾਬਾਈਟ ਦਿੱਤੇ ਹਨ

ਤੁਹਾਡੀ CI ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਬੈਠੀ ਛੁਪੀ ਹੋਈ ਸੋਨੇ ਦੀ ਖਾਣ

ਹਰ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਉਹਨਾਂ ਨੂੰ ਤਿਆਰ ਕਰਦੀ ਹੈ। ਲੱਖਾਂ ਲਾਈਨਾਂ, ਹਰ ਇੱਕ ਦਿਨ — ਟਾਈਮਸਟੈਂਪ, ਸਟੈਕ ਟਰੇਸ, ਨਿਰਭਰਤਾ ਰੈਜ਼ੋਲਿਊਸ਼ਨ, ਟੈਸਟ ਦੇ ਨਤੀਜੇ, ਬਿਲਡ ਆਰਟੀਫੈਕਟਸ, ਅਤੇ ਕ੍ਰਿਪਟਿਕ ਗਲਤੀ ਸੁਨੇਹੇ ਜੋ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨੂੰ ਪੜ੍ਹ ਸਕਣ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹਨ। CI ਲੌਗਸ ਆਧੁਨਿਕ ਸੌਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਦੇ ਐਗਜ਼ੌਸਟ ਫਿਊਮ ਹਨ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਸੰਸਥਾਵਾਂ ਲਈ, ਉਹਨਾਂ ਨੂੰ ਬਿਲਕੁਲ ਐਗਜ਼ੌਸਟ ਵਾਂਗ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ: ਸਟੋਰੇਜ ਵਿੱਚ ਬਾਹਰ ਕੱਢਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਪਰ ਉਦੋਂ ਕੀ ਜੇ ਉਹਨਾਂ ਲੌਗਾਂ ਵਿੱਚ ਪੈਟਰਨ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਦੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲਤਾਵਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰ ਸਕਦੇ ਹਨ, ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਪ੍ਰਤੀ ਤਿਮਾਹੀ ਸੈਂਕੜੇ ਘੰਟੇ ਖਰਚਣ ਵਾਲੀਆਂ ਰੁਕਾਵਟਾਂ ਦੀ ਪਛਾਣ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਪ੍ਰਣਾਲੀਗਤ ਮੁੱਦਿਆਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ ਜੋ ਕੋਈ ਵੀ ਇੰਜੀਨੀਅਰ ਕਦੇ ਨਹੀਂ ਦੇਖਦਾ? ਅਸੀਂ ਇੱਕ ਵੱਡੇ ਭਾਸ਼ਾ ਮਾਡਲ ਵਿੱਚ CI ਲੌਗ ਡੇਟਾ ਦੇ ਟੈਰਾਬਾਈਟ ਫੀਡ ਕਰਕੇ ਪਤਾ ਲਗਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ — ਅਤੇ ਜੋ ਅਸੀਂ ਖੋਜਿਆ ਉਸ ਨੇ ਬਦਲ ਦਿੱਤਾ ਕਿ ਅਸੀਂ DevOps ਬਾਰੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਿਵੇਂ ਸੋਚਦੇ ਹਾਂ।

ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ CI ਲੌਗਸ ਸਭ ਤੋਂ ਘੱਟ ਉਪਯੋਗੀ ਡੇਟਾ ਕਿਉਂ ਹਨ

ਸਿਰਫ਼ ਵਾਲੀਅਮ 'ਤੇ ਗੌਰ ਕਰੋ। ਇੱਕ ਮੱਧ-ਆਕਾਰ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ 200 ਬਿਲਡ ਪ੍ਰਤੀ ਦਿਨ ਕਈ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ ਚਲਾਉਂਦੀ ਹੈ, ਰੋਜ਼ਾਨਾ ਲਗਭਗ 2-4 GB ਕੱਚਾ ਲੌਗ ਡੇਟਾ ਤਿਆਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਸਾਲ ਤੋਂ ਵੱਧ, ਇਹ ਸਟ੍ਰਕਚਰਡ ਅਤੇ ਅਰਧ-ਸੰਰਚਨਾ ਵਾਲੇ ਟੈਕਸਟ ਦੇ ਇੱਕ ਟੈਰਾਬਾਈਟ ਤੋਂ ਵੱਧ ਹੈ ਜੋ ਹਰ ਸੰਕਲਨ, ਹਰੇਕ ਟੈਸਟ ਸੂਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਹਰ ਤੈਨਾਤੀ ਪੜਾਅ, ਅਤੇ ਹਰ ਅਸਫਲ ਮੋਡ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਜਿਸਦਾ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੇ ਕਦੇ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ। ਇਹ ਤੁਹਾਡੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸੰਸਥਾ ਦੀ ਉਤਪਾਦਕਤਾ ਦਾ ਪੂਰਾ ਪੁਰਾਤੱਤਵ ਰਿਕਾਰਡ ਹੈ — ਅਤੇ ਲਗਭਗ ਕੋਈ ਵੀ ਇਸਨੂੰ ਨਹੀਂ ਪੜ੍ਹਦਾ।

ਸਮੱਸਿਆ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਡੇਟਾ ਵਿੱਚ ਮੁੱਲ ਦੀ ਘਾਟ ਹੈ। ਇਹ ਹੈ ਕਿ ਸਿਗਨਲ-ਟੂ-ਆਇਸ ਅਨੁਪਾਤ ਬੇਰਹਿਮ ਹੈ। ਇੱਕ ਆਮ CI ਰਨ ਆਉਟਪੁੱਟ ਦੀਆਂ ਹਜ਼ਾਰਾਂ ਲਾਈਨਾਂ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ 3-5 ਲਾਈਨਾਂ ਵਿੱਚ ਕਾਰਵਾਈਯੋਗ ਜਾਣਕਾਰੀ ਹੋਵੇ। ਇੰਜੀਨੀਅਰ ਲਾਲ ਟੈਕਸਟ ਲਈ ਸਕੈਨ ਕਰਨਾ ਸਿੱਖਦੇ ਹਨ, "ਫੇਲ" ਲਈ grep ਅਤੇ ਅੱਗੇ ਵਧਦੇ ਹਨ। ਪਰ ਉਹ ਪੈਟਰਨ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹਨ - ਫਲੈਕੀ ਟੈਸਟ ਜੋ ਹਰ ਮੰਗਲਵਾਰ ਨੂੰ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਨਿਰਭਰਤਾ ਜੋ ਹਰ ਬਿਲਡ ਵਿੱਚ 40 ਸਕਿੰਟ ਜੋੜਦੀ ਹੈ, ਮੈਮੋਰੀ ਲੀਕ ਜੋ ਸਿਰਫ ਉਦੋਂ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਤਿੰਨ ਖਾਸ ਸੇਵਾਵਾਂ ਇੱਕੋ ਸਮੇਂ ਚੱਲਦੀਆਂ ਹਨ - ਉਹ ਪੈਟਰਨ ਵਿਅਕਤੀਗਤ ਲੌਗ ਪੱਧਰ 'ਤੇ ਅਦਿੱਖ ਹੁੰਦੇ ਹਨ। ਉਹ ਸਿਰਫ ਪੈਮਾਨੇ 'ਤੇ ਉਭਰਦੇ ਹਨ।

ਪਰੰਪਰਾਗਤ ਲੌਗ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲ ਜਿਵੇਂ ਕਿ ELK ਸਟੈਕ ਅਤੇ ਡੈਟਾਡੌਗ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਸਤਹ ਕੀਵਰਡ ਮੈਚਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ CI ਆਉਟਪੁੱਟ ਦੀ ਅਰਥਗਤ ਜਟਿਲਤਾ ਨਾਲ ਸੰਘਰਸ਼ ਕਰਦੇ ਹਨ। ਇੱਕ ਬਿਲਡ ਅਸਫਲਤਾ ਸੁਨੇਹਾ ਜੋ ਪੜ੍ਹਦਾ ਹੈ "ਪੋਰਟ 5432 'ਤੇ ਕੁਨੈਕਸ਼ਨ ਤੋਂ ਇਨਕਾਰ" ਅਤੇ ਇੱਕ ਜੋ ਪੜ੍ਹਦਾ ਹੈ "ਘਾਤਕ: ਉਪਭੋਗਤਾ 'ਡਿਪਲੋਏ' ਲਈ ਪਾਸਵਰਡ ਪ੍ਰਮਾਣੀਕਰਨ ਅਸਫਲ" ਦੋਵੇਂ ਡਾਟਾਬੇਸ-ਸੰਬੰਧੀ ਅਸਫਲਤਾਵਾਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਦੇ ਮੂਲ ਕਾਰਨ ਅਤੇ ਹੱਲ ਬਿਲਕੁਲ ਵੱਖਰੇ ਹਨ। ਉਸ ਅੰਤਰ ਨੂੰ ਸਮਝਣ ਲਈ ਉਸ ਕਿਸਮ ਦੇ ਪ੍ਰਸੰਗਿਕ ਤਰਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿ ਹਾਲ ਹੀ ਵਿੱਚ, ਸਿਰਫ਼ ਮਨੁੱਖ ਹੀ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਸਨ।

ਪ੍ਰਯੋਗ: ਇੱਕ LLM ਨੂੰ ਬਿਲਡ ਹਿਸਟਰੀ ਦੇ 3.2 ਟੈਰਾਬਾਈਟ ਫੀਡ ਕਰਨਾ

ਸੈੱਟਅੱਪ ਸੰਕਲਪ ਵਿੱਚ ਸਿੱਧਾ ਸੀ ਅਤੇ ਅਮਲ ਵਿੱਚ ਭਿਆਨਕ ਸੀ। ਅਸੀਂ 138,000 ਤੋਂ ਵੱਧ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਪਲੇਟਫਾਰਮ ਤੋਂ 14 ਮਹੀਨਿਆਂ ਦੇ CI ਲੌਗ ਇਕੱਠੇ ਕੀਤੇ - ਕਈ ਸੇਵਾਵਾਂ, ਵਾਤਾਵਰਣ, ਅਤੇ ਤੈਨਾਤੀ ਟੀਚਿਆਂ ਵਿੱਚ ਬਿਲਡ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹੋਏ। ਕੱਚਾ ਡੇਟਾਸੈਟ 3.2 ਟੈਰਾਬਾਈਟ 'ਤੇ ਆਇਆ: ਲਗਭਗ 847 ਮਿਲੀਅਨ ਵਿਅਕਤੀਗਤ ਲੌਗ ਲਾਈਨਾਂ ਫੈਲੀਆਂ 1.6 ਮਿਲੀਅਨ CI ਪਾਈਪਲਾਈਨ ਚੱਲਦੀਆਂ ਹਨ। ਅਸੀਂ ਇਸ ਡੇਟਾ ਨੂੰ ਚੰਕ ਕੀਤਾ, ਏਮਬੈਡ ਕੀਤਾ, ਅਤੇ ਇੰਡੈਕਸ ਕੀਤਾ, ਫਿਰ ਇੱਕ ਰੀਟ੍ਰੀਵਲ-ਔਗਮੈਂਟੇਡ ਜਨਰੇਸ਼ਨ (RAG) ਪਾਈਪਲਾਈਨ ਬਣਾਈ ਜੋ ਸਾਡੇ ਬਿਲਡ ਇਤਿਹਾਸ ਬਾਰੇ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੀ ਹੈ।

ਪਹਿਲੀ ਚੁਣੌਤੀ ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ ਸੀ। CI ਲੌਗ ਸਾਫ਼ ਟੈਕਸਟ ਨਹੀਂ ਹਨ। ਉਹਨਾਂ ਵਿੱਚ ANSI ਕਲਰ ਕੋਡ, ਪ੍ਰਗਤੀ ਬਾਰ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਦੇ ਹਨ, ਬਾਈਨਰੀ ਆਰਟੀਫੈਕਟ ਚੈਕਸਮ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਚਾਰ ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਟਾਈਮਸਟੈਂਪ ਹੁੰਦੇ ਹਨ ਜੋ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਸ ਟੂਲ ਨੇ ਤਿਆਰ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਸਿਰਫ਼ ਸਧਾਰਣਕਰਨ 'ਤੇ ਤਿੰਨ ਹਫ਼ਤੇ ਬਿਤਾਏ - ਸ਼ੋਰ ਨੂੰ ਉਤਾਰਨਾ, ਟਾਈਮਸਟੈਂਪਾਂ ਨੂੰ ਮਾਨਕੀਕਰਨ ਕਰਨਾ, ਅਤੇ ਹਰੇਕ ਲੌਗ ਹਿੱਸੇ ਨੂੰ ਮੈਟਾਡੇਟਾ ਨਾਲ ਟੈਗ ਕਰਨਾ ਕਿ ਇਹ ਕਿਸ ਪਾਈਪਲਾਈਨ ਪੜਾਅ, ਰਿਪੋਜ਼ਟਰੀ, ਸ਼ਾਖਾ ਅਤੇ ਵਾਤਾਵਰਣ ਨਾਲ ਸਬੰਧਤ ਹੈ।

ਦੂਜੀ ਚੁਣੌਤੀ ਲਾਗਤ ਸੀ। ਟੈਕਸਟ ਦੇ ਟੈਰਾਬਾਈਟ ਉੱਤੇ ਚੱਲਣਾ ਸਸਤਾ ਨਹੀਂ ਹੈ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਹਮਲਾਵਰ ਚੰਕਿੰਗ ਅਤੇ ਮੁੜ ਪ੍ਰਾਪਤੀ ਅਨੁਕੂਲਨ ਦੇ ਨਾਲ ਵੀ। ਅਸੀਂ ਇਕੱਲੇ ਪਹਿਲੇ ਮਹੀਨੇ ਦੇ ਦੌਰਾਨ ਮਹੱਤਵਪੂਰਨ ਗਣਨਾ ਕ੍ਰੈਡਿਟਾਂ ਦੁਆਰਾ ਬਰਨ ਕੀਤਾ, ਜਿਆਦਾਤਰ ਕਿਉਂਕਿ ਸਾਡੀ ਸ਼ੁਰੂਆਤੀ ਪਹੁੰਚ ਬਹੁਤ ਭੋਲੀ ਸੀ — ਪ੍ਰਤੀ ਪੁੱਛਗਿੱਛ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੰਦਰਭ ਭੇਜਣਾ ਅਤੇ ਇਸ ਬਾਰੇ ਕਾਫ਼ੀ ਚੋਣਵੇਂ ਨਹੀਂ ਹੋਣਾ ਕਿ ਕਿਹੜੇ ਲੌਗ ਹਿੱਸੇ ਢੁਕਵੇਂ ਸਨ। ਦੂਜੇ ਮਹੀਨੇ ਦੇ ਅੰਤ ਤੱਕ, ਅਸੀਂ ਬਿਹਤਰ ਏਮਬੈਡਿੰਗ ਰਣਨੀਤੀਆਂ ਅਤੇ ਇੱਕ ਦੋ-ਪੜਾਅ ਮੁੜ ਪ੍ਰਾਪਤੀ ਪ੍ਰਣਾਲੀ ਦੁਆਰਾ ਪ੍ਰਤੀ-ਕਵੇਰੀ ਲਾਗਤਾਂ ਨੂੰ 87% ਤੱਕ ਘਟਾ ਦਿੱਤਾ ਹੈ ਜੋ ਵੱਡੇ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੀ-ਫਿਲਟਰ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟੇ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਸੀ।

ਐਲਐਲਐਮ ਦੇ ਪੰਜ ਪੈਟਰਨ ਜੋ ਮਨੁੱਖ ਕਦੇ ਨਹੀਂ ਕਰਨਗੇ

ਚੁਨ ਰਹੇ ਸਵਾਲਾਂ ਦੇ ਪਹਿਲੇ ਹਫ਼ਤੇ ਦੇ ਅੰਦਰ, ਸਿਸਟਮ ਨੇ ਅਜਿਹੀਆਂ ਸੂਝ-ਬੂਝਾਂ ਪੇਸ਼ ਕੀਤੀਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹੱਥੀਂ ਖੋਜਣ ਵਿੱਚ ਮਨੁੱਖੀ ਵਿਸ਼ਲੇਸ਼ਕ ਨੂੰ ਮਹੀਨਿਆਂ ਦਾ ਸਮਾਂ ਲੱਗਾ ਹੋਵੇਗਾ। ਇਹ ਕਿਨਾਰੇ ਦੇ ਕੇਸ ਜਾਂ ਉਤਸੁਕਤਾ ਨਹੀਂ ਸਨ — ਇਹ ਸਿਸਟਮਿਕ ਸਮੱਸਿਆਵਾਂ ਸਨ ਜੋ ਅਸਲ ਇੰਜਨੀਅਰਿੰਗ ਘੰਟਿਆਂ ਦਾ ਖੂਨ ਵਹਿ ਰਹੀਆਂ ਸਨ।

1. ਫੈਂਟਮ ਨਿਰਭਰਤਾ ਕੈਸਕੇਡ। 9 ਮਹੀਨੇ ਪਹਿਲਾਂ ਇੱਕ ਸਿੰਗਲ npm ਪੈਕੇਜ ਅੱਪਡੇਟ ਨੇ ਹਰੇਕ JavaScript ਬਿਲਡ ਵਿੱਚ 22-ਸਕਿੰਟ ਦੀ ਦੇਰੀ ਸ਼ੁਰੂ ਕੀਤੀ ਸੀ। ਦੇਰੀ ਨੂੰ ਮਾਸਕ ਕੀਤਾ ਗਿਆ ਸੀ ਕਿਉਂਕਿ ਇਹ ਇੱਕ CI ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਅੱਪਗਰੇਡ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਸੀ ਜਿਸ ਨੇ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਨਿਰਮਾਣ ਕੀਤਾ। ਨੈੱਟ-ਨੈੱਟ, ਬਿਲਡ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਪਰ ਉਹ ਅਜੇ ਵੀ 22 ਸਕਿੰਟ ਤੇਜ਼ ਹੋ ਸਕਦੇ ਸਨ। 400+ JS ਬਿਲਡ ਪ੍ਰਤੀ ਦਿਨ, ਜੋ ਕਿ ਰੋਜ਼ਾਨਾ 2.4 ਘੰਟੇ ਦੀ ਬਰਬਾਦੀ ਸੀ।
2. ਸਮਾਂ ਜ਼ੋਨ ਫਲੇਕ। ਇੱਕ ਟੈਸਟ ਸੂਟ ਵਿੱਚ 4.7% ਅਸਫਲਤਾ ਦੀ ਦਰ ਸੀ — ਤੰਗ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਉੱਚੀ, ਸਿਰਫ ਇੰਨੀ ਘੱਟ ਕਿ ਕਿਸੇ ਨੇ ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਨਹੀਂ ਦਿੱਤੀ। LLM ਨੇ ਪਛਾਣ ਕੀਤੀ ਕਿ ਅਸਫਲਤਾਵਾਂ 23:00 ਅਤੇ 01:00 UTC ਦੇ ਵਿਚਕਾਰ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਬਿਲਡਾਂ ਨਾਲ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਬੰਧਿਤ ਹਨ, ਜਦੋਂ ਇੱਕ ਮਿਤੀ-ਤੁਲਨਾ ਫੰਕਸ਼ਨ ਇੱਕ ਦਿਨ ਦੀ ਸੀਮਾ ਨੂੰ ਪਾਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਦੋ-ਲਾਈਨ ਫਿਕਸ ਨੇ ਫਲੇਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰ ਦਿੱਤਾ।
3. ਸਾਇਲੈਂਟ ਰੋਲਬੈਕ ਪੈਟਰਨ। ਸਟੇਜਿੰਗ ਲਈ ਤੈਨਾਤੀਆਂ 99.2% ਵਾਰ ਸਫਲ ਰਹੀਆਂ, ਪਰ LLM ਨੇ ਦੇਖਿਆ ਕਿ 31% "ਸਫਲ" ਸਟੇਜਿੰਗ ਤੈਨਾਤੀਆਂ ਦੇ ਬਾਅਦ 45 ਮਿੰਟਾਂ ਦੇ ਅੰਦਰ ਉਸੇ ਸੇਵਾ ਦੀ ਇੱਕ ਹੋਰ ਤੈਨਾਤੀ ਕੀਤੀ ਗਈ ਸੀ — ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਪਾਸ ਕਰਨ ਦੇ ਬਾਵਜੂਦ ਪਹਿਲੀ ਤੈਨਾਤੀ ਕਾਰਜਸ਼ੀਲ ਤੌਰ 'ਤੇ ਟੁੱਟ ਗਈ ਸੀ। ਇਹ ਖੋਜ ਕਰਨ ਲਈ ਅਗਵਾਈ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਨਕਲੀ ਸੇਵਾ ਤੋਂ ਕੈਸ਼ ਕੀਤੇ ਜਵਾਬਾਂ ਦੇ ਕਾਰਨ ਇੱਕ ਏਕੀਕਰਣ ਟੈਸਟ ਪਾਸ ਹੋ ਰਿਹਾ ਸੀ।
4. ਸੋਮਵਾਰ ਸਵੇਰ ਦੀ ਰੁਕਾਵਟ। ਸਥਾਨਕ ਸਮੇਂ ਅਨੁਸਾਰ ਹਰ ਸੋਮਵਾਰ ਸਵੇਰੇ 9:00 ਅਤੇ 10:30 AM ਵਿਚਕਾਰ ਕਤਾਰ ਬਣਾਉਣ ਦੇ ਸਮੇਂ ਵਿੱਚ 340% ਦਾ ਵਾਧਾ ਹੋਇਆ, ਕਿਉਂਕਿ ਡਿਵੈਲਪਰ ਜੋ ਵੀਕਐਂਡ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਸਨ, ਉਹਨਾਂ ਨੇ ਸਟੈਂਡਅੱਪ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਅੱਗੇ ਵਧਾਇਆ। ਫਿਕਸ ਤਕਨੀਕੀ ਨਹੀਂ ਸੀ — ਇਹ ਕਾਰਜਸ਼ੀਲ ਸੀ: ਸੋਮਵਾਰ ਦੇ ਵਾਧੇ ਦੀ ਉਮੀਦ ਕਰਨ ਲਈ CI ਰਨਰ ਪੂਲ ਸਕੇਲਿੰਗ ਅਨੁਸੂਚੀ ਨੂੰ ਹੈਰਾਨ ਕਰ ਰਿਹਾ ਸੀ।
5. ਕੰਪਾਈਲਰ ਫਲੈਗ ਜਿਸ ਨੂੰ ਕਿਸੇ ਨੇ ਵੀ ਸੈੱਟ ਕੀਤਾ ਹੈ। 67% C++ ਬਿਲਡ ਬਿਨਾਂ ਵਾਧੇ ਵਾਲੇ ਕੰਪਾਈਲੇਸ਼ਨ ਸਮਰਥਿਤ ਕੀਤੇ ਚੱਲ ਰਹੇ ਸਨ, ਪ੍ਰਤੀ ਬਿਲਡ ਔਸਤ 3.8 ਮਿੰਟ ਜੋੜਦੇ ਹੋਏ। ਫਲੈਗ ਨੂੰ ਆਨਬੋਰਡਿੰਗ ਗਾਈਡ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਗਿਆ ਸੀ ਪਰ ਇਸਨੂੰ ਕਦੇ ਵੀ ਸ਼ੇਅਰ ਕੀਤੇ CI ਕੌਂਫਿਗਰੇਸ਼ਨ ਟੈਂਪਲੇਟ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ।

"ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਬੱਗ ਉਹ ਨਹੀਂ ਹਨ ਜੋ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰ ਦਿੰਦੇ ਹਨ। ਉਹ ਉਹ ਹਨ ਜੋ ਚੁੱਪਚਾਪ ਹਰ ਬਿਲਡ ਤੋਂ, ਹਰ ਦਿਨ, ਸਾਲਾਂ ਤੱਕ 30 ਸਕਿੰਟ ਚੋਰੀ ਕਰਦੇ ਹਨ — ਜਦੋਂ ਤੱਕ ਕੋਈ ਆਖਰਕਾਰ ਸਹੀ ਡੇਟਾਸੈਟ ਦਾ ਸਹੀ ਸਵਾਲ ਨਹੀਂ ਪੁੱਛਦਾ।"

ਇੱਕ ਪ੍ਰੈਕਟੀਕਲ CI ਇੰਟੈਲੀਜੈਂਸ ਲੇਅਰ ਬਣਾਉਣਾ

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

ਅਸੀਂ ਤਿੰਨ-ਪੱਧਰੀ ਪਹੁੰਚ 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ। ਪਹਿਲਾ ਟੀਅਰ ਆਟੋਮੈਟਿਕ ਟ੍ਰਾਈਏਜ ਹੈ: ਹਰ ਅਸਫਲ ਬਿਲਡ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਰੂਟ ਕਾਰਨ ਸ਼੍ਰੇਣੀ (ਬੁਨਿਆਦੀ ਢਾਂਚਾ, ਨਿਰਭਰਤਾ, ਟੈਸਟ ਤਰਕ, ਸੰਰਚਨਾ, ਜਾਂ ਫਲੇਕ) ਦੁਆਰਾ ਇੱਕ ਭਰੋਸੇ ਦੇ ਸਕੋਰ ਨਾਲ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਕੱਲੇ ਇਸ ਨੇ ਬਿਲਡ ਅਸਫਲਤਾਵਾਂ ਲਈ ਔਸਤ ਸਮਾਂ-ਸਥਾਨ ਨੂੰ 34% ਘਟਾ ਦਿੱਤਾ, ਕਿਉਂਕਿ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਹੁਣ ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਿ ਕਿੱਥੋਂ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ, ਲੌਗ ਪੜ੍ਹਨ ਵਿੱਚ 10 ਮਿੰਟ ਨਹੀਂ ਲਗਾਉਣੇ ਪਏ। ਦੂਜਾ ਦਰਜਾ ਰੁਝਾਨ ਖੋਜ ਹੈ: ਇੱਕ ਹਫਤਾਵਾਰੀ ਡਾਇਜੈਸਟ ਜੋ ਉਭਰ ਰਹੇ ਪੈਟਰਨਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ — ਵਧਦੀ ਅਸਫਲਤਾ ਦਰਾਂ, ਵਧ ਰਹੇ ਬਿਲਡ ਟਾਈਮ, ਨਵੇਂ ਗਲਤੀ ਦਸਤਖਤ — ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਉਹ ਨਾਜ਼ੁਕ ਬਣ ਜਾਣ। ਤੀਜਾ ਦਰਜਾ ਇੰਟਰਐਕਟਿਵ ਇਨਵੈਸਟੀਗੇਸ਼ਨ ਹੈ: ਇੱਕ ਇੰਟਰਫੇਸ ਜਿੱਥੇ ਇੰਜੀਨੀਅਰ ਬਿਲਡ ਹਿਸਟਰੀ ਬਾਰੇ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦੇ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ "ਸਰਵਿਸ X ਮਾਰਚ ਦੇ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਅਕਸਰ ਅਸਫਲ ਕਿਉਂ ਹੋਇਆ?" ਜਾਂ "ਭੁਗਤਾਨ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਸਮਾਂ ਸਮਾਪਤੀ ਦੀਆਂ ਗਲਤੀਆਂ ਦਾ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਕੀ ਹੈ?"

ਗੁੰਝਲਦਾਰ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਚਲਾਉਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ — ਖਾਸ ਤੌਰ 'ਤੇ Mewayz, ਜੋ ਕਿ 207 ਏਕੀਕ੍ਰਿਤ ਮੋਡੀਊਲ ਨੂੰ ਆਰਕੈਸਟ੍ਰੇਟ ਕਰਦਾ ਹੈ, ਦੁਆਰਾ CRM, ਇਨਵੌਇਸਿੰਗ, ਪੇਰੋਲ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਵਰਗੇ ਕਈ ਕਾਰੋਬਾਰੀ ਫੰਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹਨ — ਇਸ ਕਿਸਮ ਦੀ ਨਿਰੀਖਣਯੋਗਤਾ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਸਿੰਗਲ ਡਿਪਲਾਇਮੈਂਟ ਗਾਹਕ-ਸਾਹਮਣੇ ਵਾਲੇ ਵਰਕਫਲੋ, ਬਿਲਿੰਗ ਤਰਕ, ਅਤੇ HR ਸਿਸਟਮਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਛੂਹਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ CI ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਅੰਤਰ-ਨਿਰਭਰਤਾ ਨੂੰ ਸਮਝਣਾ ਵਿਕਲਪਿਕ ਨਹੀਂ ਹੈ। ਇਹ ਭਰੋਸੇਯੋਗਤਾ ਬਣਾਈ ਰੱਖਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ ਜਿਸ 'ਤੇ 138,000+ ਉਪਭੋਗਤਾ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।

ਕੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ (ਅਜੇ ਤੱਕ)

ਇਮਾਨਦਾਰੀ ਪ੍ਰਚਾਰ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਇਸ ਪਹੁੰਚ ਦੀਆਂ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਹਨ ਜੋ ਇਸ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨੂੰ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ। LLMs ਭੁਲੇਖਾ ਪਾਉਂਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਉਹ CI ਲੌਗਸ ਬਾਰੇ ਭੁਲੇਖਾ ਪਾਉਂਦੇ ਹਨ, ਤਾਂ ਨਤੀਜੇ ਯਕੀਨਨ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ। ਅਸੀਂ ਦੇਖਿਆ ਹੈ ਕਿ ਸਿਸਟਮ ਭਰੋਸੇ ਨਾਲ ਇੱਕ ਬਿਲਡ ਅਸਫਲਤਾ ਨੂੰ ਇੱਕ ਨਿਰਭਰਤਾ ਟਕਰਾਅ ਲਈ ਵਿਸ਼ੇਸ਼ਤਾ ਦਿੰਦਾ ਹੈ ਜੋ ਕਦੇ ਮੌਜੂਦ ਨਹੀਂ ਸੀ, ਬਨਾਵਟੀ ਸੰਸਕਰਣ ਨੰਬਰਾਂ ਨਾਲ ਪੂਰਾ ਹੁੰਦਾ ਹੈ। RAG ਪਾਈਪਲਾਈਨ ਇਸ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾਉਂਦੀ ਹੈ, ਪਰ ਇਹ ਇਸਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦੀ ਹੈ। ਸਿਸਟਮ ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੀ ਹਰ ਸੂਝ ਨੂੰ ਅਜੇ ਵੀ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਨੁੱਖੀ ਤਸਦੀਕ ਦੀ ਲੋੜ ਹੈ।

ਪੈਮਾਨਾ ਇੱਕ ਚੁਣੌਤੀ ਬਣਿਆ ਹੋਇਆ ਹੈ। ਜਦੋਂ ਕਿ ਮੁੜ ਪ੍ਰਾਪਤੀ ਪ੍ਰਣਾਲੀ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਸੰਭਾਲ ਸਕਦੀ ਹੈ, ਨਵੇਂ ਲੌਗਸ ਦੀ ਸ਼ੁਰੂਆਤੀ ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਏਮਬੈਡਿੰਗ ਗਣਨਾਤਮਕ ਤੌਰ 'ਤੇ ਮਹਿੰਗੀ ਹੈ। ਅਸੀਂ ਰੋਜ਼ਾਨਾ ਲਗਭਗ 800,000 ਨਵੀਆਂ ਲੌਗ ਲਾਈਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਸੂਚਕਾਂਕ ਨੂੰ ਤਾਜ਼ਾ ਰੱਖਣ ਲਈ ਸਮਰਪਿਤ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ, ਲਾਗਤ-ਲਾਭ ਦੀ ਗਣਨਾ ਇਸ ਪਹੁੰਚ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦੀ - ਘੱਟੋ ਘੱਟ ਅਜੇ ਨਹੀਂ। ਜਿਵੇਂ ਕਿ ਮਾਡਲ ਦੀਆਂ ਲਾਗਤਾਂ ਘਟਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ (ਉਹ ਬਰਾਬਰ ਸਮਰੱਥਾ ਲਈ ਪਿਛਲੇ 18 ਮਹੀਨਿਆਂ ਵਿੱਚ ਲਗਭਗ 90% ਘਟੀਆਂ ਹਨ), ਅਰਥ ਸ਼ਾਸਤਰ ਬਦਲ ਜਾਵੇਗਾ।

ਸੁਰੱਖਿਆ ਦਾ ਸਵਾਲ ਵੀ ਹੈ। CI ਲੌਗਸ ਵਿੱਚ ਭੇਦ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ — API ਕੁੰਜੀਆਂ, ਕਨੈਕਸ਼ਨ ਸਤਰ, ਅੰਦਰੂਨੀ URL — ਉਹਨਾਂ ਨੂੰ ਰਗੜਨ ਦੇ ਸਭ ਤੋਂ ਵਧੀਆ ਯਤਨਾਂ ਦੇ ਬਾਵਜੂਦ। ਇਸ ਡੇਟਾ ਨੂੰ ਬਾਹਰੀ LLM API ਨੂੰ ਭੇਜਣਾ ਜੋਖਮ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਇੱਕ ਸਥਾਨਕ ਸਕ੍ਰਬਿੰਗ ਪਾਈਪਲਾਈਨ ਨਾਲ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਰਿਪੋਜ਼ਟਰੀਆਂ ਲਈ ਸਵੈ-ਹੋਸਟ ਕੀਤੇ ਮਾਡਲਾਂ 'ਤੇ ਅਨੁਮਾਨ ਚਲਾ ਕੇ ਇਸ ਨੂੰ ਘਟਾਉਂਦੇ ਹਾਂ, ਪਰ ਇਹ ਜਟਿਲਤਾ ਅਤੇ ਲਾਗਤ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਕੋਈ ਵੀ ਸਮਾਨ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੀਮਾਂ ਨੂੰ ਆਪਣੇ ਖ਼ਤਰੇ ਦੇ ਮਾਡਲ ਦਾ ਧਿਆਨ ਨਾਲ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਟੈਰਾਬਾਈਟ ਤੋਂ ਬਿਨਾਂ ਸ਼ੁਰੂਆਤ ਕਰਨਾ

ਤੁਹਾਨੂੰ ਆਪਣੇ CI ਲੌਗਸ ਤੋਂ ਮੁੱਲ ਕੱਢਣਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇੱਕ ਵਿਸ਼ਾਲ ਡੇਟਾਸੈਟ ਜਾਂ ਇੱਕ ਸਮਰਪਿਤ ML ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇੱਥੇ ਇੱਕ ਵਿਹਾਰਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ ਜਿਸਨੂੰ ਹਰ ਹਫ਼ਤੇ ਕੁਝ ਸੌ ਬਿਲਡਾਂ ਵਾਲੀ ਕੋਈ ਵੀ ਟੀਮ ਲਾਗੂ ਕਰ ਸਕਦੀ ਹੈ:

• ਅਸਫਲਤਾ ਵਰਗੀਕਰਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਆਪਣੇ ਪਿਛਲੇ 90 ਦਿਨਾਂ ਦੇ ਅਸਫਲ ਬਿਲਡ ਲੌਗਾਂ ਨੂੰ ਨਿਰਯਾਤ ਕਰੋ। ਹਰੇਕ ਅਸਫਲਤਾ ਨੂੰ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਨ ਲਈ ਕਿਸੇ ਵੀ LLM API ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਸਧਾਰਨ ਵਰਗੀਕਰਨ (ਇਨਫਰਾ ਬਨਾਮ ਕੋਡ ਬਨਾਮ ਸੰਰਚਨਾ ਬਨਾਮ ਫਲੇਕ) ਤਰਜੀਹ ਲਈ ਤੁਰੰਤ ਮੁੱਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• ਬਿਲਡ ਅਵਧੀ ਦੇ ਰੁਝਾਨਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ। ਪ੍ਰਤੀ ਪਾਈਪਲਾਈਨ ਪੜਾਅ ਬਿਲਡ ਅਵਧੀ ਦੀ ਇੱਕ ਸਮਾਂ-ਸੀਰੀਜ਼ ਬਣਾਉਣ ਲਈ ਆਪਣੇ ਲੌਗਸ ਤੋਂ ਟਾਈਮਸਟੈਂਪ ਪਾਰਸ ਕਰੋ। ਆਲੇ-ਦੁਆਲੇ ਦੇ ਲੌਗ ਸੰਦਰਭ ਦੇ ਨਾਲ ਇੱਕ LLM ਨੂੰ ਵਿਗਾੜਾਂ ਨੂੰ ਫੀਡ ਕਰੋ ਅਤੇ ਮੂਲ ਕਾਰਨ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਲਈ ਪੁੱਛੋ।
• "ਸਪੱਸ਼ਟ" ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰੋ। ਇੱਕ ਅਸਫ਼ਲਤਾ ਤੋਂ ਬਾਅਦ ਦਾ ਹੁੱਕ ਸੈਟ ਅਪ ਕਰੋ ਜੋ ਇੱਕ ਅਸਫਲ ਬਿਲਡ ਦੀਆਂ ਆਖ਼ਰੀ 500 ਲਾਈਨਾਂ ਨੂੰ ਪ੍ਰੋਂਪਟ ਦੇ ਨਾਲ ਇੱਕ LLM ਨੂੰ ਭੇਜਦਾ ਹੈ: "ਇਸ CI ਅਸਫਲਤਾ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸੰਖੇਪ ਕਰੋ ਅਤੇ ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਹੱਲ ਦਾ ਸੁਝਾਅ ਦਿਓ।" ਇਹ ਇਕੱਲਾ ਟੀਮ ਦੇ ਹਰੇਕ ਇੰਜੀਨੀਅਰ ਲਈ 5-10 ਮਿੰਟ ਪ੍ਰਤੀ ਅਸਫਲਤਾ ਬਚਾਉਂਦਾ ਹੈ।
• ਖੋਜਣਯੋਗ ਪੁਰਾਲੇਖ ਬਣਾਓ। ਆਪਣੇ ਲੌਗ ਇਤਿਹਾਸ ਨੂੰ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦੁਆਰਾ ਪੁੱਛਗਿੱਛਯੋਗ ਬਣਾਉਣ ਲਈ ਏਮਬੈਡਿੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। LangChain ਅਤੇ LlamaIndex ਵਰਗੇ ਟੂਲ ਇਸ ਨੂੰ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਇੱਥੋਂ ਤੱਕ ਕਿ ML ਅਨੁਭਵ ਤੋਂ ਬਿਨਾਂ ਟੀਮਾਂ ਲਈ ਵੀ।

ਕੁੰਜੀ ਛੋਟੀ ਜਿਹੀ ਸ਼ੁਰੂਆਤ ਕਰਨਾ ਹੈ, ਇਹ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈ ਕਿ ਇਨਸਾਈਟਸ ਸਹੀ ਹਨ, ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਫੈਲਾਉਣਾ ਹੈ। ਇਸ ਕਿਸਮ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਟੂਲਿੰਗ ਈਕੋਸਿਸਟਮ ਤੇਜ਼ੀ ਨਾਲ ਪਰਿਪੱਕ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਜੋ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਲੋੜੀਂਦਾ ਕਸਟਮ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸੀ, ਉਹ ਸ਼ੈਲਫ ਤੋਂ ਬਾਹਰਲੇ ਹਿੱਸਿਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਉਪਲਬਧ ਹੈ।

ਭਵਿੱਖ ਓਪਰੇਸ਼ਨਲ ਇੰਟੈਲੀਜੈਂਸ ਹੈ

ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਜਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ ਉਹ ਸਿਰਫ਼ ਲੌਗ ਵਿਸ਼ਲੇਸ਼ਣ ਹੀ ਨਹੀਂ ਹੈ — ਇਹ ਸੰਚਾਲਨ ਖੁਫ਼ੀਆ ਜਾਣਕਾਰੀ ਵੱਲ ਇੱਕ ਬੁਨਿਆਦੀ ਤਬਦੀਲੀ ਹੈ। ਉਹੀ ਪਹੁੰਚ ਜੋ CI ਲੌਗਸ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ ਗਾਹਕ ਸਹਾਇਤਾ ਟਿਕਟਾਂ, ਵਿਕਰੀ ਪਾਈਪਲਾਈਨ ਡੇਟਾ, ਵਿੱਤੀ ਲੈਣ-ਦੇਣ, ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਵਰਕਫਲੋ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਆਮ ਥ੍ਰੈੱਡ ਇਹ ਹੈ ਕਿ ਸੰਸਥਾਵਾਂ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਅਰਧ-ਸੰਗਠਿਤ ਟੈਕਸਟ ਡੇਟਾ ਤਿਆਰ ਕਰਦੀਆਂ ਹਨ ਜਿਸ ਵਿੱਚ ਕਾਰਵਾਈਯੋਗ ਪੈਟਰਨ ਹੁੰਦੇ ਹਨ, ਅਤੇ LLM ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਨੂੰ ਲੱਭਣ ਲਈ ਵਿਲੱਖਣ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲ ਹੁੰਦੇ ਹਨ।

ਇਸੇ ਕਰਕੇ ਵਪਾਰਕ ਸੰਚਾਲਨ ਨੂੰ ਕੇਂਦਰਿਤ ਕਰਨ ਵਾਲੇ ਪਲੇਟਫਾਰਮਾਂ ਦਾ ਢਾਂਚਾਗਤ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡਾ CRM ਡੇਟਾ, ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਬੰਧਨ, ਇਨਵੌਇਸਿੰਗ, HR ਰਿਕਾਰਡ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਸਾਰੇ ਇੱਕ ਸਿਸਟਮ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ - ਜਿਵੇਂ ਕਿ ਉਹ ਮੇਵੇਜ਼ ਦੇ ਏਕੀਕ੍ਰਿਤ ਮੋਡੀਊਲ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ ਕਰਦੇ ਹਨ - ਕ੍ਰਾਸ-ਡੋਮੇਨ ਇੰਟੈਲੀਜੈਂਸ ਦੀ ਸੰਭਾਵਨਾ ਗੁਣਾ ਹੁੰਦੀ ਹੈ। ਤੁਹਾਡੇ CI ਲੌਗਸ ਵਿੱਚ ਇੱਕ ਪੈਟਰਨ ਗਾਹਕ ਮੰਥਨ ਨਾਲ ਸਬੰਧਿਤ ਹੋ ਸਕਦਾ ਹੈ। ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਵਿੱਚ ਇੱਕ ਵਾਧਾ ਇੱਕ ਤੈਨਾਤੀ ਅਸਫਲਤਾ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਕਨੈਕਸ਼ਨ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਦਿਸਦੇ ਹਨ ਜਦੋਂ ਡੇਟਾ ਵੱਖਰੇ ਸਿਲੋਜ਼ ਦੀ ਬਜਾਏ ਕਨੈਕਟ ਕੀਤੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।

ਉਹ ਟੀਮਾਂ ਜੋ ਅਗਲੇ ਦਹਾਕੇ ਵਿੱਚ ਵਧਣ-ਫੁੱਲਣਗੀਆਂ, ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਉਹ ਸਭ ਤੋਂ ਵੱਧ ਇੰਜੀਨੀਅਰ ਜਾਂ ਸਭ ਤੋਂ ਵੱਡੇ ਬਜਟ ਵਾਲੀਆਂ ਹੋਣ। ਉਹ ਉਹ ਹਨ ਜੋ ਆਪਣੇ ਖੁਦ ਦੇ ਡੇਟਾ ਨੂੰ ਸੁਣਨਾ ਸਿੱਖਦੇ ਹਨ — ਇਸ ਦੇ ਟੈਰਾਬਾਈਟ ਸਮੇਤ ਉਹ ਸੁੱਟ ਰਹੇ ਹਨ। ਤੁਹਾਡੇ CI ਲੌਗਸ ਗੱਲ ਕਰ ਰਹੇ ਹਨ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਉਹ ਸੁਣਨ ਲਈ ਤਿਆਰ ਹੋ ਜੋ ਉਨ੍ਹਾਂ ਦਾ ਕਹਿਣਾ ਹੈ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

ਕੀ LLM ਅਸਲ ਵਿੱਚ CI ਲੌਗਸ ਵਿੱਚ ਉਪਯੋਗੀ ਪੈਟਰਨ ਲੱਭ ਸਕਦੇ ਹਨ?

ਬਿਲਕੁਲ। ਵੱਡੇ ਭਾਸ਼ਾ ਦੇ ਮਾਡਲ ਵਿਸ਼ਾਲ ਗੈਰ-ਸੰਗਠਿਤ ਟੈਕਸਟ ਵਿੱਚ ਆਵਰਤੀ ਪੈਟਰਨਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਵਿੱਚ ਉੱਤਮ ਹਨ। ਜਦੋਂ CI ਲੌਗਸ ਦੇ ਟੈਰਾਬਾਈਟ 'ਤੇ ਇਸ਼ਾਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਅਸਫਲਤਾ ਦੇ ਸਬੰਧਾਂ, ਅਸਪਸ਼ਟ ਟੈਸਟਾਂ ਦੇ ਹਸਤਾਖਰਾਂ, ਅਤੇ ਨਿਰਭਰਤਾ ਟਕਰਾਅ ਨੂੰ ਦਰਸਾ ਸਕਦੇ ਹਨ ਜੋ ਮਨੁੱਖੀ ਇੰਜੀਨੀਅਰ ਕਦੇ ਵੀ ਹੱਥੀਂ ਨਹੀਂ ਫੜ ਸਕਦੇ ਹਨ। ਕੁੰਜੀ ਇੰਜੈਸ਼ਨ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਢਾਂਚਾ ਬਣਾਉਣਾ ਹੈ ਤਾਂ ਕਿ ਮਾਡਲ ਕੱਚੇ ਸ਼ੋਰ ਦੀ ਬਜਾਏ ਸਹੀ ਢੰਗ ਨਾਲ ਕੱਟੇ ਹੋਏ, ਪ੍ਰਸੰਗਿਕ ਤੌਰ 'ਤੇ ਅਮੀਰ ਲੌਗ ਹਿੱਸੇ ਪ੍ਰਾਪਤ ਕਰੇ।

ਲੌਗ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਸ ਕਿਸਮ ਦੀਆਂ CI ਅਸਫਲਤਾਵਾਂ ਦਾ ਅਨੁਮਾਨ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ?

LLM-ਸੰਚਾਲਿਤ ਲੌਗ ਵਿਸ਼ਲੇਸ਼ਣ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨਾਲ ਸਬੰਧਤ ਸਮਾਂ ਸਮਾਪਤੀ, ਆਵਰਤੀ ਨਿਰਭਰਤਾ ਰੈਜ਼ੋਲੂਸ਼ਨ ਅਸਫਲਤਾਵਾਂ, ਮੈਮੋਰੀ-ਬਾਉਂਡ ਬਿਲਡ ਕਰੈਸ਼ਾਂ, ਅਤੇ ਖਾਸ ਕੋਡ ਮਾਰਗਾਂ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੇ ਗਏ ਅਸਪਸ਼ਟ ਟੈਸਟਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਹੌਲੀ-ਹੌਲੀ ਰੀਗਰੈਸ਼ਨ ਦੀ ਵੀ ਪਛਾਣ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਬਿਲਡ ਟਾਈਮ ਹੌਲੀ ਹੌਲੀ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਵਧਦਾ ਹੈ। ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਉਤਪਾਦਨ ਦੀਆਂ ਤੈਨਾਤੀਆਂ ਵਿੱਚ ਬਲਾਕਿੰਗ ਘਟਨਾਵਾਂ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਕੈਸਕੇਡਿੰਗ ਅਸਫਲਤਾ ਪੈਟਰਨ ਨੂੰ ਦੋ ਤੋਂ ਤਿੰਨ ਸਪ੍ਰਿੰਟ ਫੜਦੀਆਂ ਹਨ।

ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਕੀਮਤੀ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਕਿੰਨੇ CI ਲੌਗ ਡੇਟਾ ਦੀ ਲੋੜ ਹੈ?

ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ 30 ਤੋਂ 90 ਦਿਨਾਂ ਦੇ ਲਗਾਤਾਰ ਪਾਈਪਲਾਈਨ ਇਤਿਹਾਸ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਬਾਅਦ ਅਰਥਪੂਰਨ ਪੈਟਰਨ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ। ਛੋਟੇ ਡੇਟਾਸੇਟਸ ਸਤਹ-ਪੱਧਰ ਦੀ ਸੂਝ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਪਰ ਅਸਲ ਮੁੱਲ ਹਜ਼ਾਰਾਂ ਬਿਲਡ ਦੌੜਾਂ ਦੇ ਕਰਾਸ-ਰੈਫਰੈਂਸਿੰਗ ਤੋਂ ਆਉਂਦਾ ਹੈ। ਆਪਣੀਆਂ CI ਪਾਈਪਲਾਈਨਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਗੁੰਝਲਦਾਰ ਵਰਕਫਲੋ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ, Mewayz ਵਰਗੇ ਪਲੇਟਫਾਰਮ app.mewayz.com 'ਤੇ ਸੰਚਾਲਨ ਡੇਟਾ ਨੂੰ ਕੇਂਦਰਿਤ ਕਰਨ ਲਈ $19/mo ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ 207 ਏਕੀਕ੍ਰਿਤ ਮੋਡੀਊਲ ਪੇਸ਼ ਕਰਦੇ ਹਨ।

ਕੀ LLM ਨੂੰ CI ਲੌਗ ਫੀਡ ਕਰਨਾ ਇੱਕ ਸੁਰੱਖਿਆ ਜੋਖਮ ਹੈ?

ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਜੇਕਰ ਲਾਪਰਵਾਹੀ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਵੇ। CI ਲੌਗਸ ਵਿੱਚ ਅਕਸਰ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ, API ਕੁੰਜੀਆਂ, ਅੰਦਰੂਨੀ URL, ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਵੇਰਵੇ ਹੁੰਦੇ ਹਨ। ਕਿਸੇ ਵੀ LLM ਦੁਆਰਾ ਲੌਗਸ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਮਜਬੂਤ ਰੀਡੈਕਸ਼ਨ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਭੇਦ, ਪ੍ਰਮਾਣ ਪੱਤਰ, ਅਤੇ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਪਛਾਣਨ ਯੋਗ ਜਾਣਕਾਰੀ ਨੂੰ ਹਟਾ ਦਿੰਦੀਆਂ ਹਨ। ਸਵੈ-ਮੇਜ਼ਬਾਨੀ ਜਾਂ ਆਨ-ਪ੍ਰੀਮਾਈਸ ਮਾਡਲ ਤੈਨਾਤੀਆਂ ਤੀਜੀ-ਧਿਰ ਕਲਾਉਡ-ਅਧਾਰਿਤ ਅਨੁਮਾਨ ਅੰਤਮ ਬਿੰਦੂਆਂ ਨੂੰ ਕੱਚੇ ਲੌਗ ਭੇਜਣ ਦੇ ਮੁਕਾਬਲੇ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾਉਂਦੀਆਂ ਹਨ।