Длинное окно не значит, что модель прочитала весь файл

В четверг утром в «Севере» на стол легла заявка 184: договор поставки, приложение и переписка с площадкой, всё одним файлом. В поле чата светилось, что окно большое и текст влезет целиком. Сотрудник вставил файл, спросил срок поставки и получил гладкий абзац. Срок он взял из последнего приложения. Условие про приёмку, которое сидело в середине, в ответ не попало.

Цена ошибки здесь не в том, что ответ «немного неполный». Заявку 184 уже переслали снабжению как проверенную. Склад заказал машину на дату из хвоста файла, а пункт о простое в середине никто не увидел. Вечер ушёл на звонки, потому что окно было длинным, а чтение — дырявым.

Окно — это лимит отправки, не обещание прочтения

Окно контекста — лимит, сколько текста можно отправить за один раз. Оно не обещает, что каждый абзац повлиял на ответ. Влезть и быть учтённым — разные вещи.

В «Севере» это спутали на заявке 184. Файл приняли, полоска не ругнулась, и все решили: раз не обрезало, значит прочитано. Обрезка — это отказ принять хвост. Дырка в середине выглядит как обычный уверенный ответ. Как у одного поставщика описан сам лимит, видно в справке об окнах контекста. Это описание механизма, не гарантия внимательности.

Короткий файл тоже можно прочитать криво, если вопрос размыт. Длинный файл добавляет отдельный риск: часть строк физически уехала в запрос и всё равно не попала в ответ. Пока эти два сбоя не различены, команда лечит не то. На заявке 184 лечили «неполноту» новым вопросом «расскажи подробнее», хотя дырка была в середине папки, а не в краткости формулировки.

Середина теряется чаще краёв

Работа Lost in the Middle показала на задачах поиска факта качественную картину: модель чаще держит начало и конец длинного текста и чаще теряет середину. Цифры той работы сюда пересказывать незачем. Вывод один, и его достаточно, чтобы не верить закладке «файл влез».

У заявки 184 папка как раз такая. На первой странице — стороны и предмет. В конце — подпись и крайний срок. В середине — как принимают кабель, если длина бухты не сходится с накладной. Сотрудник спросил «какие риски по сроку». Ответ оперся на конец и на шапку. Середина осталась без пометки, хотя файл был отправлен целиком.

Это не значит, что середина всегда пропадает. Значит, что удача по краям не доказывает чтение середины. Пока вы не спросили факт именно оттуда, вы этого не знаете. В «Севере» после срыва попросили модель «перечитать внимательнее». Тон стал ещё глаже, середина не появилась. Внимательность не включается наречием. Она проверяется фактом, который вы сами спрятали не у края.

Прячьте одну дату в середине и одну в хвосте

Практический тест короткий. Возьмите тот же договор, что пойдёт в работу, не учебный абзац из чужого блога. В середину положите одну дату, которой нет в начале. В последний абзац — другую. Спросите обе одним вопросом.

На заявке 184 в «Севере» так и стоило сделать до звонка на склад. В середине лежала дата готовности склада к приёмке. В последнем абзаце — дата отгрузки с завода. Вопрос звучал бы так: назови обе даты и строку, откуда каждая взята. Если в ответе жива только отгрузка, окно большое, а чтение дырявое. Совпали обе — ещё не приговор «можно не резать». Зато этот файл на этих двух фактах не провалился.

Тест занимает один заход. Иначе на склад приезжает машина в день отгрузки, когда склад ещё закрыт по пункту из середины, и вечер уходит на звонки. Повторите его на втором вопросе, не на тех же датах: спросите имя площадки из середины и имя подписанта из конца. Если снова жив только хвост, паттерн уже ваш, а не случайность одной фразы.

Даты удобны тем, что их трудно примерно угадать из шапки. Сумму и номер пункта лучше не класть в тот же тест, если вы ещё не решили, можно ли этот файл вообще отдавать в чат. Для заявки 184 хватило двух дат, которые и так собирались обсуждать внутри отдела.

Режьте файл и спрашивайте кусок

Что делать, если тест мигнул: резать файл на куски, задавать вопрос к куску, не склеивать десять договоров «на всякий случай». Кусок — это один договор или одно приложение, не «всё, что нашлось в папке к вечеру».

Для заявки 184 хватило трёх кусков: предмет и стороны, условия приёмки, сроки и ответственность. Один и тот же вопрос к каждому куску. Ответ, в котором факта нет, должен так и сказать, а не добирать из соседнего приложения. Сотрудник «Севера» сначала склеил заявку с прошлогодней поставкой «для контекста». Модель уверенно приписала заявке 184 площадку из старого файла. Контекст оказался чужой историей.

Это не поиск по документам. Поиск находит фрагмент и только потом отдаёт его в ответ. Как устроен такой слой, разобрано в гайде нейросеть по вашим документам. Пока у вас нет этого слоя, ручная нарезка честнее, чем один огромный вставленный файл. Нарезка не блестит. Она оставляет на столе три коротких ответа вместо одного гладкого, и это как раз то, что можно сверить глазами.

Просите ответ только по фрагменту

Промпт, который держит дырку на виду, короткий. Он запрещает добирать из общих соображений и из соседних кусков, которых в этом сообщении нет.

В «Севере» его повесили на заявку 184 вторым сообщением, уже после нарезки. Первая версия вопроса была «проанализируй договор». Вторая — с оградой и запретом сглаживать пустоту. Разница видна сразу: во второй версии модель пишет, что условия простоя во фрагменте нет, если вы дали ей только сроки. Пустая строка полезнее выдуманного пункта.

Как собирать такие вопросы, без надежды на длину окна, — в гайде как писать промпты. Длина запроса там не считается добродетелью. Добродетель — чтобы модель могла честно сказать «нет в тексте».

Ответь только по фрагменту ниже. Если факта нет — напиши «во фрагменте нет». Не добирай из других договоров и не сглаживай пустое место правдоподобной датой.

Фрагмент:
[вставьте один кусок заявки, не весь архив]

Вопрос:
[один вопрос, например: какая дата приёмки]

Промпт не читает папку за вас. Он не даёт ответу притвориться, что середина проверена, когда в сообщении середины не было. На заявке 184 его имеет смысл держать в заметке отдела, а не вспоминать после звонка со склада.

Длина не лечит кривой вопрос

Не покупайте более длинное окно, пока короткий кусок уже отвечает криво. Длина не лечит плохой вопрос. Если на одном приложении заявки 184 модель путает сторону поставки и сторону приёмки, более длинная лента добавит шума, а не внимательности.

В «Севере» как раз обсуждали окно подлиннее, когда черновик по одному пункту приёмки уже врал. Сначала починили вопрос: кто спрашивает, что считается ответом, чего делать, если строки нет. Короткий кусок после этого стал попадать. Длинное окно осталось на полке. Покупка длины до этого теста — способ получить ту же дырку в более длинной ленте.

Чего не следует ещё: склеивать «для полноты» переписку, спецификацию и чужой типовой договор. Модель не отличит вашу заявку 184 от типового текста, если вы сами сложили их в одну простыню и спросили «ну что там в целом».

Как сделать за один вечер

1. Возьмите один живой файл, не образец из справки. Для учёбы на своём материале подойдёт заявка вроде 184, если её можно отдать в чат.
2. Отметьте два факта: один в середине, один в последнем абзаце. Даты удобны, потому что их трудно примерно угадать.
3. Спросите оба факта одним сообщением по целому файлу и запишите, что совпало.
4. Разрежьте файл на куски и задайте тот же вопрос к куску, где факт лежит. Сравните ответы.
5. Оставьте в рабочей заметке промпт «во фрагменте нет» и уберите привычку клеить пачку договоров в один заход.

Длинное окно экономит вставку. Оно не заменяет закладку в середине папки. Пока в «Севере» заявка читается кусками и пустой ответ называется пустым, вечер остаётся вашим, а не складом.