blog

LLM yordamida keng ko'lamli texnik hujjatlarni yaratish

NEXTREE.

• 10 min read
LLM yordamida keng ko'lamli texnik hujjatlarni yaratish

"Hujjatni LLM ga berib yuborsam, bir hujjatni tezda olishim mumkin" deb o'ylagan paytdan boshlab, haqiqiy muammo yechimi boshlandi.

Yaqinda ishtirok etgan arxitektura maslahat loyihaida, o'nlab biznes chegaralargacha (Bounded Context) va yuzlab xizmatlarni tartibga solgan yirik xizmat ta'rifnomasini yozishim kerak edi. Kirish materiallari bir nechta varaqdan iborat xizmat katalogi Excel va mavjud tasnif tizimini tartibga solgan 24 betlik Word hujjatidan iborat edi. Maqsad, ushbu materiallardan kelib chiqib, yangi ta'rifnomani bir xil formatdagi Word hujjati shaklida tayyorlash edi.

Dastlab, sodda yondashdim. Materiallarni LLM ga uzatib, "Ushbu tuzilishga hujjat tayyorlasang bo'ladi" deb o'yladim. Ammo haqiqiy natijalar umuman kutganimdek bo'lmagan edi. Birinchi natija 187 betga yetdi va hajmi bilan birga format va tuzilmasi ham foydalanish holatiga kelmaydigan darajada edi.

Ushbu maqolada LLM yordamida yirik texnik hujjatlarni yaratishda duch kelgan ko'payish va format buzilishi muammosini, kirishni bo'lish, tuzilma qayta loyihalash, yaratish vositalarini almashtirish va moslikni tasdiqlash degan to'rt bosqichda hal qilish jarayonini tahlil qildim. Natijada 187 betlik muvaffaqiyatsizlikdan foydalanishga yaroqli 43 betlik oxirgi nusxaga o'tish jarayonidagi muammolar va ushbu jarayonda LLM chiqishini kod bilan qanday bog'laganimiz va tasdiqlaganimizni ham muhokama qilaman.

1. Texnologiya tanlash sabablari — Nima uchun 'LLM ga butunlay topshirish' muvaffaqiyatsizlikka uchradi

Birinchi urinish eng sodda usul edi. Kirish materialini to'liq LLM ga yetkazib, kerakli hujjat tuzilmasini tabiiy til bilan tushuntirib, natijani olishga harakat qildim. Ammo bu usul uchta jihatdan cheklovlarni ko'rsatdi.

Birinchisi, hajmning ko'payishi edi. Birinchi natija (v1) 187 bet edi. Sabablarini texnik tahlil qilsak, LLM har bir xizmatni alohida bo'lim (hedding) tarzida yozganligi uchun edi. Har bir xizmat uchun sarlavha va ta'rif parchalari qo'shilganda, hajm eksponensial darajada oshdi. Inson kutgan narsa "xizmatlarni jadval satrlariga siqish" edi, ammo LLM, aniq nazorat qilinmasa, har bir narsani maksimal darajada kengaytirib yozish tendencyasiga ega edi.

Ikkinchi, formatdagi noaniqlik edi. Jadval uslubi bo'limdan bo'limgacha farqlanib turardi va hedning darajalari beqaror edi, hamda muqova va mazmuni umuman tayyorlanmagan yoki formatga mos kelmagan edi. Hujjatning umumiy nizomiga muvofiq format qonunlari yo'q edi.

Uchinchisi, qayta tiklash yo'qligidir. O'sha material bilan yana so'rov qilsangiz ham, bo'limlar tuzilishi va hajmi har safar o'zgarib turardi. Yirik hujjatlarda bu juda muhim bir narsa edi. Bir marta ko'rib chiqilgandan so'ng, yana yaratilganda tuzilma zahiraga tushadi va ko'rish o'zi ma'nosiz bo'ladi.

Natijada, LLM 'mazmun yaratish texnologiyasi' ekanligini, 'yirik hujjatlarni strukturalash texnologiyasi' emasligini his qildim. Ayniqsa, hajm va formatni LLMning tabiiy til chiqishiga butunlay topshirganda, barqaror natijalar olinmaydi.

Keyinchalik yondashuvni butunlay o'zgartirdim. Ushbu ikkita tarkibni alohida nazorat qilishga qaror qildim.

  • Tuzilma/hajm: Hu jjati qiyofasini (qaysi modullarni jadvalga siqish va qaysilarini bo'limga joylashtirish) inson tomonidan aniq belgilanishi kerak

  • Format/rendiring: jadval uslubi, rang, hedning, muqova va mazmun kabi vizual elementlar kod tomonidan izchil mas'uliyatga olinadi.

Ya'ni, LLM faqat 'nima yoza olish' (mazmun) bilan shug'ullanadi, 'qanday tuzish va chizish' (tuzilma va format) esa inson va kod tomonidan nazorat qilinadi.

2. Tatbiq jarayoni va amalga oshirish

Butun ishlar katta to‘rt bosqichga asoslangan holda o‘tkazildi. Kirishni taqsimlash, tuzilmani qayta loyihalash, yaratuvchi vositalarni almashtirish, moslikni tekshirish. Har bir bosqich alohida tekshirilishi mumkin bo‘lishi uchun ajratildi, muammo paydo bo‘lsa, qaysi bosqichdan kelib chiqayotganini tezda aniqlash imkonini berdi.

2.0 Kirishni taqsimlash — kontekst oynasi chegaralarini hisobga olgan holda BC birliklarini chaqirish

Ishga o‘tishdan oldin, eng avvalo hal qilinishi kerak bo‘lgan masala kirishni uzatish usuli edi. Kirish materiallari o‘nlab biznes chegaralari va yuzlab xizmatlarni o‘z ichiga olganligi sababli, buning barchasini bir vaqtning o‘zida bir chaqiriqqa quyib qo‘yish ikkita muammoni keltirib chiqarishi mumkin edi. Biri token chegarasidan (Kontekst Chekli), ikkinchisi esa uzun kirish ma’lumotlarining o‘rtasidagi axborot yo‘qolishidir (O‘rta Joyda Yo‘qolish).

Shuning uchun kirish materiallarini bir o‘rinda yubormasdan, biznes chegaralari (BC) bo‘yicha bo‘lib, har birini alohida LLMni chaqirish uchun aylantirib ishlatishga qaror qildik. Har bir chaqirish o‘sha BCning xizmatlar ro‘yxati va umumiy tasnif tizimi (qatlamlarni aniqlash va boshqalar) ni kontekst sifatida qabul qilib, faqat o‘sha BCga tegishli hujjat parchalarini yaratishga imkon berdi. Shunday qilib yaratilgan parchalarni oxirida bitta hujjatga birlashtirdik.

Bu usulning foydalari aniq edi. Har bir chaqiruvning kirishi qisqa bo‘lib, axborot yo‘qolishi deyarli bo‘lmadi va muammo paydo bo‘lganda o‘sha BCni qayta yaratish kifoya, butun jarayonni qaytadan tiklashga hojat qolmadi. Katta kirish ma’lumotlari uchun “bir vaqtning o‘zida” emas, “ma’noli birliklarga bo‘lib aylanish” usuli barqaror ekanligini tasdiqladik.

2.1 Tuzilmani qayta loyihalash — 'xizmat = bo‘lim' ni 'xizmat = jadval qatori' ga aylantirish

Hajm ko‘p bo‘lishining bevosita sababi tuzilma edi. Shuning uchun, hujjatning skeletini aniq aniqlashni boshidanoq o‘zgartirdim. Asosiy tamoyil “alohida xizmatlarni alohida bo‘lim sifatida yaratmaslik” edi. O‘rniga bir xil biznes chegarasiga tegishli xizmatlarni bir jadvalga birlashtirib, har bir xizmatni jadvalning qatori sifatida siqib o‘tkazdik.

Buni LLM chaqiruviga aniq cheklovlar bilan belgilang. Oddiygina “soddalashtirib yoz” emas, balki “har bir xizmatni H4 bo‘limida qilmang. Domen jadvalining qatoriga siqib qo‘ying. Biznes chegarasiga o‘rtacha 1.5 sahifadan oshmasin” kabi tuzilmani raqamlar bilan nazorat qildik.

[구조 제약 — 프롬프트에 명시]
1. 개별 서비스를 H4 섹션으로 만들지 말 것 (그러면 180쪽 초과).
   → 서비스는 도메인 표의 '행'으로 압축.
2. 비즈니스 경계(BC)당 평균 1.5쪽, 총 40~45쪽 목표.
3. 문서 골격(헤딩 구조)은 아래 고정 템플릿을 그대로 따를 것.
   - H1 = Part, H2 = 비즈니스 경계, H3 = 하위 섹션

Shu bir o‘zgarish bilan hajm keskin kamaydi. 187 sahifadan 31 sahifagacha (v2) tushdi. “LLMdan hajmni qisqartirishni so‘rash” va “tuzilmani hajm oshmaydigan shaklda katta tuzish” talablarining mutlaqo turli natijalarga olib kelishini tasdiqladik.

2.2 Yaratuvchi vositalarni almashtirish — pandoc asosiy konversiyasining chegaralari

Hajm muammosini hal qilgan v2 (31 sahifa) tuzilma jihatidan to‘g‘ri edi, ammo yana bir muammoga duch keldik. LLM tomonidan yaratilgan markdownni pandoc orqali Wordga aylantirdik, lekin pandocning asosiy uslubi muqova, ro‘yxat, ranglar, jadval dizayni kabi vizual yakunlanishni ta’minlamadi. Mazmun mos bo‘lsa-da, mijozlarga yetkazish mumkin bo‘ladigan hujjat darajasida ko‘rinmaydi.

Shuning uchun, render qilish usulini o‘zgartirdik. Markdownni to‘g‘ridan-to‘g‘ri aylantirish o‘rniga, hujjat tuzilmasini kod yordamida to‘g‘ridan-to‘g‘ri yig‘uvchi docx yaratish kutubxonasidan (docx-js) foydalanishga qaror qildik. Bu orqali muqova, ro‘yxat, sarlavha uslubi, jadval dizayni, ranglar kabi format elementlarini kod darajasida aniq nazorat qilishimiz mumkin edi.

Bu vaqtni LLM chiqishi va kod o‘rtasidagi 'ma’lumot ko‘prigi'ni o‘rganish muhim. LLM tabiatan tabiiy tilni chiqaradigan model bo‘lgani uchun, erkin shakldagi matnni to‘g‘ri qabul qilsa, kod barqaror parselay olmaydi. Shuning uchun, LLMning yakuniy chiqish formatini qat’iy JSON sxemasi bilan kuchli ravishda o‘zgartirdik. Tabiiy til hujjatlarini bevosita yozishga ruxsat bermasdan, oldindan belgilangan sxemaning maydonlarini to‘ldirishga majbur qildik.

// LLM 출력은 자연어가 아니라 이 스키마를 따르는 JSON 으로 강제
{
  "bc": "환자·방문",
  "overview": "환자/encounter/동의 등 ...",
  "coreServices": [
    { "id": "S-001", "name": "환자", "layer": "Data", "owner": "원무" }
  ],
  "events": ["PatientCreated", "EncounterStarted"],
  "kpis": ["환자 등록 정합성", "encounter 완료율"]
}

Kod bu JSONni olib, docx-js obyekti sifatida mexanik ravishda render qildi. Ya’ni LLM “nima yozish”ni JSON maydonlari shakli bilan to‘ldiradi va kod ushbu maydonlarni o‘qib, jadval qatorlari va paragraflarni chizish vazifasini bajaradi. Shunday qilib, chiqish formatini sxemaga o‘rnatgach, LLMning formatni tasodifan o‘zgartirish holatlari yo‘qoldi, va noto‘g‘ri formatdagi javoblar parselash jarayonida darhol filtrlanishi mumkin bo‘ldi.

// 서식의 단일 책임: 스타일 규칙을 코드 한 곳에서만 정의
const doc = new Document({
  styles: {
    default: { document: { run: { font: "Malgun Gothic", size: 20 } } },
    paragraphStyles: [
      { id: "Heading1", run: { size: 32, bold: true }, ... },
      { id: "Heading2", run: { size: 28, bold: true }, ... },
    ],
  },
  sections: [{ children: [/* 표지 → 목차 → 본문 */] }],
});

Vositalarni o‘zgartirishning asosiy maqsadi “mazmun va formatlarni ajratish” edi. LLM tomonidan yaratilgan mazmun (jadval qatorlari ma’lumotlari) hech bir o‘zgarishsiz qoldi, va uni chizish usuli (shrift, rang, chegara) kod tomonidan alohida mas’ullikka berildi. Natijada LLM chiqishi biroz o‘zgarganida ham oxirgi hujjat ko‘rinishi har doim bir xil saqlanib qoldi.

2.3 Format stilizatsiyasi — rang kodlash va jadval dizayni

Oxir-oqibat, o'qish imkoniyatini oshirish maqsadida vizual qoidalarni kodga aks ettirdim. Hujjatda turlicha xususiyatlarga ega bo'lgan bir necha maydonlar aralashganligi sababli, maydonlarga ranglarni alohida belgilab, bir ko'z bilan farqlanishini ta'minladim. Shuningdek, jadval sarlavhasiga fon rangi qo'shib, kesishayotgan qatorlarga soyali (zebra striping) usulini qo'llab, jadvalning o'qish imkoniyatini oshirdim.

[영역별 색상 코딩]
Core 영역    : 딥블루 (#1F4E79)
AI 지원 영역  : 퍼플   (#7030A0)
Analytics    : 그린   (#00875A)
공통(Shared) : 앰버   (#BF8F00)

Barcha format qoidalarini kodning bitta joyiga jamlaganimda, hujjatning butuniga bir xil tarzda qo'llanilib, keyingi tuzatishlar ham bitta joyni o'zgartirish orqali butun hujjatda aks etgan edi. Shunday qilib, tayyorlangan v3 oxirgi nusxasi 43 betdan iborat edi. Hajmi belgilangan doiraga kirdi, qopqoq, mazmuni, ranglar va jadval dizayni bilan jihozlangan, haqiqatan ham etkazib berishga mos keladigan hujjat bo'ldi.

2.4 Muvofiqlikni tekshirish — yo'qotish va halüsinatsiyani o'chirish

Katta hajmdagi yaratishda eng muhim bo'lgan jihat ma'lumotlarning muvofiqligidir. Texnik hujjatlarda yuzlab xizmatlardan birortasining ham yo'qolishi yoki buzilishi (halüsinatsiya) halokatli hisoblanadi. LLM ba'zi elementlarni ma'lumotlarda bo'lmagan holda ishonchli ko'rsatilishi mumkin yoki, aksincha, ayrim elementlarni shunchaki o'chirib qo'yishi mumkin, shuning uchun odam 43 betni birma-bir solishtirishi ishonchli va davom ettiriladigan usul emas edi.

Shuning uchun, quyi bosqichda muvofiqlikni tekshirish skriptini joylashtirdim. Asosiy maqsad oddiy edi. Asl Excelning xizmat ID ro'yxati bilan, LLM tomonidan yaratilgan JSON ma'lumotlaridagi xizmat ID ro'yxatini mexaniki ravishda bir-biriga solishtirish edi. Ikki to'plamning farqini hisoblab, ayni bir ID yoki aslida mavjud bo'lmagan ID (halüsinatsiya) topilsa, tekshirishni muvaffaqiyatsiz deb hisoblardim va keyingi bosqichga o'tishga imkon bermasdim.

source_ids = set(load_ids_from_excel())   # 원본 카탈로그
output_ids = set(s["id"] for bc in result for s in bc["coreServices"])

missing = source_ids - output_ids   # 누락된 서비스
halluc  = output_ids - source_ids   # 원본에 없는 서비스(환각)

assert not missing, f"누락: {missing}"
assert not halluc,  f"환각: {halluc}"

Ushbu tekshirish orqali, ayrim xizmatlar ma'lum BC chaqiruvlarida yo'qolishi yoki kiritilmadi deb noto'g'ri generatsiya qilish holatlari odam ko'rishidan oldin avtomatik tarzda aniqlanadi. Muammo aniqlanganda, faqat o'sha BC ni qaytadan yaratish kifoya bo'lganligi sababli, xarajat ham kam bo'ldi. "Yaratildi" emas, balki "kiritmalar bilan to'g'ri mos ravishda yaratildi"ni ta'minlash bosqichi katta hajmdagi hujjat avtomatlashtirishida albatta zarur ekanligini tasdiqlab oldik.

3. Sinov va xatolardan olingan saboqlar

Ushbu ish bir marta tayyorlanmagan, balki uch marta versiyalar orqali takomillashtirilgan. Har bir versiyadan olingan saboqlarni quyidagicha tizimlash mumkin.

버전   분량     상태       핵심 문제 / 개선
----   ----     ------     -------------------------------
v1     187쪽    실패       서비스마다 별도 섹션 → 분량 폭증
v2      31쪽    분량 OK    구조는 잡힘, 그러나 서식 미흡(pandoc 기본)
v3      43쪽    최종       docx-js로 표지·목차·색상·표 완성

Birinchidan, hajm nazorati yordam so'rash bilan emas, balki tuzilma bilan amalga oshirilishi kerak. LLMdan "qisqa yozishingizni" so'rash orqali 187 betni qisqartira olmadim. "Xizmatlar jadvalning qatorlariga siqiladi" degan tuzilmaviy cheklovni aniq belgilaganda, hajm nazorat ostiga olindi.

Ikkinchidan, 'mazmun to'g'ri' va 'yetkazib berish mumkin' bir-biridan farq qiladi. v2 mazmuni va hajmi jihatidan to'g'ri edi, lekin format chegarasi bo'lmaganligi sababli uni to'g'ridan-to'g'ri yetkazib berish qiyin edi. Pandocdan docx-js ga o'tib, formatni kod orqali nazorat qilganimdan keyin yuqori sifatga erishildi.

Uchinchidan, format bir joyda nazorat qilinishi kerak. Ranglar, jadval va sarlavhalar kabi qoidalarni kontentning turli joylariga tarqatmasdan, render kodiga bir joyda jamlanganida, izchillik saqlanib, tuzatishlar ham osonlashdi.

To'rtinchidan, LLM natijalari ishonish emas, balki tekshirishdir. Natijalarni JSON sxemasiga majburlab, kirish bilan ID muvofiqligini avtomaik ravishda solishtirmasak, yo'qotish va halüsinatsiya odamga kashf qilinishigacha hujjatda qolib ketardi. Tekshirishni quyi bosqichda kod orqali o'rnatish ishonchlilikni boshqarib turdi.

4. Amalga oshirish natijalari

Natijada 187 betdan foydalanishga yaramaydigan loyiha, qopqoq, mazmuni, ranglar va jadval dizayni bilan jihozlangan 43 betlik yetkaziladigan hujjatga tayyorlanishi mumkin bo'ldi. Oddiy hajm jihatidan qaraganda, bu 77% ga qisqartirish bo'ldi va eng muhimi, har safar siljigan tuzilma va formatlar barqaror bo'ldi, bu esa eng muhim yutuqdir.

Ish jarayoniga oid o‘zgarishlar ham bo‘ldi. Dastlab LLM chiqindilarini odamlar alohida to‘g‘rilashlari kerak edi, ammo tuzilmani mustahkamlab va formattingni kod orqali nazorat qila boshlaganimizdan so‘ng, bir xil turdagi hujjatlarni takroriy yaratishda odamlar ishtiroki sezilarli darajada kamaydi. Kirish materiallari yangilanganida, bir xil quvur liniyasi orqali qayta yaratilishi mumkin bo‘lgani uchun, saqlash xarajatlari ham pasaydi.

5. Cheklovlar va kelajak rejalari

Ushbu ish orqali LLM asosidagi keng ko‘lamli hujjat yaratishning asosiy skeleti yetarlicha tasdiqlandi. Biroq, yaxshilanishi kerak bo‘lgan joylar ham aniq.

Birinchidan, hozirda tuzilma cheklovlari va format qoidalarini odamlar to‘g‘ridan-to‘g‘ri belgilamoqdalar. Kelajakda kirish materiallarining hajmini ko‘rib, mos miqdor va siqish darajasini avtomatik tarzda taklif qiladigan bosqich bo‘lsa, yanada samarali bo‘lishi mumkin deb hisoblaymiz.

Ikkinchidan, agar kirish materiallari jadval (Excel) shaklida bo‘lsa, yaxshi ishladi, lekin noaniq hujjatlarni kirish sifatida olganda, avval tuzilmani chiqarish uchun oldindan ishlov berish kerak. Ushbu qismda oldin tayyorlangan hujjat rejasi tahlil qilish tajribasini birlashtirsak, "noaniq hujjatlarni o‘qib tuzilmani tushunish va yangi ta'rifnoma bilan qayta tuzish" jarayonini kengaytirishga umid qilmoqdamiz.

Ushbu tajribani o‘tkazganimda, shunchaki "AI yaxshi yozish" bilan ish faoliyatida foydalanish mumkin bo‘lgan keng ko‘lamli natijalar chiqmasligini to‘g‘ridan-to‘g‘ri his qildim. Nihoyat, muhim narsa "mazmunni yaratish" emas, balki "tuzilmani odam nazorat qiladi, formattingni kod mas'uliyatini oladi va natijalarni tekshiradi" ekanligini yana bir bor tasdiqlash imkonini berdi.

Qo‘llanma

Junny

Site footer