Как да превеждаме дълги документи с локален LLM: разбиване на части и проверки

Хората превеждат документи с локален LLM по една причина: файлът не може да напусне машината им. Локалният модел може да свърши работа, но връща обикновен текст, а не преведен файл, и най-лошите му грешки са тихи. В нашия тест една единствена заявка за откъс от 3179 думи се върна с правилния брой абзаци и ясен сигнал за завършване, но един абзац беше загубил повече от една трета от съдържанието си и беше придобил изречения, които липсват в източника.

Кратък отговор: разделете текста по границите на абзаците на части от около 600 думи, поставете речник на имената и повтарящите се термини в системната инструкция, изключете режима на мислене на модела и сравнете всяка част с изходния абзац по абзац, преди да ѝ се доверите. Всеки от трите начина, по които проведохме теста, се провали някъде и нито един от провалите не даде съобщение за грешка. Очаквайте модел със среден размер на лаптоп да отнеме часове за цяла книга и планирайте да възстановите форматирането сами.

Всичко по-долу идва от едно изпълнение на 23 октомври 2026 г.: Qwen 3.6 27B (Q4_K_M GGUF) в LM Studio 0.4.8 на Apple M4 Max с 64 GB памет, превеждащ началото на Die Verwandlung на Кафка от немски на английски. Тестовият скрипт, резултатите и необработените примери за грешки са свободни за изтегляне, за да можете да го повторите със своя модел.

Кога локалният LLM е правилният инструмент

Изпълнявайте превода локално, когато решението се определя от правилата за документа, а не от удобството:

• клиентски договор, изследователско споразумение или политика на работодателя забранява качването на файла във външна услуга;
• текстът е личен или поверителен и не можете първо да премахнете чувствителните части; или
• трябва да обработите много файлове без разходи за документ и вече притежавате подходящ хардуер.

Ако нито едно от тези условия не е налице, локалният модел обикновено е по-бавният път към по-лош резултат. Отказвате се от три неща, които предоставя услугата за превод на документи: преведен файл в оригиналния формат, модел, по-голям от това, което машината ви може да побере, и работен процес, изграден за последователност в цяла книга. Преди да изберете който и да е от двата пътя, прегледайте контролния списък за поверителност при превод на документи. Той обхваща правото да обработвате файла, минималните работни копия и какво прави услугата с качванията.

„Локален“ също се нуждае от точно значение. Моделът работи на вашия компютър и в нашия тест заявките отиваха само до localhost. Това не ви казва какво приложението около модела записва в дневници, актуализира или докладва. Ако правилата ви изискват доказателство, че нищо не напуска устройството, проверете собствените настройки и политика на средата за изпълнение или го стартирайте на машина без достъп до мрежата.

Какво тествахме

Преведохме първите 19 абзаца на Die Verwandlung (3179 немски думи) от обществено достъпното издание на Project Gutenberg. Литературният немски е подходящ стрес тест: абзаците са дълги, изреченията се вмъкват едно в друго и едни и същи герои и длъжности се повтарят.

И трите изпълнения използваха един и същ модел и настройки: температура 0.2, максимум 12 000 изходни токена и контекстов прозорец от 16 384 токена. Инструкцията изискваше по един английски абзац за всеки немски абзац и нищо друго.

Всяко изпълнение завърши с нормален сигнал за спиране и всяко съдържаше различна тиха грешка. Изпълнение В изпусна и измисли текст. Изпълнение Б преведе текст, който трябваше да бъде пропуснат. Изпълнение А, най-чистото, даде на един герой грешна роля в последната си част.

Грешка 1: Една голяма заявка изпусна част от абзац

Изпълнение В завърши нормално и върна точно 19 абзаца. Проверка на броя абзаци щеше да го приеме. Абзац 6 обаче се върна с 214 думи при изходен текст от 260 думи.

В изходния текст Грегор поглежда часовника, осъзнава, че е изпуснал влака си, и след това обмисля да се обади болен: шефът му щеше да дойде с лекаря от здравната каса, който смята всички за здрави, но мързеливи, и Грегор признава, че всъщност се чувства добре, освен сънливостта и необичайния апетит. Изпълнение В преведе първата част, а после изпусна целия пасаж за болничния ден – 98 от 260-те немски думи в абзаца. На негово място написа, че Грегор „щял да бъде уволнен на момента“, че канцеларският помощник има навик „да вижда във всичко, което му се докладва, повод да се покаже“, и че тази мисъл „предизвикала усмивка на устните му“. Нищо от това не е в немския текст.

Изпълнението на части преведе същия абзац изцяло, с 267 думи.

Една извадка не доказва, че дългите заявки винаги се провалят. Тя показва какво да проверявате: една дълга единична заявка може тихо да компресира или да измисли текст, като същевременно изглежда структурно завършена. Читател, който не знае немски, нямаше да има причина да го забележи.

Грешка 2: Моделът преведе „контекста“, който трябваше да пропусне

Често срещан съвет е да изпращате предишния абзац с всяка част, за да запази моделът нишката. В изпълнение Б го добавихме към съобщението под етикет „Контекст (вече преведен, НЕ превеждай).“

В част 4 моделът все пак го преведе. Частта върна четири абзаца за три изходни абзаца, като първият беше втори превод на последния абзац от част 3. Съединени заедно, книгата щеше да съдържа този абзац два пъти, с различни формулировки всеки път.

Практическото правило: ако изпращате контекст, дръжте го извън текста, който моделът трябва да преведе, дръжте го кратък и проверявайте броя абзаци на всяка част. Ако не можете да проверите, не го включвайте.

Грешка 3: Част, изпратена сама, даде на герой грешна роля

Изпълнение А изпращаше всяка част без глосар и без контекст. За първите пет части това проработи добре: Prokurist стана „главен чиновник“ във всичките 16 места, където се появи. Шестата част беше един-единствен абзац, в който главният чиновник се кара на Грегор през вратата. Разгледан сам, моделът преведе der Prokurist като „търговският пътник“, което е собствената работа на Грегор. Броят абзаци съвпадна и съотношението на дължината беше 1,00, така че нито една от структурните проверки не го забеляза.

В изпълнение Б, което имаше глосара в системната инструкция и предишния абзац като контекст, същият абзац правилно използваше „главен чиновник“. Този тест не може да каже кое от двете го е поправило. Тъй като контекстът също причини грешка 2, глосарът е по-безопасното място за пренасяне на имена и роли от част на част: той е кратък, стои в инструкцията и можете да го проверите механично.

Работният процес, който издържа

1. Първо извлечете чист текст от файла

Локалният LLM превежда текст, не файлове. Конвертирайте документа, преди да започнете:

• DOCX или EPUB: експортирайте в чист текст или Markdown с един абзац на блок, като запазвате заглавията като отделни редове.
• PDF с текстов слой: извлечете текста, след което поправете счупените редове и пренасянето на думи. Нашето ръководство за поправяне на OCR прекъсвания на редове и пренасяне на думи обхваща същото почистване. Конвертор като Docling може да създаде Markdown от PDF и Office файлове.
• Сканиран PDF: първо стартирайте OCR. Ако не сте сигурни дали даден PDF има използваем текст, вижте Извличане на текст от PDF срещу OCR.

Запазете структурата на абзаците непроменена. Всяка следваща проверка зависи от съответствие едно към едно между изходните и преведените абзаци.

2. Изключете режима на мислене и го потвърдете

Много съвременни отворени модели разсъждават, преди да отговорят. При превод това губи време и изходни токени. В нашата настройка тестова заявка от 200 токена изразходва 199 токена за разсъждения и върна празен отговор.

Опитахме три често срещани превключвателя. Добавянето на /no_think към подканата не направи нищо, а chat_template_kwargs с enable_thinking: false също не направи нищо. Изпращането на "reasoning_effort": "none" в заявката изключи разсъжденията: отговорът отчете 0 токена за разсъждения и върна превода директно. Този параметър не е посочен на страницата за чат завършвания на LM Studio, така че го третирайте като поведение, което наблюдавахме във версия 0.4.8 с този модел. Проверявайте броя на reasoning_tokens в собствените си отговори, вместо да се доверявате на който и да е превключвател.

3. Определете размера на контекстния прозорец преди частите

Контекстният прозорец трябва да побере инструкцията, частта и пълния превод. В нашите разделени на части изпълнения немска част от 500 до 670 думи използва около 800 до 1500 входни токена, в зависимост от речника и контекста, и 640 до 870 изходни токена, така че няколко хиляди токена са достатъчни. Единичната заявка от 3179 думи се нуждаеше от 4953 входни токена и 3930 изходни токена.

Ollama задава дължината на контекста по подразбиране според наличната памет: 4k токена под 24 GiB VRAM, 32k от 24 до 48 GiB и 256k при 48 GiB или повече, според документацията за дължина на контекста, проверена на 23 октомври 2026 г. Можете да я увеличите с OLLAMA_CONTEXT_LENGTH. В LM Studio задайте дължината на контекста, когато зареждате модела. Ако част плюс нейният превод не се поберат, изходът може да бъде отрязан.

4. Разделяйте на части по границите на абзаците, около 600 думи

Никога не разделяйте вътре в абзац или изречение. Нашите части бяха с целеви размер 700 думи и завършваха на най-близката граница на абзац, което доведе до шест части от 243 до 667 думи. По-малките части струват малко: изпълнение A отне 10,4 минути срещу 9,5 минути за единичната заявка, а неуспешната част е евтина за повторно изпълнение.

Пазете инструкцията кратка и еднаква за всяка част. Нашата беше: преведете на английски, запазете точно един изходен абзац за всеки входен абзац, разделени с празен ред, и изведете само превода. Добавете речник към същата инструкция: един ред за всяко име, заглавие или повтарящ се термин, във формата Prokurist = chief clerk. Нашето ръководство за създаване на преводачески речник обхваща какво да включите. Кратките части губят околната история и речникът е това, което я пренася.

5. Проверете всяка част, преди да ги съедините

Изпълнете три проверки за всяка част:

1. Брой абзаци. Изходът трябва да има същия брой абзаци като входа. Това улови грешка 2.
2. Съотношение на дължината за абзац. Сравнете броя думи на всеки преведен абзац с неговия източник. Това улови грешка 1, която проверката за брой абзаци пропусна.
3. Термини от речника за абзац. Където се появява изходен термин, неговият изискан превод трябва да се появи същия брой пъти. Това улови грешка 3, която и двете други проверки пропуснаха. Езиците с флексия ще изискват известна преценка тук, защото немски или руски термин променя формата си.

За немска към английска проза абзаците на изпълнение A останаха между 0,98 и 1,17 изходни думи на входна дума. Повреденият абзац на изпълнение C беше 0,82. Задайте свой собствен диапазон, като проверите няколко абзаца, на които имате доверие в вашата езикова двойка; стойностите по подразбиране в нашия скрипт са отправна точка, а не стандарт.

Отбелязаният абзац е мястото, където да четете първо, а не доказателство за грешка. След това прочетете самия превод, особено имена, числа, отрицания и всичко, въз основа на което читателят би предприел действие. Контролният списък за качество при превод на книги обхваща този преглед.

6. Възстановете документа

Моделът връща текст. Заглавия, бележки под линия, таблици, изображения, оформление на страницата и стилове трябва да бъдат възстановени на ръка или с инструмент за конвертиране. За кратък доклад това е дребно. За книга с бележки под линия и таблици може да отнеме повече време от превода.

Колко време отнема цяла книга

Нашето разделено на части изпълнение преведе 3179 думи за 10,4 минути, около 300 думи в минута на тази машина. При тази скорост роман от 90 000 думи би отнел приблизително пет часа генериране, преди проверките и повторните изпълнения. Това е проста аритметика от едно изпълнение, а не бенчмарк. Скоростта се променя с размера на модела, квантуването, хардуера, езиковата двойка и колко друго прави машината.

Файлът на модела беше 17,5 GB на диска, а кешът на контекста и буферите по време на изпълнение изискват памет върху това, така че една машина се нуждае от значително повече свободна памет от размера на файла. По-малък модел ще работи по-бързо и с по-малко памет, обикновено с известна загуба на качество. Тествайте го върху представителна извадка, преди да се ангажирате с цяла книга. Нашето ръководство за най-добрия LLM за превод обяснява как да изградите тази извадка и да сравните моделите справедливо.

Локален LLM или услуга за превод на документи

Ако вашите правила позволяват качване на файла, услугата за документи премахва по-голямата част от работата, описана по-горе. BookTranslator превежда цели PDF, EPUB и DOCX файлове и връща преведен файл, а в своите ЧЗВ се казва, че качените файлове и резултатите от превода не се използват за обучение на AI модели. Това е облачна услуга, така че не е опция, когато файлът трябва да остане на вашата машина. Ако се колебаете между това да стартирате модели сами и да плащате за услуга, колко всъщност струва LLM преводът показва как да планирате бюджета за токени.

Вземете тестовите файлове

Всички файлове са в папката /files/blog/translate-with-local-llm/:

• local_llm_translation_test.py: пълният тест срещу локалния API на LM Studio, с всичките три пускания. Насочете го към друг модел или изходен текст, за да повторите теста.
• check_translation.py: сравнява изходен текст и превод параграф по параграф и отпечатва несъответствия в броя на параграфите, съотношения на дължината извън диапазона и липсващи термини от речника (с --term "Prokurist=chief clerk"). Работи с резултати от всеки инструмент.
• results.csv: всяка заявка с броя параграфи, броя думи, броя токени и времето.
• failure-examples.txt: немският изходен текст и суровият изход на модела за всичките три неуспеха.

Стартирайте check_translation.py с термините от своя речник върху всеки дълъг превод, преди да разчитате на него. Отнема секунди и отбеляза и трите грешки в този тест. Той не може да ви каже дали дадено гладко изречение е грешно, така че отбелязаните абзаци са мястото, откъдето започва четенето ви, а не където свършва.