રેન્ડર ટાઈમ પર PDF પાર્સ કરવાનું બંધ કરો

મોટાભાગના ડેવલપર્સ PDF એક્સટ્રેક્શન ટૂલ્સ ખોટી રીતે બનાવે છે.

તેઓ વિઝ્યુઅલ આઉટપુટ પરથી દસ્તાવેજનું માળખું (structure) અનુમાન લગાવવાનો પ્રયાસ કરે છે. તેઓ પેજને કેનવાસ પર રેન્ડર કરે છે અને પિક્સેલ પોઝિશન જુએ છે. તેઓ કોલમ અથવા ટેબલ શોધવા માટે કોમ્પ્યુટર વિઝનનો ઉપયોગ કરે છે.

આ અભિગમ ઉલટો છે.

PDF માં ઓપરેટર સ્ટ્રીમમાં તમને જરૂરી માળખું પહેલેથી જ હોય છે.

ટેબલ એ માત્ર પિક્સેલ્સનો સમૂહ નથી. તે moveTo, lineTo, અને rectangle જેવા પાથ ઓપરેટર્સનો સમૂહ છે. ઝોન બોર્ડર (Zone boundaries) CTM સ્ટેકમાં એન્કોડ કરેલી હોય છે. જે પહેલેથી જ ત્યાં છે તેને ફરીથી બનાવવા (reconstruct) ની તમારે જરૂર નથી.

વિઝ્યુઅલ હ્યુરિસ્ટિક્સનો ઉપયોગ કરવાનું બંધ કરો. સોર્સ ડેટાનો ઉપયોગ કરો.

મેં અગાઉ બાઉન્ડિંગ બોક્સ માટે De Casteljau subdivision નો ઉપયોગ કરવાનો પ્રયાસ કર્યો હતો. મેં ટેસ્ટિંગ દરમિયાન તેને નકારી કાઢ્યું હતું.

De Casteljau એ સબડિવિઝન અલ્ગોરિધમ છે. તમે સેગમેન્ટ્સ પૂરતા નાના થાય ત્યાં સુધી કર્વ્સને વિભાજિત કરો છો. આ રેન્ડરિંગ માટે કામ કરે છે, પરંતુ બાઉન્ડિંગ બોક્સ માટે તે ખરાબ છે.

તમારે ટોલરન્સ (tolerance) પસંદ કરવો પડે છે. જો ટોલરન્સ બહુ વધારે હોય, તો બોક્સ ખોટું પડે છે. જો તે બહુ ઓછું હોય, તો તમે રિકર્ઝન (recursion) પર સંસાધનો વેડફી નાખો છો. એક વધુ સારો રસ્તો છે. ક્વોડ્રેટિક ફોર્મ્યુલાનો ઉપયોગ કરીને એનાલિટિકલ સોલ્યુશન ચોક્કસ હોય છે. તે રિકર્ઝન કરતું નથી. તે સેગમેન્ટ્સ ફાળવતું નથી.

આ જ તર્ક ઝોન ડિટેક્શન (zone detection) ને પણ લાગુ પડે છે.

ઘણા ટૂલ્સ બે ટેક્સ્ટ ગ્રુપ વચ્ચેના મધ્યબિંદુને શોધીને ઝોન બોર્ડરની ગણતરી કરે છે. આ એક વિઝ્યુઅલ અનુમાન છે. તે સ્ટ્રક્ચરલ નથી.

જો તમે મધ્યબિંદુઓનો ઉપયોગ કરો છો, તો સબ-પિક્સેલ રાઉન્ડિંગ રિજીયન્સને ખોટા ઝોનમાં મૂકી દેશે.

તેનો ઉકેલ સરળ છે. બાઉન્ડિંગ બોક્સની ઉપરની ધાર (top edge) નો ઉપયોગ કરો. રિજીયન ક્યાંથી શરૂ થાય છે તેના આધારે તે ઝોનનો ભાગ બને છે. ઉપરની ધારના વાસ્તવિક Y-કોઓર્ડિનેટનો ઉપયોગ કરો.

અસલી PDF એક્સટ્રેક્ટર બનાવવું વધુ અઘરું છે. તમારે:

• માત્ર ટેક્સ્ટ કન્ટેન્ટને બદલે ઓપરેટર સ્ટ્રીમ વાંચો.
• મેટ્રિક્સ સ્ટેટને ટ્રેક કરવા માટે CTM સ્ટેક બનાવો.
• સબપાથ્સને ભૌમિતિક રીતે (geometrically) વર્ગીકૃત કરો.
• Provenance સાથે સેગમેન્ટ્સ એમિટ કરો.

આ પિક્સેલ-આધારિત અનુમાન કરતા વધુ કામ છે. પરંતુ તે નિશ્ચિત (deterministic) પરિણામો આપે છે.

પિક્સેલ-આધારિત ટૂલ 100% ઝૂમ પર અલગ પરિણામો આપે છે અને 150% ઝૂમ પર અલગ. તે વિઝ્યુઅલ આર્ટિફેક્ટ્સનું પેટર્ન-મેચિંગ કરે છે, સ્ટ્રક્ચર એક્સટ્રેક્ટ નથી કરતું.

જો તમે ઓપરેટર સ્ટ્રીમ પાર્સ નથી કરતા, તો તમે માત્ર એક ડેમો બનાવી રહ્યા છો. તે તમારી ટેસ્ટ ફાઇલો પર કામ કરી શકે છે, પરંતુ વાસ્તવિક યુઝર અપલોડ્સ પર તે નિષ્ફળ જશે.

ઓપરેટર સ્ટ્રીમ દ્વારા જવાનો માર્ગ મુશ્કેલ છે. તમારે fill અને stroke સ્ટેટ મશીન અને PDF સ્પેસિફિકેશન સમજવું પડશે. પરંતુ તમારે તે ફક્ત એક જ વાર શીખવું પડશે. પછી તે દરેક PDF માટે કામ કરશે.

રેન્ડર-ટાઇમ પર PDF પાર્સ કરવાનું બંધ કરો: સ્ટ્રક્ચર્ડ એક્સટ્રેક્શન માટે એક બહેતર આર્કિટેક્ચર

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

નેઇવ (Naive) અભિગમ

ઘણી એપ્લિકેશનો PDF ને ત્યારે પાર્સ કરે છે જ્યારે તેને ડિસ્પ્લે કરવાની જરૂર હોય છે. આને "રેન્ડર-ટાઇમ પાર્સિંગ" કહેવામાં આવે છે. આ પ્રક્રિયા આ મુજબ દેખાય છે:

1. વપરાશકર્તા ડેટા માટે વિનંતી કરે છે.
2. એપ્લિકેશન PDF ફાઇલ મેળવે છે.
3. એપ્લિકેશન PDF ને પાર્સ કરે છે અને ડેટા કાઢે છે.
4. એપ્લિકેશન ડેટાને વપરાશકર્તાને બતાવે છે.

નેઇવ અભિગમ સાથેની સમસ્યાઓ

1. લેટન્સી (Latency) જ્યારે વપરાશકર્તા ડેટા માંગે છે, ત્યારે તેમને પાર્સિંગ પ્રક્રિયા પૂર્ણ થવાની રાહ જોવી પડે છે. જો PDF મોટી હોય અથવા LLM નો ઉપયોગ કરવામાં આવતો હોય, તો આ પ્રક્રિયા સેકન્ડો અથવા મિનિટો લઈ શકે છે, જે વપરાશકર્તાના અનુભવને બગાડે છે.

2. ખર્ચ (Cost) જો તમે ડેટા એક્સટ્રેક્શન માટે LLM (Large Language Models) નો ઉપયોગ કરી રહ્યા હોવ, તો દરેક રેન્ડર વખતે તે મોંઘું પડે છે. જો એક જ PDF ને સો વાર જોવામાં આવે, તો તમારે સો વાર ટોકન્સ માટે ચૂકવણી કરવી પડશે.

3. વિશ્વસનીયતા (Reliability) પાર્સિંગ પ્રક્રિયા નિષ્ફળ જઈ શકે છે. જો રેન્ડર-ટાઇમ પર કોઈ ભૂલ આવે, તો વપરાશકર્તાને ડેટા દેખાશે જ નહીં.

બહેતર અભિગમ: ડિકપલ્ડ એક્સટ્રેક્શન (Decoupled Extraction)

વધુ કાર્યક્ષમ રીત એ છે કે PDF ને તેના ઇન્જેશન (Ingestion) સમયે જ પાર્સ કરી લેવી. આનો અર્થ એ છે કે જ્યારે ફાઇલ સિસ્ટમમાં દાખલ થાય ત્યારે જ ડેટા કાઢી લેવામાં આવે છે, રેન્ડરિંગ સમયે નહીં.

આ આર્કિટેક્ચરમાં પ્રક્રિયા આ મુજબ હોય છે:

1. ઇન્જેશન સ્ટેજ (Ingestion Stage):

   • વપરાશકર્તા PDF અપલોડ કરે છે.
   • એક બેકગ્રાઉન્ડ જોબ (background job) શરૂ થાય છે.
   • PDF માંથી ડેટા કાઢવામાં આવે છે (OCR અથવા અન્ય સાધનો દ્વારા).
   • ડેટાને સ્ટ્રક્ચર્ડ ફોર્મેટ (જેમ કે JSON) માં રૂપાંતરિત કરવામાં આવે છે.
   • આ ડેટાને ડેટાબેઝમાં સંગ્રહિત કરવામાં આવે છે.

2. રેન્ડર સ્ટેજ (Render Stage):

   • જ્યારે વપરાશકર્તા ડેટા માંગે છે, ત્યારે એપ્લિકેશન સીધો ડેટાબેઝમાંથી ડેટા મેળવે છે.
   • કોઈ પાર્સિંગની જરૂર પડતી નથી, તેથી પ્રતિસાદ અત્યંત ઝડપી હોય છે.

તુલનાત્મક વિશ્લેષણ

વિશેષતા	રેન્ડર-ટાઇમ પાર્સિંગ	ઇન્જેશન-ટાઇમ પાર્સિંગ
ઝડપ	ધીમી (વપરાશકર્તાએ રાહ જોવી પડે છે)	અત્યંત ઝડપી (સીધો ડેટાબેઝમાંથી)
ખર્ચ	ઊંચો (દરેક વિનંતી પર ખર્ચ)	ઓછો (ફક્ત એક વાર પ્રોસેસિંગ)
સ્કેલેબિલિટી	ઓછી સ્કેલેબલ	ઉચ્ચ સ્કેલેબલ
જટિલતા	ઓછી (શરૂઆતમાં)	થોડી વધુ (બેકગ્રાઉન્ડ પ્રોસેસિંગ જરૂરી)

નિષ્કર્ષ

જો તમે સ્કેલેબલ, ઝડપી અને ખર્ચ-અસરકારક એપ્લિકેશન બનાવવા માંગતા હોવ, તો PDF પાર્સિંગને રેન્ડરિંગથી અલગ કરો. ડેટાને ઇન્જેશન સમયે જ પ્રોસેસ કરીને તેને સ્ટ્રક્ચર્ડ ફોર્મેટમાં સંગ્રહિત કરો. આનાથી તમે તમારા વપરાશકર્તાઓને શ્રેષ્ઠ અનુભવ આપી શકશો અને તમારા ઇન્ફ્રાસ્ટ્રક્ચરના ખર્ચમાં પણ ઘટાડો કરી શકશો.