ਤੁਸੀਂ ਇੱਕ ਅੰਦਰੂਨੀ ਟੂਲ ਬਣਾਇਆ ਹੈ ਜੋ ਇੱਕ ਟੀਮ ਨੂੰ ਮਾਡਲ ਦੀ API ਨੂੰ ਕਦੇ ਵੀ ਕਾਲ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ LLM-ਅਧਾਰਿਤ ਫੀਚਰ 'ਤੇ 28 ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਮਾਡਲ ਨੂੰ ਇੱਕ ਫੇਕ ਕਰਨਯੋਗ ਇੰਟਰਫੇਸ (fakeable interface) ਵਿੱਚ ਲਪੇਟ ਕੇ ਅਤੇ ਤਿੰਨ ਪਰਤਾਂ—ਨਿਰਧਾਰਤ (deterministic), ਹਿਊਰਿਸਟਿਕ (heuristic) ਅਤੇ LLM-ਅਧਾਰਿਤ ਮੁਲਾਂਕਣ (evaluation)—ਜੋੜ ਕੇ ਕੀਤਾ ਹੈ।

ਸਟੈਂਡਰਡ ਅਸਰਸ਼ਨਾਂ (Standard assertions) ਉਸੇ ਪਲ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ LLM ਗੱਦ (prose) ਤਿਆਰ ਕਰਦਾ ਹੈ। ਉਹੀ ਪ੍ਰੋਂਪਟ ਹਰ ਵਾਰ ਚਲਾਉਣ 'ਤੇ ਵੱਖਰਾ ਵਾਕ ਦੇ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ assertEqual(output, expected) ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਭਾਵੇਂ ਮਾਡਲ ਨੇ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕੀਤਾ ਹੋਵੇ। ਜ਼ਿਆਦਾਤਰ ਇੰਜੀਨੀਅਰਿੰਗ ਗਰੁੱਪ ਜਾਂ ਤਾਂ ਬਿਨਾਂ ਕਿਸੇ ਤਸਦੀਕ ਦੇ ਫੀਚਰ ਸ਼ਿਪ ਕਰ ਦਿੰਦੇ ਹਨ ਜਾਂ ਫਿਰ ਮਾਡਲ ਨੂੰ ਖੁਦ ਟੈਸਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਲਗਾਤਾਰ ਬਦਲਦੇ ਨਿਸ਼ਾਨੇ ਨੂੰ ਇੱਕ ਸਟੈਟਿਕ ਲਾਇਬ੍ਰੇਰੀ (static library) ਵਾਂਗ ਮੰਨਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ।

ਇਹ ਸਮੱਸਿਆ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

LLMs ਹੁਣ ਗਾਹਕਾਂ ਨਾਲ ਜੁੜੇ ਵਰਕਫਲੋ (customer-facing workflows)—ਜਿਵੇਂ ਕਿ ਈਮੇਲ ਆਊਟਰੀਚ, ਸਪੋਰਟ ਜਵਾਬ, ਅਤੇ ਕੰਟੈਂਟ ਜਨਰੇਸ਼ਨ—ਦੇ ਅੰਦਰ ਹਨ। ਇੱਕ ਇਕ ਭਰਮ ਵਾਲਾ ਤੱਥ (hallucinated fact) ਜਾਂ ਲੀਕ ਹੋਇਆ ਆਈਡੈਂਟੀਫਾਇਰ (leaked identifier) ਬ੍ਰਾਂਡ ਦੀ ਸਾਖ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ, ਨਿੱਜੀ ਡੇਟਾ ਨੂੰ ਪ੍ਰਗਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਕੰਪਲਾਇੰਸ ਉਲੰਘਣਾਵਾਂ (compliance violations) ਨੂੰ ਜਨਮ ਦੇ ਸਕਦਾ ਹੈ। ਇੱਕ ਭਰੋਸੇਯੋਗ ਟੈਸਟ ਰਣਨੀਤੀ ਤੋਂ ਬਿਨਾਂ, ਟੀਮਾਂ ਅਸਥਿਰ ਫੇਲ੍ਹਰਾਂ (flaky failures) ਦਾ ਪਿੱਛਾ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ ਜਾਂ ਅਜਿਹੇ ਬੱਗ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਹੀ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ।

ਪਹੁੰਚ: ਮਾਡਲ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਘਟਾਓ

ਪਹਿਲਾ ਕਦਮ ਇਹ ਸੀ ਕਿ LLM ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ ਉਸ ਨੂੰ ਸੀਮਤ ਕੀਤਾ ਜਾਵੇ। ਲੇਖਕ ਦੇ ਸਿਸਟਮ ਵਿੱਚ, ਮਾਡਲ ਸਿਰਫ ਆਊਟਰੀਚ ਮੈਸੇਜ ਦਾ ਡਰਾਫਟ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਸਾਰੀ ਰੂਟਿੰਗ ਲੌਜਿਕ (routing logic), ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ (state management) ਅਤੇ ਸੇਫਟੀ ਚੈੱਕ ਆਮ ਕੋਡ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। ਮਾਡਲ ਨੂੰ ਇੱਕ ਸਿੰਗਲ, well-defined ਆਉਟਪੁੱਟ ਤੱਕ ਸੀਮਤ ਕਰਕੇ, ਆਲੇ-ਦੁਆਲੇ ਦਾ ਸਿਸਟਮ ਨਿਰਧਾਰਤ (deterministic) ਅਤੇ ਟੈਸਟ ਕਰਨ ਯੋਗ ਰਹਿੰਦਾ ਹੈ।

ਇਸ ਨੂੰ ਸੰਭਵ ਬਣਾਉਣ ਲਈ, LLM ਇੱਕ ਪ੍ਰੋਵਾਈਡਰ ਇੰਟਰਫੇਸ (provider interface) ਦੇ ਪਿੱਛੇ ਹੁੰਦਾ ਹੈ, ਜੋ ਟੈਸਟਾਂ ਵਿੱਚ ਇੱਕ ਫੇਕ ਵਰਜ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ, ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਬਾਹਰੀ API ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ; ਟੈਸਟ ਸੂਟ ਵਿੱਚ, ਇੱਕ ਹਲਕਾ ਫੇਕ (lightweight fake) ਇੱਕ ਤਿਆਰ ਕੀਤਾ ਹੋਇਆ ਜਵਾਬ (canned response) ਵਾਪਸ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਬਾਕੀ ਕੋਡ ਸਿਰਫ ਇੰਟਰਫੇਸ ਨਾਲ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ਪੂਰੇ ਵਰਕਫਲੋ ਨੂੰ ਯੂਨਿਟ ਟੈਸਟਾਂ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਕਦੇ ਵੀ ਨੈੱਟਵਰਕ ਨੂੰ ਛੂਹਦੇ ਨਹੀਂ ਹਨ। ਨਤੀਜਾ ਇੱਕ ਅਨੁਮਾਨਿਤ ਕੋਰ (predictable core) ਹੈ ਜਿਸਦੀ 28 ਟੈਸਟਾਂ ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਇਮਾਨਦਾਰ ਮੁਲਾਂਕਣ ਹਾਰਨੈਸ

ਸੀਮਤ ਰੇਂਜ ਦੇ ਬਾਵਜੂਦ, ਮਾਡਲ ਦਾ ਆਉਟਪੁੱਟ ਨਾਨ-ਡਿਟਰਮਨਿਸਟਿਕ (nondeterministic) ਰਹਿੰਦਾ ਹੈ। ਇਸ ਲਈ ਲੇਖਕ ਨੇ ਤਿੰਨ-ਪਰਤੀ ਮੁਲਾਂਕਣ ਹਾਰਨੈਸ ਬਣਾਇਆ ਹੈ, ਜਿਸ ਵਿੱਚ ਹਰੇਕ ਪਰਤ ਜੋਖਮ ਦੀ ਇੱਕ ਵੱਖਰੀ ਸ਼੍ਰੇਣੀ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ।

  • ਲੇਅਰ 1 – ਨਿਰਧਾਰਤ (Deterministic) ਚੈੱਕ ਸਧਾਰਨ ਰੈਗੂਲਰ-ਐਕਸਪ੍ਰੈਸ਼ਨ (regular-expression) ਨਿਯਮ ਗਲਤ ਬਿਲਡਿੰਗ ID ਜਾਂ ਵਰਜਿਤ ਟੋਕਨਾਂ ਵਰਗੀਆਂ ਸਪੱਸ਼ਟ ਗਲਤੀਆਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ। ਇਹ ਚੈੱਕ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਬਾਈਨਰੀ pass/fail ਦਿੰਦੇ ਹਨ।

  • ਲੇਅਰ 2 – ਹਿਊਰਿਸਟਿਕ (Heuristic) ਚੈੱਕ ਸਕ੍ਰਿਪਟਾਂ ਭਰਮ ਵਾਲੇ ਨੰਬਰਾਂ ਜਾਂ ਮਿਤੀਆਂ ਦੀ ਭਾਲ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਸਪੱਸ਼ਟ ਤੱਥਾਂ ਦੀ ਘੜਤ ਨੂੰ ਫਲੈਗ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਅਜਿਹੇ ਝੂਠੇ ਦਾਅਵਿਆਂ ਨੂੰ ਮਿਸ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਨੰਬਰਾਂ ਦੇ ਸੰਕੇਤ ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਲੇਖਕ ਖੁੱਲ੍ਹੇਆਮ ਇਸ ਸੀਮਾ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।

  • ਲੇਅਰ 3 – LLM ਜੱਜ (LLM judge) ਇੱਕ ਸੈਕੰਡਰੀ ਮਾਡਲ ਟੋਨ ਅਤੇ ਪੇਸ਼ੇਵਰਤਾ (professionalism) ਨੂੰ ਰੇਟ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਕਦਮ ਇੱਕ ਹੋਰ ਸੰਭਾਵਨਾਤਮਕ ਪ੍ਰਣਾਲੀ (probabilistic system) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਇਸਦੀ ਵਰਤੋਂ ਸਿਰਫ ਵਿਅਕਤੀਗਤ ਪਹਿਲੂਆਂ (subjective aspects) ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ ਨਿਰਧਾਰਤ ਨਿਯਮ ਅਸੰਭਵ ਹੋਣਗੇ।

ਹਾਰਨੈਸ ਦੀ ਕੁੰਜੀ ਮੁਲਾਂਕਣ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਡੇਟਾ ਸੈੱਟ ਹੈ। ਲੇਖਕ ਨੇ ਜਾਣੇ-ਪਛਾਣੇ ਗਲਤੀ ਦੇ ਪੈਟਰਨਾਂ—ਖਾਸ ਜਾਲ ਅਤੇ ਡੋਮੇਨ ਗਿਆਨ—ਨੂੰ ਐਨਕੋਡ ਕੀਤਾ ਹੈ ਤਾਂ ਜੋ ਹਾਰਨੈਸ ਬਿਲਕੁਲ ਉਹਨਾਂ ਗਲਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕੇ ਜੋ ਅਸਲ ਵਿੱਚ ਸਾਹਮਣੇ ਆਈਆਂ ਹਨ। ਇਹ ਕੋਈ ਜਾਦੂਈ "catch-all" ਨਹੀਂ ਹੈ ਬਲਕਿ ਇੱਕ ਨਿਸ਼ਾਨਾ ਬਣਾਇਆ ਗਿਆ ਸੁਰੱਖਿਆ ਜਾਲ ਹੈ।

ਟੀਮਾਂ ਲਈ ਇਸਦਾ ਕੀ ਮਤਲ