મદદનીશ આર્કિટેક્ચર જે કંપનીના ડેટા સાથે વાત કરે છે

નફો:

• એન્ડ-ટુ-એન્ડ એન્ટરપ્રાઇઝ આરએજી સહાયકના ઘટકો અને ડેટા ફ્લોની રચના
• મલ્ટિ-સોર્સ ડેટા (વિકિ, ટિકિટ, પીડીએફ, ડેટાબેઝ) ને એક જ સહાયકમાં જોડવું
• માપનીયતા, કેશીંગ અને લેટન્સી માટે આર્કિટેક્ચરલ નિર્ણયો લો

અગાઉના એકમોમાં, અમે એક પછી એક ભાગો શીખ્યા: એમ્બેડિંગ, વેક્ટર ડેટાબેઝ, ચંકીંગ, પુનઃપ્રાપ્તિ. હવે ચાલો આને જોડીએ અને સહાયકનું એન્ડ-ટુ-એન્ડ આર્કિટેક્ચર બનાવીએ જે તમારી પોતાની કંપનીના ડેટા સાથે વાત કરે છે. ધ્યેય એ છે કે કર્મચારી પૂછે, "અમારી રજા નીતિ શું છે?" એક સિસ્ટમ જ્યાં લોકો પ્રશ્નો પૂછી શકે છે, જવાબો વાસ્તવિક આંતરિક દસ્તાવેજો, ટાંકણો પર આધારિત છે અને બહુવિધ ડેટા સ્ત્રોતોને જોડે છે. આ એકમ સમગ્ર આર્કિટેક્ચર, ડેટા ફ્લો અને ઉત્પાદન સ્તરના નિર્ણયોની પ્રક્રિયા કરે છે.

એન્ડ-ટુ-એન્ડ ઘટકો

કોર્પોરેટ આરએજી સહાયકમાં બે અલગ-અલગ લાઇન હોય છે. ઇન્ડેક્સીંગ લાઇન (ઓફલાઇન) ડેટા તૈયાર કરે છે; ક્વેરી લાઇન (ઓનલાઈન) પ્રશ્નનો જવાબ આપે છે.

ઇન્ડેક્સીંગ લાઇન ઘટકો:

1. કનેક્ટર્સ: કનેક્ટર્સ જે સ્ત્રોતોમાંથી ડેટા ખેંચે છે — વિકી, ટિકિટ સિસ્ટમ, ફાઇલ સ્ટોર, ડેટાબેઝ, ઇમેઇલ.
2. નોર્મલાઇઝેશન: વિવિધ ફોર્મેટ્સ (PDF, HTML, DOCX) ને ક્લીન ટેક્સ્ટમાં કન્વર્ટ કરવું; હેડર/ફૂટર સફાઈ.
3. ચંકીંગ + મેટાડેટા: ચંકીંગ અને ટેગીંગ (સ્રોત, તારીખ, સત્તા).
4. એમ્બેડિંગ + લોડિંગ: વેક્ટર ડેટાબેઝમાં વેક્ટર અને મેટાડેટા લખવા.

ક્વેરી પાઇપલાઇન ઘટકો:

1. ક્વેરી પ્રીપ્રોસેસિંગ: પુનર્લેખન, વિકેન્દ્રીકરણ.
2. પુનઃપ્રાપ્તિ: હાઇબ્રિડ શોધ + મેટાડેટા ફિલ્ટર + ફરીથી રેન્કિંગ.
3. પ્રોમ્પ્ટ બનાવટ: નમૂનામાં સંદર્ભ + પ્રશ્ન + સૂચનાઓ મૂકવી.
4. જનરેશન: મોડેલ + સ્ત્રોતોમાંથી ગ્રાઉન્ડેડ (સંદર્ભિક) જવાબ.
5. પોસ્ટ-પ્રોસેસિંગ: સંદર્ભ ફોર્મેટિંગ, સુરક્ષા તપાસ, લોગિંગ.

ટીપ: ક્વેરી લાઇનથી ઇન્ડેક્સીંગ લાઇનને ભૌતિક રીતે અલગ કરો. અનુક્રમણિકા ધીમી અને સામયિક છે (બેચેસમાં રાતોરાત ચાલે છે); પૂછપરછની લાઇન હળવી અને તાત્કાલિક હોવી જોઈએ. જ્યારે વપરાશકર્તા રાહ જુએ છે ત્યારે બે રેખાઓનું મિશ્રણ ભારે પ્રક્રિયાને દબાણ કરે છે.

ડેટા ફ્લો વિઝ્યુઅલાઈઝ

[ઇન્ડેક્સિંગ - ઑફલાઇન]સંસાધનો → નોર્મલાઇઝ → ચંક+મેટાડેટા → એમ્બેડ → વેક્ટર ડીબી (વિકી, ટિકિટ, પીડીએફ, ડીબી)[QUERY - ઓનલાઇન]વપરાશકર્તા પ્રશ્ન → પ્રી-પ્રોસેસિંગ → પુનઃપ્રાપ્તિ (હાઇબ્રિડ+ફિલ્ટર+રિંક) → પ્રોમ્પ્ટ (સંદર્ભ+પ્રશ્ન+સૂચનાઓ → ઉપયોગ કરો

મલ્ટિ-સોર્સ ડેટાનું સંયોજન

વાસ્તવિક કંપનીઓમાં, જવાબ એક જગ્યાએ અટકતો નથી. "ગ્રાહકને રિફંડ કેવી રીતે આપવું?" પ્રશ્નનો જવાબ મદદ લેખ (પ્રક્રિયા), ટિકિટ ઇતિહાસ (વાસ્તવિક ઉદાહરણો) અને નીતિ PDF (નિયમો) બંનેમાં મળી શકે છે. સહાયકે તે બધાને એક પૂલમાં શોધવું જોઈએ.

નિર્ણાયક મુદ્દો: જ્યારે એક વેક્ટર સ્ટોરમાં સંસાધનોને જોડવામાં આવે છે, ત્યારે દરેક શાર્ડમાં `સ્રોત_ટૂર` મેટાડેટા હોવા જોઈએ. તેથી તમે તે બધાને શોધી શકો છો અને જો જરૂરી હોય તો તેને ફિલ્ટર કરી શકો છો, જેમ કે "ફક્ત સત્તાવાર નીતિઓ લાવો". ઉપરાંત, વિવિધ સ્ત્રોતોમાં વિશ્વસનીયતાના વિવિધ સ્તરો હોય છે: સત્તાવાર નીતિ > મદદ લેખ > કર્મચારીની ટિકિટ નોંધ. તમે રિ-રેન્કિંગ અથવા પ્રોમ્પ્ટમાં આ પ્રાથમિકતાનો ઉલ્લેખ કરી શકો છો.

સ્ત્રોત

સામગ્રી પ્રકાર

વિશ્વાસ

અપડેટ ફ્રીક્વન્સી

નીતિ પીડીએફ

સત્તાવાર નિયમ

ઉચ્ચ

માસિક

મદદ લેખ

પ્રક્રિયા

મધ્યમ-ઉચ્ચ

સાપ્તાહિક

ટિકિટ ઇતિહાસ

વાસ્તવિક નમૂના

મધ્યમ

સતત

વિકી

મિશ્ર/વર્તમાન નોંધ

ચલ

સતત

માપનીયતા, કેશ અને લેટન્સી

ઉત્પાદનમાં ત્રણ મુદ્દાઓ બહાર આવે છે. લેટન્સી: જ્યારે વપરાશકર્તા 2 સેકન્ડથી વધુ રાહ જુએ છે ત્યારે અનુભવ બગડે છે. ઉકેલ: સ્ટ્રીમિંગ સ્વરૂપમાં જવાબ પ્રદર્શિત કરો — મોડેલ લખે છે તેમ તે સ્ક્રીન પર રેડવામાં આવે છે. કેશ: વારંવાર પૂછાતા પ્રશ્નો અને પુનરાવર્તિત સંદર્ભો માટે, કેશ ઝડપ વધારે છે અને ખર્ચ ઘટાડે છે. સ્કેલ: જેમ જેમ વપરાશકર્તા વધે છે તેમ, પુનઃપ્રાપ્તિ અને મોડલ કૉલને આડી રીતે માપવામાં સક્ષમ બનવું જરૂરી છે.

ખર્ચની બાજુએ અંગૂઠાનો નિયમ: સૌથી મોંઘું પગલું સામાન્ય રીતે મોટા મોડલ પર જતા ટોકન્સની સંખ્યા છે. તેથી, ફરીથી રેન્કિંગ દ્વારા સંદર્ભને 4 સારા ભાગોમાં ઘટાડવાથી ગુણવત્તા અને કિંમત બંનેમાં સુધારો થાય છે. સામાન્ય ડિઝાઇન એ સરળ વર્ગીકરણ અથવા રૂટીંગ માટે નાના/ઝડપી મોડલનો અને અંતિમ જવાબ માટે વધુ શક્તિશાળી મોડલ (દા.ત. ક્લાઉડ-ઓપસ-4-8)નો ઉપયોગ કરવાનો છે.

સાવધાન: "એકવાર કરો, ભૂલી જાઓ" તરીકે અનુક્રમણિકા સેટ કરશો નહીં. દસ્તાવેજો બદલવામાં આવે છે, કાઢી નાખવામાં આવે છે, ઉમેરવામાં આવે છે. રી-ઇન્ડેક્સીંગ વ્યૂહરચના સ્થાપિત કરો: બદલાયેલ દસ્તાવેજો શોધો અને ફક્ત તેમના પર જ પુનઃપ્રક્રિયા કરો. વાસી ઇન્ડેક્સ એવો જવાબ આપે છે જે વર્તમાન લાગે છે પણ ખોટો છે.

નબળા આર્કિટેક્ચર / મજબૂત આર્કિટેક્ચર

નબળી (એક સ્ક્રિપ્ટ, બધું મિશ્રિત):

જ્યારે વપરાશકર્તા પૂછે છે: તે સમયે દસ્તાવેજો વાંચો, તેમને કટકા કરો, તેમને એમ્બેડ કરો, તેમને શોધો, તેમને જવાબ આપો. # સમસ્યા: દરેક પ્રશ્ન માટે તમામ અનુક્રમણિકા પુનરાવર્તિત થાય છે; વિલંબની સેકંડ, # કોઈ સ્ત્રોત અલગ નથી, કોઈ ફિલ્ટર નથી, કોઈ તાજું નથી.

શક્તિશાળી (સ્પ્લિટ પાઇપ્સ + મેટાડેટા + કેશ + સ્ટ્રીમિંગ):

અનુક્રમણિકા: બેચ રાત્રે ચાલે છે, બદલાયેલ દસ્તાવેજોને તાજું કરે છે. ક્વેરી: લાઇટવેઇટ લાઇન — પ્રી-પ્રોસેસિંગ → હાઇબ્રિડ રીટ્રીવલ+ફિલ્ટર → રિરેન્ક → પ્રોમ્પ્ટ → મોડેલ (સ્ટ્રીમિંગ) → સંદર્ભ → લોગ. વારંવાર પૂછાતા પ્રશ્નો અને સ્ત્રોત કેશ્ડ છે.

ત્રણ મિની કેસ

કેસ 1 — ગૂંચવણભરી રેખા, ભારે વિલંબ. એક સ્ટાર્ટઅપે એક સ્ક્રિપ્ટ લખી છે જે દરેક પ્રશ્ન સાથે પીડીએફ પર ફરીથી પ્રક્રિયા કરે છે; દરેક જવાબમાં સરેરાશ 11 સેકન્ડનો સમય લાગ્યો. જ્યારે ઇન્ડેક્સીંગ લાઇનને અલગ કરવામાં આવી હતી અને ડેટા અગાઉ વેક્ટર સ્ટોરમાં ટ્રાન્સફર કરવામાં આવ્યો હતો, ત્યારે ક્વેરીનો સમય ઘટીને 1.3 સેકન્ડ થયો હતો અને સ્ટ્રીમિંગ સાથે, "પ્રથમ શબ્દ" 400 ms માં દેખાયો હતો.

કેસ 2 — ઘણા બધા સંસાધનો, ખોટી પ્રાથમિકતા. સહાયક સહાયકે પોલિસી પીડીએફ અને જૂની ટિકિટ નોટોને સમાન વજન આપ્યું; મોડલ કેટલીકવાર સત્તાવાર નિયમ તરીકે બે વર્ષ પહેલાંના કર્મચારીનું ખોટું રેટિંગ રજૂ કરે છે. જ્યારે source_tour મેટાડેટા અને "વિરોધાભાસના કિસ્સામાં સત્તાવાર નીતિ ધ્યાનમાં લો" સૂચનાને પ્રોમ્પ્ટમાં ઉમેરવામાં આવી હતી, ત્યારે ખોટી-અગ્રતાની ભૂલો 89% ઘટાડી હતી.

કેસ 3 - વાસી અનુક્રમણિકા. એચઆર સહાયક એવા ઇન્ડેક્સ સાથે કામ કરી રહ્યો હતો જે 3 મહિના સુધી અપડેટ કરવામાં આવ્યો ન હતો; રજાની નીતિ બદલાઈ ગઈ છે, પણ આસિસ્ટન્ટ જૂના દિવસોની વાત કહેતા હતા. જ્યારે દૈનિક તાજું ઇન્સ્ટોલ કરવામાં આવ્યું હતું, જે બદલાયેલ ફાઇલોને શોધે છે, વર્તમાન-પ્રતિભાવ દર 70% થી વધીને 99% થયો છે.

સામાન્ય ભૂલો

• અનુક્રમણિકા અને ક્વેરી લાઇનનું મિશ્રણ: જ્યારે વપરાશકર્તા રાહ જુએ છે ત્યારે ભારે પ્રક્રિયા કરવામાં આવે છે; વિલંબ ફૂટે છે.
• મેટાડેટામાં સ્ત્રોતનો પ્રકાર ન મૂકવો: કોઈ પ્રાથમિકતા અને ફિલ્ટરિંગ નહીં; અવિશ્વસનીય સ્ત્રોત સત્તાવાર હોવાનું જણાય છે.
• તાજગી વ્યૂહરચના સ્થાપિત કરી નથી: ઇન્ડેક્સ વાસી બની જાય છે; વર્તમાનમાં દેખાતા ખોટા જવાબો ઉત્પન્ન થાય છે.
• સ્ટ્રીમિંગ છોડો: વપરાશકર્તા ખાલી સ્ક્રીન પર જુએ છે; કથિત વિલંબ વધુ બને છે.
• દરેક પગલા પર સૌથી મોટા મોડલનો ઉપયોગ: ખર્ચ બિનજરૂરી રીતે વધે છે; સ્ટીયરિંગને નાના મોડેલ પર છોડી દો.

સારાંશમાં

• કોર્પોરેટ આરએજી આસિસ્ટન્ટ બે અલગ-અલગ લાઈનો ધરાવે છે: ઓફલાઈન ઈન્ડેક્સીંગ અને ઓનલાઈન ક્વેરી; તેમને શારીરિક રીતે અલગ કરો.
• ઇન્ડેક્સીંગ = કનેક્ટર + નોર્મલાઇઝ + ભાગ/મેટાડેટા + એમ્બેડ/અપલોડ; ક્વેરી = પૂર્વ-પ્રક્રિયા + પુનઃપ્રાપ્તિ + પ્રોમ્પ્ટ + જનરેટ + પોસ્ટ-પ્રક્રિયા.
• મલ્ટિ-સોર્સ ડેટાને એક જ રિપોઝીટરીમાં જોડવામાં આવે છે, પરંતુ source_type મેટાડેટા અને ટ્રસ્ટની પ્રાથમિકતા સાચવવામાં આવે છે.
• વિલંબ માટે સ્ટ્રીમિંગ અને કેશ, સંદર્ભ થ્રોટલિંગ અને ખર્ચ માટે મોડેલની પસંદગી મહત્વપૂર્ણ છે.
• ફરીથી અનુક્રમણિકા કર્યા વિના, અનુક્રમણિકા વાસી બની જાય છે; નિયમિતપણે બદલાતા દસ્તાવેજોની પુનઃપ્રક્રિયા કરો.

એપ્લિકેશન કાર્ય

તમારી પોતાની ટીમ માટે સહાયકનો આર્કિટેક્ચરલ ડાયાગ્રામ દોરો. (1) ઓછામાં ઓછા ત્રણ વાસ્તવિક ડેટા સ્ત્રોતોને ઓળખો અને દરેક માટે કનેક્ટરની જરૂરિયાત, અપડેટ ફ્રીક્વન્સી અને ટ્રસ્ટ લેવલ લખો. (2) બોક્સ-એરો ડાયાગ્રામ સાથે ઇન્ડેક્સીંગ અને ક્વેરી લાઇનોને અલગથી દોરો. (3) "હું આ સહાયકમાં લેટન્સી અને ખર્ચ ક્યાં ઘટાડી શકું?" પ્રશ્નના ઓછામાં ઓછા બે નક્કર નિર્ણયો લખો. (4) તમારી તાજગી વ્યૂહરચનાનું એક વાક્યમાં વર્ણન કરો: કયા સંસાધનને ફરીથી અનુક્રમિત કરવામાં આવશે અને કેટલી વાર?

ચેકલિસ્ટ

• [ ] હું અનુક્રમણિકા અને ક્વેરી રેખાઓ અલગથી અને યોગ્ય ઘટકો સાથે દોરી શકું છું.
• [ ] હું source_type અને ટ્રસ્ટ અગ્રતા સાથે બહુ-સ્રોત ડેટાને જોડી શકું છું.
• [ ] હું લેટન્સી માટે સ્ટ્રીમિંગ/કેશ નિર્ણયો લઈ શકું છું અને ખર્ચ માટે મોડેલની પસંદગી કરી શકું છું.
• [ ] હું જાણું છું કે શા માટે રી-ઇન્ડેક્સીંગ વ્યૂહરચના આવશ્યક છે.
• [ ] હું ધ્યાનમાં રાખું છું કે મારા આર્કિટેક્ચરમાં સૌથી મોંઘું પગલું એ સામાન્ય રીતે ટોકન છે જે મોટા મોડેલ પર જાય છે.